XPost: alt.comp.os.windows-10
On 05/12/2018 17.21, arlen holder wrote:
> Hi Paul, Wildman, and Carlos,
>
> (I will respond to Paul's advice separately, as this is already long.)
>
> Thanks for your good advice:
> GRUB_DISABLE_OS_PROBER=true"
> Which is what I needed and will take, as much as I understand it, as I
> readily admit I never really understood how grub works (since it installs
> itself in a dual-boot setup) and where you have explained to me already
> more than I knew about my own Grub setup!
>
> This is what Grub found this morning, booting with all 3 HDDs powered on:
>
> o Ubuntu
> o Advanced options for Ubuntu
> o Memory test
> o Windows 10 (on /dev/sda1)
> o Windows 10 (on /dev/sda2)
> o Windows 10 (on /dev/sda3)
Wait, the photo you posted is very different from your text above. It
displays:
o Ubuntu
o Advanced options for Ubuntu
o Memory test
o Windows 10 (on /dev/sda1)
o Windows 10 (on /dev/sdb1)
o Windows 10 (on /dev/sdc1)
Those are three different disks, the first partition of each one.
>
> I have never really understood this "sda" SCSI drive nomenclature since I
> never use terms like "sda" except when I'm forced to,
sda, sdb, sdc are each a different disk, in hardware. Note: a real
complete disk, not what Windows calls "disk", which often is a single
partition. And they are named in the order the kernel finds them - which
can be different from the order that grub finds them, the bios finds
them, or the boot order. And in fact, the names sda, sdb etc, can apply
to different disks on the next boot. Or not.
Which is why currently in Linux we refer to their UUID, Labels, or paths
instead.
> so I had assumed
> (wrongly it turns out) that sda3 must contain the latest Windows 10, but
> choosing sda3 failed to boot no matter what options I tried:
>
> o Preparing Automatic Repair
> o Diagnosing your PC
> o Your PC did not start correctly
Well, that's probably your computer manufacturer repair partition. And
it probably fails because it doesn't find the partition layout it
expected to find, or the Windows version it expected to find. Say, you
bought the machine with Windows 8, you installed 10 on your own, well,
the "repair" can no longer work.
>
> The same sequence happens with sda2, so sda2 and sda3 must be HDD1 and HDD2
> (each of which has an "old" Windows 10), where HDD2 definitely also has the
> older Ubuntu dual boot setup that I had never bothered to wipe out (but
> where I don't know if that HDD2 is sda2 or sda3 yet since I never use sda
> SCSI-drive nomenclature except in debugging situations).
Notice that Grub doesn't find anything *now*. The grub menu is created
when you run some command in Linux that tells it to update the boot
menu, probably running os-prober (I'm not familiar with Ubuntu). So the
menu that it shows you could be old and not reflect current reality, if
you did not tell Linux to update the grub menu after installing Windows
on HDD3.
Also, when it writes 3 entries named "Windows" doesn't mean that all of
them will boot windows, some of them could be wrong. For example,
Windows can install a small boot partition and then a big system
partition (or disk in Windows parlance). os-prober may list both.
> The question is "where is grub coming from", given that HDD3 (which
> previously had Windows 10 1803 + Ubuntu 18.04) was just "wiped out" a week
> or so ago using a Windows 10 1809 ISO to perform a clean install on that
> HDD3. [It seems clear that Grub must be coming from HDD2 since that's the
> only possibility left!]
Obviously from HDD2 or HDD1. Just boot each disk separately and find
out, if that is of importance.
And obviously your BIOS boot order doesn't list HDD3 as the first disk
to boot - and no, it being the first SATA connector in your motherboard
is irrelevant, as the order is something that *you* decide and write.
>
> After the recent power interruption destroyed Windows 10 1803, I was able
> to boot to Ubuntu 18.04, so it was only Windows that was affected by the
> power outage.
>
> Nonetheless, I wanted to start both new and clean, so I explicitly
> disconnected HDD1 and HDD2 before I booted to a newly made Windows 10 1809
> ISO and then I told that Windows 10 1809 boot GUI to destroy the previous
> Ubuntu 18.04 partition along with the previous Windows partition (where the
> plan is to install Ubuntu 18.10 as the dual boot companion to Windows 1809:
> o
> o
>
> Given that, I had "thought" (and intended) that I wiped out Grub2 at the
> same time, which I probably did ... but only on HDD3 was grub wiped out
> (apparently).
Well, you disconnected the other disks, so grub there was not modified.
>
> Subsequent booting on HDD3 (with both HDD1 and HDD2 disconnected) showed no
> hint of Grub, as HDD3 booted right to Windows (where I will add Ubuntu
> 18.10 soon).
Obviously.
>
> Before I do that, I need to better figure the "boot sequence with grub"
> out, since I had "thought" that connecting HDD3 explicitly on the
> motherboard SATA1 port was how to tell the computer to boot to that
> specific OS (which is the only working windows left).
No.
>
> But somehow, when I connect HDD2 and HDD1, the older Grub (from Ubuntu
> 17.04) is taking over, which is the sequence I need to try to understand,
> since it's certainly an "older grub" that I don't want to be active.
Obviously.
>
> I saw Carlos' suggestion of:
> ">You can easily create your own menu and disable os-prober."
> Where I agree that the 'wrong' grub is running, which is then finding the
> "wrong" Windows to attempt the booting process.
It is the correct grub, you told the computer to boot it :-P
Select what disks to boot first here:
Note 1: It usually is a list; if the first entry fails, it tries to boot
the second, then the third, till one boots - or none. In that list, HDD3
is not the first.
Note 2: I would suggest to leave HDD3 alone and install Ubuntu on HDD1 or 2.
Note 3: Don't disable os-prober unless you know how to boot the computer
with a broken grub. A mistake puts you out of commission.
--
Cheers, Carlos.
--- SoupGate-Win32 v1.05
* Origin: SpaceSST BBS Usenet Fidonet Gateway (255:255/999)
|
