info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to reset dual boot Linux:Win GRUB after "inaccessible boot device"
505 views
Skip to first unread message
arlen holder
Dec 3, 2018, 9:16:17 PM12/3/18
to
It's hard to describe, where, in summary, I think I want advice how to
clean up the grub mess.
*How do I clean up Grub such that Grub only sees the latest Windows 10*
(and a soon-to-be-added Ubuntu dual boot?)
Best to do a short history...as there are 7 OS's previously installed.
From memory...
0. Windows works fine on HDD1 and HDD2 as Win7 and then Vista and then
Win10 Pro (all before my time).
1. When I get the PC, I add Ubuntu 16.04 dual boot no problem via Grub.
2. Works fine for years, where I did so many customizations that Win10
would not update for two years, which was fine by me.
3. Finally, a January Win10 update bricked the OS such that even the
Microsoft store couldn't unbrick it but the HDDs were just fine otherwise
and it would boot fine to Ubuntu via Grub.
4. I bought HDD 3 at that time frame and installed a new Win10 Pro which
worked fine for a few months, until I tried to remove Cortana, which
bricked the Win10 but again, the Ubuntu was just fine via Grub.
5. Changed the OS on HDD3 to Win10 & Ubuntu 17.04 around the May or June
time frame (give or take) and all works fine with Grub showing plenty of
operating systems, but only the Win10 and the new and old Ubuntu boot.
6. Desktop works fine for months, where Grub shows so many operating
systems available it's not funny, but really, only the last two (on HDD3
work, plus the older Ubuntu on HDD2 still works via Grub).
7. Two weeks ago, a power outage kills the system while I was working on
it, where the reboot when the power returned (two days later!) was
"inaccessible boot device".
8. I can't fit any more HDDs in the desktop so instead of buying HDD #4 I
just install Windows 10 Pro 1809 on the HDD #3, using the clean install
wiping everything out, where I wiped out the Linux partitions also, just to
start fresh.
9. To keep the installation simple, I disconnect HDD1 and HDD2 and left
them disconnected (because I didn't need them).
10. Today, I need a file on one of the old HDDs, so I power down, connect
the cables to HDD1 and HDD2, but when I boot, I get the "inaccessible boot
device" again. I can get to grub, but it won't boot to any OS now (since
even Ubuntu no longer exists on HDD3 sda1.
11. I power down and disconnect the two HDDs HDD1 and HDD2, and power up,
and everything works fine booting to Windows via Grub (there's no Ubuntu
anymore so the only working OS is this latest Win10 Pro 1809 anyway).
12. While booted to Windows, I re-connect the power to HDD1 and HDD2, and I
can see HDD1 and HDD2 just fine while in Windows 10 Pro 1809 on HDD3 to
get my files (they act like "removable drives" according to the popup when
I connected them while booted).
My question?
*How do I clean up Grub such that Grub only sees the latest Windows 10?*
Asked another way, how do I tell Grub to FORGET about every OS other than
the current Windows 10 1809 on HDD3, and the Ubuntu 17.10 that I plan on
installing on HDD3 soon?
clean up the grub mess.
*How do I clean up Grub such that Grub only sees the latest Windows 10*
(and a soon-to-be-added Ubuntu dual boot?)
Best to do a short history...as there are 7 OS's previously installed.
From memory...
0. Windows works fine on HDD1 and HDD2 as Win7 and then Vista and then
Win10 Pro (all before my time).
1. When I get the PC, I add Ubuntu 16.04 dual boot no problem via Grub.
2. Works fine for years, where I did so many customizations that Win10
would not update for two years, which was fine by me.
3. Finally, a January Win10 update bricked the OS such that even the
Microsoft store couldn't unbrick it but the HDDs were just fine otherwise
and it would boot fine to Ubuntu via Grub.
4. I bought HDD 3 at that time frame and installed a new Win10 Pro which
worked fine for a few months, until I tried to remove Cortana, which
bricked the Win10 but again, the Ubuntu was just fine via Grub.
5. Changed the OS on HDD3 to Win10 & Ubuntu 17.04 around the May or June
time frame (give or take) and all works fine with Grub showing plenty of
operating systems, but only the Win10 and the new and old Ubuntu boot.
6. Desktop works fine for months, where Grub shows so many operating
systems available it's not funny, but really, only the last two (on HDD3
work, plus the older Ubuntu on HDD2 still works via Grub).
7. Two weeks ago, a power outage kills the system while I was working on
it, where the reboot when the power returned (two days later!) was
"inaccessible boot device".
8. I can't fit any more HDDs in the desktop so instead of buying HDD #4 I
just install Windows 10 Pro 1809 on the HDD #3, using the clean install
wiping everything out, where I wiped out the Linux partitions also, just to
start fresh.
9. To keep the installation simple, I disconnect HDD1 and HDD2 and left
them disconnected (because I didn't need them).
10. Today, I need a file on one of the old HDDs, so I power down, connect
the cables to HDD1 and HDD2, but when I boot, I get the "inaccessible boot
device" again. I can get to grub, but it won't boot to any OS now (since
even Ubuntu no longer exists on HDD3 sda1.
11. I power down and disconnect the two HDDs HDD1 and HDD2, and power up,
and everything works fine booting to Windows via Grub (there's no Ubuntu
anymore so the only working OS is this latest Win10 Pro 1809 anyway).
12. While booted to Windows, I re-connect the power to HDD1 and HDD2, and I
can see HDD1 and HDD2 just fine while in Windows 10 Pro 1809 on HDD3 to
get my files (they act like "removable drives" according to the popup when
I connected them while booted).
My question?
*How do I clean up Grub such that Grub only sees the latest Windows 10?*
Asked another way, how do I tell Grub to FORGET about every OS other than
the current Windows 10 1809 on HDD3, and the Ubuntu 17.10 that I plan on
installing on HDD3 soon?
Diesel
Dec 4, 2018, 2:33:19 AM12/4/18
to
arlen holder <ar...@arlen.com> news:pu4o1f$jo5$1...@news.mixmin.net
remark or comment in your entire post.
> *How do I clean up Grub such that Grub only sees the latest
> Windows 10* (and a soon-to-be-added Ubuntu dual boot?)
Nor have I seen you claim that only one in one thousand people will
know the answer to your question, this time around.
> Best to do a short history...as there are 7 OS's previously
> installed.
Wasn't really necessary...
> My question?
> *How do I clean up Grub such that Grub only sees the latest
> Windows 10?*
Ahh. If only you weren't such an asshole in previous threads and
wouldn't continue posting full source code in alt.comp.freeware.
GRUB really isn't difficult to work with. Maybe you need to spend a
little more time learning how to use a search engine, so that you can
tell us what you already tried (fancy that, you trying to do it
yourself before asking someone else to tell you how right?) that
didn't work. Show some initiative.
Or wait for someone who doesn't know you well and who can help to
just offer it up. There's a sucker born every minute, and usenet
isn't in short supply.
--
To prevent yourself from being a victim of cyber
stalking, it's highly recommended you visit here:
https://tekrider.net/pages/david-brooks-stalker.php
===================================================
The road to success is always under construction.
Tue, 04 Dec 2018 02:16:16 GMT in alt.os.linux, wrote:
> It's hard to describe, where, in summary, I think I want advice
> how to clean up the grub mess.
I'm shocked Arlen. I didn't detect one single insult or condescending
> It's hard to describe, where, in summary, I think I want advice
> how to clean up the grub mess.
remark or comment in your entire post.
> *How do I clean up Grub such that Grub only sees the latest
> Windows 10* (and a soon-to-be-added Ubuntu dual boot?)
know the answer to your question, this time around.
> Best to do a short history...as there are 7 OS's previously
> installed.
> My question?
> *How do I clean up Grub such that Grub only sees the latest
> Windows 10?*
wouldn't continue posting full source code in alt.comp.freeware.
GRUB really isn't difficult to work with. Maybe you need to spend a
little more time learning how to use a search engine, so that you can
tell us what you already tried (fancy that, you trying to do it
yourself before asking someone else to tell you how right?) that
didn't work. Show some initiative.
Or wait for someone who doesn't know you well and who can help to
just offer it up. There's a sucker born every minute, and usenet
isn't in short supply.
--
To prevent yourself from being a victim of cyber
stalking, it's highly recommended you visit here:
https://tekrider.net/pages/david-brooks-stalker.php
===================================================
The road to success is always under construction.
arlen holder
Dec 4, 2018, 3:07:39 AM12/4/18
to
On Tue, 4 Dec 2018 07:33:17 -0000 (UTC), Diesel wrote:
> I'm shocked Arlen. I didn't detect one single insult or condescending
> remark or comment in your entire post.
Your mother wears army boots while swimming after troop ships.
> I'm shocked Arlen. I didn't detect one single insult or condescending
> remark or comment in your entire post.
There now... are you feeling more comfy now that I just insulted you? :)
Problem with Grub is that it shouldn't even exist since this HDD3 is
supposed to be "only Windows" at this point in time.
So Grub is coming from somewhere else.
Carlos E.R.
Dec 4, 2018, 5:40:07 AM12/4/18
to
Tell your BIOS to boot the correct one.
--
Cheers, Carlos.
Paul
Dec 4, 2018, 7:56:39 AM12/4/18
to
1 | MBR | Win7 Vista
+-----+---------------
+-----+---------------
2 | MBR | Windows 10 Ubuntu 16.04 Win10 Inaccessible Boot Device
+-----+---------------
+-----+---------------------------
3 | MBR | Windows 10 Ubuntu 17.04
+-----+---------------------------
====>
+-----+---------------------------
3 | MBR | Windows 10 1809
+-----+---------------------------
It sounds like, for some reason, with HDD3 alone, you're booting
from HDD3. (Since you clean installed Windows 10, GRUB is no longer
on HDD3.)
Then, when you connect HDD1 and HDD2 before the boot process begins,
your computer is booting via HDD2. Using popup boot function key,
you should be able to tell it to boot from HDD3, while the
other two disks are present.
To start, it's a matter of entering the BIOS, while
all three hard drives are connected, and specifying HDD3
as the boot device. Then the GRUB on HDD2 can't do anything.
When you install Ubuntu 18.04 on HDD3 soon, you can temporarily
disconnect HDD1 and HDD2, just for the sake of a lack of hair
loss. GRUB will take over HDD3. After installation, power down,
connect HDD1 and HDD2, enter the BIOS, verify HDD3 is the
boot device, and boot. The now-working GRUB on HDD3 will be...
just fine.
Your Inaccessible Boot Device, could have been caused by the
BIOS losing settings during the power outage. Using a multimeter,
clip the black lead onto chassis, touch the red lead to the
top of the CR2032 coin cell, and see if it's at least 3V.
Replace the CR2032 coin cell if it is flat. Verify the SATA
port settings are correct for the Win10 on HDD3 (or it will
go "Inaccessible Boot Volume" as well).
If you lost BIOS power, the SATA ports could revert to a different
setting than the Windows 10 on HDD2 was using. You need to boot
Windows 10 HDD2 in Safe Mode, to allow the drivers to re-load
for the new SATA settings.
Right now, one copy of Windows 10 could be using ATA IDE on the
SATA port, the second Windows 10 could be using the AHCI on SATA.
Since Hot Plug is obviously working, you're probably AHCI in the
BIOS now, which is how you installed Windows 10 on HDD3. You need
to work on the Windows 10 on HDD2 until you get the right
driver to load so it's AHCI too. Safe Mode can be achieved more
than one way, and a BCDEDIT to put the boot menu there is my
preferred method. However, the presence of GRUB and chainloading,
may actually result in Win10 HDD2 no longer presenting the boot menu
(since chainloading "jumps past" that boot menu and jumps
straight into the OS loading stage).
Not a problem. Make a backup copy of the 440 byte boot loader
on HDD2. Copy 440 bytes of HDD3 Windows boot loader to the
MBR of HDD2. Now, if you select HDD2 as the boot device,
the Windows boot menu (assumes Windows boot flag still set)
will take over. Using the Win10 installer DVD, boot to Command
Prompt and set up the boot menu. After the boot to Safe Mode
by pressing F8 in that menu, the next boot to Normal Windows
should resolve the boot issue.
https://winaero.com/blog/enable-the-legacy-windows-7-like-boot-menu-in-windows-10/
Now, restore the 440 byte Ubuntu boot loader on HDD2 and it
will take over. And you can chainload that (working) Windows
on HDD2.
By the time you're finished, HDD2 should run independently.
HDD3 should run independently. When you put 18.04 on HDD3,
GRUB will take over there. The runs of update-grub that
occur when the kernel updates on HDD3, will cause the grub
menu building process to include OSes on the other drives.
With some effort on your part, you can improve the quality
of the labels on all OSes, so that the GRUB menu on HDD3
is usable.
Attempts to edit the GRUB menu on HDD3 will be fruitless,
because each kernel upgrade install will only cause update-grub
and re-generate things. I couldn't find any documents to suggest
the GRUB menu build process could be "trimmed" in any way.
Removing OS-prober will prevent GRUB from seeing any Windows
OS, but then it's not much of a multiboot machine any more.
It's the fact that GRUB hasn't evolved to the higher maintenance
model of modern distros, that makes this a mess. Some tweaks
are needed to make this situation more sensible, like a template
for each subtending OS that keeps some sort of user preferences
between rebuilds. The /etc/default/grub has some settings,
but I didn't see enough in there to really control things.
*******
This article
https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows
has a pointer to this tool. Nice GUI and everything.
https://help.ubuntu.com/community/Boot-Repair
*******
Some GRUB related commands
sudo update-grub
sudo grub-install /dev/sdX
*******
How to repair GRUB via chrooting from a LiveCD. This
is an "offline" repair of GRUB. Chroot means "Change root"
or in effect, fool the system into seeing the hard drive
component parts as being part of the current slash.
Then, carry out a repair procedure, followed by dismounting
all the fakery. I expect the Boot-Repair above is doing
some of this for you.
https://askubuntu.com/questions/145241/how-do-i-run-update-grub-from-a-livecd
HTH,
Paul
Carlos E.R.
Dec 4, 2018, 12:12:07 PM12/4/18
to
On 04/12/2018 13.56, Paul wrote:
> Attempts to edit the GRUB menu on HDD3 will be fruitless,
> because each kernel upgrade install will only cause update-grub
> and re-generate things. I couldn't find any documents to suggest
> the GRUB menu build process could be "trimmed" in any way.
> Removing OS-prober will prevent GRUB from seeing any Windows
> OS, but then it's not much of a multiboot machine any more.
You can easily create your own menu and disable os-prober.
> Attempts to edit the GRUB menu on HDD3 will be fruitless,
> because each kernel upgrade install will only cause update-grub
> and re-generate things. I couldn't find any documents to suggest
> the GRUB menu build process could be "trimmed" in any way.
> Removing OS-prober will prevent GRUB from seeing any Windows
> OS, but then it's not much of a multiboot machine any more.
--
Cheers, Carlos.
Wildman
Dec 4, 2018, 9:11:56 PM12/4/18
to
GRUB_DISABLE_OS_PROBER=true
--
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!
arlen holder
Dec 5, 2018, 11:21:21 AM12/5/18
to
On Tue, 04 Dec 2018 07:56:39 -0500, Paul wrote:
> It sounds like, for some reason, with HDD3 alone, you're booting
> from HDD3. (Since you clean installed Windows 10, GRUB is no longer
> on HDD3.)
Hi Paul,
> It sounds like, for some reason, with HDD3 alone, you're booting
> from HDD3. (Since you clean installed Windows 10, GRUB is no longer
> on HDD3.)
Yes. You are correct. You know the situation better than I do!
HDD3 is supposed to be my boot disk, so it is connected to SATA1.
HDD3 has a clean install of Win10 1809 booted from the ISO optical disc.
Grub2 & Ubuntu 18.04 should be wiped clean off that HDD3 (AFAIK).
> Then, when you connect HDD1 and HDD2 before the boot process begins,
> your computer is booting via HDD2. Using popup boot function key,
> you should be able to tell it to boot from HDD3, while the
> other two disks are present.
I just looked, first using the "Escape" boot key.
Trial and error shows the first disk in the list below to be HDD3:
<http://www.bild.me/bild.php?file=9539818grub04.jpg>
o WDC WD10EZEX
o Toshiba HDWD110
o WDC WD10EFRX
And where I have no idea what this is, given the DVD drive is empty:
o hp DVD-RAM
> To start, it's a matter of entering the BIOS, while
> all three hard drives are connected, and specifying HDD3
> as the boot device. Then the GRUB on HDD2 can't do anything.
Let me reboot to try this, as I am doing what you suggest in series.
Then I used the F10 key to boot to the BIOS as you suggested.
The funny thing is that the "good" HDD3 disk (which is attached to SATA1)
does seem to be the first in the BIOS boot-order list also.
In fact, the list seems to be the same (not surprisingly in hindsight):
<http://www.bild.me/bild.php?file=1696675grub07.jpg>
o WDC WD10EZEX
o Toshiba HDWD110
o WDC WD10EFRX
Otherwise I get "inaccessible boot device".
<http://www.bild.me/bild.php?file=3246150grub05.jpg>
In addition, trial & error shows that HDD3 is sda1 to Grub:
<http://www.bild.me/bild.php?file=1139725grub06.jpg>
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)
Where I'm not yet sure which disk is sdb1 or sdc1:
<http://www.bild.me/bild.php?file=4411450grub01.jpg>
Hmmmm... the grub on HDD2 (or HDD1) is doing "something" it shouldn't be
doing, which means, yet again, I don't understand how Grub is found.
Certainly when I boot to Ubuntu, it's the *old* ubuntu, so that Ubuntu
can't be on HDD3.
> When you install Ubuntu 18.04 on HDD3 soon, you can temporarily
> disconnect HDD1 and HDD2, just for the sake of a lack of hair
> loss.
I learned this the hard way already to "simplify" boot installs.
I will likely install Ubuntu 18.10 shortly, after I get grub figured out.
> GRUB will take over HDD3. After installation, power down,
> connect HDD1 and HDD2, enter the BIOS, verify HDD3 is the
> boot device, and boot. The now-working GRUB on HDD3 will be...
> just fine.
That's how I *expected* it to work! :)
Right now, the only good Windows is on HDD3 but there's a good Ubuntu and a
dominant Grub on either HDD2 or HDD1 (I'm not sure which drive it is yet).
> Your Inaccessible Boot Device, could have been caused by the
> BIOS losing settings during the power outage. Using a multimeter,
> clip the black lead onto chassis, touch the red lead to the
> top of the CR2032 coin cell, and see if it's at least 3V.
any indication of a bad battery, but I do keep the machine running 24/7 so
I will check the voltage later.
> Replace the CR2032 coin cell if it is flat. Verify the SATA
> port settings are correct for the Win10 on HDD3 (or it will
> go "Inaccessible Boot Volume" as well).
only tell you that the HDD3 is on the motherboard SATA1 for sure.
> If you lost BIOS power, the SATA ports could revert to a different
> setting than the Windows 10 on HDD2 was using. You need to boot
> Windows 10 HDD2 in Safe Mode, to allow the drivers to re-load
> for the new SATA settings.
without power might have done it. But I can also power down the machine
when not using it, which will check it almost the same.
> Right now, one copy of Windows 10 could be using ATA IDE on the
> SATA port, the second Windows 10 could be using the AHCI on SATA.
> Since Hot Plug is obviously working, you're probably AHCI in the
> BIOS now, which is how you installed Windows 10 on HDD3. You need
> to work on the Windows 10 on HDD2 until you get the right
> driver to load so it's AHCI too. Safe Mode can be achieved more
> than one way, and a BCDEDIT to put the boot menu there is my
> preferred method. However, the presence of GRUB and chainloading,
> may actually result in Win10 HDD2 no longer presenting the boot menu
> (since chainloading "jumps past" that boot menu and jumps
> straight into the OS loading stage).
"AHCI" settings in BIOS. Let me boot back to BIOS to check... and, since
this is getting long, I'll respond to the rest after reading the quoted
articles first.
arlen holder
Dec 5, 2018, 11:21:22 AM12/5/18
to
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:
<http://www.bild.me/bild.php?file=6315743grub_02.jpg>
o Windows 10 (on /dev/sda3)
I have never really understood this "sda" SCSI drive nomenclature since I
never use terms like "sda" except when I'm forced to, 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:
<http://www.bild.me/bild.php?file=7780746grub03.jpg>
o Preparing Automatic Repair
o Diagnosing your PC
o Your PC did not start correctly
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).
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!]
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 <http://releases.ubuntu.com/18.10/>
o <http://releases.ubuntu.com/18.10/ubuntu-18.10-desktop-amd64.iso>
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).
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).
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).
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.
I saw Carlos' suggestion of:
"wrong" Windows to attempt the booting process.
And I saw Wildman's suggestion of:
obviously grub exists, even as it's an "older" grub on a non-boot disk).
The interesting question is "where do I find this Grub", since, the HDD3
boot disk, which I specifically attached to the 1st motherboard port
(SATA1) doesn't have grub (as far as I know).
(Obviously, I will research more how to figure out why the 'wrong' grub is
taking over, and then how to stop that grub from activating itself.)
(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:
<http://www.bild.me/bild.php?file=6315743grub_02.jpg>
o Ubuntu
o Advanced options for Ubuntu
o Memory test
o Windows 10 (on /dev/sda1)
o Windows 10 (on /dev/sda2)
o Advanced options for Ubuntu
o Memory test
o Windows 10 (on /dev/sda1)
o Windows 10 (on /dev/sda3)
I have never really understood this "sda" SCSI drive nomenclature since I
never use terms like "sda" except when I'm forced to, 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:
<http://www.bild.me/bild.php?file=7780746grub03.jpg>
o Preparing Automatic Repair
o Diagnosing your PC
o Your PC did not start correctly
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).
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!]
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 <http://releases.ubuntu.com/18.10/>
o <http://releases.ubuntu.com/18.10/ubuntu-18.10-desktop-amd64.iso>
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).
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).
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).
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.
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.
And I saw Wildman's suggestion of:
"> Add this to /etc/default/grub"
" > GRUB_DISABLE_OS_PROBER=true"
Where, in my plan, there should not be a grub in the first place (but
" > GRUB_DISABLE_OS_PROBER=true"
obviously grub exists, even as it's an "older" grub on a non-boot disk).
The interesting question is "where do I find this Grub", since, the HDD3
boot disk, which I specifically attached to the 1st motherboard port
(SATA1) doesn't have grub (as far as I know).
(Obviously, I will research more how to figure out why the 'wrong' grub is
taking over, and then how to stop that grub from activating itself.)
Carlos E.R.
Dec 5, 2018, 2:00:08 PM12/5/18
to
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:
> <http://www.bild.me/bild.php?file=6315743grub_02.jpg>
> 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
> 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:
> <http://www.bild.me/bild.php?file=6315743grub_02.jpg>
> 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)
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.
o Windows 10 (on /dev/sdc1)
>
> I have never really understood this "sda" SCSI drive nomenclature since I
> never use terms like "sda" except when I'm forced to,
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:
> <http://www.bild.me/bild.php?file=7780746grub03.jpg>
> o Preparing Automatic Repair
> o Diagnosing your PC
> o Your PC did not start correctly
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).
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!]
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 <http://releases.ubuntu.com/18.10/>
> o <http://releases.ubuntu.com/18.10/ubuntu-18.10-desktop-amd64.iso>
>
> 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).
>
> 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).
>
> 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).
>
> 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.
>
> 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.
Select what disks to boot first here:
<http://www.bild.me/bild.php?file=9539818grub04.jpg>
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.
Paul
Dec 5, 2018, 2:51:18 PM12/5/18
to
Carlos E.R. wrote:
> Select what disks to boot first here:
> <http://www.bild.me/bild.php?file=9539818grub04.jpg>
>
> 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.
One reason I'm not analyzing these pictures,
> Select what disks to boot first here:
> <http://www.bild.me/bild.php?file=9539818grub04.jpg>
>
> 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.
is you have to "build up" your computer, one
piece at a time.
You can't expect to "hammer downwards" and "tame" errant
pieces of this and that, with your magic wand.
If you don't want the other OSes, delete the OS giblets,
so that nobody, not the OS itself, nor any OS-prober, can
detect them.
Clean up the component disks.
Either work on each disk separately, repairing the
broken images on each one.
Or move the data off them (somewhere) and make
data partitions in their place.
To sit around doing "this and that" with that mess
plugged in, is pointless. It's just a big "maintenance time suck".
You'll be constantly hitting the side of the boiler
with your hammer, trying to get heat out of it.
You could, if you wanted, put all the Windows 10 on
one disk drive, and have them managed by the
Windows 10 boot manager.
Put all your Ubuntu distros on one disk drive. Have
them handled by Grub. Disable OS-prober.
Manage the boot using the popup boot menu (select
the Windows disk or the Ubuntu disk).
Many things are possible. They take thought and planning.
But lugging around a set of side-effects, from two
hard drives you're not using, doesn't make sense.
Build a setup that does makes sense. Build a setup
you like, not the one I like.
Just about everything on those disks, can be torn
apart and reassembled, and lashed together again.
And Arlen is the person to do it. A little Macrium
here (partition movement), some LiveCD there, and
you can fix it.
Paul
Mike Easter
Dec 5, 2018, 3:03:22 PM12/5/18
to
Paul wrote:
> Just about everything on those disks, can be torn
> apart and reassembled, and lashed together again.
> And Arlen is the person to do it. A little Macrium
> here (partition movement), some LiveCD there, and
> you can fix it.
I sense that Arlen needs to understand grub's 3 parts better. Maybe he
> Just about everything on those disks, can be torn
> apart and reassembled, and lashed together again.
> And Arlen is the person to do it. A little Macrium
> here (partition movement), some LiveCD there, and
> you can fix it.
could visit the wp article and the grub docs in whatever depth
necessary. He could also use some repair tools just to examine what he
has before he tries to take them apart and reassemble, such as supergrub
2, rescatux, or boot-repair from a live cd/usb. Even a little hex dump
could see grub's part 1 'signature' in the mbr.
He has 3 tera worth of disks there, 2 WDs & a Tosh. I would hope
there's enough spare space to move some things around.
--
Mike Easter
to aol only
arlen holder
Dec 5, 2018, 4:57:18 PM12/5/18
to
On Wed, 5 Dec 2018 19:58:51 +0100, Carlos E.R. wrote:
> 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.
Mea culpa.
> 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.
The pictures are correct.
My transcription was wrong.
The correction is sda1, sdb1, & sdc1, each of which is it's own HDD.
The only working Windows is HDD3 on sda1 (SATA1):
<http://www.bild.me/bild.php?file=6315743grub_02.jpg>
The other two Windows got corrupted (one by MS, the other by me):
<http://www.bild.me/bild.php?file=4411450grub01.jpg>
Trial and error shows HDD3 to be "WDC WD10EZEX":
<http://www.bild.me/bild.php?file=9539818grub04.jpg>
Where HDD3 was already set up in the BIOS to boot first:
<http://www.bild.me/bild.php?file=1696675grub07.jpg>
What "seems" to be happening is:
o Disconnecting HDD2 & HDD3, Windows boots from HDD3.
o Connecting HDD2 & HDD3, Grub on either HDD2 or HDD3 takes over!
There is a good Ubuntu (an older version) on either HDD2 or HDD3.
That's likely where Grub is coming from.
I'll respond to the rest separately as I wanted to make this correction.
Carlos E.R.
Dec 5, 2018, 5:04:07 PM12/5/18
to
boot is organized.
Download from here and run - in Linux, of course, but a live may do -:
<https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
--
Cheers, Carlos.
Carlos E.R.
Dec 5, 2018, 5:12:08 PM12/5/18
to
On 05/12/2018 22.57, arlen holder wrote:
> Where HDD3 was already set up in the BIOS to boot first:
> <http://www.bild.me/bild.php?file=1696675grub07.jpg>
>
> What "seems" to be happening is:
> o Disconnecting HDD2 & HDD3, Windows boots from HDD3.
> o Connecting HDD2 & HDD3, Grub on either HDD2 or HDD3 takes over!
Just look at that same bios screen when the three disks are connected.
> Where HDD3 was already set up in the BIOS to boot first:
> <http://www.bild.me/bild.php?file=1696675grub07.jpg>
>
> What "seems" to be happening is:
> o Disconnecting HDD2 & HDD3, Windows boots from HDD3.
> o Connecting HDD2 & HDD3, Grub on either HDD2 or HDD3 takes over!
The first listed and bootable disk will be hdd2 or hdd3.
--
Cheers, Carlos.
Mike Easter
Dec 5, 2018, 5:18:56 PM12/5/18
to
Carlos E.R. wrote:
> Or, you can just use "bootinfoscript" script, and it will tell you how
> boot is organized.
>
> Download from here and run - in Linux, of course, but a live may do -:
>
> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
That's nice.
> Or, you can just use "bootinfoscript" script, and it will tell you how
> boot is organized.
>
> Download from here and run - in Linux, of course, but a live may do -:
>
> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
There's a howto and examples in an Ub thread:
https://ubuntuforums.org/showthread.php?t=1291280 Boot Info Script: How to
The last message there says that the graphical button in boot repair
runs that script.
--
Mike Easter
David W. Hodgins
Dec 5, 2018, 6:46:30 PM12/5/18
to
On Wed, 05 Dec 2018 17:02:14 -0500, Carlos E.R. <robin_...@es.invalid> wrote:
> Or, you can just use "bootinfoscript" script, and it will tell you how
> boot is organized.
> Download from here and run - in Linux, of course, but a live may do -:
> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
Nice script. Thanks for posting the link.
> Or, you can just use "bootinfoscript" script, and it will tell you how
> boot is organized.
> Download from here and run - in Linux, of course, but a live may do -:
> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
# wc -l RESULTS.txt
1314 RESULTS.txt
Time to clean up my system a bit. :-)
Regards, Dave Hodgins
--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.
arlen holder
Dec 6, 2018, 5:17:24 PM12/6/18
to
On Wed, 5 Dec 2018 23:02:14 +0100, Carlos E.R. wrote:
> Or, you can just use "bootinfoscript" script, and it will tell you how
> boot is organized.
>
> Download from here and run - in Linux, of course, but a live may do -:
>
> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
I haven't posted much as I haven't any new information as it's clear I'm
> Or, you can just use "bootinfoscript" script, and it will tell you how
> boot is organized.
>
> Download from here and run - in Linux, of course, but a live may do -:
>
> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
confused how Grub gets started in the first place, hence the help
is instrumental (where I need to read more of the references).
Hence this post is just the conclusion from that nice bootinfoscript program.
The main thing is, I think, that it cleared up which disk has what:
o HDD3: The only working Windows is on sda (WD10EZEX)
o HDD2: Grub & Ubuntu (17.10) is on sdb (TOSHIBA_HDWD110)
o HDD1: Nothing of use (other than data) is on sdc (WD10EFRX)
Here's how I ran that test.
I connected all three HDDs & booted to Grub which allowed me to boot
to the older Ubuntu (which turns out to be Ubuntu 17.10):
$ lsb_release -a
Reported Ubuntu 17.10
<http://www.bild.me/bild.php?file=4360794grub08.jpg>
I had originally thought that you just run the bootinfoscript, so while in
Ubuntu, I went to the Windows hierarchy in /media where I had copied
that script (I love that Ubuntu reads Windows partitions!) and ran the
script in Ubuntu - but that's not the way to run the script apparently.
<http://www.bild.me/bild.php?file=6907397grub09.jpg>
You install the boot-info-script program, and then you run the script.
$ sudo apt-get install boot-info-script
$ sudo /usr/sbin/bootinfoscript
Reported it found sda, sdb, and sdc, putting results in ~/RESULTS.txt
<http://www.bild.me/bild.php?file=7476838grub10.jpg>
The bootinfoscript found Windows on all three HDDs (as expected).
<http://www.bild.me/bild.php?file=9161369grub11.jpg>
======Boot Info Summary: =====
=> Windows 7/8/2012 is installed in the MBR of /dev/sda.
=> Grub2 (v2.00) is installed in the MBR of /dev/sdb and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
for (,msdos5)/boot/grub. It also embeds following components:
modules
----------------------------------------------
fshelp ext2 part_msdos biosdisk
----------------------------------------------
=> Windows 7/8/2012 is installed in the MBR of /dev/sdc.
sda1: _____
File system: ntfs
Boot sector type: Windows 8/2012: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /bootmgr /Boot/BCD
sda2: _____
File system: ntfs
Boot sector type: Windows 8/2012: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /Windows/System32/winload.exe
sdb1: _____
File system: ntfs
Boot sector type: Windows 8/2012: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /bootmgr /Boot/BCD
sdb2: _____
File system: ntfs
Boot sector type: Windows 8/2012: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /Windows/System32/winload.exe
sdb3: _____
File system: Extended Partition
Boot sector type: -
Boot sector info:
sdb5: _____
File system: ext4
Boot sector type: -
Boot sector info:
Operating System: Ubuntu 17.10
Boot files: /boot/grub/grub.cfg /etc/fstab
/boot/grub/i386-pc/core.img
sdc1: _____
File system: ntfs
Boot sector type: Windows 8/2012: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /bootmgr /Boot/BCD
sdc2: _____
File system: ntfs
Boot sector type: Windows 7/2008: NTFS
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files: /Windows/System32/winload.exe
... ... ...
=== sdb5: Location of files loaded by Grub: ====
905.471122742 = 972.242214912 boot/grub/grub.cfg 3
873.617935181 = 938.040115200 boot/grub/i386-pc/core.img 1
808.271976471 = 867.875426304 boot/vmlinuz-4.13.0-46-generic
... ... ...
It's clear from the output that Grub is on sdb, but I wasn't sure if
that is the Toshiba or Western Digital HDD so I grep'ed the
RESULTS.txt for "TOSHIBA", which found this section:
=== "ls -l /dev/disk/by-id" output: ===
lrwxrwxrwx 1 root root 9 Dec 6 13:21 ata-TOSHIBA_HDWD110_x -> ../../sdb
lrwxrwxrwx 1 root root 10 Dec 6 13:21 ata-TOSHIBA_HDWD110_x-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Dec 6 13:21 ata-TOSHIBA_HDWD110_x-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Dec 6 13:21 ata-TOSHIBA_HDWD110_x-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Dec 6 13:21 ata-TOSHIBA_HDWD110_x-part5 -> ../../sdb
Grepping for WDC, I find in the same section:
lrwxrwxrwx 1 root root 9 Dec 6 13:21 ata-WDC_WD10EFRX-x -> ../../sdc
lrwxrwxrwx 1 root root 10 Dec 6 13:21 ata-WDC_WD10EFRX-x-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Dec 6 13:21 ata-WDC_WD10EFRX-x-part2 -> ../../sdc2
And...
lrwxrwxrwx 1 root root 9 Dec 6 13:21 ata-WDC_WD10EZEX-x -> ../../sda
lrwxrwxrwx 1 root root 10 Dec 6 13:21 ata-WDC_WD10EZEX-x-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Dec 6 13:21 ata-WDC_WD10EZEX-x-part2 -> ../../sda2
I can conclude, I think, from the script's output...
o HDD3: The only working Windows is on sda (WD10EZEX)
o HDD2: Grub & Ubuntu (17.10) is on sdb (TOSHIBA_HDWD110)
o HDD1: Nothing of use (other than data) is on sdc (WD10EFRX)
Andy D. Robinson
Dec 6, 2018, 5:40:56 PM12/6/18
to
Re: Message-ID <news:pu9a7k$ehv$1...@dont-email.me>
> If you don't want the other OSes, delete the OS giblets,
> so that nobody, not the OS itself, nor any OS-prober, can
> detect them.
Hi Paul,
That is what I want to do, but I'm not sure how to do it gracefully.
I don't need (nor want) the older Windows 10s on HDD1 & HDD2.
<http://www.bild.me/bild.php?file=4411450grub01.jpg>
I'd be perfectly happy to eliminate the two old Win10 OS giblets!
<http://www.bild.me/bild.php?file=8520861grub12.jpg>
I booted to Grub and then Linjux to run Carlos' suggested bootinfoscript.
<https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
<http://www.bild.me/bild.php?file=9161369grub11.jpg>
This script proved:
That script "thinks" that Windows is "working" on all 3 HDDs.
But the HDD1 & HDD2 Windows are both long gone, never to be recovered.
And I don't care about the Ubuntu since I'll install Ubuntu 18.10 on HDD3.
And, I don't care about the Grub on sda2 either.
The question is what's the most graceful way to clear the OS giblets?
Do I simply wipe out C:\Windows on HDD2 (sdb) and HDD1 (sdc)?
(Is it _that_ easy? Or will that open a new can of worms?)
> If you don't want the other OSes, delete the OS giblets,
> so that nobody, not the OS itself, nor any OS-prober, can
> detect them.
That is what I want to do, but I'm not sure how to do it gracefully.
I don't need (nor want) the older Windows 10s on HDD1 & HDD2.
<http://www.bild.me/bild.php?file=4411450grub01.jpg>
I'd be perfectly happy to eliminate the two old Win10 OS giblets!
<http://www.bild.me/bild.php?file=8520861grub12.jpg>
I booted to Grub and then Linjux to run Carlos' suggested bootinfoscript.
<https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
<http://www.bild.me/bild.php?file=9161369grub11.jpg>
This script proved:
o HDD3: The only working Windows is on sda (WD10EZEX)
o HDD2: Grub & Ubuntu (17.10) is on sdb (TOSHIBA_HDWD110)
o HDD1: Nothing of use (other than data) is on sdc (WD10EFRX)
<http://www.bild.me/bild.php?file=9161369grub11.jpg>
o HDD2: Grub & Ubuntu (17.10) is on sdb (TOSHIBA_HDWD110)
o HDD1: Nothing of use (other than data) is on sdc (WD10EFRX)
That script "thinks" that Windows is "working" on all 3 HDDs.
But the HDD1 & HDD2 Windows are both long gone, never to be recovered.
And I don't care about the Ubuntu since I'll install Ubuntu 18.10 on HDD3.
And, I don't care about the Grub on sda2 either.
The question is what's the most graceful way to clear the OS giblets?
Do I simply wipe out C:\Windows on HDD2 (sdb) and HDD1 (sdc)?
(Is it _that_ easy? Or will that open a new can of worms?)
arlen holder
Dec 6, 2018, 5:53:55 PM12/6/18
to
On Thu, 6 Dec 2018 22:40:55 +0000, Andy D. Robinson wrote:
> The question is what's the most graceful way to clear the OS giblets?
> Do I simply wipe out C:\Windows on HDD2 (sdb) and HDD1 (sdc)?
> (Is it _that_ easy? Or will that open a new can of worms?)
Drat. I apologize.
> The question is what's the most graceful way to clear the OS giblets?
> Do I simply wipe out C:\Windows on HDD2 (sdb) and HDD1 (sdc)?
> (Is it _that_ easy? Or will that open a new can of worms?)
I never switch privacy nyms on purpose in the same thread.
My vpn scripts that Marek mostly wrote somehow didn't like,
I think, that I moved from Linux to Windows just now, posting from both
(where it keeps a variable based on the subject line), so something
didn't reset (a bug in those scripts somewhere as my long time Usenet
reader is "vi" and the randomizer scripts use telnet to the nntp server).
Anyway, the question that remains is simply how to gracefully
eliminate all the cross-platform OS giblets, which are:
o The Windows 10 on HDD1 (WD10EFRX, sdc)
o The Windows 10 on HDD2 (Toshiba, sdb)
o The Ubuntu 17.10 on HDD2 (sdb)
o The Grub on HDD2
<http://www.bild.me/bild.php?file=8520861grub12.jpg>
Is it as simple as deleting C:\Windows in HDD1 (sdc) & HDD2 (sdb)?
<http://www.bild.me/bild.php?file=4411450grub01.jpg>
Can I just "rm -rf" to wipe out /etc/grub on HDD2 (sdb)?
<http://www.bild.me/bild.php?file=6315743grub_02.jpg>
I'm confused what's the graceful way to wipe out the OS giblets
while keeping the data on HDD1 (WD sdc) & HDD2 (Toshiba sdb) intact?
😉 Good Guy 😉
Dec 6, 2018, 5:55:27 PM12/6/18
to
On 06/12/2018 22:40, Andy D. Robinson
wrote:
Re
Please note this chap calling himself as Andy D. Robinson is a known paedophile nym-shifter so please update your kill-file to make sure you don't see any of his posts about paedophilia activities. There is no point in responding to any of his posts. It was all quiet until his post just popped up.
Path: aioe.org!news.mixmin.net!.POSTED!not-for-mail From: "Andy D. Robinson" <andydrobin...@virginmedia.uk> Newsgroups: alt.comp.os.windows-10,alt.os.linux Subject: Re: How to reset dual boot Linux:Win GRUB after "inaccessible boot device" Date: Thu, 6 Dec 2018 22:40:55 +0000 Organization: Mixmin Message-ID: <puc8hn$lhs$1...@news.mixmin.net> References: <pu4o1f$jo5$1...@news.mixmin.net> <pu5ti5$juc$1...@dont-email.me> <pu8tu0$k6a$2...@news.mixmin.net> <bojldf-...@Telcontar.valinor> <pu9a7k$ehv$1...@dont-email.me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 6 Dec 2018 22:40:55 -0000 (UTC) Injection-Info: news.mixmin.net; posting-host="d7f3355f28ead1fdfbeed8e206f882bf7dbeb703"; logging-data="22076"; mail-complaints-to="ab...@mixmin.net" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Content-Language: en-GB Xref: aioe.org alt.comp.os.windows-10:80281 alt.os.linux:51776
--
With over 950 million devices now
running Windows 10, customer satisfaction is higher than any
previous version of windows.
William Unruh
Dec 6, 2018, 8:01:06 PM12/6/18
to
On 2018-12-06, arlen holder <ar...@arlen.com> wrote:
> On Wed, 5 Dec 2018 23:02:14 +0100, Carlos E.R. wrote:
>
>> Or, you can just use "bootinfoscript" script, and it will tell you how
>> boot is organized.
>>
>> Download from here and run - in Linux, of course, but a live may do -:
>>
>> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
>
> I haven't posted much as I haven't any new information as it's clear I'm
> confused how Grub gets started in the first place, hence the help
> is instrumental (where I need to read more of the references).
>
> Hence this post is just the conclusion from that nice bootinfoscript program.
>
> The main thing is, I think, that it cleared up which disk has what:
> o HDD3: The only working Windows is on sda (WD10EZEX)
> o HDD2: Grub & Ubuntu (17.10) is on sdb (TOSHIBA_HDWD110)
> o HDD1: Nothing of use (other than data) is on sdc (WD10EFRX)
One of the problems with Linux is that the disk naming sd{a,b,c} is
> On Wed, 5 Dec 2018 23:02:14 +0100, Carlos E.R. wrote:
>
>> Or, you can just use "bootinfoscript" script, and it will tell you how
>> boot is organized.
>>
>> Download from here and run - in Linux, of course, but a live may do -:
>>
>> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
>
> I haven't posted much as I haven't any new information as it's clear I'm
> confused how Grub gets started in the first place, hence the help
> is instrumental (where I need to read more of the references).
>
> Hence this post is just the conclusion from that nice bootinfoscript program.
>
> The main thing is, I think, that it cleared up which disk has what:
> o HDD3: The only working Windows is on sda (WD10EZEX)
> o HDD2: Grub & Ubuntu (17.10) is on sdb (TOSHIBA_HDWD110)
> o HDD1: Nothing of use (other than data) is on sdc (WD10EFRX)
unstable. It is basically first foune first serverd. Thus the first disk
found gets sda, the second sdb, and the third sdc. The problem is that
the order in which they were found can depend, so which disk is sda can
differ from one boot to the next.This is why labels and UIDs were
invented.They remain stable ( they are written onto the disk, like name
tags at a conference. If you were used to labeling people by when they
cam through the door, Bob and Irene could refer to very differnt people
from one day to t he next). So learn to use UUIDs or labels instead of
relying on sd{a,b,c}
Paul
Dec 6, 2018, 8:02:24 PM12/6/18
to
Windows can do it too.
which gparted # check if it is present
gparted # system will tell you how to install
sudo gparted # run it - needs root for physical layer access
You can remove the Windows partitions if you want.
*******
You can use "dd" to erase a disk entirely. Here, I'm erasing
16 sectors at a time, in an attempt to keep the disk drive
at full rate. As long as the 8192 divides evenly into the
disk size, the whole disk gets erased.
dd if=/dev/zero of=/dev/sda bs=8192
To monitor the erasure and its rate
which iotop # check
iotop # hint
sudo iotop # run
sudo iotop -a # run (accumulated)
https://linux.die.net/man/1/iotop
I sometimes run two terminal windows, with a sudo iotop
in one, and a sudo iotop -a in the other. It allows you
to examine the progress, and estimate the ETA.
*******
I might have these in the wrong order.
sdc1 sdc2
+-----+-------------------+---------+--- - -
1 sdc | MBR |* System Reserved | Old W10 |
+-----+-------------------+---------+--- - -
sdb1 sdb2 sdb3
+-----+-------------------+---------+--------------------
2 sdb | MBR |* System Reserved | Old W10 | Extended
+-----+-------------------+---------+--------------+- - -
GRUB | Ubuntu 17.10 | SWAP?
+--------------+------
sdb5
sda1 sda2 ??? ???
+-----+-------------------+------------+-------------------+---------------+
3 sda | MBR |* System Reserved | Latest W10 | Ubuntu 18.04 next | 1GB SWAP next |
+-----+-------------------+------------+-------------------+---------------+
W10,
GRUB
next
On the middle one, remove sdb5 then sdb3, then the others in any order.
In the top one, remove in any order.
dd erasure of 1 and 2, if you wanted it forensically clean
and wanted to aid future "testdisk" partition scans. Even
when you remove a partition, the header sector of the partition
is left, and will be "sniffed" by "testdisk" on a scan. Cleaning
a disk thoroughly takes a while, so it's a time versus opportunity
thing.
Before you start, unplug 1 and 2 and verify it boots. Maybe
you are already satisfied that 3 boots just fine, and don't need
to do this now.
When installing Ubuntu on 3, you can:
1) Define a couple partitions before the job starts.
2) Win10 is a bit of a weasel, in that you can define
sda3 as a primary, but Win10 will make sda4 Extended
and sda5 Logical. We can't have that now. Using "diskpart",
you can make a primary for sda4 and override the less
than hygienic Disk Management behavior. It should really
ask whether you want a Primary or Extended/Logical, rather
than just charge ahead and ruin it.
3) Shut down, unplug drive 1 and drive 2. Best practice
is to leave no room for an install to run amok.
4) Make sure you have a backup of sda1 and sda2, just in
case that's an OS you really want to keep. Never assume
anything, about installs, no matter which OS does it.
(Win2K once, erased a disk on me. It was recoverable,
but still a bit of a shocker.)
5) In Ubuntu, do a Custom install, select the big partition
as your "Slash", select the small partition as your "Swap"
and away you go.
6) Plug in drive 1 and drive 2.
Paul
Carlos E.R.
Dec 6, 2018, 9:44:07 PM12/6/18
to
On 06/12/2018 23.17, arlen holder wrote:
> On Wed, 5 Dec 2018 23:02:14 +0100, Carlos E.R. wrote:
>
>> Or, you can just use "bootinfoscript" script, and it will tell you how
>> boot is organized.
>>
>> Download from here and run - in Linux, of course, but a live may do -:
>>
>> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
>
> I haven't posted much as I haven't any new information as it's clear I'm
> confused how Grub gets started in the first place, hence the help
> is instrumental (where I need to read more of the references).
How grub starts is very clear. Shall I repeat it?
> On Wed, 5 Dec 2018 23:02:14 +0100, Carlos E.R. wrote:
>
>> Or, you can just use "bootinfoscript" script, and it will tell you how
>> boot is organized.
>>
>> Download from here and run - in Linux, of course, but a live may do -:
>>
>> <https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript>
>
> I haven't posted much as I haven't any new information as it's clear I'm
> confused how Grub gets started in the first place, hence the help
> is instrumental (where I need to read more of the references).
You have the wrong boot order in the bios menu. JUST CHANGE IT!
And no, that a disk is in the first SATA socket or the third is irrelevant.
...
(the rest of the post contains obvious information that I delete)
--
Cheers, Carlos.
Carlos E.R.
Dec 6, 2018, 10:08:07 PM12/6/18
to
On 06/12/2018 23.53, arlen holder wrote:
> On Thu, 6 Dec 2018 22:40:55 +0000, Andy D. Robinson wrote:
>
>> The question is what's the most graceful way to clear the OS giblets?
>> Do I simply wipe out C:\Windows on HDD2 (sdb) and HDD1 (sdc)?
>> (Is it _that_ easy? Or will that open a new can of worms?)
>
> Drat. I apologize.
> I never switch privacy nyms on purpose in the same thread.
>
> My vpn scripts that Marek mostly wrote somehow didn't like,
> I think, that I moved from Linux to Windows just now, posting from both
> (where it keeps a variable based on the subject line), so something
> didn't reset (a bug in those scripts somewhere as my long time Usenet
> reader is "vi" and the randomizer scripts use telnet to the nntp server).
Sigh :-(
> On Thu, 6 Dec 2018 22:40:55 +0000, Andy D. Robinson wrote:
>
>> The question is what's the most graceful way to clear the OS giblets?
>> Do I simply wipe out C:\Windows on HDD2 (sdb) and HDD1 (sdc)?
>> (Is it _that_ easy? Or will that open a new can of worms?)
>
> Drat. I apologize.
> I never switch privacy nyms on purpose in the same thread.
>
> My vpn scripts that Marek mostly wrote somehow didn't like,
> I think, that I moved from Linux to Windows just now, posting from both
> (where it keeps a variable based on the subject line), so something
> didn't reset (a bug in those scripts somewhere as my long time Usenet
> reader is "vi" and the randomizer scripts use telnet to the nntp server).
> Anyway, the question that remains is simply how to gracefully
> eliminate all the cross-platform OS giblets, which are:
> o The Windows 10 on HDD1 (WD10EFRX, sdc)
> o The Windows 10 on HDD2 (Toshiba, sdb)
> o The Ubuntu 17.10 on HDD2 (sdb)
> o The Grub on HDD2
> <http://www.bild.me/bild.php?file=8520861grub12.jpg>
>
> Is it as simple as deleting C:\Windows in HDD1 (sdc) & HDD2 (sdb)?
> <http://www.bild.me/bild.php?file=4411450grub01.jpg>
>
> Can I just "rm -rf" to wipe out /etc/grub on HDD2 (sdb)?
any partition or filesystem, but in some out of sight sectors.
You posted it yourself:
> => Grub2 (v2.00) is installed in the MBR of /dev/sdb and looks at sector 1 of
> the same hard drive for core.img. core.img is at this location and looks
> for (,msdos5)/boot/grub. It also embeds following components:
software. You could erase the first track of the disk, that would do it,
but would erase any partition table, too.
What we do is to simply overwrite the code in first sector of the disk,
the MBR (but not the rest of the sector). I have forgotten the msdos
command that did that... ah, "fdisk /mbr" it was. Still, grub's core.img
is not deleted, but nothing points to it and thus it will not run and
display the menu.
No need to delete Linux or Windows with anything special. Just use a
*good* partitioning software and tell it to delete the relevant
partitions leaving empty unpartitioned space there. It works instantly,
seconds.
If you are paranoid - wait, you are, 'cos you are the nameshifter - then
use dd in Linux to overwrite with zeroes. It will take hours. Or use one
of those programs that overwrites with random data 32 times. It will
take days. Or use a special command in the "ATA Security Feature Set" to
do a "security erase". There is some Windows software to do it, but I
don't remember which.
--
Cheers, Carlos.
Paul
Dec 6, 2018, 11:28:05 PM12/6/18
to
We have one of those.
http://www.chrysocome.net/dd
http://www.chrysocome.net/downloads/dd-0.6beta3.zip
The "dd.exe" is a bit "cranky" and is an acquired taste.
There's also a hex editor that opens disk drives.
You have to run that as Administrator to run amok
in there. I've not seen any description of what
happens when you zero out the entire C: partition
while the OS is running :-)
https://mh-nexus.de/en/hxd/
There's all sorts of fun utilities. Even the
OS has the buildin "diskpart", which can remove
the MBR or clean an entire disk from end to end.
("Clean" and "Clean All").
There's fixboot, fixmbr, bootsect, bootrec, all
sorts of utilities. And bcdedit for adjusting
the boot menu in Vista+.
Paul
Carlos E.R.
Dec 7, 2018, 8:28:08 AM12/7/18
to
>
> We have one of those.
>
> http://www.chrysocome.net/dd
>
> http://www.chrysocome.net/downloads/dd-0.6beta3.zip
«This version does not actually do any conversion but it allows the
flexible copying of data under in a win32 environment. At the moment
block devices under Win9x are not supported but that will be added soon.»
Ah, no raw access, but it is needed in this case.
But then the examples have things that seem raw access:
dd if=\\.\a: of=c:\temp\disk1.img bs=1440k
> The "dd.exe" is a bit "cranky" and is an acquired taste.
It is "special" in Linux, so in Windows even more :-)
> There's also a hex editor that opens disk drives.
before that I think "debug.com" would do. We could remove boot virii
with those in MsDOS.
> You have to run that as Administrator to run amok
> in there. I've not seen any description of what
> happens when you zero out the entire C: partition
> while the OS is running :-)
>
> https://mh-nexus.de/en/hxd/
>
> There's all sorts of fun utilities. Even the
> OS has the buildin "diskpart", which can remove
> the MBR or clean an entire disk from end to end.
> ("Clean" and "Clean All").
>
> There's fixboot, fixmbr, bootsect, bootrec, all
> sorts of utilities. And bcdedit for adjusting
> the boot menu in Vista+.
For those that do not know how grub works:
When Grub installs on the MBR (non GPT disks) it rewrites the boot code
that is on the MBR (the rest of the sector is mostly the partition
table). This code loads into memory some more sectors from the hard
disk, that typically are simply the following sectors in the first
track, and which are not inside any partition. After loading these
sectors into RAM, the code jumps to it (runs it).
This is "core.img".
All this reading is done using the BIOS interrupt calls to load sectors
from disk directly: the boot code doesn't know (yet) how to handle files.
This core.img then reads /boot/grub and learns how to read files, and
then it can write the menu.
To erase grub when installed in this manner, the only thing that is
necessary is to replace the boot code in the first sector of the disk,
the MBR. "core.img" is not deleted because it is not trivial to do, and
if nothing calls it, it is innocuous, it can not run.
GRUB can install in another manner which I prefer. The MBR is left
intact, or instead replaced with what is called "generic MBR code". This
code looks at the partition table (it is in memory at this time), finds
the first partition that is marked bootable, loads the first sector of
that partition and runs it. Windows does the same thing. Next, some
files are loaded, but not as files, but as direct sector read (bios can
not cope with files). Ie, the boot code has a table of which sectors to
read. MsDOS did the same, which is the reason that those one or two
files were unmovable.
(I may have written inaccuracies, but I think it is mostly correct)
--
Cheers, Carlos.
Diesel
Dec 8, 2018, 2:41:06 AM12/8/18
to
arlen holder <ar...@arlen.com> news:pu5ck9$o8c$1...@news.mixmin.net
> Problem with Grub is that it shouldn't even exist since this HDD3
> is supposed to be "only Windows" at this point in time.
I've read the entire thread (so far). Just wipe the drive out, load
Windows 10 on it, and when you're ready, let ubuntu put Grub back on
the drive for you.
> So Grub is coming from somewhere else.
As you've learned, it's coming from the drive in question. You
already know what to do about it, or you should by now. Have at it.
--
Don't become the next David Brooks cyberstalking victim!
Visit https://tekrider.net/pages/david-brooks-stalker.php (10/10 WOT)
to learn more. If you've already become a victim or know someone who
has, you can provide the following information to them, your lawyer,
local law enforcement, etc.
https://www.devon-cornwall.police.uk - His local police. Report?
David Brooks (BoaterDave)
Jersey Cottage 86 Granary Lane
Budleigh Salterton Devon EX9 6ER United Kingdom
Phone: 44-1395-443340 (H) 07974-193550 (M)
Email(s): davidan...@btinternet.com, boater...@aol.com
Tue, 04 Dec 2018 08:07:37 GMT in alt.os.linux, wrote:
> On Tue, 4 Dec 2018 07:33:17 -0000 (UTC), Diesel wrote:
>
>> I'm shocked Arlen. I didn't detect one single insult or
>> condescending remark or comment in your entire post.
>
> Your mother wears army boots while swimming after troop ships.
> There now... are you feeling more comfy now that I just insulted
> you? :)
That'll work. [g]
> On Tue, 4 Dec 2018 07:33:17 -0000 (UTC), Diesel wrote:
>
>> I'm shocked Arlen. I didn't detect one single insult or
>> condescending remark or comment in your entire post.
>
> Your mother wears army boots while swimming after troop ships.
> There now... are you feeling more comfy now that I just insulted
> you? :)
> Problem with Grub is that it shouldn't even exist since this HDD3
> is supposed to be "only Windows" at this point in time.
Windows 10 on it, and when you're ready, let ubuntu put Grub back on
the drive for you.
> So Grub is coming from somewhere else.
already know what to do about it, or you should by now. Have at it.
--
Don't become the next David Brooks cyberstalking victim!
Visit https://tekrider.net/pages/david-brooks-stalker.php (10/10 WOT)
to learn more. If you've already become a victim or know someone who
has, you can provide the following information to them, your lawyer,
local law enforcement, etc.
https://www.devon-cornwall.police.uk - His local police. Report?
David Brooks (BoaterDave)
Jersey Cottage 86 Granary Lane
Budleigh Salterton Devon EX9 6ER United Kingdom
Phone: 44-1395-443340 (H) 07974-193550 (M)
Email(s): davidan...@btinternet.com, boater...@aol.com
Peter 'Shaggy' Haywood
Dec 8, 2018, 3:38:25 PM12/8/18
to
Groovy hepcat arlen holder was jivin' in alt.os.linux on Thu, 6 Dec 2018
08:57 am. It's a cool scene! Dig it.
> On Wed, 5 Dec 2018 19:58:51 +0100, Carlos E.R. wrote:
>
>> 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.
>
> Mea culpa.
> The pictures are correct.
> My transcription was wrong.
>
> The correction is sda1, sdb1, & sdc1, each of which is it's own HDD.
No, each is the first partition of a separate HDD. This is an
important distinction in many ways.
> The only working Windows is HDD3 on sda1 (SATA1):
> <http://www.bild.me/bild.php?file=6315743grub_02.jpg>
>
> The other two Windows got corrupted (one by MS, the other by me):
> <http://www.bild.me/bild.php?file=4411450grub01.jpg>
>
> Trial and error shows HDD3 to be "WDC WD10EZEX":
> <http://www.bild.me/bild.php?file=9539818grub04.jpg>
>
> Where HDD3 was already set up in the BIOS to boot first:
> <http://www.bild.me/bild.php?file=1696675grub07.jpg>
>
> What "seems" to be happening is:
> o Disconnecting HDD2 & HDD3, Windows boots from HDD3.
> o Connecting HDD2 & HDD3, Grub on either HDD2 or HDD3 takes over!
No, no, that's not what's happening. At least, the HDD you've
installed the new system on (what you've been calling HDD3) can't have
grub on it. You see, it's like this...
Grub is a multi-stage boot loader. That means that it takes 2 (or
more) steps to boot a system.
First, there is the stage 1 boot loader installed (usually)
in /dev/sda - the boot sector (or MBR) of the first hard drive. Note
that this is not the same as the boot sector of /dev/sda1, the first
partition of the first hard drive. When it is installed, information
about the location of grub's stage 2 and setup files is stored in the
stage 1 image. (These are generally installed in the Linux
distro's /boot directory, usually on its root partition). When the
machine boots, it loads and runs stage 1. This then loads in the
coresponding stage 2. (Note that it may actually load a stage 1.5, an
intermediate stage, first.)
Next, stage 2 kicks in and loads the setup files and any loadable
modules it needs to do its work. It then presents the menu and waits
for user input. Ultimately it performs whatever task the user has
selected (eg. booting an OS).
Now, if you've just removed the first two hard drives and installed a
new OS (without grub) on the third (and only remaining) one, then
either of two things will happen. Either the new system will boot
normally, or an old grub stage 1 will load and look for its
coresponding stage 2 - and fail to find it. Since your Microstuffed
Losedows installation is booting from this HDD, then it means grub is
not installed on it at all.
So, what's happening? Well, I'm always tinkering with computers, and
one thing that always annoys me is that the drive boot order is
frequently changed when I install a new HDD. I have to go into the
BIOS/UEFI setup and change it to the correct order. Another possibility
is that your UEFI based system is booting from the first UEFI partition
it finds, which may contain grub. (Grub stage 1 can be installed to a
partition instead of the MBR. And I'm not sure of the details, but I
think it is installed to a special UEFI partition in a UEFI setup.) A
possible way around this might be to boot in legacy/BIOS mode instead
of UEFI mode.
In any event, your HDD3 with the new Losedows installation isn't the
drive that's booting.
--
----- Dig the NEW and IMPROVED news sig!! -----
-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!
08:57 am. It's a cool scene! Dig it.
> On Wed, 5 Dec 2018 19:58:51 +0100, Carlos E.R. wrote:
>
>> 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.
>
> Mea culpa.
> The pictures are correct.
> My transcription was wrong.
>
> The correction is sda1, sdb1, & sdc1, each of which is it's own HDD.
important distinction in many ways.
> The only working Windows is HDD3 on sda1 (SATA1):
> <http://www.bild.me/bild.php?file=6315743grub_02.jpg>
>
> The other two Windows got corrupted (one by MS, the other by me):
> <http://www.bild.me/bild.php?file=4411450grub01.jpg>
>
> Trial and error shows HDD3 to be "WDC WD10EZEX":
> <http://www.bild.me/bild.php?file=9539818grub04.jpg>
>
> Where HDD3 was already set up in the BIOS to boot first:
> <http://www.bild.me/bild.php?file=1696675grub07.jpg>
>
> What "seems" to be happening is:
> o Disconnecting HDD2 & HDD3, Windows boots from HDD3.
> o Connecting HDD2 & HDD3, Grub on either HDD2 or HDD3 takes over!
installed the new system on (what you've been calling HDD3) can't have
grub on it. You see, it's like this...
Grub is a multi-stage boot loader. That means that it takes 2 (or
more) steps to boot a system.
First, there is the stage 1 boot loader installed (usually)
in /dev/sda - the boot sector (or MBR) of the first hard drive. Note
that this is not the same as the boot sector of /dev/sda1, the first
partition of the first hard drive. When it is installed, information
about the location of grub's stage 2 and setup files is stored in the
stage 1 image. (These are generally installed in the Linux
distro's /boot directory, usually on its root partition). When the
machine boots, it loads and runs stage 1. This then loads in the
coresponding stage 2. (Note that it may actually load a stage 1.5, an
intermediate stage, first.)
Next, stage 2 kicks in and loads the setup files and any loadable
modules it needs to do its work. It then presents the menu and waits
for user input. Ultimately it performs whatever task the user has
selected (eg. booting an OS).
Now, if you've just removed the first two hard drives and installed a
new OS (without grub) on the third (and only remaining) one, then
either of two things will happen. Either the new system will boot
normally, or an old grub stage 1 will load and look for its
coresponding stage 2 - and fail to find it. Since your Microstuffed
Losedows installation is booting from this HDD, then it means grub is
not installed on it at all.
So, what's happening? Well, I'm always tinkering with computers, and
one thing that always annoys me is that the drive boot order is
frequently changed when I install a new HDD. I have to go into the
BIOS/UEFI setup and change it to the correct order. Another possibility
is that your UEFI based system is booting from the first UEFI partition
it finds, which may contain grub. (Grub stage 1 can be installed to a
partition instead of the MBR. And I'm not sure of the details, but I
think it is installed to a special UEFI partition in a UEFI setup.) A
possible way around this might be to boot in legacy/BIOS mode instead
of UEFI mode.
In any event, your HDD3 with the new Losedows installation isn't the
drive that's booting.
--
----- Dig the NEW and IMPROVED news sig!! -----
-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!
arlen holder
Dec 9, 2018, 1:01:16 PM12/9/18
to
On Fri, 7 Dec 2018 14:24:55 +0100, Carlos E.R. wrote:
> Right, then it is just google on how to repair the MBR :-)
> For those that do not know how grub works:
I realize I haven't updated this thread, where, as a courtesy and as a good
> Right, then it is just google on how to repair the MBR :-)
> For those that do not know how grub works:
Usenet citizen, I usually post an update showing exactly what was done so
as to add to the overall tribal knowledge.
Fact is, I'm moving more cautiously than normal for a couple of reasons,
one being that I now UNDERSTAND what is going on thanks to your input
(plural your).
I'm also cautious because, while I don't care what happens to the Windows
10 on the two older HDDs, I don't want to wipe out the partition as I will
lose the data on those two older HDDs. (Given the Win10 on those two HDDs
were both bricked earlier this year, I've likely pulled "much" of the data
I need that was on them, but I don't know for sure.)
I could just move the data around, given I have 3TB in toto for the three
disks, but what I think I'll do is "gracefully" remove the working Ubuntu
on HDD2, and gracefully remove the working Grub on HDD2, and then, probably
far less gracefully, remove the long-gone bricked Windows 10 on HDD2 and
HDD1.
It should be noted that the Microsoft Store couldn't resurrect either of
those bricked Win10s so there's no reason for me to even try.
The operative word here is "gracefully" remove the working Grub & Ubuntu
and the two non-working Win10 setups.
I have BIOS (not UEFI) but this Ubuntu thread shows the complexity:
<https://askubuntu.com/questions/429610/uninstall-grub-and-use-windows-bootloader#869888>
No two procedures seem to be alike, which means I need to better UNDERSTAND
the two steps:
a. Gracefully removing the "active" booters (i.e., Grub & Ubuntu on HDD2)
b. Gracefully removing the "bricked" booters (i.e., Win10 on HDD1 & HDD2)
I'll report back when I have done my homework (which includes re-reading
both Carlos' and Paul's helpful hints and reading all their references).
Thanks.
Carlos E.R.
Dec 10, 2018, 9:48:08 AM12/10/18
to
Have all the disks connected. Get to the bios page. Configure which disk
is to boot. Only one disk has to boot, the one that currently has
Windows, hdd3. Done. Boot.
I have been telling this several times, so just do it!
--
Cheers, Carlos.
0 new messages