Jump to content











Photo
- - - - -

Can't install grub with BootICE


  • Please log in to reply
34 replies to this topic

#26 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 2 weeks ago

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

#27 doveman

doveman

    Frequent Member

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

Posted 2 weeks ago

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
  • 14389 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 weeks ago

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



#29 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 2 weeks ago

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



#30 doveman

doveman

    Frequent Member

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

Posted A week ago

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
  • 431 posts
  • Location:Surrey
  •  
    United Kingdom

Posted A week ago

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
  • 6765 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted A week ago

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
  • 14389 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

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



#34 doveman

doveman

    Frequent Member

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

Posted 5 days ago

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
  • 14389 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 5 days ago

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






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users