Discussion:
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD as a dual boot?
(too old to reply)
Arlen Holder
2018-06-17 02:37:45 UTC
Permalink
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD
as a dual boot?

I tried a half-dozen times, but Ubuntu 18.04 LTS desktop just won't *ask*
to install side-by-side to a new Windows 10 Pro 1803 in a single-HDD
dual-boot arrangement.

Any ideas why the latest Ubuntu desktop won't install side-by-side
next to the latest Windows 10 Pro?

Did I skip a step somehow in the tutorials?
Did the tutorials skip a step?
Or did I find a bug in Ubuntu?

======== everything below is gory detail on that question ==========

The "Try Ubuntu" boots fine but the "Install Ubuntu" will not ask to be
placed side-by-side with Windows 10 Pro no matter how many
times I've tried.

Either I did something wrong - or it's a bug in Ubuntu as I followed the
tutorials below (skipping the "optional" fast-boot disabling step).
<https://www.linuxtechi.com/dual-boot-ubuntu-18-04-lts-with-windows-10/>
<https://linoxide.com/distros/install-ubuntu-18-04-dual-boot-windows-10/.
<https://askubuntu.com/questions/1031993/how-to-install-ubuntu-18-04-alongside-windows-10>
<https://www.techsupportpk.com/2018/05/how-to-install-ubuntu-1804-desktop-dual-boot-with-windows-10.html>
<https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/how-to-install-ubuntu-18-04-alongside-with-windows-10-or-8-in-dual-boot.html>

As usual, I write up the steps ahead of time and print them, so that
I can follow them perfectly, but the actual steps are almost never those
that are documented, so it's either a corner case where I need a different
step, or my first Ubuntu 18.04LTS bug (I seem to have a sad gift for
finding bugs in operating systems).

All I want to do is install Ubuntu side by side with Windows 10 Pro.
I'd be perfectly happy to be told *where* my user error is, so I documented
*every* step so that we can figure out if this is user error or a bug in
Ubuntu setup or a bug in the tutorials.

Here are the steps I performed to install Ubuntu next to Windows 10:
* I put a new HDD in an older HP Pavillion desktop tower
* I created a Windows 10 ISO using the standard media-creation tool method
<https://www.microsoft.com/en-us/software-download/windows10>
* I installed the latest Win10 Pro which automatically activated just fine
* I created the Ubuntu ISO from https://www.ubuntu.com/download/desktop
---------------------------
Checksum information
---------------------------
Name: ubuntu-18.04-desktop-amd64.iso
Size: 1921843200 bytes (1832 MB)
SHA256: A55353D837CBF7BC006CF49EEFF05AE5044E757498E30643A9199B9A25BC9A34
---------------------------
* Note that the Ethernet cable is connected to a rooftop WiFi antenna
* This setup requires a static IP address of 192.168.1.something
* I disconnected all other disks so that the install disk is unambiguous
* Only 1 disk remains which is the terabyte Windows 10 Pro boot disk
* Run the HP F9 Diagnostic test on the CPU, memory, & HDD (all pass)
* Boot to the recently installed Windows 10 Pro 1803 (latest version)
* On Windows, run msinfo32 to figure out if you're using BIOS or EFI
RMBStart > Run > msinfo32
BIOS Mode = Legacy <== this is BIOS <== this is what mine reports
BIOS Mode = UEFI <== this is EFI <== mine does not report this
* Run Disk Management to create space RMBStart > Run > diskmgmt.msc
* Right click on the volume > Shrink Volume
* Enter the amount of space to shrink in MB = 40000 (aka 40GB)
* Mine showed 38.87GB unallocated show up next to C: 892.45GB
* Put the Ubuntu 18.04LTS desktop boot disc in the DVD drive
* Shut down the PC & then turn the power back on
* Press ESC at POST to boot to the boot selection
* Choose to boot off the Ubuntu boot disc in the DVD drive
* Ubuntu Welcome screen asks "Try Ubuntu" or "Install Ubuntu"
* Press "Install Ubuntu" (although it will never work!)
* Accept the English(US) keyboard layout
* Leave the "Updates and other software" at the default
* Note: It doesn't matter *what* options you choose - it fails every time
* At this point, you're *supposed* to get a screen giving you a choice
* You're supposed to be able to install "side by side" with Windows 10
* But this screen only proves an "Installation type" of /dev/sda

That's the bug. Or error.
You can't install Ubuntu side by side with Windows 10 Pro.

* Your only choice is to quit the installation
* At this point, you notice the "wired" Ethernet never connected
* NOTE: There is no way to make that wired connection manually yet anyway
* At this point, the system continues to Ubuntu 18.04 using the DVD
* Once at the Ubuntu desktop, there is an "Install Ubuntu 18.04 LTS" icon
* But first, let's finally manually connect to the "wired" Intenet
* Set IVP4 to 192.168.1.something, 255.255.255.0, 192.168.1.1, 8.8.8.8
* Now, for the first time possible, you're on the Internet (ping google)
* Now you can click "Install Ubuntu 18.04 LTS" but it will never work
* The exact same problem happens where you don't get the side-by-side
choice

This is either a bug in the tutorials (they skipped some steps?),
or this is a bug in Ubuntu (it won't set up a side-by-side installation),
or I am doing a step wrong (or skipping a step that isn't documented).

Any ideas why the latest Ubuntu desktop won't install side-by-side
next to the latest Windows 10 Pro?

===== everything below is gory documentation of the steps =====

Following are forty-nine sequential photos documenting every step in gory
photographic detail because this is either:
a. User error in following the tutorials (maybe I missed a step?)
b. A bug in the tutorials (maybe they skipped a step?)
c. A bug in Ubuntu (maybe they never tested the installation this way?)

<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
Number 32 is missing simply because I misnumbered the photos
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>

In summary, can you offer a suggestion as to why Ubuntu 18.04 does not ask
to install next to Windows 10 Pro single HDD as a dual boot setup?
Jonathan N. Little
2018-06-17 03:33:00 UTC
Permalink
Post by Arlen Holder
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD
as a dual boot?
If your drive is formatted MBR and the Windows 10 install has 4 primary
partitions (Windows will take up 3 and OEM puts some utility partition)
then all 4 primary partitions are taken and all Ubuntu can do is overwrite.
--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Arlen Holder
2018-06-17 04:22:42 UTC
Permalink
Post by Jonathan N. Little
If your drive is formatted MBR and the Windows 10 install has 4 primary
partitions (Windows will take up 3 and OEM puts some utility partition)
then all 4 primary partitions are taken and all Ubuntu can do is overwrite.
Hi Jonathan,

Thanks for that helpful advice, as I admit I'm not all that familiar with
partitioning.

AFAIK, I didn't do *anything* to partition anything other than exactly what
the tutorials said to do (which was to 'Shrink volume' to create a 40000MB
section of that brand new 1 terabyte hard disk drive).
<https://www.linuxtechi.com/dual-boot-ubuntu-18-04-lts-with-windows-10/>
<https://www.techsupportpk.com/2018/05/how-to-install-ubuntu-1804-desktop-dual-boot-with-windows-10.html>
<https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/how-to-install-ubuntu-18-04-alongside-with-windows-10-or-8-in-dual-boot.html>

But maybe there are hidden partitions that Windows or Ubuntu created?
Dunno.

This is the related screenshot from the previous post:
<http://img4.imagetitan.com/img.php?image=18_dualboot06.jpg>

Here is a new screeenshot taken just now of the same setup:
<Loading Image...>

I see no indication of multiple partitions - but - *something* is wrong,
so, every viable avenue needs to be explored - hence I appreciate the help.

To be double clear, the terabyte hard drive is brand spanking new.
* I never formatted it. I never partitioned it.
* I simply installed the Windows 10 ISO on it.
* And then I installed willy-nilly a bunch of software on Windows.
* I haven't even organized Windows yet - as I'm still in the setup phase.
* I just wanted to install dual-boot Ubuntu side by side with Windows.

I've done dual-boot Linux with Windows before where it was never this hard.

I don't understand yet why Ubuntu won't give me the choice of side-by-side
installation with Windows, whether I do it from the start:
<http://img4.imagetitan.com/img.php?image=18_dualboot23.jpg>
Or if I try it after the Ubuntu ISO dvd has booted to itself:
<http://img4.imagetitan.com/img.php?image=18_dualboot42.jpg>

In summary, to answer your question, I only see only one drive with two
partitions, but maybe I'm reading the results wrong as I'm not all that
familiar with partitioning.

I appreciate the help though, as only one of three possibilities exist:
1. I screwed up somewhere, or,
2. The tutorials suck, or,
3. Ubuntu has a bug.
Grant Taylor
2018-06-17 05:27:44 UTC
Permalink
Post by Arlen Holder
Thanks for that helpful advice, as I admit I'm not all that familiar
with partitioning.
;-)
Post by Arlen Holder
AFAIK, I didn't do *anything* to partition anything other than exactly
what the tutorials said to do (which was to 'Shrink volume' to create
a 40000MB section of that brand new 1 terabyte hard disk drive).
That shrinks the existing partition and creates a new partition in the
recently freed space.
Post by Arlen Holder
But maybe there are hidden partitions that Windows or Ubuntu created?
Dunno.
Not in the screenshot that you showed.

It is (or used to be) possible to have ""hidden partitions. They used a
different partition type which caused OSs to not not assign drive
letters to them or show them (by default) in file managers.

I don't know how prevalent this ever was or if it even still works.
Either way, I think that you are not dealing with ""hidden partitions.
Post by Arlen Holder
I see no indication of multiple partitions
Where do you see no indication of multiple partitions? Both of the
screenshots that you linked to are showing two partitions on Disk 0.
Post by Arlen Holder
but - *something* is wrong, so, every viable avenue needs to be explored -
hence I appreciate the help.
Why do you say that something is wrong?
Post by Arlen Holder
To be double clear, the terabyte hard drive is brand spanking new.
* I never formatted it. I never partitioned it.
Yes you did. Indirectly.
Post by Arlen Holder
* I simply installed the Windows 10 ISO on it.
Windows installation took care of partitioning and formatting the drive
on your behalf.
Post by Arlen Holder
* And then I installed willy-nilly a bunch of software on Windows.
* I haven't even organized Windows yet - as I'm still in the setup phase.
* I just wanted to install dual-boot Ubuntu side by side with Windows.
Okay.

Are you booting via BIOS or EFI?
Post by Arlen Holder
I've done dual-boot Linux with Windows before where it was never this hard.
What specifically are you referring to as hard? Creating free space and
creating a new partition?

I remember time (not that long ago) when you couldn't do this without
3rd part utilities.

Save for backing everything up, blowing everything away, and starting
from scratch. But who wants to go there? ;-)
Post by Arlen Holder
I don't understand yet why Ubuntu won't give me the choice of side-by-side
I don't know. I question if the side-by-side feature is included in the
18.04 installer or not.
Post by Arlen Holder
In summary, to answer your question, I only see only one drive with two
partitions, but maybe I'm reading the results wrong as I'm not all that
familiar with partitioning.
That's what I'm seeing too.
Post by Arlen Holder
1. I screwed up somewhere, or,
I'm not reading any indication of that yet.
Post by Arlen Holder
2. The tutorials suck, or,
Meh....
Post by Arlen Holder
3. Ubuntu has a bug.
A non-existent feature is not necessarily a bug.
--
Grant. . . .
unix || die
Arlen Holder
2018-06-17 07:12:18 UTC
Permalink
Post by Grant Taylor
Post by Arlen Holder
I see no indication of multiple partitions
Where do you see no indication of multiple partitions? Both of the
screenshots that you linked to are showing two partitions on Disk 0.
I appreciate the request for clarification where it was my mistake for not
being clear.

Jonathan was suggesting a possible reason that Ubuntu won't install
side-by-side with Windows being "too many" partitions (i.e., more than 4).

To be clear, what I see (and I think you confirmed):
1. There was originally only one partition (after installing Windows).
2. Now there are two (after "Shrinking volume" as per the tutorials).
Post by Grant Taylor
Post by Arlen Holder
but - *something* is wrong, so, every viable avenue needs to be explored -
hence I appreciate the help.
Why do you say that something is wrong?
Well, what I *want* to get Ubuntu to pop up is this choice to:
* Install Ubuntu alongside Windows 10
<Loading Image...>

Some tutorials show it as this question:
* Install Ubuntu alongside Windows Boot Manager
<Loading Image...>

I *never* see that choice no matter how many times I try.
I'm "scared" to OK this prompt though.... maybe the question comes *after*
you OK this prompt?
<http://img4.imagetitan.com/img.php?image=18_dualboot23.jpg>

The only reason I don't OK that prompt is that it seems to be asking to use
the *entire* disk where I want it to be alongside of Windows (not on top of
Windows).
Post by Grant Taylor
Are you booting via BIOS or EFI?
It's an old HP Pavillion tower which, I think, is too old for EFI.

Here's a screenshot from the original post that implies it's "Legacy".
<http://img4.imagetitan.com/img.php?image=18_dualboot05.jpg>
Post by Grant Taylor
Post by Arlen Holder
I've done dual-boot Linux with Windows before where it was never this hard.
What specifically are you referring to as hard? Creating free space and
creating a new partition?
What's hard is that it's seemingly impossible to get Ubuntu to *ask* to
install itself *alongside* Windows 10 like it does in the tutorial:
<Loading Image...>
Post by Grant Taylor
Post by Arlen Holder
I don't understand yet why Ubuntu won't give me the choice of side-by-side
I don't know. I question if the side-by-side feature is included in the
18.04 installer or not.
Thanks for that suggestion. It might just be that Ubuntu *can't* install
side by side with Windows nowadays then, at least with the Desktop ISO from
https://www.ubuntu.com/download/desktop
<http://img4.imagetitan.com/img.php?image=18_dualboot47.jpg>
---------------------------
Checksum information
---------------------------
Name: ubuntu-18.04-desktop-amd64.iso
Size: 1921843200 bytes (1832 MB)
SHA256: A55353D837CBF7BC006CF49EEFF05AE5044E757498E30643A9199B9A25BC9A34

There's no way for me to figure that out except to ask if anyone here has
ever installed Ubuntu side by side with Windows using the default installer
as described in the original post?
Post by Grant Taylor
A non-existent feature is not necessarily a bug.
I would agree with you that if the 64-bit Ubuntu 18.05LTS Desktop ISO can't
install next to Windows 10, then that's not a bug - it's just a non
existent feature.

But is that the case?

I have no way of knowing if my expectation is valid that the 64-bit Ubuntu
18.04 Desktop ISO doesn't have the ability to install alongside Windows.

Has anyone in this newsgroup installed the 64-bit Ubuntu 18.04 Desktop ISO
alongside Windows successfully?

How did you get Ubuntu to *ask* this set of questions?
<Loading Image...>
William Unruh
2018-06-17 13:32:47 UTC
Permalink
Windows 10 tends to install all sorts of partitions-- The main partition, a
swap partition, a recovery partition, and perhaps more.

What dows
fdisk -l /dev/sda
give you
Of if that does not try
fdisk -l and look for the Disk.
Post by Arlen Holder
Post by Grant Taylor
Post by Arlen Holder
I see no indication of multiple partitions
Where do you see no indication of multiple partitions? Both of the
screenshots that you linked to are showing two partitions on Disk 0.
I appreciate the request for clarification where it was my mistake for not
being clear.
Jonathan was suggesting a possible reason that Ubuntu won't install
side-by-side with Windows being "too many" partitions (i.e., more than 4).
1. There was originally only one partition (after installing Windows).
2. Now there are two (after "Shrinking volume" as per the tutorials).
Post by Grant Taylor
Post by Arlen Holder
but - *something* is wrong, so, every viable avenue needs to be explored -
hence I appreciate the help.
Why do you say that something is wrong?
* Install Ubuntu alongside Windows 10
<https://www.linuxtechi.com/wp-content/uploads/2018/05/Install-ubuntu-along-windows10.jpg>
* Install Ubuntu alongside Windows Boot Manager
<https://cdn.itzgeek.com/wp-content/uploads/2018/04/Install-Ubuntu-18.04-Alongside-With-Windows-10-Automatic-Partitioning.png>
I *never* see that choice no matter how many times I try.
I'm "scared" to OK this prompt though.... maybe the question comes *after*
you OK this prompt?
<http://img4.imagetitan.com/img.php?image=18_dualboot23.jpg>
The only reason I don't OK that prompt is that it seems to be asking to use
the *entire* disk where I want it to be alongside of Windows (not on top of
Windows).
Post by Grant Taylor
Are you booting via BIOS or EFI?
It's an old HP Pavillion tower which, I think, is too old for EFI.
Here's a screenshot from the original post that implies it's "Legacy".
<http://img4.imagetitan.com/img.php?image=18_dualboot05.jpg>
Post by Grant Taylor
Post by Arlen Holder
I've done dual-boot Linux with Windows before where it was never this hard.
What specifically are you referring to as hard? Creating free space and
creating a new partition?
What's hard is that it's seemingly impossible to get Ubuntu to *ask* to
<https://4.bp.blogspot.com/-jDA_U7VjD7I/Wuvdthe-gpI/AAAAAAAAQ14/2zbQBhPn8kYy8bUQLHybuhmEdA07ElnmwCLcBGAs/s1600/Ubuntu1804-Dual-Boot-Windows10-7.png>
Post by Grant Taylor
Post by Arlen Holder
I don't understand yet why Ubuntu won't give me the choice of side-by-side
I don't know. I question if the side-by-side feature is included in the
18.04 installer or not.
Thanks for that suggestion. It might just be that Ubuntu *can't* install
side by side with Windows nowadays then, at least with the Desktop ISO from
https://www.ubuntu.com/download/desktop
<http://img4.imagetitan.com/img.php?image=18_dualboot47.jpg>
---------------------------
Checksum information
---------------------------
Name: ubuntu-18.04-desktop-amd64.iso
Size: 1921843200 bytes (1832 MB)
SHA256: A55353D837CBF7BC006CF49EEFF05AE5044E757498E30643A9199B9A25BC9A34
There's no way for me to figure that out except to ask if anyone here has
ever installed Ubuntu side by side with Windows using the default installer
as described in the original post?
Post by Grant Taylor
A non-existent feature is not necessarily a bug.
I would agree with you that if the 64-bit Ubuntu 18.05LTS Desktop ISO can't
install next to Windows 10, then that's not a bug - it's just a non
existent feature.
But is that the case?
I have no way of knowing if my expectation is valid that the 64-bit Ubuntu
18.04 Desktop ISO doesn't have the ability to install alongside Windows.
Has anyone in this newsgroup installed the 64-bit Ubuntu 18.04 Desktop ISO
alongside Windows successfully?
How did you get Ubuntu to *ask* this set of questions?
<https://i.stack.imgur.com/MADNE.png>
Arlen Holder
2018-06-17 21:05:23 UTC
Permalink
Post by William Unruh
Windows 10 tends to install all sorts of partitions-- The main partition, a
swap partition, a recovery partition, and perhaps more.
What dows
fdisk -l /dev/sda
give you
Of if that does not try
fdisk -l and look for the Disk.
I agree with you that, in the past, Windows did install multiple partitions
- but - in this case of the absolute latest of Windows 10 ISOs, it did not
seem to install anything but a single partition of the entire brand new
terabyte HDD.

After booting to the 64bit Ubuntu Desktop 18.04 ISO, I tried both the blkid
and fdisk commands, where only the blkid command worked to any extent.
<>

$ blkid
/dev/sda1: LABEL="Disk1" ... TYPE="ntfs" ...
/dev/sr0: ... LABEL="Ubuntu 18.04 LTS amd64" TYPE="iso9660" ...

I don't see any indication there is anything wrong with the HDD partitions.
I think the tutorials suck in that they seem to have skipped a step.

The step they all seem to have skipped is what should transpire between
this step
<Loading Image...>
and this step
<https://www.linuxtechi.com/wp-content/uploads/2018/05/Install-ubuntu-along-windows10.jpg>
Where the tutorials show them as sequential!
<https://www.linuxtechi.com/dual-boot-ubuntu-18-04-lts-with-windows-10/>

But they are NOT sequential:(
If the tutorials were correct, I'd be done by now.
And I wouldn't be asking this question here, of the Ubuntu experts.
Arlen Holder
2018-06-17 21:11:44 UTC
Permalink
Post by Arlen Holder
After booting to the 64bit Ubuntu Desktop 18.04 ISO, I tried both the blkid
and fdisk commands, where only the blkid command worked to any extent.
<>
$ blkid
/dev/sda1: LABEL="Disk1" ... TYPE="ntfs" ...
/dev/sr0: ... LABEL="Ubuntu 18.04 LTS amd64" TYPE="iso9660" ...
I don't see any indication there is anything wrong with the HDD partitions.
I think the tutorials suck in that they seem to have skipped a step.
I forgot to include the screenshot in the above post.
My apologies for not being complete in my answer.

Here is the missing screenshot:
<Loading Image...>
David W. Hodgins
2018-06-17 05:30:28 UTC
Permalink
Post by Arlen Holder
Thanks for that helpful advice, as I admit I'm not all that familiar with
partitioning.
Given that, be sure to check back here before making any changes. I'd
also strongly advise making a full backup, and make sure you know how
to recover from that backup, before continuing. A mistake in the
partitioning stage can wipe out the windows install, and without a
full backup would require re-installing windows.
Post by Arlen Holder
But maybe there are hidden partitions that Windows or Ubuntu created?
Dunno.
Windows does hide partitions, and some manufacturers create their own
hidden partitions. These are used to effectively re-install windows every
time one of it's updates makes the system un-bootable.

I also don't use Ubuntu. If you can get into a command prompt with it,
the command "blkid /dev/sd*" will show what type of partition table is in
use and which partitions are in use. That's the information that will be
needed for others more familiar with windows to provide advice on how
to proceed.

Regards, Dave Hodgins
--
Change ***@nomail.afraid.org to ***@teksavvy.com for
email replies.
Arlen Holder
2018-06-17 07:13:10 UTC
Permalink
Post by David W. Hodgins
Given that, be sure to check back here before making any changes.
Thanks for that advice.

I actually have 3 separate hard drives in that tower, which was shown in
the first photo from the original post where I disconnected two of them:
<http://img4.imagetitan.com/img.php?image=18_dualboot01.jpg>

I bought a brand new hard drive to start fresh, and all I've done so far is
put Windows 10 and my software DVD on it so there's nothing to back up
since it's just Windows + the software which is easy to recover.
<http://img4.imagetitan.com/img.php?image=18_dualboot04.jpg>

I just want Ubuntu to install "alongside" Windows, where I am not sure what
to say to this prompt, which 'seems' to be asking to install on top of
Windows (but maybe not?????).
<http://img4.imagetitan.com/img.php?image=18_dualboot23.jpg>

The only reason I don't OK that prompt is that it seems to be asking to use
the *entire* disk where I want it to be alongside of Windows (not on top of
Windows).
Post by David W. Hodgins
also strongly advise making a full backup, and make sure you know how
to recover from that backup, before continuing. A mistake in the
partitioning stage can wipe out the windows install, and without a
full backup would require re-installing windows.
Thanks for that advice where all my data is on those two other (currently
disconnected) hard disk drives, so I can "play" with the Windows 10 hard
drive partitions if that's what I must do to get Ubuntu to simply ask this
question:

* Install Ubuntu alongside Windows 10
<https://www.linuxtechi.com/wp-content/uploads/2018/05/Install-ubuntu-along-windows10.jpg>

Some tutorials show it as this question:
* Install Ubuntu alongside Windows Boot Manager
<https://cdn.itzgeek.com/wp-content/uploads/2018/04/Install-Ubuntu-18.04-Alongside-With-Windows-10-Automatic-Partitioning.png>

I *never* see that choice no matter how many times I try.
Post by David W. Hodgins
I also don't use Ubuntu. If you can get into a command prompt with it,
the command "blkid /dev/sd*" will show what type of partition table is in
use and which partitions are in use. That's the information that will be
needed for others more familiar with windows to provide advice on how
to proceed.
I don't yet have Ubuntu installed on the hard drive.

Ubuntu is only on the DVD as a bootable ISO.
<http://img4.imagetitan.com/img.php?image=18_dualboot07.jpg>

When I boot to that bootable ISO and open a terminal window,
I can run the suggested command:
$ blkid
Which reports the one hard drive and the DVD ISO disc:
/dev/sda1: ... LABEL="Disk1" ... TYPE="ntfs"
/dev/sr0: ... LABEL="Ubuntu 18.04 LTS amd64" TYPE="iso9660"
As shown below:
<Loading Image...>

I don't see any indication yet that there is anything wrong with the hard
disk drive (as it's brand spanking new) so I think the problem is:
a. Either the tutorials suck, or,
b. I screwed up something (but Windows 10 boots just fine), or,
c. Ubuntu can't do what the tutorials all say it can do.

I'd be perfectly happy if I could get Ubuntu to pop this form up!
<https://i.stack.imgur.com/MADNE.png>
Carlos E.R.
2018-06-17 08:35:53 UTC
Permalink
Post by Arlen Holder
Post by David W. Hodgins
I also don't use Ubuntu. If you can get into a command prompt with it,
the command "blkid /dev/sd*" will show what type of partition table is in
use and which partitions are in use. That's the information that will be
needed for others more familiar with windows to provide advice on how
to proceed.
I don't yet have Ubuntu installed on the hard drive.
Ubuntu is only on the DVD as a bootable ISO.
<http://img4.imagetitan.com/img.php?image=18_dualboot07.jpg>
When I boot to that bootable ISO and open a terminal window,
$ blkid
/dev/sda1: ... LABEL="Disk1" ... TYPE="ntfs"
/dev/sr0: ... LABEL="Ubuntu 18.04 LTS amd64" TYPE="iso9660"
<http://img4.imagetitan.com/img.php?image=18_dualboot52.jpg>
This is the only important information in that post. Avoid the rest.

According to it, there is a single partition on sda.

I would ask for the output of:

fdisk -l

and please post ONLY that answer.
--
Cheers, Carlos.
Arlen Holder
2018-06-17 21:42:41 UTC
Permalink
Post by Carlos E.R.
fdisk -l
and please post ONLY that answer.
Here is the result of "sudo fdisk -l" where I'm not sure what loops are:
<Loading Image...>

Device = /dev/sda1
Boot = *
Start = 2049
End = 1871601663
Sectors = 1871599616
Size = 892.5G
Id = 7
Type = HPFS/NTFS/exFAT
Carlos E.R.
2018-06-17 22:08:10 UTC
Permalink
Post by Arlen Holder
Post by Carlos E.R.
fdisk -l
and please post ONLY that answer.
<http://img4.imagetitan.com/img.php?image=18_dualboot56.jpg>
Ok, disk is 1 GB unit with plain DOS partition table (ie, not GPT), and
a single partition. No hidden partitions.

Disk has 1953525168 sectors (512 bytes each) and the partition uses
1871599616 sectors, leaving 81925552 sectors unused, which makes 40 GiB.

A small Linux system could be installed.
Post by Arlen Holder
Here is the result from the blkid /dev/sd*
<http://img4.imagetitan.com/img.php?image=18_dualboot54.jpg>
And here is the result from fdisk -luS /dev/sd?
<http://img4.imagetitan.com/img.php?image=18_dualboot55.jpg>
the first one says the disk is a "promise_fasttrack_raid-member", and
someone here said that you would not be able to install on such a disk
without erasing it first.




Really, there is no need to obfuscate the UUID identifiers, those are
not private info, just usually too long to paste into emails.

And obviously, you were supposed to do the commands as root or with
sudo. You should know, if you are going to use ubuntu, that if you get
"permission denied" you must use sudo. No need to post here a photo full
of "permission denied"s.
--
Cheers, Carlos.
Arlen Holder
2018-06-17 22:38:55 UTC
Permalink
Post by Carlos E.R.
the first one says the disk is a "promise_fasttrack_raid-member", and
someone here said that you would not be able to install on such a disk
without erasing it first.
Paul kindly mentioned the RAID situation, where I'm thoroughly confused
since there never was RAID on this system AFAIK but if I press "control f"
at the POST prompt, this raid-related screen does pop up (as noted in the
original post):
<http://img4.imagetitan.com/img.php?image=18_dualboot11.jpg>

Since I'm never going to use the RAID, I would not mind turning that off
(if it's turned on), but AFAIK, the RAID is not enabled.

All I did was buy a new terabyte HDD and install the latest Windows 10 ISO
on it... nothing more ... where I didn't enable or touch any RAID settings
at that time. Then I tried to install Ubuntu.

Given the HDD started out blank, I don't see how this sentence above makes
sense though ... so that's where I'm confused:
"you would not be able to install the disk without erasing it first."

I can erase the disk - but it came erased in the first place.
So I don't see how erasing it would change anything.
Do you?
Post by Carlos E.R.
Really, there is no need to obfuscate the UUID identifiers, those are
not private info, just usually too long to paste into emails.
Thanks. I see I missed a couple anyway ... so whatever they indicate, you
know it by now! :)
Post by Carlos E.R.
And obviously, you were supposed to do the commands as root or with
sudo. You should know, if you are going to use ubuntu, that if you get
"permission denied" you must use sudo. No need to post here a photo full
of "permission denied"s.
I noticed belatedly my "sudo !$" so that was a mistake on my part.
Thanks for reminding me that I need to clean up results before posting.

Back to Paul's suggestions, it seems that the tutorials suck since none of
them even hinted at this problem.

I wasn't sure what Paul was suggesting with the RAID and fastboot, but I
did turn off the supposedly optional "fast boot" option in Windows
(although I should note that *every* boot has been a cold boot with the
power turned off.

I don't know how to turn off the RAID message but AFAIK, I'm not using RAID
(but I did see that "RAID promise" message too).
Carlos E.R.
2018-06-17 23:18:54 UTC
Permalink
Post by Arlen Holder
Post by Carlos E.R.
the first one says the disk is a "promise_fasttrack_raid-member", and
someone here said that you would not be able to install on such a disk
without erasing it first.
Paul kindly mentioned the RAID situation, where I'm thoroughly confused
since there never was RAID on this system AFAIK but if I press "control f"
at the POST prompt, this raid-related screen does pop up (as noted in the
<http://img4.imagetitan.com/img.php?image=18_dualboot11.jpg>
Since I'm never going to use the RAID, I would not mind turning that off
(if it's turned on), but AFAIK, the RAID is not enabled.
All I did was buy a new terabyte HDD and install the latest Windows 10 ISO
on it... nothing more ... where I didn't enable or touch any RAID settings
at that time. Then I tried to install Ubuntu.
It is either your disk or your board. The output is clear, the disk is
seen as a raid member.


Maybe they gave you a used disk. Run this command using Linux:

smartctl -A /dev/sda

and pay attention to the line:

9 Power_On_Hours

There are also Windows programs that get the same info, but I don't know
them.
Post by Arlen Holder
Back to Paul's suggestions, it seems that the tutorials suck since none of
them even hinted at this problem.
Whys should they? Tutorials do not cover abnormal situations. That's
what forums are for.
Post by Arlen Holder
I wasn't sure what Paul was suggesting with the RAID and fastboot, but I
did turn off the supposedly optional "fast boot" option in Windows
(although I should note that *every* boot has been a cold boot with the
power turned off.
Both fast and slow boot start with power fully turned off. Not related.

In windows you can switch off the fast boot feature, and instead have
"hibernate" show up in the menu, so that you can choose "hibernate" or
"power off".
--
Cheers, Carlos.
Arlen Holder
2018-06-18 00:45:21 UTC
Permalink
Post by Carlos E.R.
It is either your disk or your board. The output is clear, the disk is
seen as a raid member.
Thanks for that advice that the RAID controller is the problem where Ubuntu
18.04 doesn't seem to do what Ubuntu 17.04 had no problem doing on the
exact same machine only a short while ago.

I'm *sure* the RAID controller is on the motherboard since this is the
second brand new disk I've put in (previous one was Toshiba, this one is
Western Digital) where I've always done the same thing which is start with
a brand-new disk and let Windows 10 use the entire disk as a single
partition.

Also, this same machine (on the other disk) was previously set up as a dual
boot to Ubuntu 17.04, so, the RAID bug is new with Ubuntu 18.04 (as I don't
recall having this problem when I installed Ubuntu 17.04).

I have a knack for finding bugs, unfortunately.

At the very least, Ubuntu 18.04 should output a barf message.
At the very best, Ubuntu 18.4 should work as Ubuntu 17.04 did on the other
hard drive in this same machine.

My workaround will be two simple steps:
1. See if I can turn off the RAID in the BIOS, or,
2. Just give up on the buggy Ubuntu 18.04 & re-install 17.04 instead
(but I hate Unity so that means installing a desktop separately).
Post by Carlos E.R.
smartctl -A /dev/sda
9 Power_On_Hours
Interesting command. Thank you for that suggestion. It's a brand-new disk
from Fryes, so, here's the interesting results, where I had to install the
command first:
$ sudo apt-get install smartctl
<Loading Image...>

Then I was able to run:
$ sudo smartctl -A /dev/sda
<Loading Image...>

Where the "Power_On_Hours" line revealed:
ID# = 9 Power_On_Hours
Flag = 0x0032
Value = 100
Worst = 100
Thresh = 000
Type = Old_age
Updated = Always
When_Failed = -
Raw_Value = 206

From that, I assume the HDD has 206 hours of power on, which is pretty low
considering I leave the machine powered up all the time continuously.
Post by Carlos E.R.
There are also Windows programs that get the same info, but I don't know
them.
I can boot to the Ubuntu 18.04 ISO just fine so that's ok.
Post by Carlos E.R.
Both fast and slow boot start with power fully turned off. Not related.
I agree with you - where I *always* boot from a cold start whenever
installing an ISO but I disabled the fast-start anyway - just to get that
out of the picture.
Post by Carlos E.R.
In windows you can switch off the fast boot feature, and instead have
"hibernate" show up in the menu, so that you can choose "hibernate" or
"power off".
Thanks for that advice. It's a desktop so "hibernate" isn't all that
useful. I'm perfectly fine with a full shutdown to its cold state.

What I need to figure out how to do is how to get Ubuntu 18.04 to do what
Ubuntu 17.04 did naturally, which is just find the disk and install to that
disk (with or without RAID on the motherboard being an issue).
Arlen Holder
2018-06-18 03:14:32 UTC
Permalink
Post by Arlen Holder
$ sudo apt-get install smartctl
<http://img4.imagetitan.com/img.php?image=18_dualboot57.jpg>
Actually, for the tribal knowledge, that was this command:
$ sudo apt install smartmontools
When it asks for a mail-server configuration, I selected:
No configuration

Then I could run the smartctl command:
$ sudo smartctl -A /dev/sda

I ran the command after turning off RAID in the BIOS (which killed Windwos
boot) where the command showed 2 more hours on the HDD:
Power_On_Hours = 208 (Raw Value)
<http://img4.imagetitan.com/img.php?image=18_dualboot67.jpg>
Carlos E.R.
2018-06-18 10:02:36 UTC
Permalink
Post by Arlen Holder
Post by Arlen Holder
$ sudo apt-get install smartctl
<http://img4.imagetitan.com/img.php?image=18_dualboot57.jpg>
$ sudo apt install smartmontools
No configuration
$ sudo smartctl -A /dev/sda
I ran the command after turning off RAID in the BIOS (which killed Windwos
boot)
This proves that the disk was in raid mode, otherwise nothing would have
changed.
Post by Arlen Holder
Power_On_Hours = 208 (Raw Value)
Sure.

Notice that this command reads directly from the disk. It can order the
disk firmware to do tests, which are performed by the disk without the
computer intervention. Then you call the command to find out the results.

So it is the disk saying how many hours it has run, not the computer.

Changing things on the bios or the operating system or even moving the
disk to another computer doesn't change SMART results.

More info: wikipedia.
--
Cheers, Carlos.
Carlos E.R.
2018-06-18 02:48:16 UTC
Permalink
Post by Arlen Holder
Post by Carlos E.R.
It is either your disk or your board. The output is clear, the disk is
seen as a raid member.
Thanks for that advice that the RAID controller is the problem where Ubuntu
18.04 doesn't seem to do what Ubuntu 17.04 had no problem doing on the
exact same machine only a short while ago.
It doesn't necessarily has to be Ubuntu. Something somewhere changed and
the installer got somewhere unexpected. Hey, this is Linux, you are part
of the community and you test the software and report the bugs :-)

(No, I don't use Ubuntu)
Post by Arlen Holder
Post by Carlos E.R.
smartctl -A /dev/sda
9 Power_On_Hours
Interesting command. Thank you for that suggestion. It's a brand-new disk
from Fryes, so, here's the interesting results, where I had to install the
Yes, it is a very interesting command.
Yes, your disk seems to be about a week old if used 24*7
Post by Arlen Holder
Post by Carlos E.R.
Both fast and slow boot start with power fully turned off. Not related.
I agree with you - where I *always* boot from a cold start whenever
installing an ISO but I disabled the fast-start anyway - just to get that
out of the picture.
Post by Carlos E.R.
In windows you can switch off the fast boot feature, and instead have
"hibernate" show up in the menu, so that you can choose "hibernate" or
"power off".
Thanks for that advice. It's a desktop so "hibernate" isn't all that
useful. I'm perfectly fine with a full shutdown to its cold state.
I always hibernate my desktop everyday when I stop using it. Faster than
boot when having two dozens of apps running in the desktop: everything
is ready in the same state I left it before, files opened et all ready :-)
Post by Arlen Holder
What I need to figure out how to do is how to get Ubuntu 18.04 to do what
Ubuntu 17.04 did naturally, which is just find the disk and install to that
disk (with or without RAID on the motherboard being an issue).
Well, apparently it can not.

There is something raid related on that hard disk, even if you yourself
did not write it. Maybe you can see it by placing the disk in a
different controller. And your new release of Ubuntu sees it and barfs.

Maybe you might be able to create the Linux partitions on another
computer and tell Ubuntu to just use them. But as I said, I don't use
Ubuntu, so I can not help with specifics.
--
Cheers, Carlos.
Paul
2018-06-17 23:34:28 UTC
Permalink
Post by Arlen Holder
Post by Carlos E.R.
the first one says the disk is a "promise_fasttrack_raid-member", and
someone here said that you would not be able to install on such a disk
without erasing it first.
Paul kindly mentioned the RAID situation, where I'm thoroughly confused
since there never was RAID on this system AFAIK but if I press "control f"
at the POST prompt, this raid-related screen does pop up (as noted in the
<http://img4.imagetitan.com/img.php?image=18_dualboot11.jpg>
Promise puts metadata on ALL drives, even JBOD drives.
That was a claim I did not waste time verifying
(the PDC 20378 stayed turned OFF on my P4C800-e Deluxe).

I saw one "funny" with the chip and disk in non-RAID
mode, that caused me to swear off using it. If I moved
the Promise drive to the Intel port, the first partition
would disappear. That was an incentive to stop using
the Promise chip - the policy in my computer room,
is if hardware isn't broadly compatible, I don't use it.
Not being able to move disks between ports on the
same motherboard, meant the Promise got switched off.

This should not be upsetting the Ubuntu installer.
(The JBOD status should not be cause for concern,
it is JBOD after all.) For the most part, the
Promise metadata should be benign in this situation.

AMD licensed Promise RAID code, for usage with SBxxx
Southbridges. That's why the use <ctrl>-F, just
like Promise does. If they're not using Promise-licensed
code, they'll use a different hotkey to signify
that fact.

Turning off the AMD RAID at BIOS level, and setting to AHCI,
should be enough to prevent Promise(AMD) RAID code from loading
at BIOS level.

As for your existing OS install, I haven't a clue
what all these issues mean in terms of driver
choices. Unless a RAID configuration was specified,
for the most part the driver is supposed to be
"AHCI-like".

I think you can fix this. However, I can't give
you even a wild time estimate :-/

Paul
Carlos E.R.
2018-06-18 02:37:14 UTC
Permalink
Post by Paul
Post by Arlen Holder
Post by Carlos E.R.
the first one says the disk is a "promise_fasttrack_raid-member", and
someone here said that you would not be able to install on such a disk
without erasing it first.
Paul kindly mentioned the RAID situation, where I'm thoroughly confused
since there never was RAID on this system AFAIK but if I press "control f"
at the POST prompt, this raid-related screen does pop up (as noted in the
 <http://img4.imagetitan.com/img.php?image=18_dualboot11.jpg>
Promise puts metadata on ALL drives, even JBOD drives.
That was a claim I did not waste time verifying
(the PDC 20378 stayed turned OFF on my P4C800-e Deluxe).
:-(
--
Cheers, Carlos.
Arlen Holder
2018-06-18 03:36:22 UTC
Permalink
Post by Paul
Promise puts metadata on ALL drives, even JBOD drives.
That was a claim I did not waste time verifying
(the PDC 20378 stayed turned OFF on my P4C800-e Deluxe).
:-(
I don't really understand all the "promise" stuff Paul said, but he seems
to be right on everything! (As usual.)

Looking up what JBOD drives are...
<https://en.wikipedia.org/wiki/Non-RAID_drive_architectures>

Oh. OK. "Just a bunch of disks"... well ... ok.
That's how I want it to be (I never wanted RAID in the first place.)

About this "promise" stuff. I bought a Western Digital disk.
I never saw the word "promise" until today.

Googling, I find this description of the "Promise FastTrack FastSwap IDE
Raid Controller: <https://www.anandtech.com/show/264/5>

But I don't have any card on the motherboard other than the Nvidia graphics
card, so, "promise" must be part of the BIOS somehow.

What's amazing is that all the tutorials suck since none of them explain
this issue with RAID poop left on the hard disk drive.
<https://linuxconfig.org/how-to-install-ubuntu-18-04-bionic-beaver>
<https://websiteforstudents.com/how-to-install-ubuntu-18-04-lts-beta-desktop/>

Apparently I'm not the only one running into this Ubuntu 18.04 bug:
<https://askubuntu.com/questions/1029854/raid-set-up-in-ubuntu-18-04>

But the manual on setting up Ubuntu 18.04 with "degraded RAID" is complex:
<https://help.ubuntu.com/lts/serverguide/advanced-installation.html>

At this point, I'm like a deer caught in the headlights.
I'm not sure what do to.

Where am I?
a. I changed the BIOS from RAID to AHCI.
b. Then Windows stopped booting.

Should I just change the BIOS back to RAID?
Paul
2018-06-18 03:55:53 UTC
Permalink
Post by Arlen Holder
Where am I?
a. I changed the BIOS from RAID to AHCI.
b. Then Windows stopped booting.
Should I just change the BIOS back to RAID?
Well, yes.

Paul
Grant Taylor
2018-06-18 04:40:19 UTC
Permalink
Post by Arlen Holder
Where am I?
a. I changed the BIOS from RAID to AHCI.
b. Then Windows stopped booting.
Should I just change the BIOS back to RAID?
I would leave it in AHCI mode and reinstall Windows, using part of the
disk, and then install Linux using the remainder of the disk.
--
Grant. . . .
unix || die
Paul
2018-06-18 04:44:40 UTC
Permalink
Post by Grant Taylor
Post by Arlen Holder
Where am I?
a. I changed the BIOS from RAID to AHCI.
b. Then Windows stopped booting.
Should I just change the BIOS back to RAID?
I would leave it in AHCI mode and reinstall Windows, using part of the
disk, and then install Linux using the remainder of the disk.
It's possible to change it. I've done it before.

Consider it practice, for the time when it matters.

And setting it back to RAID again, would tip it upright.
I've also made mistakes and had to backtrack.

Some of the commands can be issued in offline mode
(which is analogous to chroot, sorta). That shouldn't
be necessary in this case though, as changing the BIOS
back to RAID, will get you back in.

Paul
Arlen Holder
2018-06-18 05:42:59 UTC
Permalink
Post by Paul
It's possible to change it. I've done it before.
Consider it practice, for the time when it matters.
And setting it back to RAID again, would tip it upright.
I've also made mistakes and had to backtrack.
Some of the commands can be issued in offline mode
(which is analogous to chroot, sorta). That shouldn't
be necessary in this case though, as changing the BIOS
back to RAID, will get you back in.
Paul
Hi Paul,
Do I describe the problem correctly below?

1. I had the BIOS set to RAID (whether I knew it or not).
2. Hence, some RAID dung was left on the Windows boot disk.
3. When the Ubuntu installer sees that RAID dung, it craps out.
4. All I've accomplished, at the moment, is to switch to AHCI.
5. But the RAID dung is *still* imprinted on the Windows hard drive.

So....

My only viable option is to re-install Windows on the HDD.
That's OK.
(I've had three bricked Windows in this desktop in the past month.)

But do I need to format the HDD first before re-installing Windows?
Or can I just install Windows on it again, without re-formatting?
Paul
2018-06-18 06:39:23 UTC
Permalink
Post by Arlen Holder
Post by Paul
It's possible to change it. I've done it before.
Consider it practice, for the time when it matters.
And setting it back to RAID again, would tip it upright.
I've also made mistakes and had to backtrack.
Some of the commands can be issued in offline mode
(which is analogous to chroot, sorta). That shouldn't
be necessary in this case though, as changing the BIOS
back to RAID, will get you back in.
Paul
Hi Paul,
Do I describe the problem correctly below?
1. I had the BIOS set to RAID (whether I knew it or not).
2. Hence, some RAID dung was left on the Windows boot disk.
3. When the Ubuntu installer sees that RAID dung, it craps out.
4. All I've accomplished, at the moment, is to switch to AHCI.
5. But the RAID dung is *still* imprinted on the Windows hard drive.
So....
My only viable option is to re-install Windows on the HDD.
That's OK.
(I've had three bricked Windows in this desktop in the past month.)
But do I need to format the HDD first before re-installing Windows?
Or can I just install Windows on it again, without re-formatting?
That's more or less it, as I see it.

I just don't understand what "offensive" info could be
in that metadata.

A Secure Erase would be one way to clean the
disk before reinstalling Win10 (in AHCI mode).

You can boot the Win10 DVD and use diskpart from the
Command Prompt (in the troubleshooting section).

diskpart
list disk
select disk 0
clean all
(... several hours pass)
exit

then reboot and start the Win10 install.
After that, resize as desired and start the
Ubuntu install. Cross fingers.

Paul
Arlen Holder
2018-06-18 07:09:13 UTC
Permalink
Post by Paul
I just don't understand what "offensive" info could be
in that metadata.
A Secure Erase would be one way to clean the
disk before reinstalling Win10 (in AHCI mode).
You can boot the Win10 DVD and use diskpart from the
Command Prompt (in the troubleshooting section).
diskpart
list disk
select disk 0
clean all
(... several hours pass)
exit
then reboot and start the Win10 install.
After that, resize as desired and start the
Ubuntu install. Cross fingers.
Paul
Hi Paul,
Thanks for all your help and patience.

I think the main focus now is simply to remove the RAID dung that is stuck
to the hard drive.

To try to remove the RAID dung stuck to the hard drive, I'm running the
suggested diskpart stuff.... I will report back when done.

Since I'm unfamiliar with the commands, I appreciate that you wrote them
for me.
a. diskpart
b. list disk
c. select disk 0
d. clean all

I just ran them and am waiting for the "clean all" to complete.
<Loading Image...>
Arlen Holder
2018-06-18 06:50:53 UTC
Permalink
Post by Arlen Holder
But do I need to format the HDD first before re-installing Windows?
Or can I just install Windows on it again, without re-formatting?
I decided to move forward and booted to a Windows 10 ISO to take a look at
the hard disk drive that has the RAID dung stuck to it.
<Loading Image...>

I deleted the partitions one by one as I fumbled about:
<Loading Image...>

Then I installed Windows 10 all over again:
<Loading Image...>

Then I looked at the disk partitions that Windows did by default:
<Loading Image...>

I tried the "Shrink volume" command again:
<Loading Image...>

I made it 40000 MB as the tutorials suggested:
<Loading Image...>

Now I had my three partitions (2 for Windows, 1 for Linux):
<Loading Image...>

So it's time to install the Ubuntu 18.04 ISO yet again...
<Loading Image...>

Drat. Same darn problem. Ubuntu won't install alongside Windows.
Once I boot to Ubuntu, I run the blkid commands which reveal that the RAID
dung is *still* clinging to the hard drive.

How on earth am I supposed to get rid of this RAID dung on the hard drive?
Paul
2018-06-18 07:10:17 UTC
Permalink
Post by Arlen Holder
Post by Arlen Holder
But do I need to format the HDD first before re-installing Windows?
Or can I just install Windows on it again, without re-formatting?
I decided to move forward and booted to a Windows 10 ISO to take a look at
the hard disk drive that has the RAID dung stuck to it.
<http://img4.imagetitan.com/img.php?image=18_dualboot80.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot81.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot82.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot83.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot84.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot85.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot86.jpg>
So it's time to install the Ubuntu 18.04 ISO yet again...
<http://img4.imagetitan.com/img.php?image=18_dualboot87.jpg>
Drat. Same darn problem. Ubuntu won't install alongside Windows.
Once I boot to Ubuntu, I run the blkid commands which reveal that the RAID
dung is *still* clinging to the hard drive.
How on earth am I supposed to get rid of this RAID dung on the hard drive?
There's more than one way.

Secure Erase is one way.

Using "dd" to poke at the end of the disk is another.

Since you've resized the Win10 partition, there's little
risk of damaging anything with "dd".

For the (Linux) command suggested here, you can work out
the arithmetic in two steps.

https://djlab.com/2013/07/removing-raid-metadata/

dd if=/dev/zero of=$YOUR_DEV bs=512 seek=$(( $(blockdev --getsz $YOUR_DEV) - 1024 )) count=1024

You can try the

blockdev --getsz /dev/sda

part first and get a size. Then subtract 1024 from it.
The "resultingnumber" would be fitted like this.

sudo dd if=/dev/zero of=/dev/sda bs=512 seek=resultingnumber count=1024

This results in the last 512*1024 bytes of disk getting written.
And assumes the metadata is in that section.

Flip over to the Ubuntu installer, and try again. If it
still fails...

You can write larger and larger sections at the end, by enlarging
the 1024 part. For example, I might try

sudo dd if=/dev/zero of=$YOUR_DEV bs=512 seek=$(( $(blockdev --getsz $YOUR_DEV) - 10240 )) count=10240

Anyway, that's the "efficient" way to do it.

You also want to verify the "size" of the disk when
connected to a non AMD/Promise SATA port. Just in case
the area of the disk that needs to be written, is
"protected" by the RAIDness. The size of the disk
is always slightly bigger than the size on the tin.
A 1TB drive might be 1,000,204,886,016 bytes
and just a bit bigger than 1*10**12. The number
is usually divisible by 63 (for fake CHS geometry).

Secure Erase has its own challenges. It's offered gratis
in SSD Toolbox software, but the free version for hard
drives involved a password. And it'll take a couple
hours for it to run.

The creator of Secure Erase feature, used to live here.
That's just as icky to work with, as RAID metadata :-)
It's a lot easier with an SSD Toolbox version (which
may be brand-locked).

https://en.wikipedia.org/wiki/HDDerase

https://web.archive.org/web/20151230142025/http://cmrr.ucsd.edu/people/Hughes/Secure-Erase.html

That's the basic idea. No guarantees though.
It would probably have worked on my test setup,
but that's because it's Intel RSTe.

Paul
Arlen Holder
2018-06-18 07:19:13 UTC
Permalink
Post by Paul
That's the basic idea. No guarantees though.
It would probably have worked on my test setup,
but that's because it's Intel RSTe.
Thanks Paul,

The goal is to get the RAID dung off the hard disk.

I can only do one method at a time so I'm doing the Windows 10 ISO diskpart
suggestion now on the WD Blue terabyte disk (which shows only 931 GB
visible to dispart).

I am waiting for the "clean all" to complete.
<http://img4.imagetitan.com/img.php?image=18_dualboot88.jpg>

If that fails, I'll try the next method ... but I can only do one at a
time... Thanks!
Arlen Holder
2018-06-18 14:53:42 UTC
Permalink
Post by Arlen Holder
I am waiting for the "clean all" to complete.
<http://img4.imagetitan.com/img.php?image=18_dualboot88.jpg>
The diskpart "clean all" completed:
<Loading Image...>

Then I looked up what else "diskpart" can do while I was already there:
<http://www.jwgoerlich.us/blogengine/post/2009/11/05/Use-Diskpart-to-Create-and-Format-Partitions.aspx>
<https://www.windowscentral.com/how-clean-and-format-storage-drive-using-diskpart-windows-10>

First I had to figure out the difference between "GPR" and "MBT":
<https://www.maketecheasier.com/differences-between-mbr-and-gpt/>

Not a single tutorial I followed worked as documented, but I did seem to
manage to format to GPT NTFS using this jumbled sequence of disjoint
diskpart commands:
diskpart> convert gpt
diskpart> create partition primary
diskpart> select part 1
diskpart> active
diskpart> format fs=ntfs label=disc1 quick

Here is a screenshot of those results:
<Loading Image...

I will now boot to Ubuntu 18.04 on ISO DVD to check if the RAID dung has
been wiped off the disk.
Arlen Holder
2018-06-18 15:28:30 UTC
Permalink
Post by Arlen Holder
<http://img4.imagetitan.com/img.php?image=18_dualboot90.jpg
I will now boot to Ubuntu 18.04 on ISO DVD to check if the RAID dung has
been wiped off the disk.
Woo hoo!

Finally the RAID dung has been cleaned off the disk by diskpart!
<Loading Image...>

I booted to the Ubuntu 18.04 Desktop ISO and ran these two commands that
Carlos had kindly suggested in the beginning:
$ blkid
/dev/sda1: LABEL="disc1" . TYPE="ntfs" PARTLABEL="Basic data partition"
/dev/sr0: ... LABEL="Ubuntu 18.04 LTS amd64" ... TYPE="iso9660" ...

$ blkid /dev/sd*
/dev/sda1: LABEL="disc1" . TYPE="ntfs" PARTLABEL="Basic data partition"

Thanks to everyone, especially Paul and Carlos for figuring out the key
issue which was that the RAID dung was stuck to the disk and how to clean
it off and changing the BIOS to eliminate the RAID dung from getting put on
the disk again.

I will now simply follow those original tutorials... :)
a. I'll install Windows (letting it do whatever it wants to the disk)
b. Then I'll shrink volume to create a 40GB space for Ubuntu 18.04
c. Then I'll install Ubuntu 18.04 Desktop alongside Windows 10

Unless something goes wrong, you should hear from me only in a summary
statement so that the overall tribal knowledge is updated for the next
person to benefit from, as always, from all our hard work!
Paul
2018-06-18 17:52:23 UTC
Permalink
Post by Arlen Holder
Post by Arlen Holder
<http://img4.imagetitan.com/img.php?image=18_dualboot90.jpg
I will now boot to Ubuntu 18.04 on ISO DVD to check if the RAID dung has
been wiped off the disk.
Woo hoo!
Finally the RAID dung has been cleaned off the disk by diskpart!
<http://img4.imagetitan.com/img.php?image=18_dualboot91.jpg>
I booted to the Ubuntu 18.04 Desktop ISO and ran these two commands that
$ blkid
/dev/sda1: LABEL="disc1" . TYPE="ntfs" PARTLABEL="Basic data partition"
/dev/sr0: ... LABEL="Ubuntu 18.04 LTS amd64" ... TYPE="iso9660" ...
$ blkid /dev/sd*
/dev/sda1: LABEL="disc1" . TYPE="ntfs" PARTLABEL="Basic data partition"
Thanks to everyone, especially Paul and Carlos for figuring out the key
issue which was that the RAID dung was stuck to the disk and how to clean
it off and changing the BIOS to eliminate the RAID dung from getting put on
the disk again.
I will now simply follow those original tutorials... :)
a. I'll install Windows (letting it do whatever it wants to the disk)
b. Then I'll shrink volume to create a 40GB space for Ubuntu 18.04
c. Then I'll install Ubuntu 18.04 Desktop alongside Windows 10
Unless something goes wrong, you should hear from me only in a summary
statement so that the overall tribal knowledge is updated for the next
person to benefit from, as always, from all our hard work!
Amazing.

And I thought that RAID metadata was going to be stuck there forever :-)

You would likely have to run a bunch more test
cases, to positively identify what fixed it. And
at this point, I'd be moving on... I don't mind doing
test cases with simple setups, but erasing whole disks
over and over again makes this sport too expensive.

Paul
Arlen Holder
2018-06-19 00:36:31 UTC
Permalink
Post by Paul
And I thought that RAID metadata was going to be stuck there forever :-)
Hi Paul,

The one thing I'd love to know is *how* you knew to look at the RAID dung
as the underlying problem?

That the RAID dung even *existed*, let alone that the RAID dung was what
Ubuntu couldn't handle - would never have occurred to me in a million
years.

How did you *know* that the problem was that
a. There was RAID dung on the hard drive, and,
b. That Ubuntu was barfing on that RAID dung?
Paul
2018-06-19 01:06:08 UTC
Permalink
Post by Arlen Holder
Post by Paul
And I thought that RAID metadata was going to be stuck there forever :-)
Hi Paul,
The one thing I'd love to know is *how* you knew to look at the RAID dung
as the underlying problem?
That the RAID dung even *existed*, let alone that the RAID dung was what
Ubuntu couldn't handle - would never have occurred to me in a million
years.
How did you *know* that the problem was that
a. There was RAID dung on the hard drive, and,
b. That Ubuntu was barfing on that RAID dung?
I googled it :-)

I could find comments from people about RAID and this
sort of issue. That's where it started.

Paul
Arlen Holder
2018-06-19 01:30:37 UTC
Permalink
Post by Paul
I googled it :-)
I could find comments from people about RAID and this
sort of issue. That's where it started.
But the *keywords* for googling are almost impossible!

There was ZERO error in Ubuntu.
There was ZERO error in Windows.

The only problem was a particular question wasn't asked
(the question being whether to install alongwide Windows).

That makes for lousy keywords - so I'm amazed you found the problem because
I don't think I ever would have found it on my own.

BTW, I'm still a bit confused about WHERE on earth the RAID dung is
"located" on the hard drive.

This is the only indication I know of where the problems shows itself:
PROBLEM: /dev/sda TYPE="promise_fasttrack_raid_member"
NO_PROB: /dev/sda TYPE="ntfs"

Do you know *where* that particular dung is located on the hard disk drive?
Specifically, is that RAID dung located in an "accessible" location?

(Bear in mind, I never ran "dd" but I just wiped clean every single bit of
teh entire Terabyte HDD, which, as you know, took hours upon hours, to
complete.)

Could just those bits have possibly been changed
FROM: TYPE="promise_fasttrack_raid_member"
TO: TYPE="ntfs"
David W. Hodgins
2018-06-19 01:49:03 UTC
Permalink
Post by Arlen Holder
Post by Paul
I googled it :-)
I could find comments from people about RAID and this
sort of issue. That's where it started.
But the *keywords* for googling are almost impossible!
There was ZERO error in Ubuntu.
There was ZERO error in Windows.
The "blkid /dev/sd*" output showed that sda was a raid member, and
since it was the only hard drive, it had to be part of a degraded
array.

As to it not being documented, installing a dual boot system on a
degraded raid array, is likely something the documentation writers
had never tried, or if they did, the installer writers may have felt
that erasing the disk was the most likely to be desired, and correct
way to handle it.

Regards, Dave Hodgins
--
Change ***@nomail.afraid.org to ***@teksavvy.com for
email replies.
Arlen Holder
2018-06-19 02:25:11 UTC
Permalink
Post by David W. Hodgins
As to it not being documented, installing a dual boot system on a
degraded raid array, is likely something the documentation writers
had never tried, or if they did, the installer writers may have felt
that erasing the disk was the most likely to be desired, and correct
way to handle it.
This "degraded array" is really a "falsely degraded array" since it was
working just fine for all purposes but installing Ubuntu. :)

I realize that 'degraded array' is most likely the correct google keyword
... but ... it would not have been intuitive to me to use that search term!

So I'm indebted to those who knew enough to search for the correct terms.

BTW, as I recall, late last night, after I gave up on trying to "save" the
Windows 10 installation, I *did* hit the button for Ubuntu to install on
the "sda" drive (which was the only option).

It failed.

I don't remember the details - but I don't think Ubuntu would *ever* have
installed on that falsely degraded array (but I'm not sure).
Carlos E.R.
2018-06-19 10:38:37 UTC
Permalink
Post by Arlen Holder
Post by David W. Hodgins
As to it not being documented, installing a dual boot system on a
degraded raid array, is likely something the documentation writers
had never tried, or if they did, the installer writers may have felt
that erasing the disk was the most likely to be desired, and correct
way to handle it.
This "degraded array" is really a "falsely degraded array" since it was
working just fine for all purposes but installing Ubuntu. :)
No, it is not falsely degraded. I have been using a degraded array (5)
for about a year because I didn't bother to add another member to it, I
didn't care for its contents. A degraded array can be used just fine,
Windows had no problems with yours. Ubuntu might have installed there if
it had the driver for it.

It was truly degraded as far as the computer was concerned. And move it
to another computer with support for that type of raid, and it would
have been detected as raid member... no fake at all.
--
Cheers, Carlos.
Paul
2018-06-19 01:53:25 UTC
Permalink
Post by Arlen Holder
Post by Paul
I googled it :-)
I could find comments from people about RAID and this
sort of issue. That's where it started.
But the *keywords* for googling are almost impossible!
There was ZERO error in Ubuntu.
There was ZERO error in Windows.
The only problem was a particular question wasn't asked
(the question being whether to install alongwide Windows).
That makes for lousy keywords - so I'm amazed you found the problem because
I don't think I ever would have found it on my own.
BTW, I'm still a bit confused about WHERE on earth the RAID dung is
"located" on the hard drive.
PROBLEM: /dev/sda TYPE="promise_fasttrack_raid_member"
NO_PROB: /dev/sda TYPE="ntfs"
Do you know *where* that particular dung is located on the hard disk drive?
Specifically, is that RAID dung located in an "accessible" location?
(Bear in mind, I never ran "dd" but I just wiped clean every single bit of
teh entire Terabyte HDD, which, as you know, took hours upon hours, to
complete.)
Could just those bits have possibly been changed
FROM: TYPE="promise_fasttrack_raid_member"
TO: TYPE="ntfs"
The RAID metadata can be stored near the end of the drive.

There's a procedure I can use for finding it (involves
scanning the entire disk drive). I've used a compressor
I wrote, for locating "non-zero" data on a zeroed disk,
and that's the tool I'd use.

But really, a bit of selective disk copying, from areas near
the beginning of the drive, or areas near the end of the
drive, will locate it pretty quickly. The "dd" command,
with its seek and skip options, allows targeted copying
into a separate data file for examination. It would
only take me about five minutes, if I had the right
hardware in front of me. The complete disk scan, is
for cases where there are no hints as to where stuff
is stored.

If you use the HxD hex editor, you can look anywhere
on the disk drive. But that's subject to the access
limits (if RAID mode is enabled). A RAID driver
will prevent access to the metadata area, if everything
is working properly. That's why you have to use
a command and get the disk size, while the disk is
plugged into different computers, to see if your
computer (Device Under Test) is playing games with
you. If one computer said the drive had 9 bytes,
and the RAID computer said the drive had 8 bytes,
then you know the RAID computer is hiding 1 byte.
And that's the behavior you'd be looking for.
And the metadata then, might be up near the end
(in that 1 byte area). That's the basic
principle.

Paul
Carlos E.R.
2018-06-19 01:58:34 UTC
Permalink
Post by Arlen Holder
Post by Paul
I googled it :-)
I could find comments from people about RAID and this
sort of issue. That's where it started.
But the *keywords* for googling are almost impossible!
There was ZERO error in Ubuntu.
There was ZERO error in Windows.
The only problem was a particular question wasn't asked
(the question being whether to install alongwide Windows).
That makes for lousy keywords - so I'm amazed you found the problem because
I don't think I ever would have found it on my own.
BTW, I'm still a bit confused about WHERE on earth the RAID dung is
"located" on the hard drive.
PROBLEM: /dev/sda TYPE="promise_fasttrack_raid_member"
NO_PROB: /dev/sda TYPE="ntfs"
Well, that line was the main clue :-)

Once that line calls attention, you might think to google about it or
about problems with that type of raid and installations. I did not
search, though.
Post by Arlen Holder
Do you know *where* that particular dung is located on the hard disk drive?
Specifically, is that RAID dung located in an "accessible" location?
It is accessible on a SATA port that doesn't have raid firmware, or at
least, it is of another brand. And this is an educated guess on my part:
I have not done it, but I have read about it.

It might be at the start of the disk, then lie to the rest of the
computer about which is the first sector, doing a sector translation of
some sort. This is getting complicated, math involved on every disk
operation, so the next guess is that it has to be at the end of the
disk; then the raid firmware only has to lie about the disk size, which
is easier to do.

Some of the posts here mentioned erasing a number of sectors at the end
of the disk, so it matches my guess.
Post by Arlen Holder
(Bear in mind, I never ran "dd" but I just wiped clean every single bit of
teh entire Terabyte HDD, which, as you know, took hours upon hours, to
complete.)
dd might have failed if run with that controller, specially if still set
to raid mode.
Post by Arlen Holder
Could just those bits have possibly been changed
FROM: TYPE="promise_fasttrack_raid_member"
TO: TYPE="ntfs"
Not a bit, but several sectors with metadata. Possibly the response to
some SATA command.
--
Cheers, Carlos.
Arlen Holder
2018-06-19 02:25:08 UTC
Permalink
Post by Carlos E.R.
Well, that line was the main clue :-)
In hindsight only, this screenshot was also a clue, if I had only known
ahead of time to look for RAID dung (aka falsely degraded RAID arrays) in
the JBOD setup! :)
<http://img4.imagetitan.com/img.php?image=18_dualboot71.jpg>
Paul
2018-06-19 02:29:50 UTC
Permalink
Post by Arlen Holder
Post by Carlos E.R.
Well, that line was the main clue :-)
In hindsight only, this screenshot was also a clue, if I had only known
ahead of time to look for RAID dung (aka falsely degraded RAID arrays) in
the JBOD setup! :)
<http://img4.imagetitan.com/img.php?image=18_dualboot71.jpg>
Oh, my. It was "ready". Yikes.
That doesn't sound good.

And let's hope that function remains disabled
while the BIOS is set to AHCI mode.

Paul
Grant Taylor
2018-06-19 03:17:45 UTC
Permalink
Post by Carlos E.R.
dd might have failed if run with that controller, specially if still
set to raid mode.
dd very likely would have successfully written to the end of the disk
that was presented to the OS. The RAID controller very likely would not
have presented those sectors to the OS. Thus dd would have completed
successfully ($?=0) but not achieved the desired goal (assuming the
drive was connected to the RAID controller).
--
Grant. . . .
unix || die
Paul
2018-06-19 03:26:51 UTC
Permalink
Post by Grant Taylor
Post by Carlos E.R.
dd might have failed if run with that controller, specially if still
set to raid mode.
dd very likely would have successfully written to the end of the disk
that was presented to the OS. The RAID controller very likely would not
have presented those sectors to the OS. Thus dd would have completed
successfully ($?=0) but not achieved the desired goal (assuming the
drive was connected to the RAID controller).
And it has a parentage problem.

The port in question, is on an AMD Southbridge.

AMD licensed Promise (firmware) RAID technology.

This is signified by <ctrl>-F working once the RAID BIOS
module is enabled.

AMD actually has two generations of RAID. One
started by <ctrl>-F (the OP) and a newer version
which uses <ctrl>-R.

Since the tech is by Promise, it would presumably follow
Promise practices, whatever those are.

The Promise was quite annoying, at least in the 20378
era, in that the driver had no PNP info to distinguish
between RAID and non-RAID mode. The user could
load the module of their choosing. Whereas a lot of
other hardware implementations, present a different
PNP identifier for each operating mode. If you change
from IDE to AHCI or RAID, the PNP information reflects
this. On Intel chipsets, there was usually an addendum
document, with the code points expected. The main spec
wouldn't list the info, and you had to dig for
a separate document.

The AMD behavior could be like the 20378 case, but
many years have passed, and who knows what Promise
provided for the money paid by AMD. And the equipment
the OP is using, is the <ctrl>-F flavor.

Paul
Carlos E.R.
2018-06-19 10:39:28 UTC
Permalink
Post by Grant Taylor
Post by Carlos E.R.
dd might have failed if run with that controller, specially if still
set to raid mode.
dd very likely would have successfully written to the end of the disk
that was presented to the OS.  The RAID controller very likely would not
have presented those sectors to the OS.  Thus dd would have completed
successfully ($?=0) but not achieved the desired goal (assuming the
drive was connected to the RAID controller).
Yes, that is what I meant.
--
Cheers, Carlos.
Paul
2018-06-19 11:43:42 UTC
Permalink
Post by Carlos E.R.
Post by Grant Taylor
Post by Carlos E.R.
dd might have failed if run with that controller, specially if still
set to raid mode.
dd very likely would have successfully written to the end of the disk
that was presented to the OS. The RAID controller very likely would not
have presented those sectors to the OS. Thus dd would have completed
successfully ($?=0) but not achieved the desired goal (assuming the
drive was connected to the RAID controller).
Yes, that is what I meant.
It's tricky.

If you temporarily move the disk to a platform
that is a different brand than the RAID metadata
on the disk, chances are you'll get a "true size"
for the drive.

Then, move the disk back to the target system,
and check the claimed size again. If the claimed
size is on the order of one cylinder smaller (about 5MB
or so), then the hardware (firmware/fakeraid) is
protecting the metadata from reads or writes by
the user.

In theory, when in RAID mode, the target system
reduces the size of the disk by a cylinder. When
flipped back to AHCI mode, the target system
should expose the full size of the disk (which
is what happened in the OPs case as he was able
to erase the metadata). But there's no guarantee
this will happen in fact. There are some systems
that continue to mark JBOD disks in the same
way.

So while what the OP did to erase the metadata
was a worthwhile experiment, there simply
aren't enough standards or even defacto
standards, to say whether this will always
work.

FreeBSD seems to have some commands which might
be related to this. There is "graid" and "geom".
And they seem to expose the metadata and print
out information, as well as offering to "delete array".
But the only way to gain access to that environment,
is to install it, as there is no (recent) LiveCD.

Paul
Paul
2018-06-19 12:30:15 UTC
Permalink
Post by Paul
FreeBSD seems to have some commands which might
be related to this. There is "graid" and "geom".
And they seem to expose the metadata and print
out information, as well as offering to "delete array".
But the only way to gain access to that environment,
is to install it, as there is no (recent) LiveCD.
Paul
And that actually works.

In TrueOS,

graid list

shows a device with RAID metadata.

graid remove raid/r0 ada1

deleted the metadata. The last two identifiers
were the values in the "list" output.

When Ubuntu LiveCD was booted and
the installer run, it worked properly
with the freshly (metadata-erased) disk.

The other thing that was of minor interest,
is I set up the array using the BIOS RAID
window. And quickly booted into TrueOS after
that. And "graid list" shows TrueOS was
rebuilding the array. Even though no
partitions were defined on it. It looks
like TrueOS (FreeBSD) takes their fakeRAID
seriously :-) There was no setup to do,
and it appears their graid thing honors
the info passed in the metadata.

Paul
Arlen Holder
2018-06-19 14:49:49 UTC
Permalink
Post by Paul
So while what the OP did to erase the metadata
was a worthwhile experiment, there simply
aren't enough standards or even defacto
standards, to say whether this will always
work.
For the record, the *only* command found to erase the RAID dung metadata
was your suggested use of DiskPart "clean all":
<http://img4.imagetitan.com/img.php?image=18_dualboot89.jpg>

Do you think the Ubuntu DiskPart equivalent for cleaning off the RAID dung
metadata might be something like gparted?
Paul
2018-06-19 23:48:18 UTC
Permalink
Post by Arlen Holder
Post by Paul
So while what the OP did to erase the metadata
was a worthwhile experiment, there simply
aren't enough standards or even defacto
standards, to say whether this will always
work.
For the record, the *only* command found to erase the RAID dung metadata
<http://img4.imagetitan.com/img.php?image=18_dualboot89.jpg>
Do you think the Ubuntu DiskPart equivalent for cleaning off the RAID dung
metadata might be something like gparted?
If you can do it with "clean all", you can do it with "dd".
Even Windows has a third-party dd port ("dd.exe").

The command that has "superior reach" and can blast RAID metadata
no matter what, is ATA Secure Erase. The CMRR site had the HDDerase
for that purpose.

But any time a task requires "wrangling disks", the more potent
the command, the more command line it becomes, and you eventually
find yourself booting floppies and the like. No really useful tool
has a GUI. You have to climb into the trench with your disk drive,
and duke it out. None of these tasks are "grandpa-easy". It helps
to have a copy of the ATA spec or something :-) If you design
disk drives in your spare time, it'll be easy for you.

Paul
Arlen Holder
2018-06-20 15:52:03 UTC
Permalink
Post by Paul
The command that has "superior reach" and can blast RAID metadata
no matter what, is ATA Secure Erase. The CMRR site had the HDDerase
for that purpose.
Hi Paul,
You use a lot of cryptic words that I'm unfamiliar with! :)
<https://cmrr.ucsd.edu/resources/secure-erase.html>

I've updated the solution section to mention most of the suggestions by
Carlos and Paul so that the tribal knowledge can benefit if/when I re-post
it (I already posted a solution to
<http://tinyurl.com/alt-os-linux>
<http://tinyurl.com/alt-comp-os-windows-10>
so I don't want to confuse things with these additional details until
they're more fully fleshed out).
<https://groups.google.com/d/msg/alt.os.linux/D7E7FQ1NLNk/B4xroB8rCAAJ>

For reference, the Ultimate Boot CD contains the tools Paul speaks of:
<http://www.ultimatebootcd.com/download.html>

Since Paul uses words I don't understand, at least not at first, such as
"CMRR" and "ATA Secure Erase"... I had to look them up ... where they go
together hand in hand):
<http://www.t13.org/Documents/UploadedDocuments/docs2004/e04147r0-TechProposalFreezeLockSecureErase.pdf>

"So what's the magic? Secure Erase is a set of commands embedded in most
ATA drives built since 2001. If this is so wonderful, why haven't you heard
of it before? Because it's been disabled by most motherboard BIOSes."
"UCSD's CMRR to the rescue The University of California at San Diego hosts
the Center for Magnetic Recording Research. Dr. Gordon Hughes of CMRR
helped develop the Secure Erase standard."
<https://www.zdnet.com/article/how-to-really-erase-a-hard-drive/>

Data Sanitization Tutorial
<https://cmrr.ucsd.edu/_files/data-sanitization-tutorial.pdf>
Paul
2018-06-20 18:55:01 UTC
Permalink
Post by Arlen Holder
Post by Paul
The command that has "superior reach" and can blast RAID metadata
no matter what, is ATA Secure Erase. The CMRR site had the HDDerase
for that purpose.
Hi Paul,
You use a lot of cryptic words that I'm unfamiliar with! :)
<https://cmrr.ucsd.edu/resources/secure-erase.html>
I've updated the solution section to mention most of the suggestions by
Carlos and Paul so that the tribal knowledge can benefit if/when I re-post
it (I already posted a solution to
<http://tinyurl.com/alt-os-linux>
<http://tinyurl.com/alt-comp-os-windows-10>
so I don't want to confuse things with these additional details until
they're more fully fleshed out).
<https://groups.google.com/d/msg/alt.os.linux/D7E7FQ1NLNk/B4xroB8rCAAJ>
<http://www.ultimatebootcd.com/download.html>
Since Paul uses words I don't understand, at least not at first, such as
"CMRR" and "ATA Secure Erase"... I had to look them up ... where they go
<http://www.t13.org/Documents/UploadedDocuments/docs2004/e04147r0-TechProposalFreezeLockSecureErase.pdf>
"So what's the magic? Secure Erase is a set of commands embedded in most
ATA drives built since 2001. If this is so wonderful, why haven't you heard
of it before? Because it's been disabled by most motherboard BIOSes."
"UCSD's CMRR to the rescue The University of California at San Diego hosts
the Center for Magnetic Recording Research. Dr. Gordon Hughes of CMRR
helped develop the Secure Erase standard."
<https://www.zdnet.com/article/how-to-really-erase-a-hard-drive/>
Data Sanitization Tutorial
<https://cmrr.ucsd.edu/_files/data-sanitization-tutorial.pdf>
Like HPA (Host Protected Area), if a command has a "trap door"
and only one such command can be applied per power cycle, it's
possible for well designed BIOS code to in effect, disable the
feature.

For example, my current motherboard in this machine, has six
Intel ports and two JMicron ports. The Intel ports don't
allow HPA commands to work, implying the BIOS code for the
port issued at least one HPA command at power up. The JMicron
ports though, they allow HPA (I can execute one HPA
operation per power cycle). And thus, when I want to do
HPA work, I have to use the JMicron chip and connect via
an adapter.

Obviously, Secure Erase is a dangerous thing to leave sitting
about. I understood you could set a password for it. And that
appeared to be a "feature" in HDDErase. It's unclear how
the SSD Toolbox software programs, are managing to issue
such a command. It seems a lot simpler for SSDs, but I
don't understand why it should be simpler. The command set
and protocol should be identical. If a port was actually
blocking Secure Erase, we should be hearing SSD owners
whining about the issue. When I needed to Secure Erase
the Neutron SSD I bought, I ran that on an Intel port
on the other machine, and there was no complaint there.
It just worked.

Paul
Carlos E.R.
2018-06-20 08:05:53 UTC
Permalink
Post by Arlen Holder
Post by Paul
So while what the OP did to erase the metadata
was a worthwhile experiment, there simply
aren't enough standards or even defacto
standards, to say whether this will always
work.
For the record, the *only* command found to erase the RAID dung metadata
<http://img4.imagetitan.com/img.php?image=18_dualboot89.jpg>
In Windows. There are others in Linux. I suggested hdparm.
--
Cheers, Carlos.
Grant Taylor
2018-06-19 03:04:21 UTC
Permalink
Post by Arlen Holder
But the *keywords* for googling are almost impossible!
Sadly, this is not atypical for my career. Part of what my clients paid
me for was knowing how to research their errors.
Post by Arlen Holder
There was ZERO error in Ubuntu.
There was ZERO error in Windows.
Not surprising. Lack of an actual "error" does not mean there were not
"symptoms" or "clues". (More below.)
Post by Arlen Holder
The only problem was a particular question wasn't asked
(the question being whether to install alongwide Windows).
Yep. That makes it a bugger to search for. Usually it's "Why is
$QUESTION missing" type query.
Post by Arlen Holder
That makes for lousy keywords - so I'm amazed you found the problem because
I don't think I ever would have found it on my own.
;-)
Post by Arlen Holder
BTW, I'm still a bit confused about WHERE on earth the RAID dung is
"located" on the hard drive.
I'm used to things going at the start or end of the drive. Usually in
the first / last 1 ~ 10 MB.

I typically will zero the first and last 1 ~ 10 MB of the drive when
confronted with things like that.
Post by Arlen Holder
PROBLEM: /dev/sda TYPE="promise_fasttrack_raid_member"
NO_PROB: /dev/sda TYPE="ntfs"
I think Promise (and a few others) actually steal the last tiny bit of
the physical drive for meta data and present an ever slightly smaller
drive to the OS. Hence one of the reasons that you can't move a drive
from a Promise (et al) controller to a stock {P,S}ATA controller and get
it to work. Or rather that's a likely reason why it doesn't if it
doesn't. (Sometimes it will work.)
Post by Arlen Holder
Do you know *where* that particular dung is located on the hard disk drive?
Specifically, is that RAID dung located in an "accessible" location?
Usually the last or last 1 ~ 10 MB of the drive.
Post by Arlen Holder
(Bear in mind, I never ran "dd" but I just wiped clean every single bit of
teh entire Terabyte HDD, which, as you know, took hours upon hours, to
complete.)
I've run DD a LOT of times. The simplest is to just do the following
and wait (sometimes seemingly forever).

dd if=/dev/zero of=/dev/$DRIVE
Post by Arlen Holder
Could just those bits have possibly been changed
FROM: TYPE="promise_fasttrack_raid_member"
TO: TYPE="ntfs"
There is also a chance that the Promise created a partition table and
set a partition type. I don't know for sure how blkid knows
"promise_fasttrack_raid_member". I do know that "ntfs" is a partition type.
--
Grant. . . .
unix || die
Carlos E.R.
2018-06-18 21:59:55 UTC
Permalink
Post by Arlen Holder
Post by Arlen Holder
<http://img4.imagetitan.com/img.php?image=18_dualboot90.jpg
I will now boot to Ubuntu 18.04 on ISO DVD to check if the RAID dung has
been wiped off the disk.
Woo hoo!
:-)
Post by Arlen Holder
Thanks to everyone, especially Paul and Carlos for figuring out the key
issue which was that the RAID dung was stuck to the disk and how to clean
it off and changing the BIOS to eliminate the RAID dung from getting put on
the disk again.
Welcome :-)
Post by Arlen Holder
I will now simply follow those original tutorials... :)
a. I'll install Windows (letting it do whatever it wants to the disk)
b. Then I'll shrink volume to create a 40GB space for Ubuntu 18.04
Using the original Windows install media it is possible to tell the
installer to use only part of the hard disk, so that the shrinking step
is not necessary.

At least it was so when I tried with W7 and Server 2008. It is
manufacturer disks which are more restrictive.
--
Cheers, Carlos.
Arlen Holder
2018-06-19 00:36:30 UTC
Permalink
Post by Carlos E.R.
Using the original Windows install media it is possible to tell the
installer to use only part of the hard disk, so that the shrinking step
is not necessary.
Thanks for the helpful advice where together, you and Paul figured out that
not only was there RAID dung on the hard disk drive, but that this RAID
dung was what the Ubuntu installer was balking at.

I'm amazed you two knew that as it would never have occurred to me, and
certainly it wasn't described in any of the tutorials I homeworked upon.

So, this Usenet thread is a case of:
a. I did my homework and followed the tutorials
b. But Ubuntu just wouldn't ask to install alongside Windows
c. I asked here and you guys all gave helpful advice
d. I tried as much of the advice as I was comfortable with
e. Where, eventually, the problem was determined to be twofold
- RAID dung was left on the hard drive, and,
- Ubuntu was barfing on that RAID dung
f. I then followed the cleanup instructions
g. And lo and behold - Ubuntu finally *asked* to install alongside Windows

Who would have known this would have happened, given there's no mention
that I know of about this problem in the Ubuntu installation tutorials?

Not me.

Thanks for the help and advice and patience and expertise and willingness
to help someone who needed help. I will try to write up a summary so that
the tribal knowledge record benefits so that the next person with the same
problem start where we left off, standing on our shoulders.
Carlos E.R.
2018-06-19 01:35:07 UTC
Permalink
Post by Arlen Holder
Post by Carlos E.R.
Using the original Windows install media it is possible to tell the
installer to use only part of the hard disk, so that the shrinking step
is not necessary.
Thanks for the helpful advice where together, you and Paul figured out that
not only was there RAID dung on the hard disk drive, but that this RAID
dung was what the Ubuntu installer was balking at.
I'm amazed you two knew that as it would never have occurred to me, and
certainly it wasn't described in any of the tutorials I homeworked upon.
No, I did an educated guess :-)

I had heard of problems with disks that had been used before as part of
some raid types. As soon as I noticed that your disk was detected
somewhere as a raid member it clicked, and then I read here of the
analysis and tests Paul had been doing, and I was 95% sure.
Post by Arlen Holder
a. I did my homework and followed the tutorials
b. But Ubuntu just wouldn't ask to install alongside Windows
c. I asked here and you guys all gave helpful advice
d. I tried as much of the advice as I was comfortable with
e. Where, eventually, the problem was determined to be twofold
- RAID dung was left on the hard drive, and,
- Ubuntu was barfing on that RAID dung
f. I then followed the cleanup instructions
g. And lo and behold - Ubuntu finally *asked* to install alongside Windows
Who would have known this would have happened, given there's no mention
that I know of about this problem in the Ubuntu installation tutorials?
Tutorials can not speak about what has not been found before. The writer
must have at least heard of it.

That's what forums are for; to ask other people that have other
experiences and may know or at least guess what is happening or have
other ideas to try.
Post by Arlen Holder
Not me.
Thanks for the help and advice and patience and expertise and willingness
to help someone who needed help. I will try to write up a summary so that
the tribal knowledge record benefits so that the next person with the same
problem start where we left off, standing on our shoulders.
:-)
--
Cheers, Carlos.
Arlen Holder
2018-06-19 01:46:16 UTC
Permalink
Post by Carlos E.R.
That's what forums are for; to ask other people that have other
experiences and may know or at least guess what is happening or have
other ideas to try.
Well, in this particular thread, the Usenet worked as it's supposed to!

1. I asked a question of Windows/Linux groups (fup to Linux only).
2. People came in from both groups to help suggest solutions.
3. Not a single person trolled nor posted worthless chitchat banter.
4. Many suggestions were made (some easy, some not so easy to do).
5. I tried every viable suggestion (reporting back results when available).
6. The problem was finally resolved after many hours of effort.
7. And I'm currently writing a summary for posting back to both groups.

My 100-photo documented step-by-step summary will be the payback for all
the excellent help from you, Carlos E.R. and Paul and William Unruh and
Jonathan N. Little and Grant Taylor and David W. Hodgins and stepore and
Dirk T. Verbeek, etc.

Thanks for being an excellent Usenet citizen!
Arlen Holder
2018-06-19 00:36:28 UTC
Permalink
Post by Arlen Holder
Unless something goes wrong, you should hear from me only in a summary
statement so that the overall tribal knowledge is updated for the next
person to benefit from, as always, from all our hard work!
Now that the RAID dung has finally been removed from the HDD, I proceeded
to install Windows 10 Pro where there was a minor glitch on the GPT
partition type...
"Windows cannot be installed to this disk.
The selected diwsk is of the GPT partition style".
<Loading Image...>

I must have read wrong that GPT is better than MBR, but at this point, I
just had Windows 10 installation delete it and create a new one where
Windows also created a 532MB "System Reserved" partition (for whatever
reason Windows 10 does that).
<Loading Image...

Following the tutorials, I ran "Shrink volume" in Windows Disk Management.
<Loading Image...>

This created an extra 40GB partition for Ubuntu to use:
<Loading Image...>

Finally! Woo hoo! Ubuntu finally *asked* to install alongside Windows!
<Loading Image...>

The only thing Ubuntu asked was to format with this instruction:
"The partition tables of the following devices are changed:
SCSI1 (0,0,0) (sda)
The following partitions are going to be formatted:
partition #5 of SCSI1 (0,0,0) (sda) as ext4"
<Loading Image...>

Once Ubuntu formatted the disk, it installed itself nicely using Grub.
<Loading Image...>

Here are the results from "blkid" and "blkid /dev/sd*" where the main
point is that the RAID dung is no longer in existence! (Woo hoo!)
<Loading Image...>

Booting to Windows 10, the 40GB Linux partition shows up as "unallocated"
<Loading Image...>

Being as I'm likely one of the most well-organized people on the planet,
now it's time to set up the Windows GUI as per this thread last week:
Tutorial for setting up a well-organized consistent efficient Windows menu system
<http://www.pcbanter.net/showthread.php?t=1104432>

Again. :)
Carlos E.R.
2018-06-19 01:46:11 UTC
Permalink
Post by Arlen Holder
Post by Arlen Holder
Unless something goes wrong, you should hear from me only in a summary
statement so that the overall tribal knowledge is updated for the next
person to benefit from, as always, from all our hard work!
Now that the RAID dung has finally been removed from the HDD, I proceeded
to install Windows 10 Pro where there was a minor glitch on the GPT
partition type...
"Windows cannot be installed to this disk.
The selected diwsk is of the GPT partition style".
<http://img4.imagetitan.com/img.php?image=18_dualboot92.jpg>
I must have read wrong that GPT is better than MBR, but at this point, I
just had Windows 10 installation delete it and create a new one where
Windows also created a 532MB "System Reserved" partition (for whatever
reason Windows 10 does that).
<http://img4.imagetitan.com/img.php?image=18_dualboot93.jpg
GPT is better, yes.

But the designers of Windows thought that it is not possible to boot a
GPT disk on a Bios computer, they thought that EFI was required. Not so:
for instance this machine was built before EFI and GPT were known, yet
my boot disk is GPT. It needs certain tricks that Windows alone is not
able to do on its own :-P

GPT disks have a protective or fake MBR sector and partition table. It
is possible to install boot code in there, and it works.


Yes, Windows does create a small boot partition too. Windows 7 also did
it, so not new.
Post by Arlen Holder
Following the tutorials, I ran "Shrink volume" in Windows Disk Management.
<http://img4.imagetitan.com/img.php?image=18_dualboot94.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot95.jpg>
Finally! Woo hoo! Ubuntu finally *asked* to install alongside Windows!
<http://img4.imagetitan.com/img.php?image=18_dualboot96.jpg>
SCSI1 (0,0,0) (sda)
partition #5 of SCSI1 (0,0,0) (sda) as ext4"
<http://img4.imagetitan.com/img.php?image=18_dualboot97.jpg>
You will find (in Linux) that there is also a partition number 3 or 4 of
type extended.
Post by Arlen Holder
Once Ubuntu formatted the disk, it installed itself nicely using Grub.
<http://img4.imagetitan.com/img.php?image=18_dualboot98.jpg>
Here are the results from "blkid" and "blkid /dev/sd*" where the main
point is that the RAID dung is no longer in existence! (Woo hoo!)
<http://img4.imagetitan.com/img.php?image=18_dualboot99.jpg>
Ah, there, #3, as I said.
Post by Arlen Holder
Booting to Windows 10, the 40GB Linux partition shows up as "unallocated"
<http://img4.imagetitan.com/img.php?image=18_dualboot100.jpg>
It amazes me that to this day Windows refuses to recognize other systems
partitions :-o
Post by Arlen Holder
Being as I'm likely one of the most well-organized people on the planet,
Tutorial for setting up a well-organized consistent efficient Windows menu system
<http://www.pcbanter.net/showthread.php?t=1104432>
Again. :)
:-)
--
Cheers, Carlos.
Carlos E.R.
2018-06-18 10:18:44 UTC
Permalink
Post by Arlen Holder
Post by Arlen Holder
But do I need to format the HDD first before re-installing Windows?
Or can I just install Windows on it again, without re-formatting?
I decided to move forward and booted to a Windows 10 ISO to take a look at
the hard disk drive that has the RAID dung stuck to it.
<http://img4.imagetitan.com/img.php?image=18_dualboot80.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot81.jpg>
But you did not do the "Secure Erase" thing as recommended... so the
result was as expected.

A Linux tool to do that is "hdparm --security-erase" (read the manual
first). I have never done it, but I think it is:

hdparm --security-erase NULL /dev/sda

The operation is performed by the disk firmware, not by the computer.
--
Cheers, Carlos.
Carlos E.R.
2018-06-18 10:06:56 UTC
Permalink
Post by Arlen Holder
What's amazing is that all the tutorials suck since none of them explain
this issue with RAID poop left on the hard disk drive.
Why should they? Tutorials do not cover all cases, specially not corner
cases.
Post by Arlen Holder
At this point, I'm like a deer caught in the headlights.
I'm not sure what do to.
Where am I?
a. I changed the BIOS from RAID to AHCI.
b. Then Windows stopped booting.
Should I just change the BIOS back to RAID?
IMO, no. Just install Windows again or try to repair its boot somehow.
No idea how.
--
Cheers, Carlos.
Arlen Holder
2018-06-18 03:14:31 UTC
Permalink
Post by Paul
Turning off the AMD RAID at BIOS level, and setting to AHCI,
should be enough to prevent Promise(AMD) RAID code from loading
at BIOS level.
I shut down the HP Pavillion desktop, pressed F10 upon cold startup, went
into the "Advanced" BIOS tab:
<Loading Image...>

The SATA Controller Mode was set, as Paul had guessed, to RAID.
<Loading Image...>

My three choices were IDE, RAID, AHCI:
<Loading Image...>

I changed the SATA Controller Mode to AHCI as per Paul's suggestion:
<Loading Image...>

Of course, I had no idea what "AHCI" means, but Google is my friend...
What does AHCI Mode, IDE Mode, RAID Mode, & SATA Mean in the BIOS settings
<https://answers.microsoft.com/en-us/windows/forum/windows_8-hardware/what-does-ahci-mode-ide-mode-raid-mode-sata-mean/d622d5cd-41c4-4b84-90ef-cea69aa47089>

AHCI - Advanced Host Controller Interface - this is a hardware mechanism
that allows the software to communicate with Serial ATA (SATA) devices. It
offers features such as hot-plugging and native command queuing (NCQ).

IDE - Integrated Drive Electronics - IDE is basically the "old" version of
AHCI without hot-plugging and NCQ. (This is usually used during the
Parallel ATA (PATA) era hard disks)

The bad news (really bad) is that this completely killed Windows.
<Loading Image...>

NOTE: This is the third time I've tried a suggestion from Paul, who is very
kind and helpful, that bricked my system! :) It's not a big deal (the last
time was when I tried to remove Cortana completely, and the one prior to
that was when I tried to prevent Windows from ever updating by messing with
the System32 files such as wuaueng.dll). :) (I'm not complaining!)

Luckily, I'm getting good at re-installing Windows, but I tried rebooting a
few times from a cold start, but to no avail:
<Loading Image...>
<Loading Image...>
<Loading Image...

Windows 10 will no longer boot no matter what I do.

So I put the Ubuntu 18.04 ISO DVD in the DVD drive and tried to install
Ubuntu, but that failed in the same way as all the prior attempts did, so I
accomplished nothing by switching the BIOS from RAID to AHCI.

So I simply booted to the Ubuntu 18.04 ISO and then ran the previous
debugging commands, all of which reported the exact same things as before
the switch of BIOS control from RAID to AHCI.
<Loading Image...>
<Loading Image...

Specifically, this didn't change:
$ blkid /dev/sd*
/dev/sda: TYPE="promise_fasttrack_raid_member"
/dev/sda1: LABEL="Disk1" ... TYPE="ntfs" ...

Paul ... did I miss a step in your recommendations?
Paul
2018-06-18 03:43:51 UTC
Permalink
Post by Arlen Holder
Post by Paul
Turning off the AMD RAID at BIOS level, and setting to AHCI,
should be enough to prevent Promise(AMD) RAID code from loading
at BIOS level.
I shut down the HP Pavillion desktop, pressed F10 upon cold startup, went
<http://img4.imagetitan.com/img.php?image=18_dualboot59.jpg>
The SATA Controller Mode was set, as Paul had guessed, to RAID.
<http://img4.imagetitan.com/img.php?image=18_dualboot60.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot61.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot62.jpg>
Of course, I had no idea what "AHCI" means, but Google is my friend...
What does AHCI Mode, IDE Mode, RAID Mode, & SATA Mean in the BIOS settings
<https://answers.microsoft.com/en-us/windows/forum/windows_8-hardware/what-does-ahci-mode-ide-mode-raid-mode-sata-mean/d622d5cd-41c4-4b84-90ef-cea69aa47089>
AHCI - Advanced Host Controller Interface - this is a hardware mechanism
that allows the software to communicate with Serial ATA (SATA) devices. It
offers features such as hot-plugging and native command queuing (NCQ).
IDE - Integrated Drive Electronics - IDE is basically the "old" version of
AHCI without hot-plugging and NCQ. (This is usually used during the
Parallel ATA (PATA) era hard disks)
The bad news (really bad) is that this completely killed Windows.
<http://img4.imagetitan.com/img.php?image=18_dualboot63.jpg>
NOTE: This is the third time I've tried a suggestion from Paul, who is very
kind and helpful, that bricked my system! :) It's not a big deal (the last
time was when I tried to remove Cortana completely, and the one prior to
that was when I tried to prevent Windows from ever updating by messing with
the System32 files such as wuaueng.dll). :) (I'm not complaining!)
Luckily, I'm getting good at re-installing Windows, but I tried rebooting a
<http://img4.imagetitan.com/img.php?image=18_dualboot64.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot65.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot66.jpg
Windows 10 will no longer boot no matter what I do.
So I put the Ubuntu 18.04 ISO DVD in the DVD drive and tried to install
Ubuntu, but that failed in the same way as all the prior attempts did, so I
accomplished nothing by switching the BIOS from RAID to AHCI.
So I simply booted to the Ubuntu 18.04 ISO and then ran the previous
debugging commands, all of which reported the exact same things as before
the switch of BIOS control from RAID to AHCI.
<http://img4.imagetitan.com/img.php?image=18_dualboot67.jpg>
<http://img4.imagetitan.com/img.php?image=18_dualboot68.jpg
$ blkid /dev/sd*
/dev/sda: TYPE="promise_fasttrack_raid_member"
/dev/sda1: LABEL="Disk1" ... TYPE="ntfs" ...
Paul ... did I miss a step in your recommendations?
And when you changed it back to RAID again, what happened ?

It probably booted, right ?

*******

You need to do a driver re-enable.

https://www.tenforums.com/tutorials/22631-enable-ahci-windows-8-windows-10-after-installation.html

I think what the author of the tutorial is doing there,
is enabling both some RAID options and the AHCI option.
This is in case the operator changes their mind
at the last minute, and doesn't make the BIOS change.

*******

The more reasonable solution is here. First, go back into
the BIOS and tip it upright again by enabling RAID. Boot up,
then you can review your BCD by typing just "bcdedit" with
no arguments, and it'll show current values.

This recipe changes a value, for a kind of safe mode.

https://forums.mydigitallife.net/threads/how-to-enable-ahci-in-windows-10.67319/

Admin Command Prompt

bcdedit /set {current} safeboot minimal

Then, after shutdown, changing to AHCI in BIOS, start up again, do

Admin Command Prompt

bcdedit /deletevalue {current} safeboot

And that's supposed to handle it.

Paul
Arlen Holder
2018-06-18 05:33:41 UTC
Permalink
Post by Paul
And when you changed it back to RAID again, what happened ?
The first (warm) boot failed after changing the controller back to RAID in
the BIOS, but the second cold boot worked fine, so I'm back in Windows 10.
Post by Paul
It probably booted, right ?
Yup. Changing FROM AHCI back to RAID enabled a cold boot to Windows again.
Thanks. Whew. That's one re-installation of Windows I just avoided! :)
Post by Paul
You need to do a driver re-enable.
The complexity never ends. :)
It doesn't seem like dual-boot is in the cards for this computer.
Post by Paul
https://www.tenforums.com/tutorials/22631-enable-ahci-windows-8-windows-10-after-installation.html
I think what the author of the tutorial is doing there,
is enabling both some RAID options and the AHCI option.
This is in case the operator changes their mind
at the last minute, and doesn't make the BIOS change.
Jesus. The complexity never ends.
I'm getting close to just giving up on getting a dual boot to work.
Post by Paul
The more reasonable solution is here. First, go back into
the BIOS and tip it upright again by enabling RAID. Boot up,
then you can review your BCD by typing just "bcdedit" with
no arguments, and it'll show current values.
bcdedit
...
device = partition=C:
path = \Windows\system32\winload.exe

Here is a screenshot:
<Loading Image...>
Post by Paul
This recipe changes a value, for a kind of safe mode.
https://forums.mydigitallife.net/threads/how-to-enable-ahci-in-windows-10.67319/
Admin Command Prompt
bcdedit /set {current} safeboot minimal
This says "The operation completed successfully."
Here is that screenshot again:
<http://img4.imagetitan.com/img.php?image=18_dualboot69.jpg>

I cold booted, twice, just to see if it would work, but Windows booted into
Safe Mode each time.
<Loading Image...>
Post by Paul
Then, after shutdown, changing to AHCI in BIOS
BTW, the RAID message still comes up during the boot process:
<Loading Image...>

I cold booted and pressed F10 to change the BIOS from RAID to AHCI.
And it warm booted to Windows 10 Safe Mode for a third time.
<Loading Image...>
Post by Paul
Start up again, do
Admin Command Prompt
bcdedit /deletevalue {current} safeboot
Since I'm stuck in Safe Mode, I'm not sure if this will work.
Trying it... it says "The operation completed successfully."
<Loading Image...>
Post by Paul
And that's supposed to handle it.
I then shut down the system and performed a cold boot.
It booted, using AHCI, to regular mode (i.e., not safe mode).
<Loading Image...>

So now I'm back in business, at least on Windows 10.

Then I popped the crappy-ass Ubuntu 18.04 Desktop installer ISO into the
DVD drive, and then cold booted which booted immediately to the Ubuntu DVD
(without me needing to press "Escape" to get to a boot menu).
<Loading Image...>

But it did the same dirty doo doo that Ubuntu 18.04 has been doing all
along...so I'm just about ready to give up on ever getting a dual boot to
work on this machine ever again.
<Loading Image...>

And, the "blkid /dev/sd*" command still reports the same thing too:
"promise_fasttrack_raid_member"
<Loading Image...

So, while I am at least booting using AHCI instead of RAID, I didn't make
any progress whatsoever on getting Ubuntu 18.04 to install alongside
Windows 10.

Bummer.
Paul
2018-06-18 06:23:31 UTC
Permalink
Post by Arlen Holder
So now I'm back in business, at least on Windows 10.
Then I popped the crappy-ass Ubuntu 18.04 Desktop installer ISO into the
DVD drive, and then cold booted which booted immediately to the Ubuntu DVD
(without me needing to press "Escape" to get to a boot menu).
<http://img4.imagetitan.com/img.php?image=18_dualboot79.jpg>
But it did the same dirty doo doo that Ubuntu 18.04 has been doing all
along...so I'm just about ready to give up on ever getting a dual boot to
work on this machine ever again.
<http://img4.imagetitan.com/img.php?image=18_dualboot76.jpg>
"promise_fasttrack_raid_member"
<http://img4.imagetitan.com/img.php?image=18_dualboot77.jpg
So, while I am at least booting using AHCI instead of RAID, I didn't make
any progress whatsoever on getting Ubuntu 18.04 to install alongside
Windows 10.
Bummer.
So the part that you "forgot", was any attempt to use
the BIOS RAID menu, to remove RAID metadata. Before
flipping to AHCI. You enter the RAID BIOS using <ctrl>-F
after enabling RAID the first time, Save and Exit, and on
the next BIOS POST, the RAID BIOS should be available for
<ctrl-F> entry. The timing window for entering the command
can be short.

Promise software (also licensed to AMD) isn't usually all
that good at that sort of thing.

However, let's take advantage of what we've got.

You could use this tool, to examine the end of the disk and
see if there's Promise metadata in the last 5 megabytes.
In the Extras menu, it will open a disk in raw mode for
examination. The usual rules apply - if a RAID driver
was being used, it could prevent examination of the
"real" end of the disk.

https://mh-nexus.de/en/hxd/

The other thing we could try, is seeing if a Linux tool
can specifically remove it.

Now, this is pretty geeky, and not particularly specific.
Maybe this would work while you're in AHCI mode, and can
"see" the end of the disk.

https://djlab.com/2013/07/removing-raid-metadata/

dd if=/dev/zero of=$YOUR_DEV bs=512 seek=$(( $(blockdev --getsz $YOUR_DEV) - 1024 )) count=1024

Now, rather than writing, you can try reading instead.
And save the contents of the end of the disk, in a small
binary sample file.

sudo dd if=/dev/sda of=endbits.bin bs=512 seek=$(( $(blockdev --getsz /dev/sda) - 10240 )) count=10240

The expression

blockdev --getsz /dev/sda

you could run that first and get the device size. And substitute
that into the seek arithmetic expression to get as a single integer result.

sudo dd if=/dev/sda of=endbits.bin bs=512 seek=somelargeinteger count=10240

Now, pop that 5MB file (512*10240) into the hxd hex editor or similar,
and there should be a small non-zero chunk in an otherwise
sea of zeros. I thought the reserved section at the end was
generally a fraction of a cylinder, and capturing that
small amount, should be sufficient to locate the
Promise metadata. This assumes it's at the end.

*******

This is an example of a <ctrl-F> manual. This would be
of the era where AMD licensed Promise RAID firmware for
the BIOS.

http://manuals.ts.fujitsu.com/file/10019/mx130s1-amd-raid-option-rom-ug-en.pdf

The functions are pretty minimal. There's no deletion of
RAID metadata as such. All you can do is delete
array definitions if any are present. While they mention
using RAIDXPert (an AMD download with a RAID Console for the OS
available on the HP web page for your machine), what are the odds
that's going to be any better ? Dunno.

So this task is likely above your payscale, unless
you can find a creative way of doing it. The linux
exhortations to use dmadm, might be wrong, as it's
a hardware RAID chunk that needs deletion.

But to start, I'd want to use a hex editor on the
raw disk and verify there really is such info on the
disk. Copying the end of the disk into "endbits.bin"
would be one way of doing that. If there's nothing
at the end of the disk, then this would be a red
herring. Yes, my experiments here showed that the
Ubuntu installer is perfectly happy if a working
RAID Mirror with Windows on it is present. It's
just a broken mirror that upsets it. Which suggests
some metadata got on there (somehow) and needs
to be overwritten with zeros.

You could back up Win10 onto a separate disk, find
a thorough way to erase the disk, then restore onto
the disk again. I don't like doing that, as it
means writing terabytes of data, when a little 64KB
"precision strike" write operation might be all that's
needed. Even if I used my old PDC 20378 to simulate
this situation and locate where the metadata is,
there's no guarantee that the 2018 version of this
approach is exactly the same as the crusty old hardware
I've got for this purpose.

Paul
David W. Hodgins
2018-06-17 09:10:10 UTC
Permalink
Post by Arlen Holder
When I boot to that bootable ISO and open a terminal window,
$ blkid
/dev/sda1: ... LABEL="Disk1" ... TYPE="ntfs"
/dev/sr0: ... LABEL="Ubuntu 18.04 LTS amd64" TYPE="iso9660"
<http://img4.imagetitan.com/img.php?image=18_dualboot52.jpg>
You missed the /dev/sd* parameter which will indicate whether it's a dos
(mbr) partition table, or a gpt partition table, as well as list the
partitions. Note for pcie ssd drives, the parameter would be /dev/nv*.

For example on my system it shows ...
$ /sbin/blkid /dev/sd*
/dev/sda: PTTYPE="dos"
/dev/sda1: LABEL="efi" UUID="3DAB-4B6E" TYPE="vfat"
/dev/sda10: LABEL="aback" UUID="07b89ef2-0604-4b4
<snip long list of paritions>
/dev/sdd: PTUUID="59455ef4-0b46-458f-8dd8-664f01172670" PTTYPE="gpt"
/dev/sdd1: LABEL="labeld1" UUID="2e8544e0-ce9f-43da-859f-36fd14de3a54" TYPE="ext4" PARTLABEL="named1" PARTUUID="9325...
<snip rest>

So sda is a dos/mbr partition table while sdd uses a gpt partition table.

As Carlos indicated fdisk can also provide useful info, though again I'd
add additional parameters ...
$ /sbin/fdisk -luS /dev/sd?

Regards, Dave Hodgins
--
Change ***@nomail.afraid.org to ***@teksavvy.com for
email replies.
Carlos E.R.
2018-06-17 10:00:49 UTC
Permalink
On Sun, 17 Jun 2018 03:13:10 -0400, Arlen Holder
Post by Arlen Holder
When I boot to that bootable ISO and open a terminal window,
 $ blkid
 /dev/sda1: ... LABEL="Disk1" ... TYPE="ntfs"
 /dev/sr0: ... LABEL="Ubuntu 18.04 LTS amd64" TYPE="iso9660"
 <http://img4.imagetitan.com/img.php?image=18_dualboot52.jpg>
You missed the /dev/sd* parameter which will indicate whether it's a dos
(mbr) partition table, or a gpt partition table, as well as list the
partitions. Note for pcie ssd drives, the parameter would be /dev/nv*.
On my system, plain "blkid" lists all partitions:


***@Telcontar:~> blkid
/dev/sda1: LABEL="c_storage_02" UUID="...
/dev/sdd1: LABEL="bios_grub" UUID="...
/dev/sdd2: LABEL="c_boot_1" UUID="...
/dev/sdd3: LABEL="c_boot_2" UUID="...


Your way apparently only sorts it differently:

***@Telcontar:~> blkid /dev/sd*
/dev/sda1: LABEL="c_storage_02"
/dev/sdb10: LABEL="a_test3" UUID="...

as root it gives information on the partition type, yes:

Telcontar:~ # blkid /dev/sd*
/dev/sda: PTUUID="..." PTTYPE="gpt"
/dev/sda1: LABEL="c_storage_02" UUID="...
/dev/sdb: PTUUID="..." PTTYPE="gpt"
/dev/sdb1: PARTLABEL="primary" PARTUUID="..."
/dev/sdb10: LABEL="a_test3" UUID="...
PARTUUID="99ed5c63-2166-46f5-8296-80ca9ec3461e"


The problem is it causes bash to expand the line to contain all devices
prior to calling blkid. It is thus bash who finds the devices, not blkid.
As Carlos indicated fdisk can also provide useful info, though again I'd
add additional parameters ...
$ /sbin/fdisk -luS /dev/sd?
Don't - because of bash expansion.

Just use "fdisk -l" or "fdisk -luS".

It will list all partitions and disks.
--
Cheers, Carlos.
David W. Hodgins
2018-06-17 10:42:38 UTC
Permalink
Post by Carlos E.R.
Post by David W. Hodgins
As Carlos indicated fdisk can also provide useful info, though again I'd
add additional parameters ...
$ /sbin/fdisk -luS /dev/sd?
Don't - because of bash expansion.
Just use "fdisk -l" or "fdisk -luS".
It will list all partitions and disks.
Just replying to this part for now.

I want it to use bash expansion, to select the hard drives and only the
hard drives. On my system without specifying the devices, the output
will also have the 16 ram drives listed first, so about 90 lines of
output I don't want, before the hard drive output.

Regards, Dave Hodgins
--
Change ***@nomail.afraid.org to ***@teksavvy.com for
email replies.
Arlen Holder
2018-06-17 21:51:48 UTC
Permalink
Post by David W. Hodgins
For example on my system it shows ...
$ /sbin/blkid /dev/sd*
$ /sbin/fdisk -luS /dev/sd?
Here is the result from the blkid /dev/sd*
<Loading Image...>

And here is the result from fdisk -luS /dev/sd?
<Loading Image...>

Both screenshots are summarized below for your convenience.
$ blkid /dev/sd*
/dev/sda: TYPE="promise_fasttrack_raid_member"
/dev/sda1: LABEL="Disk1" ... TYPE="ntfs" ...

$ sudo fdisk -luS /dev/sd?
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
...
Disklabel type: dos
Device = /dev/sda1
Boot = *
Start = 2048
End = 1871601663
Sectors = 1871599616
Size = 892.5G
Id = 7
Type = HPFS/NTFS/exFAT
Paul
2018-06-17 06:45:19 UTC
Permalink
Post by Arlen Holder
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD
as a dual boot?
I tried a half-dozen times, but Ubuntu 18.04 LTS desktop just won't *ask*
to install side-by-side to a new Windows 10 Pro 1803 in a single-HDD
dual-boot arrangement.
What I see here is a "pregnant pause" just before
your "weird unexpected" dialog shows up.

Since I used "TORAM=yes" on the boot line, there is
no DVD activity while the installer is running.
The entire DVD is held in RAM.

By doing that, if I see the hard drive light flash
on the front of the machine, I know for sure the
hard drive is being used.

So just before your "Install Type" thing, I see some
definite scanning activity, and not a short scan either.
I don't know what it's scanning, but it might be possible
to figure it out.

In any case, that doesn't solve your problem.

Your partition structure looks pretty simple. It's
marginally simpler than my test setup. I have two
0x27 NTFS System Reserved partitions as well as the
main 0x07 C: partition. Using MSDOS legacy partitioning.

*******

What the installer will do, if you insist on using the
automation, is it will create an Extended plus at
least one Logical. Even if there's room to create
a Primary.

What you would want (if the installer would give the
correct dialog box), is the "Something Else" option,
which allows the user to specify one or more
partitions. The role of each partition can be specified,
such as one small partition being for "swap", and
a larger partition being for "slash" AKA "/" the
root partition. The installer allows multiple partitions
to be defined under "/" in the traditional way, so you
could, say, put some home directories on another disk
or something.

I never do anything crazy like that.

But I do use the Something Else option to control
exactly where my "swap" will go, and what size "/"
I want. Then I start the install.

The following is the "side by side" option, and
what happens when using the automation.

Loading Image...

Loading Image...

Loading Image...

Loading Image...

*******

So back to your problem. How many hard drives
are connected currently. I had a single 500GB
hard drive connected for my test, and I got the
"correct" option with the "something else" offered
at the bottom.

Paul
Arlen Holder
2018-06-17 07:13:21 UTC
Permalink
Post by Paul
So back to your problem. How many hard drives
are connected currently. I had a single 500GB
hard drive connected for my test, and I got the
"correct" option with the "something else" offered
at the bottom.
Hi Paul,

The tower has 3 hard drives in it where the first picture in the original
post shows this picture where I disconnected the two older drives for the
purpose of installing Windows and Ubuntu on the brand new terabyte drive.
<http://img4.imagetitan.com/img.php?image=18_dualboot01.jpg>

In Windows, when I look at the disk, it seems fine:
<http://img4.imagetitan.com/img.php?image=18_dualboot51.jpg>

And yet, I can't get *this* message to come out of Ubuntu!
<https://i.stack.imgur.com/MADNE.png>

In essence, I don't see anything wrong, but at the same time, I can't get
Ubuntu to simply *ask* to be installed, side by side, with Windows.

Ubuntu seems to just want to install itself as the only hard drive:
<http://img4.imagetitan.com/img.php?image=18_dualboot42.jpg>

Maybe I'm supposed to "OK" that screen above?
(It sure doesn't seem like I should though as it seems to want to install
on top of Windows. Am I just misinterpreting what that screen is asking?)

In essence, all I'm asking is...
What's the trick to get Ubuntu to just *ask* to go alongside Windows?
stepore
2018-06-17 07:14:37 UTC
Permalink
Post by Arlen Holder
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD
as a dual boot?
Why doesn't Windows shut down properly?
Do you have "Fast startup" enabled in windows?

Windows 10 uses some stupid hybrid hibernation instead of a proper
shutdown. Try turning off fast startup or change the power off settings
or maybe even a

shutdown /s /t 0
from cmd or powershell i guess should work.

Then try again.

And please, for the love of Ghawd, settle down. Take a breath. And stop
saying side-by-side.
Paul
2018-06-17 08:09:35 UTC
Permalink
Post by stepore
Post by Arlen Holder
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD
as a dual boot?
Why doesn't Windows shut down properly?
Do you have "Fast startup" enabled in windows?
Windows 10 uses some stupid hybrid hibernation instead of a proper
shutdown. Try turning off fast startup or change the power off settings
or maybe even a
shutdown /s /t 0
from cmd or powershell i guess should work.
Then try again.
And please, for the love of Ghawd, settle down. Take a breath. And stop
saying side-by-side.
On my test setup, normally I keep Fast Startup disabled
(by using powercfg /h off). With Fast Startup enabled,
you can see "complaints" about the Windows partitions
being mountable read-only (boot log/dmesg), but the
Ubiquity menu here continues to present the correct dialog
on my setup.

So that doesn't appear to cause the "Install Type"
dialog to appear.

There's got to be something else, like too many
disks.

*******

This string, appears in the following bug report:

No devices are listed in the "Installation Type" screen

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1064151

I have tried the "nodmraid" option and still have the problem.

So the theory in that thread, near the bottom, is
that Ubiquity has gone off on a RAID lark of some sort.

But nobody returns in the thread to say the idea
resolved the problem.

Paul
Paul
2018-06-17 08:29:10 UTC
Permalink
Post by Paul
So the theory in that thread, near the bottom, is
that Ubiquity has gone off on a RAID lark of some sort.
https://forums.linuxmint.com/viewtopic.php?f=46&t=145768

"i had the exact same problem and this solved it:

Usually this happens if there is raid metadata on the disk.
If the disk was used in raid earlier, or similar.
Formatting doesn't remove the metadata.

If you are NOT running raid, boot into live mode and do:

sudo dmraid -r -E /dev/sda (or /dev/sdb, etc,
depending on the disk name)

but the issue is my latop (HP ENVY 6t-1000) has the
"intel smart start technology" which really *is* a
raid setup. So as soon as i run it, it borks my windows
install. and i have to run recovery when i try and boot
into it. :S
"

Sounds like fun.

You have to be real careful with RAID setups.

After you're done with them, it helps to thoroughly
clean them. Secure Erase will do that.

I've found in some cases, shoving the drive into
a second computer that cannot possibly recognize
the RAID metadata, enhances the ability to easily
clean it. A diskpart "clean all" is then sufficient.
Or roll your own with "dd" in such a case (dd with
/dev/zero is equivalent).

If you're good with math, the metadata is up near
the end of the disk (not always, but a good percentage
of the time), and the appropriate "seek" or
"skip" option to the dd program, will reduce the
erasure time for the metadata considerably. I've done
RAID experiments before, specifically so I would
know the offset of such metadata. (Zero the disk,
add RAID metadata, pull the disk and use a hex
editor to examine the disk on a second, non-RAID machine.)

In any case, if you F*** with RAID, you get
what you deserve. Been there, and done that,
and learned my lesson. Not only is RAID fun
to set up, it's also fun to get rid of
(properly). If the above dmraid -r -E /dev/sda
invocation does anything, I would be surprised,
as RAID does not give up easily :-)

If you really want to have some fun, clip down
two disks with HPA (Host Protected Area). Then
add RAID. Which will position the metadata in
an abnormal location. Removing the HPA later,
causes the metadata to "get lost in the lower part
of the disk". But of course, an HPA is even worse!!!
You're only allowed one HPA command per boot cycle,
so you have to reboot many many times, to carry out
HPA projects. I've used that technique to make
"small disks", for the purpose of carrying out
install procedures for RAID setups. You don't want
to wait all night for a pair of 2TB mirrors to clone.
Whereas if they're clipped down to 4GB disk size each,
it takes no time at all to do various experiments.
My 4GB hard drive here only does 5MB/sec, so you
would not want to use two actual 4GB hard drives
for this purpose. That would suck.

Paul
Paul
2018-06-17 18:49:26 UTC
Permalink
Post by Paul
Post by Paul
So the theory in that thread, near the bottom, is
that Ubiquity has gone off on a RAID lark of some sort.
https://forums.linuxmint.com/viewtopic.php?f=46&t=145768
Usually this happens if there is raid metadata on the disk.
If the disk was used in raid earlier, or similar.
Formatting doesn't remove the metadata.
sudo dmraid -r -E /dev/sda (or /dev/sdb, etc,
depending on the disk name)
but the issue is my latop (HP ENVY 6t-1000) has the
"intel smart start technology" which really *is* a
raid setup. So as soon as i run it, it borks my windows
install. and i have to run recovery when i try and boot
into it. :S
"
Sounds like fun.
Reproduced!

I switched the motherboard to RAID mode in the BIOS.

Installed two disks. Installed Win10 as a RAID1 mirror
on Intel RSTe (inbox driver, no RAID console).

1) Booted Ubuntu with the two disk mirror present.
The install menu works properly. Since the volume
hadn't been resized, Ubuntu offered to erase Win10
and install Ubuntu instead. So this case seems to
be working fine.

2) Unplugged one hard drive. Windows still boots,
as it's a "degraded" RAID1 mirror. The BIOS RAID screen
at startup, confirms "degraded" in yellow letters.

Boot Ubuntu now, and the installer menu shows
the "Install Type" screen without elaborating.

Loading Image...

Loading Image...

Loading Image...

The degraded RAID1 drive also mounts normally
when double-clicked in file management. Which means the
PARTTYPE wasn't quite as mysterious as claimed. In fact,
there's no sign in DMESG, of anything RAID at all.

Paul
Grant Taylor
2018-06-17 19:49:34 UTC
Permalink
Post by Paul
Reproduced!
Yay.
Post by Paul
I switched the motherboard to RAID mode in the BIOS.
Installed two disks. Installed Win10 as a RAID1 mirror on Intel RSTe
(inbox driver, no RAID console).
1) Booted Ubuntu with the two disk mirror present. The install menu works
properly. Since the volume hadn't been resized, Ubuntu offered to erase
Win10 and install Ubuntu instead. So this case seems to be working fine.
2) Unplugged one hard drive. Windows still boots, as it's a "degraded"
RAID1 mirror. The BIOS RAID screen at startup, confirms "degraded"
in yellow letters.
Boot Ubuntu now, and the installer menu shows the "Install Type" screen
without elaborating.
Nice investigative work Paul.
Post by Paul
The degraded RAID1 drive also mounts normally when double-clicked in
file management. Which means the PARTTYPE wasn't quite as mysterious as
claimed. In fact, there's no sign in DMESG, of anything RAID at all.
I suspect that the mounting is relying on magic information for the file
system more than information for the partition type.

I do question what the path would be back from this to a fully
functional RAID. I suspect that Windows could be fixed to have an
optimal RAID again. I doubt that the Linux install would be RAIDed.

This sounds like (what I think is called) a "swing root" type RAID where
it's actually two stand alone disks and a software driver in kernel that
applies software RAID at the driver layer below the block device. I
think it also requires completely ignoring the underlying disks.

I've also heard this type of RAID referred to as "Fake RAID". I can see
how it could cause complications that an installer wants to just avoid.
--
Grant. . . .
unix || die
Paul
2018-06-17 19:59:10 UTC
Permalink
Post by Grant Taylor
Post by Paul
Reproduced!
Yay.
Post by Paul
I switched the motherboard to RAID mode in the BIOS.
Installed two disks. Installed Win10 as a RAID1 mirror on Intel RSTe
(inbox driver, no RAID console).
1) Booted Ubuntu with the two disk mirror present. The install menu
works properly. Since the volume hadn't been resized, Ubuntu offered
to erase Win10 and install Ubuntu instead. So this case seems to be
working fine.
2) Unplugged one hard drive. Windows still boots, as it's a "degraded"
RAID1 mirror. The BIOS RAID screen at startup, confirms "degraded" in
yellow letters.
Boot Ubuntu now, and the installer menu shows the "Install Type"
screen without elaborating.
Nice investigative work Paul.
Post by Paul
The degraded RAID1 drive also mounts normally when double-clicked in
file management. Which means the PARTTYPE wasn't quite as mysterious
as claimed. In fact, there's no sign in DMESG, of anything RAID at all.
I suspect that the mounting is relying on magic information for the file
system more than information for the partition type.
I do question what the path would be back from this to a fully
functional RAID. I suspect that Windows could be fixed to have an
optimal RAID again. I doubt that the Linux install would be RAIDed.
This sounds like (what I think is called) a "swing root" type RAID where
it's actually two stand alone disks and a software driver in kernel that
applies software RAID at the driver layer below the block device. I
think it also requires completely ignoring the underlying disks.
I've also heard this type of RAID referred to as "Fake RAID". I can see
how it could cause complications that an installer wants to just avoid.
It's a RAID1 mirror, and repair would consist of using the
"Rebuild" command at BIOS level. Some RAID implementations
can rebuild at runtime, but I don't know whether Intel RSTe
does that or not.

The OS in this case has an in-box driver. Downloading
a driver and RAID Console from the Intel site, gives
additional functionality. In the RAID Console for example,
you would be able to see the degraded status.

In my experiment, with only inbox driver to work with,
the BIOS has the yellow "degraded" text, which stays
on the screen for ten seconds. But there's not a peep
from the Win10 OS screens - not even a Notification of
a degraded array. Which means pushing the power
button and walking away, you lose the ability to
detect your RAID1 has degraded.

But if you installed the full Intel package, there
would be other possible outcomes.

The inbox drivers typically are just drivers and
not consoles. For example, sound works a similar way.
If you want "all the sound functions" in a control
panel, you'd install the RealTek audio package, rather
than use the generic inbox HDAudio driver.

Paul
Wolf K
2018-06-17 11:14:37 UTC
Permalink
Post by Arlen Holder
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD
as a dual boot?
I tried a half-dozen times, but Ubuntu 18.04 LTS desktop just won't*ask*
to install side-by-side to a new Windows 10 Pro 1803 in a single-HDD
dual-boot arrangement.
Any ideas why the latest Ubuntu desktop won't install side-by-side
next to the latest Windows 10 Pro?
[...]

Try creating unallocated space or a blank partition.
--
Wolf K
kirkwood40.blogspot.com
Ethics is knowing the difference between what you have a right to do and
what is right to do. Potter Stewart
Arlen Holder
2018-06-17 22:39:24 UTC
Permalink
Post by Wolf K
Try creating unallocated space or a blank partition.
In the original post, I had pasted this image of the unallocated space:
<http://img4.imagetitan.com/img.php?image=18_dualboot06.jpg>

Those 40000MB were created by running "Shrink volume" on the original
terabyte hard disk drive which Windows was installed on.

As noted in the original post, those 40000MB were created following the
instructions here:
<https://www.linuxtechi.com/dual-boot-ubuntu-18-04-lts-with-windows-10/>
Dirk T. Verbeek
2018-06-17 20:14:14 UTC
Permalink
Post by Arlen Holder
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD
as a dual boot?
I tried a half-dozen times, but Ubuntu 18.04 LTS desktop just won't *ask*
to install side-by-side to a new Windows 10 Pro 1803 in a single-HDD
dual-boot arrangement.
Any ideas why the latest Ubuntu desktop won't install side-by-side
next to the latest Windows 10 Pro?
Did I skip a step somehow in the tutorials?
Did the tutorials skip a step?
Or did I find a bug in Ubuntu?
======== everything below is gory detail on that question ==========
The "Try Ubuntu" boots fine but the "Install Ubuntu" will not ask to be
placed side-by-side with Windows 10 Pro no matter how many
times I've tried.
Either I did something wrong - or it's a bug in Ubuntu as I followed the
tutorials below (skipping the "optional" fast-boot disabling step).
<https://www.linuxtechi.com/dual-boot-ubuntu-18-04-lts-with-windows-10/>
<https://linoxide.com/distros/install-ubuntu-18-04-dual-boot-windows-10/.
<https://askubuntu.com/questions/1031993/how-to-install-ubuntu-18-04-alongside-windows-10>
<https://www.techsupportpk.com/2018/05/how-to-install-ubuntu-1804-desktop-dual-boot-with-windows-10.html>
<https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/how-to-install-ubuntu-18-04-alongside-with-windows-10-or-8-in-dual-boot.html>
As usual, I write up the steps ahead of time and print them, so that
I can follow them perfectly, but the actual steps are almost never those
that are documented, so it's either a corner case where I need a different
step, or my first Ubuntu 18.04LTS bug (I seem to have a sad gift for
finding bugs in operating systems).
All I want to do is install Ubuntu side by side with Windows 10 Pro.
I'd be perfectly happy to be told *where* my user error is, so I documented
*every* step so that we can figure out if this is user error or a bug in
Ubuntu setup or a bug in the tutorials.
* I put a new HDD in an older HP Pavillion desktop tower
* I created a Windows 10 ISO using the standard media-creation tool method
<https://www.microsoft.com/en-us/software-download/windows10>
* I installed the latest Win10 Pro which automatically activated just fine
* I created the Ubuntu ISO from https://www.ubuntu.com/download/desktop
---------------------------
Checksum information
---------------------------
Name: ubuntu-18.04-desktop-amd64.iso
Size: 1921843200 bytes (1832 MB)
SHA256: A55353D837CBF7BC006CF49EEFF05AE5044E757498E30643A9199B9A25BC9A34
---------------------------
* Note that the Ethernet cable is connected to a rooftop WiFi antenna
* This setup requires a static IP address of 192.168.1.something
* I disconnected all other disks so that the install disk is unambiguous
* Only 1 disk remains which is the terabyte Windows 10 Pro boot disk
* Run the HP F9 Diagnostic test on the CPU, memory, & HDD (all pass)
* Boot to the recently installed Windows 10 Pro 1803 (latest version)
* On Windows, run msinfo32 to figure out if you're using BIOS or EFI
RMBStart > Run > msinfo32
BIOS Mode = Legacy <== this is BIOS <== this is what mine reports
BIOS Mode = UEFI <== this is EFI <== mine does not report this
* Run Disk Management to create space RMBStart > Run > diskmgmt.msc
* Right click on the volume > Shrink Volume
* Enter the amount of space to shrink in MB = 40000 (aka 40GB)
* Mine showed 38.87GB unallocated show up next to C: 892.45GB
* Put the Ubuntu 18.04LTS desktop boot disc in the DVD drive
* Shut down the PC & then turn the power back on
* Press ESC at POST to boot to the boot selection
* Choose to boot off the Ubuntu boot disc in the DVD drive
* Ubuntu Welcome screen asks "Try Ubuntu" or "Install Ubuntu"
* Press "Install Ubuntu" (although it will never work!)
* Accept the English(US) keyboard layout
* Leave the "Updates and other software" at the default
* Note: It doesn't matter *what* options you choose - it fails every time
* At this point, you're *supposed* to get a screen giving you a choice
* You're supposed to be able to install "side by side" with Windows 10
* But this screen only proves an "Installation type" of /dev/sda
That's the bug. Or error.
You can't install Ubuntu side by side with Windows 10 Pro.
* Your only choice is to quit the installation
* At this point, you notice the "wired" Ethernet never connected
* NOTE: There is no way to make that wired connection manually yet anyway
* At this point, the system continues to Ubuntu 18.04 using the DVD
* Once at the Ubuntu desktop, there is an "Install Ubuntu 18.04 LTS" icon
* But first, let's finally manually connect to the "wired" Intenet
* Set IVP4 to 192.168.1.something, 255.255.255.0, 192.168.1.1, 8.8.8.8
* Now, for the first time possible, you're on the Internet (ping google)
* Now you can click "Install Ubuntu 18.04 LTS" but it will never work
* The exact same problem happens where you don't get the side-by-side
choice
This is either a bug in the tutorials (they skipped some steps?),
or this is a bug in Ubuntu (it won't set up a side-by-side installation),
or I am doing a step wrong (or skipping a step that isn't documented).
Any ideas why the latest Ubuntu desktop won't install side-by-side
next to the latest Windows 10 Pro?
===== everything below is gory documentation of the steps =====
Following are forty-nine sequential photos documenting every step in gory
a. User error in following the tutorials (maybe I missed a step?)
b. A bug in the tutorials (maybe they skipped a step?)
c. A bug in Ubuntu (maybe they never tested the installation this way?)
<SNIP>
In summary, can you offer a suggestion as to why Ubuntu 18.04 does not ask
to install next to Windows 10 Pro single HDD as a dual boot setup?
Having read the other replies I would try a different approach.
I believe Win10 also has a utility to make free space on the C drive.
Or use the utility on the boot disk to do the same.
Next use the boot disk utility to repartition the free space.
Now install using manual partitioning.
Paul
2018-06-17 20:31:09 UTC
Permalink
Post by Dirk T. Verbeek
Having read the other replies I would try a different approach.
I believe Win10 also has a utility to make free space on the C drive.
Or use the utility on the boot disk to do the same.
Next use the boot disk utility to repartition the free space.
Now install using manual partitioning.
He can't get to the "Something Else" screen, as it
drops to the "Install Type" screen, which offers no
controls. It's because PARTTYPE returns <unknown>
so the installer is effectively bailing, but
without explaining why to the user.

It drops to the "Install Type" screen, because there
is RAID metadata that it does not comprehend. Apparently,
for example, a degraded mirror is not something it understands.
The main (Live) OS doesn't have a problem with the
degraded mirror, and will still mount the partition
on it.

The installer is not a total write-off. If you have
an actual working RAID array (like a RAID1 mirror),
it does recognize that, and offers the usual options
(which would include "Something Else"). So if the
OPs RAID was still functional, this wouldn't have
happened.

When you experiment with RAID, *don't forget* the
cleanup steps when you're finished... Been there
and done that. You can come back months later,
do something with your scratch disks, get
strange symptoms... and then a light goes
on and "oh yeah, this is my RAID disk experiment".
As I write this, the RAID cleaning process is
running on the other computer, to prevent future
issues with the scratch drives I used.

Paul
Arlen Holder
2018-06-17 22:23:02 UTC
Permalink
Post by Paul
As I write this, the RAID cleaning process is
running on the other computer, to prevent future
issues with the scratch drives I used.
Hi Paul,
I'm thoroughly confused about both the RAID thing (which none of the
tutorials mentioned) and the disabling of Fast Startup (which all the
tutorials said was optional).

You are totally correct though that there is some kind of "hardware"
(BIOS?) RAID thingey set up - but - there is no RAID (and there has never
been a RAID since I have had this desktop).

This screenshot from the original post is the only indication that RAID
even exists in any form (which must be coming from the computer hardware):
<http://img4.imagetitan.com/img.php?image=18_dualboot11.jpg>

The problem is, as you know, that I can't get Ubuntu to step 2 below:
STEP 1:
<https://www.linuxtechi.com/wp-content/uploads/2018/05/Installlation-type-ubuntu18-04.jpg>
STEP 2:
<https://www.linuxtechi.com/wp-content/uploads/2018/05/Install-ubuntu-along-windows10.jpg>
Where the tutorials show them as sequential!
<https://www.linuxtechi.com/dual-boot-ubuntu-18-04-lts-with-windows-10/>

That tutorial doesn't even mention fastboot.

This tutorial, likewise, shows those two screens as sequential:
<https://linoxide.com/distros/install-ubuntu-18-04-dual-boot-windows-10/>
But that tutorial shows Windows options that don't exist on my Windows PC.

Nonetheless, that tutorial does at least discuss "fast startup" but all it
says is that fast startup can prevent a boot to the Ubuntu CD, which
clearly isn't my problem.

Nonetheless, I have no problem attempting to shut off Windows fast startup
(aka fast boot) where that tutorial says to follow this procedure:
RMB-Start > Run > Power Options > Choose what the power buttons do >
Change settings that are currently unavailable >
Uncheck [x]Turn on fast startup
Then...
LMB-Start > Settings > Update & Security > Recovery > Advanced startup >
Restart now > Troubleshoot > UEFI Firmware Settings > Restart
[Note that I don't have EUFI because I have BIOS (legacy).]

As usual, the tutorial was wrong in some ways where my latest Windows 10
Pro has the following steps.
RMB-Start > Run > Power Options > Related settings >
Additional power settings > Choose what the power buttons do >
Change settings that are currently unavailable >
Uncheck [x]Turn on fast startup > Save changes
Then...
LMB-Start > Settings > Home > Update & Security > Recovery >
Advanced startup > Restart now (which said "Please wait" on a blue screen
Troubleshoot > But then there was nothing familiar in the tutorial
My only choice now was (a) Reset this PC or (b) Advanced options
I didn't get anything at this point that was in the tutorial so I
simply hit the Advanced options and then Startup, but then it got deep
so I simply returned to the operating system.

I'm not sure how to tell if "Advanced startup" is now disabled though.
And I'm not sure how to (or if I should) disable the RAID thingey.
[The disk is not RAIDed and it never was to my knowledge.]
Carlos E.R.
2018-06-17 23:23:57 UTC
Permalink
Post by Arlen Holder
Post by Paul
As I write this, the RAID cleaning process is
running on the other computer, to prevent future
issues with the scratch drives I used.
Hi Paul,
I'm thoroughly confused about both the RAID thing (which none of the
tutorials mentioned) and the disabling of Fast Startup (which all the
tutorials said was optional).
Why should they mention that? They did not create the raid.
Post by Arlen Holder
You are totally correct though that there is some kind of "hardware"
(BIOS?) RAID thingey set up - but - there is no RAID (and there has never
been a RAID since I have had this desktop).
This screenshot from the original post is the only indication that RAID
<http://img4.imagetitan.com/img.php?image=18_dualboot11.jpg>
Irrelevant.
Post by Arlen Holder
LMB-Start > Settings > Update & Security > Recovery > Advanced startup >
Restart now > Troubleshoot > UEFI Firmware Settings > Restart
[Note that I don't have EUFI because I have BIOS (legacy).]
As usual, the tutorial was wrong in some ways where my latest Windows 10
Pro has the following steps.
Gosh, do you really expect the tutorial to describe every possibly
situation in every computer?
--
Cheers, Carlos.
Paul
2018-06-17 23:24:15 UTC
Permalink
Post by Arlen Holder
Post by Paul
As I write this, the RAID cleaning process is
running on the other computer, to prevent future
issues with the scratch drives I used.
Hi Paul,
I'm thoroughly confused about both the RAID thing (which none of the
tutorials mentioned) and the disabling of Fast Startup (which all the
tutorials said was optional).
You are totally correct though that there is some kind of "hardware"
(BIOS?) RAID thingey set up - but - there is no RAID (and there has never
been a RAID since I have had this desktop).
This screenshot from the original post is the only indication that RAID
<http://img4.imagetitan.com/img.php?image=18_dualboot11.jpg>
<https://www.linuxtechi.com/wp-content/uploads/2018/05/Installlation-type-ubuntu18-04.jpg>
<https://www.linuxtechi.com/wp-content/uploads/2018/05/Install-ubuntu-along-windows10.jpg>
Where the tutorials show them as sequential!
<https://www.linuxtechi.com/dual-boot-ubuntu-18-04-lts-with-windows-10/>
That tutorial doesn't even mention fastboot.
<https://linoxide.com/distros/install-ubuntu-18-04-dual-boot-windows-10/>
But that tutorial shows Windows options that don't exist on my Windows PC.
Nonetheless, that tutorial does at least discuss "fast startup" but all it
says is that fast startup can prevent a boot to the Ubuntu CD, which
clearly isn't my problem.
Nonetheless, I have no problem attempting to shut off Windows fast startup
RMB-Start > Run > Power Options > Choose what the power buttons do >
Change settings that are currently unavailable >
Uncheck [x]Turn on fast startup
Then...
LMB-Start > Settings > Update & Security > Recovery > Advanced startup >
Restart now > Troubleshoot > UEFI Firmware Settings > Restart
[Note that I don't have EUFI because I have BIOS (legacy).]
As usual, the tutorial was wrong in some ways where my latest Windows 10
Pro has the following steps.
RMB-Start > Run > Power Options > Related settings >
Additional power settings > Choose what the power buttons do >
Change settings that are currently unavailable >
Uncheck [x]Turn on fast startup > Save changes
Then...
LMB-Start > Settings > Home > Update & Security > Recovery >
Advanced startup > Restart now (which said "Please wait" on a blue screen
Troubleshoot > But then there was nothing familiar in the tutorial
My only choice now was (a) Reset this PC or (b) Advanced options
I didn't get anything at this point that was in the tutorial so I
simply hit the Advanced options and then Startup, but then it got deep
so I simply returned to the operating system.
I'm not sure how to tell if "Advanced startup" is now disabled though.
And I'm not sure how to (or if I should) disable the RAID thingey.
[The disk is not RAIDed and it never was to my knowledge.]
In one of my posts, I tested Fast Startup ON and Fast Startup OFF.

If you read your DMESG output, there will be warnings about
Fast Startup ON causing NTFS volume mounts to be read-only.

It turns out this makes NO DIFFERENCE to the Ubuntu installer.
It was still able to scan the C: drive and determine it was
Windows 10, and offer the usual options such as "install
beside" or "erase whole disk" or "Something Else".

*******

However, the RAID situation was where it got interesting.

With Windows 10 on a fully functional two disk RAID1 mirror,
the Ubuntu installer STILL worked properly. You would
have to shrink a partition or whatever, to get the
"install beside".

But when one disk was removed from the RAID mirror pair,
dropping the array to "degraded status", that's when the
"Install Type" dialog appeared instead of the desired
dialog while using the Ubuntu installer.

That suggests that some sort of "slightly damaged"
RAID metadata is enough to trigger your problem.
The "disks" utility in Linux shows "<unknown>" for
the partition type, when in fact it's blindingly
obvious it's still MBR partitioned and working
fine. The regular file manager in the LiveCD has
no problem mounting partitions from there. It's
whatever passes for a "PARTTYPE" piece of code,
that has the problem. I think instead of whining
about the MBR, instead it's done a series of
RAID probes and decided the pattern is not
something it recognizes. Once the <unknown>
status is detected, it in effect "bails on
ruining the RAID".

Of all the test cases, only one test case matched
yours, and that's "degraded RAID metadata", not
"fully functional RAID metadata" or any other
corner case that I tried.

*******

You'll have fun with the Promise controller, I
assure you. Steps I would do:

1) Back up the OS partition on the Promise drive.
Just in case erasure is called for. It shouldn't
take long to back up a fresh install.
2) Inspect the available documentation for your
Promise chip. For example, it might be a 20378.
3) Once you figure out a way to set the metadata
back to "JBOD" or you managed to erase it entirely,
you can use your backup software emergency boot
disk, to restore your OS to the drive. There
should be no problem restoring it. I'm not convinced
the metadata issue is broken enough for either
OS type to stop booting.

Note that "naive erasure" of a drive is NOT ENOUGH.
When a RAID controller sees RAID metadata, it
moves the end_of_disk mark, such that no "ordinary"
writes can reach the RAID metadata.

The RAID console, or the RAID BIOS interface, can
write that area.

Moving the Promise disk to an Intel SATA port, now
the disk will become full sized again, making erasure
of the metadata area possible again. Very few branded
RAID problems, are portable. Promise doesn't recognize
Intel, and Intel doesn't recognize Promise. Tomshardware
did a matrix test years ago, proving what people
already knew anecdotally.

Note that AMD licenses Promise RAID technology for some
of its SBxxx Southbridges. If the RAID BIOS uses
<ctrl> F for BIOS entry for example, that's the Promise
hotkey, present on an AMD Southbridge motherboard.
That port then, would offer less-good odds of
exposing the entire platter surface. Only if
the AMD software was particularly generous when
dealing with the metadata issues, would the AMD
port be a win (when the original problem was
caused by a Promise product).

Promise metadata is "mostly compatible" across
the Promise product line. AFAIK that was a design
objective, even if some of their more advanced controllers
support modes the older stuff doesn't. A RAID1 Mirror
for example, should work across lots of their stuff,
as it's a very simple config.

Good luck,
Paul
Arlen Holder
2018-06-19 10:16:12 UTC
Permalink
Post by Arlen Holder
Why doesn't Ubuntu 18.04 ask to install next to Windows 10 Pro single HDD
as a dual boot?
****************************************************************************
SOLVED!
a. Ubuntu 18.04 would not ask to be installed alongside Windows.
b. None of the tutorials covered this specific installation problem.
c. There was no error message whatsoever to run a search upon.
****************************************************************************
PROBLEM:
A. The "Promise" RAID controller puts "RAID dung" on all JBOD drives.
B. It does this even when RAID has never been used on these JBOD drives.
C. The catch-22 RAID dung is placed in an inaccessible location.
D. Where reformatting & poartioning & reinstalling Windows has no effect!
E. Until removed, the Ubuntu 18.04 installer didn't like this RAID dung.
(Tecnically, the Raid dung appears as a "falsely degraded array" to
Ubuntu.)
F. So Ubuntu silently skipped asking about booting alongside Windows.
============================================================================
IDENTIFICATION:
1. There is no known command in Windows which will identify this problem.
2. The only command in Linux that identifies the problem is "blkid
/dev/sd*".
3. No other command on either OS is known to identify this specific
problem.
PROBLEM: /dev/sda TYPE="promise_fasttrack_raid_member"
NO_PROB: /dev/sda TYPE="ntfs"
4. Another catch-22 is that the sequence has to be done in perfect order!
----------------------------------------------------------------------------
HOMEWORK:
A. Becuse of this issue, not a single tutorial worked as documented.
B. Not a single tutorial covered this issue even in the slightest way.
C. For reference, these were the tutorials that were consulted.
<https://www.linuxtechi.com/dual-boot-ubuntu-18-04-lts-with-windows-10/>

<https://linoxide.com/distros/install-ubuntu-18-04-dual-boot-windows-10/.

<https://askubuntu.com/questions/1031993/how-to-install-ubuntu-18-04-alongside-windows-10>

<https://www.techsupportpk.com/2018/05/how-to-install-ubuntu-1804-desktop-dual-boot-with-windows-10.html>

<https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/how-to-install-ubuntu-18-04-alongside-with-windows-10-or-8-in-dual-boot.html>
etc.
____________________________________________________________________________
SOLUTION:
1. The solution involves a series of Catch-22 situations.
2. They're best summarized as two delicately performed steps:
Delicately change the BIOS "SATA Controller Mode" from "RAID" to "AHCI".
Delicately wipe out the RAID dung (using "dd" or "diskpart clean all").
(Bear in mind the dung is located in an inaccessible location.)
3. The catch-22 is that it's almost impossible to do delicately though.
4. In this case, the entire HDD (every single bit) had to be wiped clean.
****************************************************************************
DETAILS:
The desktop is manually networked via Ethernet to a rooftop antenna:
<http://img4.imagetitan.com/img.php?image=18_dualboot01.jpg>

All HDDs were disconnected save for a single brand-new 1TB HDD:
<http://img4.imagetitan.com/img.php?image=18_dualboot02.jpg>

Pressing F9 at POST shows the brand-new HD passes hardware diagnostics:
<http://img4.imagetitan.com/img.php?image=18_dualboot03.jpg>

The Windows 10 Pro installation is the absolute latest 1803 update:
<http://img4.imagetitan.com/img.php?image=18_dualboot04.jpg>

Windows' msinfo32 shows a legacy BIOS (and not EFI):
<http://img4.imagetitan.com/img.php?image=18_dualboot05.jpg>

Windows' disk management was used to create a 40GB partition for Ubuntu:
<http://img4.imagetitan.com/img.php?image=18_dualboot06.jpg>

Create & boot off of Ubuntu from https://www.ubuntu.com/download/desktop
Name: ubuntu-18.04-desktop-amd64.iso
Size: 1921843200 bytes (1832 MB)
SHA256: A55353D837CBF7BC006CF49EEFF05AE5044E757498E30643A9199B9A25BC9A34
<http://img4.imagetitan.com/img.php?image=18_dualboot07.jpg>

In all cases of rebooting, I shut down the system (cold boot):
<http://img4.imagetitan.com/img.php?image=18_dualboot08.jpg>

But there is a quick-boot feature of Windows which is best turned off:
<http://img4.imagetitan.com/img.php?image=18_dualboot09.jpg>

At this point, booting to Windows worked always sans any errors:
<http://img4.imagetitan.com/img.php?image=18_dualboot10.jpg>

In hindsight, the first clue (had we known) was that this HP Pavillion
AMD-based setup contains "Promise" RAID controller software which,
apparently, places what I've called "RAID dung" on all JBOD devices,
even when RAID isn't being used on any of those hard drives.
<http://img4.imagetitan.com/img.php?image=18_dualboot11.jpg>

Notice there is no error in Windows or in the hardware boot process:
<http://img4.imagetitan.com/img.php?image=18_dualboot12.jpg>

For this HP device, F10, Escape, & F9 are the pertinent keys
where F10 after POST brings up the BIOS menu, and where
the Escape key after POST brings up the boot menu, and, where
the F9 key after POST brings up a hardware diagnostic menu.
(The F11 System Recovery key appears to do absolutely nothing.)
<http://img4.imagetitan.com/img.php?image=18_dualboot13.jpg>

Pressing Escape at POST allows us to boot off the DVD or HDD:
<http://img4.imagetitan.com/img.php?image=18_dualboot14.jpg>

For setting up Ubuntu alongside Windows, we needed to boot
off the HP DVD drive:
<http://img4.imagetitan.com/img.php?image=18_dualboot15.jpg>

That allowed the Ubuntu 18.04 Desktop ISO to boot:
<http://img4.imagetitan.com/img.php?image=18_dualboot16.jpg>

Which didn't show any error messages whatsoever while booting:
<http://img4.imagetitan.com/img.php?image=18_dualboot17.jpg>

Things proceeded normally where Ubuntu presents the choice of:
[Try Ubuntu] or [Install Ubuntu]
<http://img4.imagetitan.com/img.php?image=18_dualboot18.jpg>

Following the tutorial, I hit the "Install Ubuntu" button:
<http://img4.imagetitan.com/img.php?image=18_dualboot19.jpg>

Which asks for the keyboard layout (default is English US)
<http://img4.imagetitan.com/img.php?image=18_dualboot20.jpg>

And then asks the penultimate question of "normal installation":
<http://img4.imagetitan.com/img.php?image=18_dualboot21.jpg>

Where Ubuntu skips the question of installing alongside Windows!
<http://img4.imagetitan.com/img.php?image=18_dualboot22.jpg>

And where the only choice is to overwrite the entire boot drive!
<http://img4.imagetitan.com/img.php?image=18_dualboot23.jpg>

Of course, the only recourse is to quit the Ubuntu installation:
<http://img4.imagetitan.com/img.php?image=18_dualboot24.jpg>

But even if we hit "Install Now" on /dev/sda, it would fail
to do anything. No error results. Just nothing would happen.
<http://img4.imagetitan.com/img.php?image=18_dualboot25.jpg>

I thought it might be due to the lack of an Ethernet network
at the time of installation (e.g., maybe Ubuntu needed some
files) but there is no way to manually set up the network:
<http://img4.imagetitan.com/img.php?image=18_dualboot26.jpg>

So you can only "Quick the installation" as your only option:
<http://img4.imagetitan.com/img.php?image=18_dualboot27.jpg>

Because even selecting to install on /dev/sda will fail to work:
<http://img4.imagetitan.com/img.php?image=18_dualboot28.jpg>

Where eventually, you realize your only other choice is to
abort the installation and boot to the Ubuntu live DVD:
<http://img4.imagetitan.com/img.php?image=18_dualboot29.jpg>

Only after booting to the Ubuntu Live DVD can you manually
set up the network.
<http://img4.imagetitan.com/img.php?image=18_dualboot30.jpg>

Where, in my case, doesn't automatically provide a DNS address:
<http://img4.imagetitan.com/img.php?image=18_dualboot31.jpg>

So I have to create an IPV4 192.168.1.x local address:
<http://img4.imagetitan.com/img.php?image=18_dualboot33.jpg>

Where that local address must be set up manually:
<http://img4.imagetitan.com/img.php?image=18_dualboot34.jpg>

And where the relevant information is basic normal stuff
192.168.1.something, 255.255.255.0, 192.168.1.1, 8.8.8.8
<http://img4.imagetitan.com/img.php?image=18_dualboot35.jpg>

After manual setup, the network easily connects to the antenna:
<http://img4.imagetitan.com/img.php?image=18_dualboot36.jpg>

Which a ping easily proves works just fine:
<http://img4.imagetitan.com/img.php?image=18_dualboot37.jpg>

So now I try the installation, with networking (assuming, at
first, that the network was the problem, which it wasn't):
<http://img4.imagetitan.com/img.php?image=18_dualboot38.jpg>

The same sequence occurs, starting with the keyboard question:
<http://img4.imagetitan.com/img.php?image=18_dualboot39.jpg>

This time I try some of the other setup options (but it doesn't
matter which setup option I select, it turned out):
<http://img4.imagetitan.com/img.php?image=18_dualboot40.jpg>

The "installation type" still won't ask to install alongside Windows:
<http://img4.imagetitan.com/img.php?image=18_dualboot41.jpg>

Again providing only the one /dev/sda option (which itself
doesn't work, as I later found out):
<http://img4.imagetitan.com/img.php?image=18_dualboot42.jpg>

So, again, the only option is to "quick the installation":
<http://img4.imagetitan.com/img.php?image=18_dualboot43.jpg>

Which puts you back in the Ubuntu live DVD desktop:
<http://img4.imagetitan.com/img.php?image=18_dualboot44.jpg>

At this point, all you can do is power off and try something else:
<http://img4.imagetitan.com/img.php?image=18_dualboot45.jpg>

Where, at least, Ubuntu is graceful in first asking you to remove
the Ubuntu Live CD from the DVD tray & then to press "Enter":
<http://img4.imagetitan.com/img.php?image=18_dualboot46.jpg>

It should be noted this is a Ubuntu Desktop 18.04 Live CD
which works so the problem isn't the Ubuntu ISO files;
<http://img4.imagetitan.com/img.php?image=18_dualboot47.jpg>

Now it's time to boot yet again:
<http://img4.imagetitan.com/img.php?image=18_dualboot48.jpg>

Where Windows shows zero errors and works just fine standalone:
<http://img4.imagetitan.com/img.php?image=18_dualboot49.jpg>

So the problem is only with the Ubuntu installation & not Windows:
<http://img4.imagetitan.com/img.php?image=18_dualboot50.jpg>

And where Windows Disk Management simply shows the 40 GB Ubuntu
space as "Unallocated" but no errors whatsoever:
<http://img4.imagetitan.com/img.php?image=18_dualboot51.jpg>

It should be noted that the "blkid" command alone isn't enough:
<http://img4.imagetitan.com/img.php?image=18_dualboot52.jpg>

Where we can ignore the "sudo !$" command above as a mistake:
<Loading Image...>

The *only* command which shows anything relevant is "blkid /dev/sd*":
which shows that there is "promise_fasttrack_raid_member"
RAID dung on the hard disk drive (aka "degraded RAID").
<http://img4.imagetitan.com/img.php?image=18_dualboot54.jpg>

Note that "fdisk -luS /dev/sd?" shows everything to be normal:
<http://img4.imagetitan.com/img.php?image=18_dualboot55.jpg>

Also note that "sudo fdisk -l" shows everything to be normal:
<http://img4.imagetitan.com/img.php?image=18_dualboot56.jpg>

Since Ubuntu is known to have problems when RAID disks are put
in non-RAID systems, we installed "smartmontools" on Ubuntu
to check how many hours the brand-new disk had been run
<http://img4.imagetitan.com/img.php?image=18_dualboot57.jpg>

Running the "sudo smartctl -A /dev/sda" command proved beyond any
doubt that the hard drive had never been used prior, as it only
had 200 hours to it which was all under my control:
<http://img4.imagetitan.com/img.php?image=18_dualboot58.jpg>

At this point, we went into the BIOS Setup Utility Advanced tab
where it was revealed that teh "SATA Controller Mode" was set
to "RAID", even though the setup was NOT a RAID setup:
<http://img4.imagetitan.com/img.php?image=18_dualboot59.jpg>

Apparently, simply having this mode set up always writes the
"RAID dung" to the hard drive, which causes no problems except
to cause Linux to think the disk is a "degraded RAID" failure:
<http://img4.imagetitan.com/img.php?image=18_dualboot60.jpg>

The three choices for the "SATA Controller Mode" were IDE, RAID, & AHCI:
<http://img4.imagetitan.com/img.php?image=18_dualboot61.jpg>

Where I set the SATA Controller Mode to AHCI:
<http://img4.imagetitan.com/img.php?image=18_dualboot62.jpg>

But, because the RAID dung was still on the hard drive, Windows
instantly failed to recognize the disk as a Windows boot disk:
<http://img4.imagetitan.com/img.php?image=18_dualboot63.jpg>

And where no amount of Automatic Repair would fix that problem:
<http://img4.imagetitan.com/img.php?image=18_dualboot64.jpg>

Time after time, attempt after attempt, Windows failed to recognize
the disk once the Sata Controller Mode was set to AHCI without
first removing the "RAID dung" on the hard drive itself:
<http://img4.imagetitan.com/img.php?image=18_dualboot65.jpg>

Try as I might, Windows wasn't going to boot until I reset the
SATA Controller Mode back to RAID, as long as the RAID dung
was still on the hard drive:
<http://img4.imagetitan.com/img.php?image=18_dualboot66.jpg>

Booting to the Linux Live DVD showed nothing changed on the
hard disk drive after I set the RAID Controller Mode to AHCI:
<http://img4.imagetitan.com/img.php?image=18_dualboot67.jpg>

Where "blkid /dev/sd*" still showed the RAID dung embedded into
the bits of the HDD as "TYPE=promise_fasttrack_raid_member":
<http://img4.imagetitan.com/img.php?image=18_dualboot68.jpg>

Following Paul's research, changing the SATA Controller Mode
back to RAID instantly allowed Windows to boot again,
where Paul suggested a Windows Boot Manager "bcdedit" of:
bcdedit /set {current} safeboot minimal
<http://img4.imagetitan.com/img.php?image=18_dualboot69.jpg>

Which seems to have stuck even though we were in SAFE MODE:
<http://img4.imagetitan.com/img.php?image=18_dualboot70.jpg>

And then, still following Paul's suggestion, we booted where
it is noted that the HP Pavillion pops for only about 1 second
this "RAID READY" message:
<http://img4.imagetitan.com/img.php?image=18_dualboot71.jpg>

And then we were still in Windows SAFE MODE after that boot:
<http://img4.imagetitan.com/img.php?image=18_dualboot72.jpg>

And then we followed Paul's next suggestion for a bcdedit of:
bcdedit /deletevalue {current} safeboot
<http://img4.imagetitan.com/img.php?image=18_dualboot73.jpg>

Which finally enabled Windows to boot NOT in SAFE MODE!
<http://img4.imagetitan.com/img.php?image=18_dualboot74.jpg>

At which point we booted to the Linux live DVD once again;
<Loading Image...>

But exactly the same problem persisted where Ubuntu would not
ask to be installed alongside Windows:
<http://img4.imagetitan.com/img.php?image=18_dualboot76.jpg>

And exactly the same "promise_fasttrack_raid_member" RAID dung
showed up on the hard disk drive, apparently indicating to
the Ubuntu installer that it was a "degraded RAID" setup,
even though it wasn't even a RAID setup and it was otherwise
working just fine:
<http://img4.imagetitan.com/img.php?image=18_dualboot77.jpg>

Interestingly, I popped in an older Ubuntu 17.0.1 live DVD,
which also exhibited the exact same issues:
<Loading Image...>

By now, I realized it is useful to tape to the display the
key boot commands to access the BIOS, Boot, or Diag menus:
<http://img4.imagetitan.com/img.php?image=18_dualboot79.jpg>

At this point, I attemped what turned out to be a vain
attempt to remove the RAID dung by wiping out everything
(or so I had thought) on the hard drive by re-installing
Windows and deleting all the partitions & reformatting the
hard drive:
<http://img4.imagetitan.com/img.php?image=18_dualboot80.jpg>

You'd "think" such a drastic reformat would remove the persistent
RAID dung on the hard drive - but it was all in vain:
<http://img4.imagetitan.com/img.php?image=18_dualboot81.jpg>

As before, Windows installed just fine without any error:
<http://img4.imagetitan.com/img.php?image=18_dualboot82.jpg>

And the hard disk drive shows up fine to Windows Disk Management:
<http://img4.imagetitan.com/img.php?image=18_dualboot83.jpg>

And where the Windows Disk Management "Shrink Volume" worked fine:
<http://img4.imagetitan.com/img.php?image=18_dualboot84.jpg>

Which allowed me to specify the 40GB partition for Ubuntu:
<http://img4.imagetitan.com/img.php?image=18_dualboot85.jpg>

And which showed that 40GB partition as "unallocated" space:
<http://img4.imagetitan.com/img.php?image=18_dualboot86.jpg>

And then I popped in the Ubuntu 18.04 ISO live boot DVD, but,
yet again, it failed to install alongside Windows, even after
such a drastic reformatting, repartitioning, and reinstalling
of Windows on the hard disk drive.
<http://img4.imagetitan.com/img.php?image=18_dualboot87.jpg>

Following Paul's lead, it belatedly sank in that the *only* method
that was going to wipe that utterly resistant RAID dung off the
hard disk drive was a bit-by-bit many-hours-ling Windows
diskpart command of "clean all":
<http://img4.imagetitan.com/img.php?image=18_dualboot88.jpg>

Many hours later, the cleanall succeeded with the output of:
"DiskPart succeeded in cleaning the disk".
<http://img4.imagetitan.com/img.php?image=18_dualboot89.jpg>

I didn't know it at the time but that DiskPart "clean all" was
the only known method that finally wiped the RAID dung off that
hard disk drive. Here you see I have converted the disk to "gpt"
(which turned out to be a mistake because the Windows 10 installer
won't recognize a GPT disk - but I didn't know that at this time).
Also, you can see I formatted the disk here as "ntfs" using the
DiskPart command: format fs-ntfs label=disc1 quick
<http://img4.imagetitan.com/img.php?image=18_dualboot90.jpg>

The proof that, finally, after all this work, the RAID dung
was finally removed from the hard drive is only evident when
you boot back to the Linux live DVD and run the "blkid /dev/sd*"
command, which finally, for the first time, did NOT show
"TYPE=promise_fasttrack_raid_member"
but showed, instead, the newly formatted type:
"TYPE=ntfs"
<http://img4.imagetitan.com/img.php?image=18_dualboot91.jpg>

Now that the RAID dung has finally been removed from the HDD, I proceeded
to install Windows 10 Pro where there was a minor glitch on the GPT
partition type...
"Windows cannot be installed to this disk.
The selected diwsk is of the GPT partition style".
<http://img4.imagetitan.com/img.php?image=18_dualboot92.jpg>

I must have read wrong that GPT is better than MBR, but at this point, I
just had Windows 10 installation delete it and create a new one where
Windows also created a 532MB "System Reserved" partition (for whatever
reason Windows 10 does that).
<http://img4.imagetitan.com/img.php?image=18_dualboot93.jpg

Following the tutorials, I ran "Shrink volume" in Windows Disk Management.
<http://img4.imagetitan.com/img.php?image=18_dualboot94.jpg>

This created an extra 40GB partition for Ubuntu to use:
<http://img4.imagetitan.com/img.php?image=18_dualboot95.jpg>

Finally! Woo hoo! Ubuntu finally *asked* to install alongside Windows!
<http://img4.imagetitan.com/img.php?image=18_dualboot96.jpg>

The only thing Ubuntu asked was to format with this instruction:
"The partition tables of the following devices are changed:
SCSI1 (0,0,0) (sda)
The following partitions are going to be formatted:
partition #5 of SCSI1 (0,0,0) (sda) as ext4"
<http://img4.imagetitan.com/img.php?image=18_dualboot97.jpg>

Once Ubuntu formatted the disk, it installed itself nicely using Grub.
<http://img4.imagetitan.com/img.php?image=18_dualboot98.jpg>

Here are the results from "blkid" and "blkid /dev/sd*" where the main
point is that the RAID dung is no longer in existence! (Woo hoo!)
<http://img4.imagetitan.com/img.php?image=18_dualboot99.jpg>

Booting to Windows 10, the 40GB Linux partition shows up as "unallocated"
<http://img4.imagetitan.com/img.php?image=18_dualboot100.jpg>

Being as I'm likely one of the most well-organized people on the planet,
now it's time to set up the Windows GUI as per the many tutorials written
to help users perfectly set up the Windows graphical user environment,
for example, see these recent posts from just last week by way of example
of the hundred or so steps required to perfectly set up Windows...
--------
Subject: Tutorial for setting up a well-organized consistent efficient Windows menu system
Date: Tue, 12 Jun 2018 08:52:36 -0000 (UTC)
Message-ID: <pfo1kd$het$***@news.mixmin.net>
--------
Subject: Quick tutorial for installing the Hewlett Packard HP LaserJet 2100tn printer on Windows.
Date: Mon, 11 Jun 2018 20:27:34 -0000 (UTC)
Message-ID: <pfmlvl$b9s$***@news.mixmin.net>
--------
Subject: Please follow this cut-and-paste tutorial to get batch command shortcuts working perfectly on Windows
Date: Fri, 8 Jun 2018 02:04:43 -0000 (UTC)
Message-ID: <pfco7q$3m9$***@news.mixmin.net>
--------
etc.
****************************************************************************
Key Contributors:
This summary is posted using good Usenet practice so that the next person
with the same problem stands on the shoulders of the following helpful
posters, all of whom contributed to the technically valuable tribal
knowledge archives for the solution of this pernicious RAID dung problem:

Hence, heartfelt thanks go out to Paul, Carlos E.R. and William Unruh,
along with Jonathan N. Little and Grant Taylor and David W. Hodgins
and stepore and Dirk T. Verbeek, et al.
****************************************************************************
****************************************************************************
Chris Elvidge
2018-06-19 11:59:01 UTC
Permalink
< lots snipped >

Would this problem have _not_ occurred if the Promise controller had
been switched to AHCI mode before attaching the drive? Is RAID mode the
default for said Promise controller?
--
Chris Elvidge, England
Carlos E.R.
2018-06-19 12:51:23 UTC
Permalink
Post by Chris Elvidge
< lots snipped >
Would this problem have _not_ occurred if the Promise controller had
been switched to AHCI mode before attaching the drive?
Probably.
Post by Chris Elvidge
Is RAID mode the
default for said Promise controller?
Dunno.
--
Cheers, Carlos.
Arlen Holder
2018-06-19 14:51:29 UTC
Permalink
Post by Carlos E.R.
Post by Chris Elvidge
Would this problem have _not_ occurred if the Promise controller had
been switched to AHCI mode before attaching the drive?
Probably.
Yes.
Both Chris Elvidge and Carlos E.R. are correct.

The proof is that the drive is brand spanking new so I know its history.
When I installed Windows with the SATA Controller Mode set to RAID, the
RAID dung was placed in an inaccessible location on the HDD (as eventually
evidenced by the results of the Ubuntu "blkid /dev/sd*" command).

When I installed Windows with the SATA Controller Mode set to AHCI, the
RAID dung was NOT placed on the HDD, (as immediately evidenced by the
results of the Ubuntu "blkid /dev/sd*" command).
Post by Carlos E.R.
Post by Chris Elvidge
Is RAID mode the
default for said Promise controller?
Dunno.
This I do not know as I acquired the older tower already used and set up.
Cows Are Nice
2018-06-19 18:02:04 UTC
Permalink
Post by Arlen Holder
Post by Carlos E.R.
Post by Chris Elvidge
Would this problem have _not_ occurred if the Promise controller had
been switched to AHCI mode before attaching the drive?
Probably.
Yes.
Both Chris Elvidge and Carlos E.R. are correct.
The proof is that the drive is brand spanking new so I know its history.
Not necessarily. You said that you bought it at Fry's.
Arlen Holder
2018-06-19 21:10:58 UTC
Permalink
Post by Cows Are Nice
Post by Arlen Holder
The proof is that the drive is brand spanking new so I know its history.
Not necessarily. You said that you bought it at Fry's.
While a hard drive could have a prior history at Fryes, that's exactly why
he suggested I run the "sudo smartctl -A /dev/sda" command., which proved
beyond any shadow of a doubt that the hard drive had never been used prior,
as it onlyhad 200 hours to it which was all under my control:
<http://img4.imagetitan.com/img.php?image=18_dualboot58.jpg>

I think it was Carlos who explained that this 200 hour number is
independent of the operating system, so it's the true odometer mileage on
the hard drive.

So, while it "could" have had a prior history, it didn't, and where this
command is a great first command to run on any hard drive ... just to be
sure.
Cows Are Nice
2018-06-20 06:01:59 UTC
Permalink
Post by Arlen Holder
Post by Cows Are Nice
Post by Arlen Holder
The proof is that the drive is brand spanking new so I know its history.
Not necessarily. You said that you bought it at Fry's.
While a hard drive could have a prior history at Fryes, that's exactly why
he suggested I run the "sudo smartctl -A /dev/sda" command., which proved
beyond any shadow of a doubt that the hard drive had never been used prior,
<http://img4.imagetitan.com/img.php?image=18_dualboot58.jpg>
You'd never know if a prior owner dicked around with it for five hours
out of that 200.
I returned a hard drive once, a long time ago. To Fry's. I couldn't get
Win98SE on it for some reason, maybe the low-level format was bad from
the factory. Or maybe malware that I suspected wrecked my old drive hid
somewhere in the motherboard, and did it again to my new drive. I
remember that board, an ASUS A7V133, had a Promise controller too. I
threw it out, bought an Abit board and another hard drive.
Post by Arlen Holder
I think it was Carlos who explained that this 200 hour number is
independent of the operating system, so it's the true odometer mileage on
the hard drive.
So, while it "could" have had a prior history, it didn't, and where this
command is a great first command to run on any hard drive ... just to be
sure.
I felt sorry for the next Fry's customer who bought my hard drive. I
should'a asked Carlos and Paul first.
Arlen Holder
2018-06-20 06:31:18 UTC
Permalink
Post by Cows Are Nice
You'd never know if a prior owner dicked around with it for five hours
out of that 200.
To your point, I considered returning the drive when Paul convinced me that
there was RAID dung stuck to some potentially inaccessible spot on the HDD,
which, one would hope - that Fryes sends back to the manufacturer to
refurbish.

I don't recall not cutting open the plastic though, so, I think it was new,
but nonetheless, the evidence clearly shows that my own SATA Controller
Mode was in RAID mode, and that "Promise" is used by AMD, so, there's
nothing fueling the speculation other than it 'could' have happened (but
probably didn't).

Occams' Razor wins on this one...
Post by Cows Are Nice
I returned a hard drive once, a long time ago. To Fry's. I couldn't get
Win98SE on it for some reason, maybe the low-level format was bad from
the factory. Or maybe malware that I suspected wrecked my old drive hid
somewhere in the motherboard, and did it again to my new drive. I
remember that board, an ASUS A7V133, had a Promise controller too. I
threw it out, bought an Abit board and another hard drive.
Understood. I return a *lot* of things to Fryes. Particularly since they
only give you 30 days, so you have to decide quickly on the borderline
stuff.
Post by Cows Are Nice
I felt sorry for the next Fry's customer who bought my hard drive. I
should'a asked Carlos and Paul first.
Next time I put in a new hard drive, I'll run Carlos' test on it, to see if
it has near-zero hours (you never know how many hours they do in factory
testing though - sort of like a new car has about a dozen miles on it
normally).
Chris Elvidge
2018-06-20 12:20:30 UTC
Permalink
Post by Arlen Holder
Next time I put in a new hard drive
I'll make sure RAID is not enabled in the BIOS?
--
Chris Elvidge, England
Cows Are Nice
2018-06-20 16:49:52 UTC
Permalink
Understood. I return a*lot* of things to Fryes.
What theme does your Fry's store have? We got "Alice in Wonderland"
nearby. Walking in the door, you look up at massive tree roots as if
you're passing through a gopher tunnel.
Mike Easter
2018-06-20 18:38:12 UTC
Permalink
Post by Cows Are Nice
Understood. I return a*lot*  of things to Fryes.
What theme does your Fry's store have? We got "Alice in Wonderland"
nearby. Walking in the door, you look up at massive tree roots as if
you're passing through a gopher tunnel.
My Fry's puts a re-packaged label on the goods opened and returned to
the store.

The theme is Atlantis/ Jules Verne - 20,000 gal fish tank, diving suit, etc.
--
Mike Easter
Arlen Holder
2018-06-20 21:00:21 UTC
Permalink
Post by Mike Easter
The theme is Atlantis/ Jules Verne - 20,000 gal fish tank, diving suit, etc.
There are a bunch of Fryes where I live (Silicon Valley).

The one where the HDD was bought is themed Egyptian pharaohs and cats.
Grant Taylor
2018-06-20 18:18:54 UTC
Permalink
one would hope - that Fryes sends back to the manufacturer to refurbish.
Eh....

I wouldn't count on it.

I've seen a LOT of "Open Box" drives for (re)sale at various box stores.
Usually at a discounted price.
I don't recall not cutting open the plastic though, so, I think it
was new
Many of the box stores that I've shopped in have shrink wrap machines to
apply new shrink wrap to boxes.
Occams' Razor wins on this one...
Parsimony decides which reason is more likely. William of Occam states
that we only need one reason. ;-)
Understood. I return a *lot* of things to Fryes. Particularly since they
only give you 30 days, so you have to decide quickly on the borderline
stuff.
Sadly I've never lived near a Fry's. I did go into one on a business
trip to Las Vegas, (unsurprisingly) it was slot machine themed.
Next time I put in a new hard drive, I'll run Carlos' test on it, to
see if it has near-zero hours (you never know how many hours they do in
factory testing though - sort of like a new car has about a dozen miles
on it normally).
I expect that new drives will have very few hours on them. I say this
because that number of hours for each drive adds up to a LOT of time
which usually directly translates to manufacturing cost -> purchase price.
--
Grant. . . .
unix || die
Carlos E.R.
2018-06-20 21:12:03 UTC
Permalink
Post by Arlen Holder
Next time I put in a new hard drive, I'll run Carlos' test on it, to
see if it has near-zero hours (you never know how many hours they do
in factory testing though - sort of like a new car has about a dozen
miles on it normally).
I expect that new drives will have very few hours on them.  I say this
because that number of hours for each drive adds up to a LOT of time
which usually directly translates to manufacturing cost -> purchase price.
One I tested recently had zero or one by the time I run the command.
Which surprises me a bit as I thought they did at least a quick test and
maybe a full (surface) one, then erased the logs. They also have to
apply the initial low lever format.
--
Cheers, Carlos.
Loading...