• Re: How to reset dual boot Linux:Win GRUB after "inaccessible boot devi

    From Wildman@255:255/999 to Carlos E.R. on Tue Dec 4 20:11:50 2018
    alt.comp.os.windows-10

    On Tue, 04 Dec 2018 18:08:57 +0100, Carlos E.R. wrote:

    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.

    Add this to /etc/default/grub

    GRUB_DISABLE_OS_PROBER=true

    --
    <Wildman> GNU/Linux user #557453
    The cow died so I don't need your bull!

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From arlen holder@255:255/999 to Paul on Wed Dec 5 16:21:20 2018
    XPost: alt.comp.os.windows-10

    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,
    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.

    Ah. This is a good idea!
    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.

    Ah. Another good suggestion (why doesn't SATA1 do its job?).
    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.

    Yes. I agree.
    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.

    Yes. I agree.
    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.

    The PC keeps time, which should indicate a good battery, where I don't see
    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).

    I'm not sure what you mean by "verify the SATA port settings", where I can
    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.

    Hmmmmmmmmmmm... maybe. I will check the battery as, I guess the two days 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).

    That's a bit confusing, where I didn't think, until now, to look at the
    "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.

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From arlen holder@255:255/999 to All on Wed Dec 5 16:21:21 2018
    XPost: alt.comp.os.windows-10

    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)

    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
    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.)

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From Carlos E.R.@255:255/999 to arlen holder on Wed Dec 5 19:58:51 2018
    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: <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
    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:
    <http://www.bild.me/bild.php?file=7780746grub03.jpg>
    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 <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).

    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: <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.

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From Paul@255:255/999 to Carlos E.R. on Wed Dec 5 14:51:16 2018
    XPost: alt.comp.os.windows-10

    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,
    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

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From Mike Easter@255:255/999 to Paul on Wed Dec 5 12:03:19 2018
    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
    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

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From arlen holder@255:255/999 to Carlos E.R. on Wed Dec 5 21:57:17 2018
    XPost: alt.comp.os.windows-10

    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From Carlos E.R.@255:255/999 to Mike Easter on Wed Dec 5 23:02:14 2018
    On 05/12/2018 21.03, Mike Easter wrote:
    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 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.

    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>

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From Carlos E.R.@255:255/999 to arlen holder on Wed Dec 5 23:09:05 2018
    XPost: alt.comp.os.windows-10

    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.
    The first listed and bootable disk will be hdd2 or hdd3.

    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From Mike Easter@255:255/999 to Carlos E.R. on Wed Dec 5 14:18:53 2018
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From David W. Hodgins@255:255/999 to Carlos E.R. on Wed Dec 5 18:44:49 2018
    On Wed, 05 Dec 2018 17:02:14 -0500, Carlos E.R. <robin_listas@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.

    # wc -l RESULTS.txt
    1314 RESULTS.txt

    Time to clean up my system a bit. :-)

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From arlen holder@255:255/999 to Carlos E.R. on Thu Dec 6 22:17:22 2018
    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)

    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)

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From Andy D. Robinson@255:255/999 to All on Thu Dec 6 22:40:55 2018
    XPost: alt.comp.os.windows-10

    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:
    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>

    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?)

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)
  • From arlen holder@255:255/999 to Andy D. Robinson on Thu Dec 6 22:53:54 2018
    XPost: alt.comp.os.windows-10

    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)?
    <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?

    --- SoupGate-Win32 v1.05
    * Origin: SpaceSST BBS Usenet <mccarragher.org> Fidonet Gateway (255:255/999)