Jump to content











Photo
- - - - -

Can't install grub with BootICE


  • Please log in to reply
62 replies to this topic

#26 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 November 2018 - 09:20 AM

The last two tests seems fine. (pointless, but fine)

Comparing the 1st with the 2nd, it seems that (for *whatever* reasons) the UMBR doesn't "like" the (hd1,5).

What happens with:
umbr -d=1 -p=1 --test (hd1)1577000+532

Can you try (only for the sake of testing) try some "lower" location for grldr?
And the map exchaniging of the drives?

:duff:
Wonko
  • doveman likes this

#27 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 27 November 2018 - 01:13 AM

With
umbr -d=1 -p=1 --test (hd1)1577000+532

I got this
Attached File  IMG_20181126_223310.jpg   104.61KB   0 downloads

Then I tried mapping the drives to swap them over
umbr -d=0 -p=1 --test (hd0,5)/grldr

and got this
Attached File  IMG_20181126_223634.jpg   105.41KB   0 downloads

Then I tried grldr on (hd1,3) (without mapping the drives)
umbr -d=1 -p=1 --test (hd1,3)/grldr

and got this
Attached File  IMG_20181126_224047.jpg   109.85KB   0 downloads

Then I tried with grldr on the USB stick I booted from rather than the HDD (same version)
umbr -d=1 -p=1 --test (hd0,0)/grldr

and got this
Attached File  IMG_20181126_224233.jpg   108.32KB   0 downloads

#28 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 November 2018 - 04:57 PM

The error is still the same. :(

 

Which grub4dos version are you trying?

Try using both the grub4dos (both the "running" one in which you run the umbr command and the copy to be inked to) and the umbr in the download on Steve6375. (I have to presume they work together and work correctly).

 

If you are already using them, then try without the --test switch (but only do that after having saved a backup copy of the first sector of the HD), maybe it  is it that is causing the issue? (from what I can understand the --test makes use of the rd device, it is possible that for *some reasons* that does not work on your machine :dubbio: )

 

Can you try on another device?

 

I mean another hard disk or USB stick?

 

How big  is the device you are using?  From the protective MBR it has more than 0xFFFFFFFF sectors, is it a 3 or 4 TB hard disk?

 

:duff:

Wonko


  • doveman likes this

#29 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 November 2018 - 01:40 PM

I did (quite a few) checks/tests.
 
Are you sure that the files on (hd1,5) are accessible by grub4dos?
Or are they Bitlockered/whatever?
 
The result of blocklist (hd1,5)/grldr:
 

#3 - blocklist (hd1,5)/grldr returns 1577000+532

 
should be:
(hd1,5)1577000+532
and NOT (my bad):
(hd1)1577000+532
 
The other issues are seemingly because of mixing/mingling with the hard disk number and/or using the old grldr version..
 
Try doing this.
Have a copy of umbr on the partition where the grldr (the "right" version) is.
Boot to the "right" version of grldr (no matter if on another device).
Root to the volume where the copy of umbr and the grldr you want to link to is, in this example (hd0,0).
Run:
umbr --test (hd0,0)/grldr (hd0)1+2
the result is in the attached image.
The lines are:
00000000: EB 4E 90 00 00 00 00 00 55 4D 42  52 01 00 00 00 <- this is the fixed header of the MBR
 
00000010: 89 C8 6E 02 00 00 E0 07 70 00 00 00 00 00 00 00 <- which represent:
89C8=0xC889 some form of sum or checksum for the contents of the file that is for the grldr 2016-12-23
6E020000=0x0000026E size of the grldr file in sectors, file is 318277 bytes, in sectors used 622=0x026E
E007=Unknown, seemingly E007 for files, C007 for blocklists
7000000000000000=0x0000000000000070 Offset in sectors (absolute i.e. from sector 0 of the device) to the beginning of the file/blocklist
 
00000020: 00 00 02 00 00 00 C0 07 70 00 00 00 00 00 00 00 <- which represent:
0000=0x0000 some form of sum or checksum for the contents, since these are two empty sectors, 0 seems a simple 16 byte checksum
02000000=0x00000002 numbers of sectors, ok, since it was (hd0)1+2
C007=Unknown, seemingly E007 for files, C007 for blocklists
0100000000000000=0x0000000000000001 Offset in sectors (absolute i.e. from sector 0 of the device) to the beginning of the file/blocklist, ok, since it was (hd0)1+2
 
00000030: 60 4A 01 00 00 00 C0 07 3F 00 00 00 00 00 00 00 <- which represent:
604A=0x4A60 some form of sum or checksum for the contents
01000000=0x00000001 numbers of sectors, ok, since this is the "automatic" entry for the PBR of current root, same as (hd0,0)0+1
C007=Unknown, seemingly E007 for files, C007 for blocklists
3F00000000000000=0x000000000000003F Offset in sectors (absolute i.e. from sector 0 of the device) to the beginning of the file/blocklist, ok, since it is 63 sectors before, same as (hd0,0)0+1
 
It seems that for some reasons (possibly a small bug in the implementation) the "failsafe" PBR (which is automatically that of "current root" unless the modifiers -d and -p are used is written as third entry (should be on fourth one), which means that you can propose not 3 different objects (besides the failsafe one) but only two (as the third one is overwritten by the "failsafe" setting).
 
The attentive reader might have noticed :dubbio: that in the image I used the umbrtest (and not the umbr) command.
Umbrtest is only a quickly and half-@§§edly hex-edited umbr that DOES NOT actually try to boot and returns to grub4dos command line, I attach it as well (just in case).

:duff:
Wonko

Attached Files


  • doveman likes this

#30 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 02 December 2018 - 11:05 PM

OK we're getting somewhere!

 

It's a 256GB SSD (I think, I'll have to check the exact size), so no issues with it being over 3TB.

 

I copied over the grldr from Steve6375's download both to my USB stick and partitions 3 and 5 on my SSD.

 

It still wasn't working but then my laptop stopped being able to see the USB stick in the boot menu, so I swapped to another stick, a 8GB FAT32 one, as opposed to the previous 32GB NTFS one.

 

That seems to have made the difference. 

 

I first tried the commands from your screenshot. For some reason root (hd0, didn't work for me but after doing root (hd0,0) the umbr command worked and when I pressed a key it rebooted to the grub4dos menu.

 

The first line of hex looks identical to yours, so I'm not sure why the alphanumeric bit differs. The second line of hex varies a bit from yours.

Attached File  IMG_20181202_223244.jpg   128.3KB   0 downloads

 

I then tried the blocklist command and now it returns +622. I don't know if that's because I've changed the USB stick or the grldr. Running umbr with that didn't give an error but it didn't boot either.

Attached File  IMG_20181202_223759.jpg   125.26KB   0 downloads

 

Then I tried

umbr -d=1 -p=1 --test (hd1,5)/grldr

 

and that didn't give an error but also didn't boot.

 

Attached File  IMG_20181202_224115.jpg   137.2KB   0 downloads

 



#31 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 02 December 2018 - 11:31 PM

Then I tried without the -d= and -p= with (hd1,5)/grldr and (hd1,3)/grldr and both gave errors and when I pressed a key it rebooted to the Intel LAN boot screen, which is part of the BIOS.

 

Attached File  IMG_20181202_224729b.jpg   147.1KB   0 downloads

 

Attached File  IMG_20181202_224852.jpg   128.55KB   0 downloads

 

The drive is definitely not bitlockered at the moment and hd1,5 has never been and I can view the contents from grub4dos.

 



#32 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 03 December 2018 - 09:42 AM

umbr [-d=D] [-p=P] [--test] [file1] [file2] [file3]
    -d=D Specifies that the disk to be installed defaults to the disk of the current ROOT
    -p=D The partition to be started after a failed boot is the first partition by default.
    --test Test mode, do not write to disk
    File1-3 can specify three startup file locations to prevent startup failures.

Note: filex can be any file format recognized by GRUB4DOS (must be stored continuously). For example (hdx, y) / path / file or (hdx) xxxx + yyyy / (hdx, y) xxx + yyy and the like.
    file1-file3 must be on the same disk and consistent with the disk specified by -d.
    file1-2 can also be a PBR such as (hd0, 3) +1
    file1 is the main startup file. If the verification fails, it will try file2 again...



#33 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 December 2018 - 09:56 AM

It wasn't

root (hd0,

it was

root (hd0, [TAB]

 

It is possible (though it makes little sense to me) that the issue is that the (hd1,5) is a logical volume inside extended.

It is also possible that since when the --test is used a (rd) disk is used, the file is simply at a too high address to fit.

 

You need the -d= parameter if you are running the command from an established root on another drive.

 

Your last two tests were run from (hd0,0) that without the -d specification gave you a 129 error, which is an attempt to say:

you are running from drive 128, so i will write data for the 128 drive, but you specified a file on a different drive, drive 129 and this makes no sense. 

 

Now, blocklist (hd1,5)/grdr returns:

(hd1,5)/1577000+622

BUT you issued:

(hd1,5)/15577000+622

maybe that is part of the problem.

 

Forget temporarily about the (hd1,5).

 

Try in a proper way on the first partition of that drive (hd1,0) after having placed in it the "right" grldr or try again, on a known to be working USB stick, with the "right" grldr file in a primary partition AND add as second payload a surely working bootsector, meaning a bootsector of a partition that ALREADY boots normally when chainloaded by grub4dos, i.e. that boots something, example

chainloader (hd0,0)

 boot

 

Your very last test failed for grldr (because you didn't specify the drive) but it worked just fine for the bootsector of "current root", (128,0)+1 or (hd0,0)+1 and it lead you to the "normal" message for a bootsector that cannot find the invoked loader (on 2nd try):

Remove disk or other media

Press any key to restart

 

 

 

:duff:

Wonko


  • doveman likes this

#34 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 08 December 2018 - 09:51 PM

I'm not quite sure what you meant by "try again, on a known to be working USB stick, with the "right" grldr file in a primary partition AND add as second payload a surely working bootsector,"

The only partition on my USB stick is (hd0,0), so the only second payload would have to be on (hd1).

I also couldn't get chainloader (hd0,0) to work as it just gave an error, as it did with any (hd1,x) variant. It didn't error when I tried chainloader (hd0,0)+1 but then it just froze when I did "boot"

Reviewing Steve6375's post of the context, I figured it was unnecessary to specify -d=0 or =p=0 when root is already (hd0,0) so I tried

umbr --test (hd0,0)/grldr

and that worked fine and rebooted to the g4d menu on the USB stick.

So then I tried
root (hd1,5)
umbr -p=5 --test (hd1,5)/grldr

and that worked and booted to the g4d menu on (hd1,5).

So then I tried it without the -test and it said success, so it's presumably written umbr somewhere but obviously not the right place because rebooting just booted into Windows 10.

I didn't test with grldr on (hd1,0) as you suggested as that's the NTFS Recovery partition and a bit fiddly to access but I've done it now and put grldr on there, so I can experiment with that if you think it will be useful.

(hd1,1) is the FAT32 ESP partition which I put grldr on previously but I can't seem to access that partition (E:) in 7-Zip anymore for some reason.

(hd1,2) is the MSR partition, (hd1,3) the NTFS Win 10 partition, (hd1,4) the NTFS Data partition, (hd1,5) the FAT32 LibreElec Boot partition and (hd1,6) the LibreElec ext3 storage partition

All the partitions are primary except for the Recovery (OEM) and the ESP (EFI) partitions.

#35 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 December 2018 - 01:23 PM

I'm not quite sure what you meant by "try again, on a known to be working USB stick, with the "right" grldr file in a primary partition AND add as second payload a surely working bootsector,"

The only partition on my USB stick is (hd0,0), so the only second payload would have to be on (hd1).

I also couldn't get chainloader (hd0,0) to work as it just gave an error, as it did with any (hd1,x) variant. It didn't error when I tried chainloader (hd0,0)+1 but then it just froze when I did "boot"

Reviewing Steve6375's post of the context, I figured it was unnecessary to specify -d=0 or =p=0 when root is already (hd0,0) so I tried

umbr --test (hd0,0)/grldr

and that worked fine and rebooted to the g4d menu on the USB stick.

So then I tried
root (hd1,5)
umbr -p=5 --test (hd1,5)/grldr

and that worked and booted to the g4d menu on (hd1,5).

So then I tried it without the -test and it said success, so it's presumably written umbr somewhere but obviously not the right place because rebooting just booted into Windows 10.

I didn't test with grldr on (hd1,0) as you suggested as that's the NTFS Recovery partition and a bit fiddly to access but I've done it now and put grldr on there, so I can experiment with that if you think it will be useful.

(hd1,1) is the FAT32 ESP partition which I put grldr on previously but I can't seem to access that partition (E:) in 7-Zip anymore for some reason.

(hd1,2) is the MSR partition, (hd1,3) the NTFS Win 10 partition, (hd1,4) the NTFS Data partition, (hd1,5) the FAT32 LibreElec Boot partition and (hd1,6) the LibreElec ext3 storage partition

All the partitions are primary except for the Recovery (OEM) and the ESP (EFI) partitions.

There is someting queer in your setup or in the tools you are using or in the way you are using them or in the OS you are running. :dubbio:

 

There are ONLY primary partitions on GPT.

 

Yes, try with (hd1,0) after having made root to it.

 

In any case the UMBR (when used without the --test) is written to the MBR. hence if you run:

cat --hex --length=80 (hd1)0+1

 

you will be seeing the first 80 bytes of the MBR, which on a GPT disk are all 00's whilst, after you have run successfully the UMBR command they will look like the ones shown when running UMBR --test.

 

About the test on a USB stick (that has only a primary partition) and is (hd0) and the partition is (hd0,0) and there is a copy of the "right" version of gryb4dos in it, aka (hd0,0)/grldr, I was proposing:
1) test that right now if you get to grub4dos and in it you run:

chainloader (hd0,0)

boot

the device actually boots *something* (possibly grub4dos or BOOTMGR or *whatever*)

2) if the above is true, run:

root (hd0,0)

umbr --test (hd0,0)/grldr (hd0,0)0+1

3) the output should give:

00000000: EB 4E 90 00 00 00 00 00 55 4D 42 52 01 00 00 00

00000010: 89 C8 6E 02 00 00 E0 07 yy yy 00 00 00 00 00 00

00000020: xx xx 01 00 00 00 C0 07 3F 00 00 00 00 00 00 00

00000030: xx xx 01 00 00 00 C0 07 3F 00 00 00 00 00 00 00

00000040:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

4) the grub4dos should boot at 1st try

5) if you re-run the same in #2 without the --test parameter it should "stick" and you should be able to see the same as in #3 by running:

cat --hex --length=80 (hd0)0+1

 

:duff:

Wonko


  • doveman likes this

#36 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 14 December 2018 - 10:50 PM

I guess all the partitions are primary, just Windows Disk Management doesn't specifically say that for the EFI and Recovery partitions.

So I checked the MBR for the SSD (hd1) and the USB stick (hd0) and as you can see the SSD already has UMBR installed, presumably as a result of the command I ran in my previous post.

Attached File  IMG_20181214_222132.jpg   169.19KB   0 downloads

In any case I rooted to (hd1,0), checked it has grldr on it and ran
umbr -p=0 (hd1,5)/grldr

and that seems to have been successful

Attached File  IMG_20181214_222421.jpg   142.76KB   0 downloads

I also double-checked the MBR again after

Attached File  IMG_20181214_222454.jpg   129.21KB   0 downloads

but rebooting the laptop still boots straight into Windows 10, no sign of grub4dos.

I tried going into the BIOS Boot Menu by pressing ESC and selecting to boot the SSD in Legacy Mode in case that was necessary to boot grub but that just made it boot into the Intel Boot Agent.

chainloader (hd0,0) (or (hd1,0) or anything it seems) doesn't work at all for me, it just gives an error 13 "Invalid or unsupported executable format"

Attached File  IMG_20181214_224800.jpg   125.92KB   0 downloads

#37 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 December 2018 - 12:14 AM

Just in case this was not mentioned before (or just forgotten):

 

On 8 and 10:

 

First: Make sure "Fast Boot" is not enabled (on Energy options).

 

Second: Disable GUI boot, easier way is use BootIce and on BCD Tab open current BCD(s), (you may have two, one for MBR [Boot\BCD] and another for UEFI [EFI\Microsoft\Boot\BCD]) on Easy Mode and disable Metro Boot Manager and save. (You should verify boot options there are as you want).

 

Optional: Disable "Secure Boot" on PC Bios, (to check if it boots as you want this way).

 

alacran

 

EDIT: I hate UEFI and always prefer to format and repartition HDD or SSD as MBR and reinstall OS, (of course on disks not bigger than 2 TB).


  • doveman likes this

#38 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 December 2018 - 08:45 AM

About the chainloader command, my bad, it should have been:

Proper:

root (hd0,0)

chainloader +1

 

(or, without establishing root, either "chainloader (hd0,0)0+1" or "chainloader (hd0,0)+1") 

 

The attempt that was successful, i.e.:

 

 

In any case I rooted to (hd1,0), checked it has grldr on it and ran
umbr -p=0 (hd1,5)/grldr

and that seems to have been successful

 

Try it again, this time with the --test switch added, it should give you the same success message AND bring you to grldr.

 

In any case, now the UMBR is properly installed, pointing to a grub4dos grldr at offset 0x19E71828.

That means LBA 434,575,400 which, multiplied by 512 makes 222,502,604,800 bytes.

 

Since this is a very high address, it is possible that either the UMBR code or - more probably the BIOS - simply cannot reach it.

 

BUT when you boot, you should have an error of some kind, what you report is more like the UMBR is completely ignored.

 

Is it possible that the BIOS looks for the 0xEE (protective entry in the MBR for the GPT disk) and decides that it really-really you want to boot to UEFI? :dubbio:

 

If you boot the laptop, after having it set to BIOS or "legacy", "normally", from the booted Windows 10 you should be able to see if you booted in BIOS or UEFI mode (since it boots, and you did not - I believe - configure the Windows 10 to boot in BIOS mode), check:

https://www.easyuefi...-uefi-mode.html

 

:duff:

Wonko


  • doveman likes this

#39 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 18 December 2018 - 06:31 PM

Just in case this was not mentioned before (or just forgotten):
 
On 8 and 10:
 
First: Make sure "Fast Boot" is not enabled (on Energy options).
 
Second: Disable GUI boot, easier way is use BootIce and on BCD Tab open current BCD(s), (you may have two, one for MBR [Boot\BCD] and another for UEFI [EFI\Microsoft\Boot\BCD]) on Easy Mode and disable Metro Boot Manager and save. (You should verify boot options there are as you want).
 
Optional: Disable "Secure Boot" on PC Bios, (to check if it boots as you want this way).
 
alacran
 
EDIT: I hate UEFI and always prefer to format and repartition HDD or SSD as MBR and reinstall OS, (of course on disks not bigger than 2 TB).


I checked and Fast Startup is disabled in Windows power options. Secure Boot was already disabled in the BIOS. I also found Fast Boot in the BIOS which I disabled. Still the laptop booted straight into Windows, no sign of grub.

BootICE only shows one BCD entry and it points to \Windows\system32\winload.efi. I unticked "Metro Boot Manager (Win8)" but the laptop still boots straight into Windows. If I go into the laptop's Boot Menu and select Legacy Mode for the SSD rather than UEFI - Windows Boot Manager, then the screen flickers three times before loading Intel Boot Agent, which then fails and exits to another screen showing "BootDevice Not Found".

Attached File  IMG_20181217_220014.jpg   90.76KB   0 downloads

If I turn off the laptop and reboot it with the USB stick plugged in and go to the BIOS Boot Menu and select Legacy Mode for the SSD, the screen still flickers three times but then grldr seems to boot from the USB as it says "trying (hd0,0)" and then the menu loads from the USB. I checked the root from the grub commandline and it's definitely got the USB as (hd0,0) even though I selected the SSD to boot from in the Boot Menu.

I think I'm going to have to admit defeat soon and repartition as MBR as you suggest, as this laptop just doesn't seem to want to boot grub/umbr from a GPT drive.

#40 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 18 December 2018 - 06:51 PM

About the chainloader command, my bad, it should have been:
Proper:
root (hd0,0)
chainloader +1
 
(or, without establishing root, either "chainloader (hd0,0)0+1" or "chainloader (hd0,0)+1")


OK, well that doesn't work either. Whether I use root (hd0,0) and chainloader +1 or just the longer chainloader commands, when I type boot it says "Remove disks or other media. Press any key to restart" and then boots to Intel Boot Agent. Which doesn't seem to make much sense when the USB stick boots fine when I boot it in legacy mode from the BIOS Boot Menu but little seems to make sense with this laptop!

 

The attempt that was successful, i.e.:
 
Try it again, this time with the --test switch added, it should give you the same success message AND bring you to grldr.


That sort of works. It first shows what I guess is the default menu when it can't locate menu.lst (with find... on the first line) before loading the one from the USB stick and when I check root it shows it's still the USB stick (hd0,0) rather than (hd1,0).
 

In any case, now the UMBR is properly installed, pointing to a grub4dos grldr at offset 0x19E71828.
That means LBA 434,575,400 which, multiplied by 512 makes 222,502,604,800 bytes.
 
Since this is a very high address, it is possible that either the UMBR code or - more probably the BIOS - simply cannot reach it.
 
BUT when you boot, you should have an error of some kind, what you report is more like the UMBR is completely ignored.
 
Is it possible that the BIOS looks for the 0xEE (protective entry in the MBR for the GPT disk) and decides that it really-really you want to boot to UEFI? :dubbio:
 
If you boot the laptop, after having it set to BIOS or "legacy", "normally", from the booted Windows 10 you should be able to see if you booted in BIOS or UEFI mode (since it boots, and you did not - I believe - configure the Windows 10 to boot in BIOS mode), check:
https://www.easyuefi...-uefi-mode.html


In the BIOS the Secure Boot setting is set to "Legacy Support Enabled and Secure Boot Disable". The other two options are "Legacy Support Disable and Secure Boot Enable" and "Legacy Support Disable and Secure Boot Disable" (I have no idea what that means, if both Legacy and Secure Boot are disabled that doesn't seem to leave any way to boot!)

Regardless of that setting, selecting "Legacy - Liteon CV5" (that being the SSD) in the BIOS Boot Menu won't boot Windows and either loads the Intel Boot Agent or if my USB stick is plugged in, loads grub4dos from that. Only selecting "UEFI- Windows Boot Manager" works and msinfo32 confirms that the BIOS Mode is UEFI.

EDIT: I tried the "Legacy Support Disable and Secure Boot Disable" option and that just removes the Legacy options for the SSD and USB stick from the Boot Menu, leaving only the UEFI options.

#41 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 December 2018 - 08:34 PM

Let's try again from the beginning, we are confusing matters (at least I am confused)

 

1) let's talk of the stick:

The "Remove disks or other media. Press any key to restart" is actually expected if you have NO system files on the USB stick (hd0,0).

If you made it installing just grub4dos on it, and installing the grub4dos grldr.mbr it boots as follows:

BIOS->MBR(grldr.mbr)->grub4dos

a "normal" booting goes instead like this:

BIOS->MBR (generic code chainloading the bootsector of the active partition)->PBR code (normally if the volume was formatted unfer Windows either NTLDR or BOOTMGR)

the set of commands:

root (hd0,0)

chainloader +1

boot

represent a way to replicate this latter sequence as follows:

BIOS->MBR(grldr.mbr)->grub4dos->above set of commands->PBR code (normally if the volume was formatted under Windows either NTLDR or BOOTMGR)

 

Of course if the system file invoked by the bootsector code (NTLDR or BOOTMGR) does not exist, the result is the message "Remove disks or other media. Press any key to restart".

 

2) let's talk of the experiment 

 

Try it again, this time with the --test switch added, it should give you the same success message AND bring you to grldr.

once grub4dos (grldr) is loaded, it tries looking for menu.lst in ALL volumes/devices it can access/read.

It is entirely possible that (for *whatever* reason) it finds the menu.lst in the USB stick BEFORE the one on (hd1,5) (or in whatever other partition on (hd1,5).

To test this, you should:

1) rename EACH and EVERY menu.lst file you have in ANY connected device/volume to *something else* (I suggest mynu.lst)

2) try again, grub4dos should not be able to find any menu.lst and boot to the commadn line

3) add/rename back a menu.lst on (hd1,5)

4) repeat the experiment.

 

Now this might be the main issue:

 

 

Regardless of that setting, selecting "Legacy - Liteon CV5" (that being the SSD) in the BIOS Boot Menu won't boot Windows and either loads the Intel Boot Agent or if my USB stick is plugged in, loads grub4dos from that. Only selecting "UEFI- Windows Boot Manager" works and msinfo32 confirms that the BIOS Mode is UEFI.

some (stupid) BIOSes check that there is an active partition in the MBR (protective or not) and only chainload the MBR code if this condition is satisfied.

BUT the UEFI specification (and Windows) won't tolerate that the single Protective MBR entry is set to active, refusing to boot in UEFI mode.

 

See this recent thread (and the links provided):

http://reboot.pro/to...e-from-windows/

 

That would explain nicely  what is happening on your machine.

When you boot from a MBR device (the USB stick) BIOS loads the MBR code (which is grldr.mbr) just fine, since the partition on the USB stick is actually active.

When you try to boot from the GPT device BIOS ignores the MBR code (the code written by the UMBR), since there is no active partition entry in the (protective) MBR.

When you boot from the stick and run from grub4dos the UMBR tool with the --test switch, when you "try" booting you are essentially chainloading the MBR (written by UMBR on a "virtual" device) from grub4dos (which doesn't care about the active status of any partition) and not from BIOS, and thus it succeeds.

 

I hope the above makes sense to you (it is actually complex).

 

:duff:

Wonko


  • doveman likes this

#42 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 20 December 2018 - 02:26 AM

Let's try again from the beginning, we are confusing matters (at least I am confused)
 
1) let's talk of the stick:
The "Remove disks or other media. Press any key to restart" is actually expected if you have NO system files on the USB stick (hd0,0).
If you made it installing just grub4dos on it, and installing the grub4dos grldr.mbr it boots as follows:
BIOS->MBR(grldr.mbr)->grub4dos
a "normal" booting goes instead like this:
BIOS->MBR (generic code chainloading the bootsector of the active partition)->PBR code (normally if the volume was formatted unfer Windows either NTLDR or BOOTMGR)
the set of commands:
root (hd0,0)
chainloader +1
boot
represent a way to replicate this latter sequence as follows:
BIOS->MBR(grldr.mbr)->grub4dos->above set of commands->PBR code (normally if the volume was formatted under Windows either NTLDR or BOOTMGR)
 
Of course if the system file invoked by the bootsector code (NTLDR or BOOTMGR) does not exist, the result is the message "Remove disks or other media. Press any key to restart".


OK, thanks for clearing that up, it makes sense to me now.
 

2) let's talk of the experiment 
once grub4dos (grldr) is loaded, it tries looking for menu.lst in ALL volumes/devices it can access/read.
It is entirely possible that (for *whatever* reason) it finds the menu.lst in the USB stick BEFORE the one on (hd1,5) (or in whatever other partition on (hd1,5).
To test this, you should:
1) rename EACH and EVERY menu.lst file you have in ANY connected device/volume to *something else* (I suggest mynu.lst)
2) try again, grub4dos should not be able to find any menu.lst and boot to the commadn line
3) add/rename back a menu.lst on (hd1,5)
4) repeat the experiment.


Before doing this I read the thread you linked to and ended up here http://www.lightofda...cgi/BIOSBootGPTand used gdisk64.exe to set the Legacy BIOS Bootable bit for partition 2 (hd0,1) which is the ESP/Boot partition, as it seemed like it might help.

The first thing it said was "Protective MBR's 0xEE partition is oversized! Auto-repairing" which I guess might have wiped UMBR but that's not easily reinstalled.

I also put grldr on (hd0,1) as it wasn't there already (I can't remember if I added it once then removed it).

I found I needed to run 7-Zip as Admin to access the ESP partition (mounted with BootICE). I must have done that originally but forgot that I needed to.

As for the experiment, as expected with all instances of menu.lst renamed to mynu.lst, grub4dos booted to the command line.

I then renamed back the menu.lst on (hd1,5) and it did find this and checking root from the command line showed it was (hd1,5).

Then I tried
(hd0,0)/umbr -p=0 --test (hd1,5)/grldr

and that succeeded and rebooted to the menu.lst on (hd1,5) (albeit after briefly showing the default menu as it looked for the one on (hd1,5).

So then I tried it without --test and that returned
[0]:(hd1,5)/grldr
success:[ffffc889]
[3]:(129,0)+1

After that I rebooted and selected Legacy mode for the SSD and after flickering three times it showed grub4dos "try (hd0,0)" and then loaded the menu.lst from (hd1,5) (confirmed as root). However that was with the USB stick still plugged in.

If I remove the USB stick, then after flickering a couple of times I get the "BootDevice Not Found" message.

It's an improvement though as it's no longer loading the Intel Boot Agent when I select Legacy mode. Windows 10 still boots OK if I leave it to boot in UEFI mode.

So I thought I'd go back to http://www.lightofda...cgi/BIOSBootGPTand try the fdisk step under Additional Note 1 in case that's the final piece of the puzzle. I've got a gparted ISO on my USB stick and that contains fdisk.

My grub4dos entry, which I cribbed from the syslinux.cfg on the ISO, is:

title Gparted 33
find --set-root /ISO/gparted-live-0.33.0-1-i686.iso
map --mem /ISO/gparted-live-0.33.0-1-i686.iso (0xff)
map --hook
root (0xff)
kernel /live/vmlinuz boot=live union=overlay username=user config components quiet noswap ip= net.ifnames=0 nosplash toram=filesystem.squashfs findiso=/ISO/gparted-live-0.33.0-1-i686.iso
initrd /live/initrd.img

which gets me as far as the choice between "start X to use GParted automatically", "Run 'ForceVideo'" or "Enter command line prompt" but the first two options get stuck on the "debian login: user (automatic login)" screen.

The command line option works and would probably be sufficient for fdisk if I knew my way around linux but I don't. mount doesn't seem to show that the SSD or USB stick are mounted (I can't see /dev/sda or /dev/sdb) and even if they were I wouldn't be sure which is which. So if you could advise me how to get that bootable flag toggled that'd be great.
 

Now this might be the main issue:
 
some (stupid) BIOSes check that there is an active partition in the MBR (protective or not) and only chainload the MBR code if this condition is satisfied.
BUT the UEFI specification (and Windows) won't tolerate that the single Protective MBR entry is set to active, refusing to boot in UEFI mode.
 
See this recent thread (and the links provided):
http://reboot.pro/to...e-from-windows/
 
That would explain nicely  what is happening on your machine.
When you boot from a MBR device (the USB stick) BIOS loads the MBR code (which is grldr.mbr) just fine, since the partition on the USB stick is actually active.
When you try to boot from the GPT device BIOS ignores the MBR code (the code written by the UMBR), since there is no active partition entry in the (protective) MBR.
When you boot from the stick and run from grub4dos the UMBR tool with the --test switch, when you "try" booting you are essentially chainloading the MBR (written by UMBR on a "virtual" device) from grub4dos (which doesn't care about the active status of any partition) and not from BIOS, and thus it succeeds.
 
I hope the above makes sense to you (it is actually complex).


I think I get the gist of it. I hope there's not going to be a test though!

That does seem to be how my (stupid) BIOS works.

Of course even if I get this working it's still going to boot straight into Windows 10 unless the user presses ESC to open the Boot Menu and selects to boot the SSD in Legacy mode, as there's no way to set it to default to that. It's not necessarily a bad thing though, as my brother will only need to boot to LibreElec occasionally and most of the time he'll be using Windows, so not seeing the grub menu all the time will probably be more convenient for him.

#43 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 December 2018 - 02:10 PM

OK.

We are making some progresses :).

 

You don' t actually need gparted at all.

 

You are already *somehow* booting to grub4dos.

 

That means that you can use:

cat --hex --skip=446 (hd1)0+1

to view the current (protective) MBR partition table.

Normally first line (i.e. first partition entry in the MBR partition table) should be:

000001BE: 00 xx xx xx  EE xx xx xx  xx xx xx xx  xx xx xx xx

where first byte is 00 and means "not active" and fifth byte is EE (which is the identifier for the GPT partition spanning over the whole disk).

In your specific case/disk, this is a subset of the second screenshot you posted here:

http://reboot.pro/to...otice/?p=208068

i.e. you should see:

000001BE:  00 00 02 00  EE FE 7F 99  01 00 00 00  FF FF FF FF

000001CE:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

000001DE:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

000001EE:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

000001FE:  55 AA

 

So you can use grub4dos to make that partition active

makeactive (hd1,0)

and quickly check its status by running;

makeactive --status (hd1,0)

and double check it re-running:

cat --hex --skip=446 (hd1)0+1

this time first line will be:

000001BE:  80 00 02 00  EE FE 7F 99  01 00 00 00  FF FF FF FF

the 80 means the active status.

 

BEFORE attempting making the first partition active, I would try seeing what happens making the second partition (which actually doesn't exist) active, i.e.:

makeactive (hd1,1)

and by running:

cat --hex --skip=446 (hd1)0+1

you should see:

 

000001BE:  00 00 02 00  EE FE 7F 99  01 00 00 00  FF FF FF FF

000001CE:  80 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

000001DE:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

000001EE:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

000001FE:  55 AA

IF the BIOS is stupid enough to accept that a non-partition with an active flag is enough to execute the MBR code :dubbio:, it would be probably the best solution (actually a "permanent" workaround).

 

If the above doesn't work do proceed to make the first partition active.

 

:duff:

Wonko


  • doveman likes this

#44 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 20 December 2018 - 07:01 PM

Ladies and Gentlemen, we have lift-off  :jump:

 

The protective MBR partition table had actually changed from before, probably after I ran gdisk I imagine.

 

Attached File  IMG_20181220_182037.jpg   160.88KB   0 downloads

 

Anyway, I set (hd1,1) active and checked that 1CE was now set to 80 and on rebooting the SSD in Legacy mode it booted grub4dos and loaded the menu.lst from (hd0,5) (without the USB stick plugged in).  :thumbup:

 

Now I just need to get my grub4dos menu entries actually working! The one for Windows 10 perhaps isn't necessary although it's nice to have it there in case the user decides that's what they actually want to boot. Maybe Windows 10 will ONLY boot if the SSD is booted in UEFI mode though, in which case I'll forget it.

 

I've tried (where (hd0,1) is the ESP/BOOT partition):

root (hd0,1)

chainloader /bootmgr

 

and from the commandline:

root (hd0,1)

chainloader +1

boot

 

but both just make the laptop reboot.

 

As I say, I don't desperately need a Windows 10 entry. I certainly need the LibreElec one though. I've tried

root (hd0,5)

kernel /KERNEL boot=UUID=LE-BOOT disk=UUID=LE-STORAGE quiet

 

which gets so far but then it says "error in mount_flash: mount_common: Could not mount UUID=LE-BOOT".

 

That's definitely the Volume Label as shown in BootICE. It shows a blank label for the Storage partition but MiniTool Partition Wizard shows it labelled as LE-STORAGE. 

 

I thought maybe the SSD being GPT is preventing LibreElec from seeing the Volume Labels. So I tried

root (hd0,5)

kernel /KERNEL boot=sda6 disk=sda7 quiet

 

but that just gave me "error in mount_flash: mount_part: Unknown filesystem sda6"



#45 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 December 2018 - 08:29 PM

Good. :)
 
Reviewing the data, yes, the GDISK did correct the partition size, now last LBA is 0x1DCF32AF =500118191 which multiplied by 512 is 256060513792, i.e. roughly 250 GB, is this correct?
 
Again two separate issues:
1) Windows 10
you need to check if the bootbcd command you ran earlier was successful.
Or maybe the change in the (protective) MBR data has changed something in the \boot\BCD and it prevents it from booting? :dubbio:
 
If I were you, I would try booting to the Windows 10 in UEFI mode, mount the ESP partition to a drive letter and then re-run bcdboot with the suitable options:

 BCDBOOT C:\WINDOWS /s <drive letter> /f BIOS 
see for reference:
https://docs.microso...ions-techref-di
 
Then you should make sure that the \bootmgr exists (it should otherwise you would have had a "file not found" when chainloading it in grub4dos) and that the \boot\BCD both exists and has valid contents (BOOTICE should be good enough to check it) otherwise BCDEDIT using the /store parameter, see for reference:
https://docs.microso...nd-line-options
and the nice guide by Misty:
http://www.mistyproj...Edit/index.html
 
2) LibreElec
Unix and relatives (Linux) are CaSe SeNsItIve.
grub4dos should not be CaSe SeNsItIve for FAT or NTFS (but it normally is on ISO/CDFS and EXT2/3/4 filesystems).
So double check the commands/names/etc.
 
Most probably (no idea how specifically Libre Elec works, what is its "base" distro - if any - etc.) may allow a number of "cheat codes" that might allow to workaround the label issue.
 
The "error in mount_flash: mount_part: Unknown filesystem sda6" seems like it doesn't "like" the FAT32 :w00t:
 
But what is on the actual (hd0,5) or sda6?
 
:duff:
Wonko
 
P.S.:
Wait a minute , UUID is not LABEL :ph34r::
https://forum.libree...placed-by-uuid/
 
You can try using the uuid command in grub4dos:
http://reboot.pro/to...d-in-this-code/
to get the UUID of the partitions involved, but cannto say if the UUID found is the same as the one that LibreElec uses, ideally you should boot to a "Live" LibreElec and check from it the "/dev/disk/by-uuid":unsure:
  • doveman likes this

#46 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 21 December 2018 - 10:56 AM

OK I've managed to fix the LibreElec problem. I just needed to add /dev/ so boot=/dev/sda6 disk=/dev/sda7.

sda6 just holds Kernel and System, which are LibreElec and sda7 is just storage for the config files, databases, etc.

As for Windows, I checked in BootICE before doing anything else and selecting I:/Boot/BCD (I: is where ESP is mounted) it shows this

Attached File  I-Boot-BCD.png   19.65KB   0 downloads

but if I select "BCD of current system" it shows this

Attached File  Current BCD.png   25.93KB   0 downloads

As you can see, they're not the same. The OS GUID differs and the Metro Boot Manager box I unticked previously for the current system is ticked for I:/Boot/BCD.

So I'm not sure which BCD is actually being used at the moment when I try and boot in Legacy mode but as we've discussed, I'll need to boot from the ESP partition as the Windows partition will be bitlocked eventually. Perhaps I should just delete the BCD and EFI folders on C: (which I recall I created previously for testing purposes) and run the bcdboot command to rebuild the one on I:?

#47 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 December 2018 - 01:31 PM

The second screenshot is correct (you are booted in UEFI mode the BCD is in \Efi\Microsoft\Boot\ and loads \Windows\System32\winlload.efi), and - since you booted to Windows 10 through this - it works.

The first one, as well looks fine (the \boot\BCD loads \Windows\system32\winload.exe).

 

Recap:

Used for UEFI booting (and totally ignored in BIOS) \bootmgr.efi, \Efi\Microsoft\Boot\BCD, \Windows\System32\winlload.efi

Used for BIOS booting (and totally ignored in UEFI) \bootmgr, \boot\BCD, \Windows\System32\winlload.exe

 

So, the UEFI/EFI files you may have duplicated on "C:\" have no influence, while BIOS files on "C:\" shouldn't, but may.

 

And yes. you should re-run the BCDBOOT on I:

BCDBOOT C:\WINDOWS /s I: /f BIOS 

so that we are sure the BIOS files are created there.

Now if you temporarily add to the latter (\boot\BCD) an entry for grldr.mbr (or for grldr or for NTLDR) and (I believe :unsure:) disable "Metro Boot Manager" and enable "Display Boot menu" you should be able to get further, when booted in BIOS via grub4dos and chainloading BOOTMGR, i.e.:

find --set--root /bootmgr 

root <- this should give (hd0,1) as feedback

chainloader /bootmgr <- this should give as feedback something like "Will boot ..... from drive=0x80, , partition=0x1(hidden sectors=0xnn) 

boot

 

should bring you to a "text mode" selection menu with entries "Windows 10" and "grub4dos" (or Ntldr. etc.).

 

What is not clear to me based on your previous report is if BOOTMGR is actually found (and it is loaded but it cannot find the \boot\BCD) or if the \boot\BCD is loaded but it cannot go on (wrong or no winload.exe)  though normally each of these should give an error (but given your "queer" BIOS they might actually produce an error but for *some reasons* the BIOS reboots the machine before you can read them). :unsure:

 

This way we can be sure that the bootmgr is loaded and that the \boot\BCD is accessed.

 

Another test you can make is the following:

 

find --set--root /bootmgr 

root <- this should give (hd0,1) as feedback

map (hd0,1) (fd0)

map --hook

root (fd0)

chainloader /bootmgr <- this should give as feedback something like "Will boot ..... from drive=0x80, , partition=0x1(hidden sectors=0xnn) 

boot

 

the hard disk partition mapped to floppy should work even if - for whatever reasons - there are issues with bootmgr on the GPT partition, as the "virtual" (fd0) thus created will be only a "volume".

:duff:

Wonko


  • doveman likes this

#48 doveman

doveman

    Frequent Member

  • Advanced user
  • 449 posts
  • Location:Surrey
  •  
    United Kingdom

Posted 22 December 2018 - 12:32 AM

And yes. you should re-run the BCDBOOT on I:

BCDBOOT C:\WINDOWS /s I: /f BIOS 
so that we are sure the BIOS files are created there.


OK, I did that and deleted C:\Boot and C:\EFI

Now if you temporarily add to the latter (\boot\BCD) an entry for grldr.mbr (or for grldr or for NTLDR) and (I believe :unsure:) disable "Metro Boot Manager" and enable "Display Boot menu" you should be able to get further, when booted in BIOS via grub4dos and chainloading BOOTMGR, i.e.:
find --set--root /bootmgr 
root <- this should give (hd0,1) as feedback
chainloader /bootmgr <- this should give as feedback something like "Will boot ..... from drive=0x80, , partition=0x1(hidden sectors=0xnn) 
boot
 
should bring you to a "text mode" selection menu with entries "Windows 10" and "grub4dos" (or Ntldr. etc.).


Unfortunately not. The feedback "Will boot..from drive=0x80" appears but then typing boot just causes the laptop to reboot, no sign of any Windows Boot Menu with the added entry for glrdr.
 

Another test you can make is the following:
 
find --set--root /bootmgr 
root <- this should give (hd0,1) as feedback
map (hd0,1) (fd0)
map --hook
root (fd0)
chainloader /bootmgr <- this should give as feedback something like "Will boot ..... from drive=0x80, , partition=0x1(hidden sectors=0xnn) 
boot
 
the hard disk partition mapped to floppy should work even if - for whatever reasons - there are issues with bootmgr on the GPT partition, as the "virtual" (fd0) thus created will be only a "volume".


With that method I get "Error 17 Cannot mount selected partition" when trying
root (fd0)

#49 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 22 December 2018 - 02:41 AM

OK, I did that and deleted C:\Boot and C:\EFI


Unfortunately not. The feedback "Will boot..from drive=0x80" appears but then typing boot just causes the laptop to reboot, no sign of any Windows Boot Menu with the added entry for glrdr.


With that method I get "Error 17 Cannot mount selected partition" when trying
root (fd0)


typo : --set--root should be --set-root

map (hd0,1) (fd0)

is equivalent to

map (hd0) (fd0)

Note: the partition number is ignored. It is a mapping for "whole drive/whole device", not for "a portion of the drive".

You really want to use

map (hd0,1)+1 (fd0)

which means to map the whole partition (hd0,1) as (fd0).


  • doveman likes this

#50 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 December 2018 - 10:56 AM

Of course tinybit is right  :thumbup:  , quite a few errors in my previous post :blush: , this is the (hopefully) correct command sequence

find --set-root /bootmgr 
root
map (hd0,1)+1 (fd0)
map --hook
root (fd0)
chainloader /bootmgr
boot

The idea here is that *for whatever reasons* BOOTMGR cannot properly access the hard disk volume where \boot\BCD is, whilst having both of them on a "virtual" floppy.

 

What is "strange" remains that usually a missing/not accessible \boot\BCD results in an error *like*:

https://social.techn...D00_550x423.png

 

Whilst for *some reasons* your laptop reboots, so it is possible that the reason is something completely different :dubbio:

 

:duff:

Wonko


  • doveman likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users