135 replies to this topic

[Wonko the Sane]

You successfully cat'ted sector number 1000000000000000000, which is located at around 500000000TB. Horrible! I think it is a bug. You may report it to yaya, the developer of grub4dos usb 2.0 storage driver.

I wonder which bug do you believe it is.

 

I find it more like "missing error control", if it was possible it should be implemented that when a user asks to read a sector beyond 50 TB, a small hand should come up of the pc and slap him/her on the face, hard, shouting "Are you §@ç#ing crazy?!".

 

Wonko

[tinybit]

I wonder which bug do you believe it is.

 

I find it more like "missing error control", if it was possible it should be implemented that when a user asks to read a sector beyond 50 TB, a small hand should come up of the pc and slap him/her on the face, hard, shouting "Are you §@ç#ing crazy?!".

 

Wonko

 

There are more than one possible cases. For instance, it could be a loop / wrap-around in some way - large sector numbers would be equivalent to small ones. Yaya should know for certain.

[devdevadev]

I will try anyway again to explain how to use the suggestion to find the limit of your BIOS.

run:

cat --hex (fd0,0)14000000+1

NO NEED to post a screenshot of the result, if you see the hex data you post:

cat --hex (fd0,0)14000000+1 OK

if you have an error 25 you post:

cat --hex (fd0,0)14000000+1 Error 25

 

Next, IF the command with 14000000 was OK, you run:

cat --hex (fd0,0)21000000+1

 

IF INSTEAD the command was Error 25, you run:

cat --hex (fd0,0)7000000+1

 

I.e. if the last command was successful, you INCREASE the offset to test in next command, if last command produced an error, you DECREASE the offset to test in next command.

The amount that you EITHER increase OR decrease is half the difference between the current  range values, this way the lower and upper limit of the range rapidly converge to the searched for limit.

Sorry I had not understood exact logic of calculation...

cat --hex (fd0,0)14000000+1 OK
cat --hex (fd0,0)21000000+1 Error 25 

So till now i found

14,000,000<x<21,000,000

 

now will test

14,000,000+(21,000,000-14,000,000)/2=17,500,000

 

IF cat --hex (fd0,0)17500000+1 OK

17,500,000<x<21,000,000

 

IF cat --hex (fd0,0)17500000+1 Error 25

14,000,000<x<17,500,000

 

Am I going correct way ?

Will report next sequences soon... 

[Wonko the Sane]

 

Am I going correct way ?

Will report next sequences soon... 

 

Yep  .

 

Just  for the record this is a "Binary Search" :

https://en.wikipedia...earch_algorithm

 

 

Wonko

[steve6375]

post http://reboot.pro/to...e-3#entry208704

shows the BIOS has an 8GB limit.

 

Can someone explain to me what fd0,0 is please?

fd0 is underfloppy with just grldr on FAT12. Where does fd0,0 come from and why does grub4dos see it as fd0,0?

[Wonko the Sane]

post http://reboot.pro/to...e-3#entry208704

shows the BIOS has an 8GB limit.

Well, no.

Now, the EDITED post you mentioned shows that.

 

 

Can someone explain to me what fd0,0 is please?

fd0 is underfloppy with just grldr on FAT12. Where does fd0,0 come from and why does grub4dos see it as fd0,0?

 

When the (half-@§§ed) MBR code is run the USB hard disk is "boot device".

The code loads the underfloppy using an address stored in a "non-standard" offset of the MBR, so *anything else*  cannot see that (unless the underfloppy volume/partition is also "declared" in the GPT table).

 

The (fd0) is NOT the underfloppy, i.e. the underfloppy does NOT exist.

 

Since the PBR/VBR code chainloads the grldr inside the underfloppy, what is loaded is grub4dos, that knows nothing about the underfloppy.

 

Then - normally - you would run (or have in the embedded menu.lst of the loaded grldr) a line to map the (known) extents of the underfloppy to (fd0). i.e.:

map (hd0)63+1985 (fd0)

as most BIOSes will have one hard disk (the boot device) as (hd0), and the volumes in it as (hd0,0), (hd0,1), etc. and the other (the internal) hard disk as  (hd1) and (hd1,0), (hd1,1), etc., (depending if the BIOS changes hard disk order based on the boot device, their order may be inverted of course).

 

Until you have mapped the extents 63+1985 to *something* the underfloppy does not exist (in BIOS or in grub4dos).

 

This particular BIOS (for *whatever* reasons) keeps the internal hard disk as (hd0) and the  USB hard disk (please read it as "boot device") as (fd0).

 

Hence the (only) partition/volume in it becomes (fd0,0), check this post:

http://reboot.pro/to...drive/?p=208633

 

Wonko

[misty]

...if it was possible it should be implemented that when a user asks to read a sector beyond 50 TB, a small hand should come up of the pc and slap him/her on the face, hard, shouting "Are you §@ç#ing crazy?!"....

Hahahahahaha - reading that has made my day - to be fair it's been a sh!t day!!!!!!

strikes again!

Misty

[tinybit]

post http://reboot.pro/to...e-3#entry208704

shows the BIOS has an 8GB limit.

 

Can someone explain to me what fd0,0 is please?

fd0 is underfloppy with just grldr on FAT12. Where does fd0,0 come from and why does grub4dos see it as fd0,0?

 

The floppy should have a partition table in its MBR sector (sector 0).

 

Yes, the MBR sector is the same sector as the BPB sector of  FAT for the floppy.

 

With respect to the BPB info, grub4dos recognized it as a normal floppy (the filesystem type is FAT), which correspond to (fd0).

 

With respect to the partition table, grub4dos recognized its entry 0, that is, (fd0,0). The partition's filesystem type seems to be NTFS.

 

devdevadev could confirm it with this command:

 

cat  --hex  (fd0)+1

 

The sector data should show both a BPB and a valid partition table.

 

Another useful / helpful command is:

 

geometry  (fd0)

 

Note that grub4dos support floppy partitions, just like those for a hard disk. So it is possible to have (fd0,0), (fd0,1), (fd0,2), (fd0,3), (fd0,4), (fd0,5), (fd0,6), (fd0,7), (fd0,8), (fd0,9), (fd0,10), (fd0,11), (fd0,12), ..., etc.

[steve6375]

These images were sent to me by devdevadev - It seems to be a pure PBR?  Maybe this is not actually LBA 0?

 

[Edit] 2nd image is not same sector so ignore it![/Edit]

Attached Files

•  image1.png   1.22MB   0 downloads
•  image2.png   1003.13KB   0 downloads

Edited by steve6375, 21 December 2018 - 09:14 AM.

[tinybit]

These images were sent to me by devdevadev - It seems to be a pure PBR?  Maybe this is not actually LBA 0?

 

The second picture seems not for LBA 0. Note that it does not end with "55 AA".

 

Emm....

 

GPT also could produce (fd0,0).  Does this USB drive have GPT?

[steve6375]

yes, I believe it is a hybrid GPT drive. I have asked devdevadev to use RMPrepISB - DriveInfo to post the outputs of the actual sectors so we can see what is on the drive...

[tinybit]

GPT info starts at LBA 1. So this will do:

 

cat  --hex  (fd0)1+1

[Wonko the Sane]

Hey guys, guess what does the WtSf in the bootsector means? 
 
The first screenshot Steve6375 posted is the beginning of the "underfloppy" bootsector (or first absolute sector of the underfloppy image), the second one is *something else* very likely dedevadev has made some confusion when sending the images.
 
 
 

GPT also could produce (fd0,0).  Does this USB drive have GPT?

 
Yes, that is exactly what is happening.
I thought it was clear in my previous post
the "internal hard disk" has been mapped as (hd1) (hd0) and has all its partitions.
the USB hard disk has been *somehow* been mapped to (fd0) and its first and only partition is (fd0,0)
http://reboot.pro/to...drive/?p=208633
 
This is what grub4dos normally does with this method, it is a kind of "overlay" between the "underfloppy", intended as "boot device" and the whole GPT hard disk, only normally this happens to be (hd0), as in the Qemu screenshot posted in the above post, with this BIOS, the USB hard disk is mapped as (fd0) instead.
 

Wonko

[devdevadev]

tinybit, on 20 Dec 2018 - 2:53 PM, said:

devdevadev could confirm it with this command:

cat --hex (fd0)+1

The sector data should show both a BPB and a valid partition table.

Another useful / helpful command is:

geometry (fd0)

 1.jpeg   129.09KB   0 downloads  2.jpeg   101.49KB   0 downloads

tinybit, on 20 Dec 2018 - 3:58 PM, said:

GPT info starts at LBA 1. So this will do:

cat --hex (fd0)1+1

 3.jpeg   129.35KB   0 downloads

misty, on 17 Dec 2018 - 12:52 AM, said:
@devdevadev
Why not put Wonko's hypothesis in post #63 to the test. Wonko has speculated that your BIOS may hit the 8.4 GiB limit with a maximum of 1024 x 255 x 63 sectors being accessible by the BIOS. 1024 x 255 x 63 = 16450560. Try the following -

cat --hex (fd0,0)16450559+1 failcat --hex (fd0,0)16450560+1 fail cat --hex (fd0,0)16450561+1 fail

 6.jpeg   81.74KB   0 downloads

tinybit, on 17 Dec 2018 - 09:00 AM, said:
Also its wrong using (fd0,0). It should be (fd0). I am so sorry for that post of mine.

cat --hex (fd0)16450559+1 ok cat --hex (fd0)16450560+1 failcat --hex (fd0)16450561+1

 7.jpeg   150.56KB   0 downloads  8.jpeg   98.92KB   0 downloads

steve6375, on 20 Dec 2018 - 3:46 PM, said:
yes, I believe it is a hybrid GPT drive. I have asked devdevadev to use RMPrepISB - DriveInfo to post the outputs of the actual sectors so we can see what is on the drive...

cat --hex (fd0)0+1

 4.jpeg   149.05KB   0 downloads  5.jpeg   142.07KB   0 downloads

 USBInfo 0.Txt   6.12KB   2 downloads

 

Wonko the Sane, on 20 Dec 2018 - 8:26 PM, said:
the "internal hard disk" has been mapped as (hd1) and has all its partitions.

the "internal hard disk" has been mapped as (hd0) and has all its partitions ?

So after doing so much investigations, Can anybody PLEASE suggest me about best and correct way (except Wonko underfloppy method which works at least  ) to install Grub4dos in 4TB GPT USB-HDD so that Grub4dos will treat (fd0,0) as (hd0,0) as default without any re-mapping.. I think this is not issue of Sony Vaio because one more PC also treat first partition of 4TB GPT USB-HDD as (fd0,0). Is it due to underfloppy used in Wonko method OR Something wrong with Grub4dos behavior for 4TB GPT USB-HDD ? Syslinux method also does not seems to work in Sony VAIO ?

 

Misty new Approach  currently does not seems to work for 4TB GPT USB-HDD ?

 http://reboot.pro/to...rt/#entry208744

[tinybit]

1.jpeg2.jpeg

3.jpeg

 

(fd0)+1 is the MBR sector (LBA 0). It has a partition table, but actually only for the EFI GPT. The only partition is (fd0,0) on this partition table. The partition type / ID is hex EE, which is protective for the EFI GPT. I think grub4dos will effectively ignore the EE protective partition.

(fd0)1+1 is LBA 1. It has EFI GPT info. And grub4dos should recognize a valid partition entry in the GPT and treat it as (fd0,0).

geometry (fd0) shows (CHS), meaning the BIOS has no LBA / EBIOS support. So it cannot access sectors across the 8.4G limit.
geometry (fd0) also shows entry 0 in the MBR partition table, with EFI GPT protective partition ID of 0xEE (that is, hex EE).

the "internal hard disk" has been mapped as (hd0) and has all its partitions ?

Yes. I think so.

[Wonko the Sane]

the "internal hard disk" has been mapped as (hd0) and has all its partitions ?

Yep, sorry, typo, corrected on original post.
 

So after doing so much investigations, Can anybody PLEASE suggest me about best and correct way (except Wonko underfloppy method which works at least  ) to install Grub4dos in 4TB GPT USB-HDD so that Grub4dos will treat (fd0,0) as (hd0,0) as default without any re-mapping.. I think this is not issue of Sony Vaio because one more PC also treat first partition of 4TB GPT USB-HDD as (fd0,0). Is it due to underfloppy used in Wonko method OR Something wrong with Grub4dos behavior for 4TB GPT USB-HDD ?

I don't get it.
The method as is works and boots grub4dos.
The menu.lst that you want to use (provided that it will work) is placed in a "too high" location, beyond the reach of the BIOS. that has an 8 GB size limit.
You can:
1) move the menu.lst to a lower position
OR:
2) use a later grub4dos using its internal USB stack via usb --init
Either way you have:
1) grub4dos booted
2) the menu.lst accessible
the only issue is that the USB hard disk is mapped to (fd0).

What (the heck) is the problem in remapping the (fd0) to (hd0) (and (hd0) to (hd1) if needed)?

This is something you ALREADY did, seemingly with success:
http://reboot.pro/to...drive/?p=208685
 

I have also tried following menu entries from command line...

usb --init
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (fd0,0)
configfile /AIO/Tools/grub4dos/menu.lst

usb --init
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (hd0,0)
configfile /AIO/Tools/grub4dos/menu.lst

Both worked and booted to AIO Grub4dos Menu...
Grub4dos.jpeg
 
And also successfully chainload AIO Grub2 Menu from AIO Grub4dos Menu

WHAT is the problem with the above?
 
Are you wanting to try each and every method theoretically possible?
 
Then next try the UMBR method that seemingly works just fine.


Wonko

[devdevadev]

geometry (fd0) shows (CHS), meaning the BIOS has no LBA / EBIOS support. So it cannot access sectors across the 8.4G limit.

 

http://chenall.net/post/grub4dos_umbr/

UMBR (Universal Master Boot Record) is a simple general-purpose MBR bootloader that only supports LBA mode (the BIOS does not support LBA and cannot be used. Currently, most of the older machines support it).

 

Are you wanting to try each and every method theoretically possible?
 Then next try the UMBR method that seemingly works just fine.

YES,   

Do you think UMBR method will also work for BIOS with no LBA / EBIOS support and 8.4G limit ?

May be UMBR work only if (fd,0)/grldr located within 8.4GB limit ?

 

BTW, I am curious to install UMBR code in the same disk (fd0,0) or (hd0,0) from which Grub4dos itself (fd0) or (hd0) executing following UMBR code if possible ? Will current Grub4dos MBR boot code be overwritten by UMBR MBR boot code successfully without any issue ? 

 

http://reboot.pro/to...e-9#entry193703

\root-
|- grldr
|- menu.lst

# (hd0,0) or (fd0,0)/AIO/Tools/grub4dos/grldr   - AIO Modified grub4dos which load /AIO/Tools/grub4dos/menu.lst as default
# (hd0,0) or (fd0,0)/grldr                      - Grub4dos 
# (hd0,0) or (fd0,0)/umbr                       - Grub4dos executable used by gptmbr.g4b (written by chenall)
# (hd0,0) or (fd0,0)/menu.lst                   - Grub4dos menu file which boots to hard disk
# (hd0,0) or (fd0,0)/4TBGPT.TAG                 - Marker file to 29GB FAT32 AIO partition 1 of 4TB GPT USB-HDD disk

title Install UMBR code to MBR of 4TB GPT USB-HDD disk
if exist (hd0,0)/4TBGPT.TAG (hd0,0)/umbr -d=0 -p=0 (hd0,0)/AIO/Tools/grub4dos/grldr (hd0,0)+1 (hd0,0)/grldr 
if exist (fd0,0)/4TBGPT.TAG (fd0,0)/umbr -d=0 -p=0 (fd0,0)/AIO/Tools/grub4dos/grldr (fd0,0)+1 (fd0,0)/grldr 
if exist (hd0,0)/4TBGPT.TAG root (hd0,0)
if exist (fd0,0)/4TBGPT.TAG root (fd0,0)
chainloader /AIO/Tools/grub4dos/grldr
pause
boot

Note- I know I should boot Grub4dos from another USB drive but I want to utilize underfloppy Grub4dos in order to execute UMBR code if possible ? Please forgive me if I am asking for any nonsense (May it be something like cutting same branch sitting on it ?  )... !!!  

[Wonko the Sane]

The 8.4 GB is a limit.
The idea of a limit is that you cannot cross it.

NO IDEA about the way CHS or LBA play into this with UMBR or with anything else, let alone specifically on your stupid SONY BIOS on a stupidly large USB disk with a stupidly large partition. 
 
No way I can convince you to §@ç#ing use the command line AND NOT a pre-made menu.lst entry (and in the specific case of UMBR the --test switch) when experimenting? 
 
You really want to always risk to make systems unbootable and/or to fail (and fail with untraceable errors)?
 
Do you understand that the whole idea of experimenting is:
https://www.goodread...ee-if-they-work

Life is trying things to see if they work.

What is the fun in doing experiments if you are already told the results?
 
JUST DO IT!

If the UMBR code doesn't work, since after all it chainloads a grldr in first partition, you can also try the syslinux/makebootfat modified MBR that chainloads the bootsector of the first (ESP) partition:

http://reboot.pro/to...o-gpt/?p=192974

If there is no EBIOS, that MBR code should print an error message, but from what I understand:

 

 

; Simple Master Boot Record, including support for EBIOS extensions.
;
; The MBR lives in front of the boot sector, and is responsible for
; loading the boot sector of the active partition. The EBIOS support
; is needed if the active partition starts beyond cylinder 1024.
;
; This MBR determines all geometry info at runtime. It uses only the
; linear block field in the partition table. It does, however, pass
; the partition table information unchanged to the target OS.

the EBIOS is only needed if the partition starts after the 8 GB.

 

Since the code is exactly the same:

 

 

; Copyright 2003-2004 H. Peter Anvin - All Rights Reserved
; Copyright 2004-2005 Andrea Mazzoleni - All Rights Reserved

as the one used in the "underfloppy" method and that works fine on the stupid Sony BIOS.:

Wonko

[tinybit]

You successfully cat'ted sector number 1000000000000000000, which is located at around 500000000TB. Horrible! I think it is a bug. You may report it to yaya, the developer of grub4dos usb 2.0 storage driver.

 

Yaya said the bug was fixed with the latest release (2018-12-23), downloadable here:

 

http://grub4dos.chenall.net/

[Wonko the Sane]

Yaya said the bug was fixed with the latest release (2018-12-23), downloadable here:

 

http://grub4dos.chenall.net/

Good, thanks .

 

Wonko

[devdevadev]

JUST DO IT!

If the UMBR code doesn't work, since after all it chainloads a grldr in first partition, you can also try the syslinux/makebootfat modified MBR that chainloads the bootsector of the first (ESP) partition:

http://reboot.pro/to...o-gpt/?p=192974

title Install UMBR code to MBR of 4TB GPT USB-HDD disk
if exist (hd0,0)/4TBGPT.TAG (hd0,0)/umbr -d=0 -p=0 (hd0,0)/AIO/Tools/grub4dos/grldr (hd0,0)+1 (hd0,0)/grldr 
if exist (fd0,0)/4TBGPT.TAG (fd0,0)/umbr -d=0 -p=0 (fd0,0)/AIO/Tools/grub4dos/grldr (fd0,0)+1 (fd0,0)/grldr 
if exist (hd0,0)/4TBGPT.TAG root (hd0,0)
if exist (fd0,0)/4TBGPT.TAG root (fd0,0)
chainloader /AIO/Tools/grub4dos/grldr
pause
boot

 1.jpeg   70.88KB   0 downloads

Does not seems to work in 4TB Sony VAIO but work fine in QEMU...

 

If the UMBR code doesn't work, since after all it chainloads a grldr in first partition, you can also try the syslinux/makebootfat modified MBR that chainloads the bootsector of the first (ESP) partition:

http://reboot.pro/to...o-gpt/?p=192974

It's looking script is written only for first (ESP) partition.

 

Can we not use "%PTGUID%"==" A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7 "

 

in place of ESP "%PTGUID%"==" 28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B " so that script will also work for 29GB FAT32 GPT Partition 1 of 4TB USB-HDD ? 

ECHO Writing new PBR ...
dsfi \\.\PhysicalDrive%tdisk% 1048576 512 LBA2048Disk%tdisk%.mod

Should i also change 1048576 offset value for writing new PBR of 29GB FAT32 Partition ?

[Wonko the Sane]

Does not seems to work in 4TB Sony VAIO but work fine in QEMU...

Sure it does not.

And what works on Qemu surely is not the same set of commands (as the device will be in Qemu (hd0) and NOT (fd0)).

 

But UNLESS you try the commands on COMMAND LINE, one by one, you will never be able to understand WHY it doesn't work and hopefully find a way to make it work.

 

In any case, besides the UTTER FUTILITY of assembling command lines in menu.lst entries when experimenting, the menu.lst  you tried makes very little sense (at least to me).

 

You are installing the UMBR (without using the --test switch, i.e. without any idea if the commands actually work and as a matter of fact they don't [1]) to chainload a grldr - loosely - on root of first partition and then you attempt to chainload another grldr  in /AIO/Tools/grub4dos/grldr.

 

But basically you are throwing a number of commands intended for a hard disk on something that is currently seen as floppy disk.

 

How about the idea of trying the commands (ONCE AGAIN one by one, on command line) after having re-mapped the (fd0) to (hd0)?

 

 

 

It's looking script is written only for first (ESP) partition.

 

Can we not use "%PTGUID%"==" A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7 "

 

in place of ESP GUID so that script will also work for 29GB FAT32 GPT Partition 1 of 4TB USB-HDD ? 

 

Sure the "installing" batch is written for a first ESP partition, basically because 99.99% of bootable GPT disks will sport a first ESP partition.

 

Nothing prevents you from modifying the batch to suit your needs, but the line:

.

IF "%PTGUID%"==" 28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B "  (ECHO OK, 1st partition GUID is EFIsys.) ELSE (GOTO :error3)

is only a check, if you simply REM it out, the batch will continue execution.

 

But nothing prevents also you from using the actual MBR code ONLY, manually writing the offsets of the first partition and - optionally - writing the BPB for the (huge, being 29 GB) "virtual superfloppy".

 

Wonko

 

[1] Please note how - notwithstanding what is on chenall's UMBR page - actual tests, actually properly performed on command line, showed that only two "booting target" parameters are accepted by UMBR (when it works), the third being always the chainloading of the partition bootsector, see:

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

[devdevadev]

Happy Christmas to ALL....

 

But UNLESS you try the commands on COMMAND LINE, one by one, you will never be able to understand WHY it doesn't work and hopefully find a way to make it work.

How about the idea of trying the commands (ONCE AGAIN one by one, on command line) after having re-mapped the (fd0) to (hd0)? 

http://reboot.pro/to...e-9#entry193703

(fd0)\root-

|- grldr
|- menu.lst

title commandline                                  
commandline

title Switch to UMBR                          (Worked only in QEMU but not in Sony VAIO BIOS)  
usb --init
if exist (fd0)/grldr map (hd0) (hd1)
if exist (fd0)/grldr map (fd0) (hd0)
if exist (fd0)/grldr map --hook
root (hd0,0)
umbr -d=0 -p=0 (hd0,0)/grldr (hd0,0)+1
chainloader (hd0,0)/grldr
boot

title AIOBOOT Grub4dos Menu                   (Worked BOTH in QEMU and Sony VAIO BIOS) 
usb --init
if exist (fd0)/grldr map (hd0) (hd1)
if exist (fd0)/grldr map (fd0) (hd0)
if exist (fd0)/grldr map --hook
root (hd0,0)
configfile /AIO/Tools/grub4dos/menu.lst

title AIOBOOT GRUB2 Menu                      (Worked BOTH in QEMU and Sony VAIO BIOS)  
usb --init
if exist (fd0)/grldr map (hd0) (hd1)
if exist (fd0)/grldr map (fd0) (hd0)
if exist (fd0)/grldr map --hook
root (hd0,0)
kernel /AIO/grub/g2ldr
boot

(fd0,0)\root-

|- AIO

|- grldr

|- umbr
|- menu.lst

title Welocme AIO
configfile /AIO/Tools/grub4dos/menu.lst

title commandline
commandline

29GiB GPT FAT32 Partition 1-

This time I have started from Commad line  option and tested following set of commands one by one on 29 GB FAT32 GPT Partition 1.

map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (hd0,0)
umbr --test -d=0 -p=0 (hd0,0)/grldr (hd0,0)+1

 1.jpeg   209.92KB   0 downloads

usb --init
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (hd0,0)
umbr --test -d=0 -p=0 (hd0,0)/grldr (hd0,0)+1

 2.jpeg   209.19KB   0 downloads  3.jpeg   105.02KB   0 downloads

usb --init
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (hd0,0)
umbr -d=0 -p=0 (hd0,0)/grldr (hd0,0)+1

 4.jpeg   140.96KB   0 downloads  after REBOOT   5.jpeg   93.81KB   0 downloads  6.jpeg   122.49KB   0 downloads

 

4GiB GPT FAT32 Partition 1-

Here I have re-partitioned 4TB GPT USB-HDD and this time created 4GiB (< 8.4 limit)  FAT32 AIO Partition 1 and use following commands.

usb --init
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (hd0,0)
umbr --test -d=0 -p=0 (hd0,0)/grldr (hd0,0)+1 

 7.jpeg   191.28KB   0 downloads  8.jpeg   151.07KB   0 downloads

Why worked in test mode ? Is it due to current effect of usb --init bios extension under (fd0)/grldr grub4dos environment ?

usb --init
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (hd0,0)
umbr -d=0 -p=0 (hd0,0)/grldr (hd0,0)+1

 9.jpeg   170.87KB   0 downloads  after REBOOT   10.jpeg   80.45KB   0 downloads

WHY this error AGAIN while 4GiB GPT FAT32 AIO Partition 1 is within 8.4GiB limit ? Is it because VAIO BIOS has no LBA / EBIOS support and UMBR bootloader only supports LBA mode ?

 

 

[1] Please note how - notwithstanding what is on chenall's UMBR page - actual tests, actually properly performed on command line, showed that only two "booting target" parameters are accepted by UMBR (when it works), the third being always the chainloading of the partition bootsector, see:

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

http://chenall.net/post/grub4dos_umbr/

Umbr [-d=D] [-p=P] [--test] [file1] [file2] [file3]

Note: This 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, try file2 again...

So how the third (File3 ?) being always the chainloading of the partition bootsector while only File1-2 can be a PBR ? 

[tinybit]

Is it because VAIO BIOS does not support LBA and UMBR bootloader only supports LBA mode ?

 

 

Great! You hit it!

 

If I am not mistaken, UMBR is based on WEE. The latter requires LBA support.

[devdevadev]

But nothing prevents also you from using the actual MBR code ONLY, manually writing the offsets of the first partition and - optionally - writing the BPB for the (huge, being 29 GB) "virtual superfloppy".

mkgrldrGPT.cmd

Spoiler

@ECHO OFF
pushd "%~dp0"
SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
::mkgrldrGPT.cmd Small batch by jaclaz to allow booting to
::grub4dos grldr placed on first partition of a GPT disk
::the partition NEEDS to be EFIsys, formatted as FAT32
::AND start at LBA 2048
::Version 0.01 Alpha 03 June 2015

FOR %%? IN (
dsfo.exe
dsfi.exe
dumphex.exe
hexalter.exe
FAT32grldr.bss
mbrfatmod32.mbr
) DO IF NOT EXIST %%? SET Mia=%%?&GOTO :Error0

::make the user choose the target disk
SET tdisk=
SET /P tdisk=Please enter the disk number:
FOR /L %%A IN (0,1,9) DO IF "%%A"=="%tdisk%" GOTO :continue
GOTO :error1
:continue

::make sure the disk exists and it is a GPT one
IF EXIST LBA0Disk%tdisk%.ori DEL LBA0Disk%tdisk%.ori
ECHO Copying LBA0 to LBA0Disk%tdisk%.ori ...
dsfo \\.\Physicaldrive%tdisk% 0 512 LBA0Disk%tdisk%.ori
FOR /F "tokens=2 delims=:" %%? IN ('dumphex /S448 /L3 /nc LBA0Disk%tdisk%.ori 2^>^&1^|FIND ":"') DO SET ProtEntry=%%?
IF "%ProtEntry%"==" 02 00 EE " (ECHO OK, Protective MBR entry found.) ELSE (GOTO :error2)
ECHO.


::let's check first partition entry in GPT table
IF EXIST LBA2Disk%tdisk%.ori DEL LBA2Disk%tdisk%.ori
ECHO Copying LBA2 to LBA2Disk%tdisk%.ori ...
dsfo \\.\Physicaldrive%tdisk% 1024 512 LBA2Disk%tdisk%.ori
ECHO.
FOR /F "tokens=2 delims=:" %%? IN ('dumphex /L16 /nc LBA2Disk%tdisk%.ori 2^>^&1^|FIND ":"') DO SET PTGUID=%%?
REM IF "%PTGUID%"==" 28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B " (ECHO OK, 1st partition GUID is EFIsys.) ELSE (GOTO :error3)

::let's check start offset of EFIsys partition
FOR /F "tokens=2 delims=:" %%? IN ('dumphex /S32 /L16 /nc LBA2Disk%tdisk%.ori 2^>^&1^|FIND ":"') DO SET PTEntry=%%?
SET /A StartLba=0x%PTEntry:~10,2%%PTEntry:~7,2%%PTEntry:~4,2%%PTEntry:~1,2%
SET /A NumLBA=0x%PTEntry:~34,2%%PTEntry:~31,2%%PTEntry:~28,2%%PTEntry:~25,2%
IF "%StartLBA%"=="2048" (ECHO OK, EFIsys starts at LBA 2048) ELSE (GOTO :error4)
ECHO.

::let's get the FAT32 bootsector
IF EXIST LBA2048Disk%tdisk%.ori DEL LBA2048Disk%tdisk%.ori
ECHO Copying LBA2048 to LBA2048Disk%tdisk%.ori ...
dsfo \\.\Physicaldrive%tdisk% 1048576 512 LBA2048Disk%tdisk%.ori
FOR /F "tokens=2 delims=:" %%? IN ('dumphex /S14 /L2 /nc LBA2048Disk%tdisk%.ori 2^>^&1^|FIND ":"') DO SET ResSect=%%?
FOR /F "tokens=2 delims=:" %%? IN ('dumphex /S82 /L5 /nc LBA2048Disk%tdisk%.ori 2^>^&1^|FIND ":"') DO SET Filesys=%%?
SET /A ResSectDec=0x%ResSect:~4,2%%ResSect:~1,2%
FOR /F "tokens=2 delims=:" %%? IN ('dumphex /S28 /L4 /nc LBA2048Disk%tdisk%.ori 2^>^&1^|FIND ":"') DO SET SectBef=%%?
SET /A SectBefDec=0x%SectBef:~10,2%%SectBef:~7,2%%SectBef:~4,2%%SectBef:~1,2%
IF "%FileSys%"== " 46 41 54 33 32 " IF "%SectBefDec%"=="2048" (ECHO OK, FAT32 bootsector found at LBA 2048) ELSE (GOTO :error5)
ECHO.

::let's copy the base MBR
IF EXIST LBA0Disk%tdisk%.mod DEL LBA0Disk%tdisk%.mod
dsfo LBA0Disk%tdisk%.ori 0 512 LBA0Disk%tdisk%.mod
::and apply the new code
dsfi LBA0Disk%tdisk%.mod 0 432 mbrfatmod32.mbr
::create the partition entry
ECHO Writing fake partition table entry at Offset 414:
SET PTLine=80 00 00 00 0B 00 00 00 %PTEntry:~1,11% %PTEntry:~25,11%
ECHO %PTLine%
SET PTLine=%PTLine: =,0x%
hexalter LBA0Disk%tdisk%.mod 414=0x%PTLine%
ECHO.

::let's create the new FAT32 PBR invoking grldr
::BPB first
IF EXIST LBA2048BPBDisk%tdisk%.ori DEL LBA2048BPBDisk%tdisk%.ori
ECHO Creating the BPB file LBA2048BPBDisk%tdisk%.ori
dsfo LBA2048Disk%tdisk%.ori 11 87 LBA2048BPBDisk%tdisk%.ori
ECHO.

::copy of GRLDR FAT32 bootsector
IF EXIST LBA2048Disk%tdisk%.mod DEL LBA2048Disk%tdisk%.mod
ECHO Creating the new PBR file LBA2048Disk%tdisk%.mod from template
dsfo FAT32grldr.bss 0 512 LBA2048Disk%tdisk%.mod
ECHO.

::replace BPB
ECHO Applying the BPB to the PBR ...
dsfi LBA2048Disk%tdisk%.mod 11 87 LBA2048BPBDisk%tdisk%.ori
ECHO.

::let's write the optional BPB to the MBR (in order to have available as root (hd0) besides the GPT (hd0,0))
::this part can probably be REMmed out as it is not strictly needed
ECHO Applying the BPB to the MBR ...
dsfi LBA0Disk%tdisk%.mod 0 87 LBA2048Disk%tdisk%.mod
ECHO.

::Set the sectors before to 0
ECHO Correcting Sectors Before to 0
hexalter LBA0Disk%tdisk%.mod 29=0x00
ECHO.

::Set the reserved sectors to current value+2048
::Here we assume that the number of reserved sectors are originally less than 255
ECHO Increasing Reserved Sectors +2048
hexalter LBA0Disk%tdisk%.mod 15=0x08
ECHO.

ECHO The program has all the data, NO changes were made to the \\.\PhysicalDrive%tdisk%.
SET Confirm=NO
ECHO Do you want to write the new MBR and PBR/VBR to the \\.\PhysicalDrive%tdisk%?
SET /P Confirm=Type YES to confirm:
IF /I NOT "%Confirm%"=="yes" GOTO :error6

ECHO Writing new MBR ...
dsfi \\.\PhysicalDrive%tdisk% 0 512 LBA0Disk%tdisk%.mod
ECHO.

ECHO Writing new PBR ...
dsfi \\.\PhysicalDrive%tdisk% 1048576 512 LBA2048Disk%tdisk%.mod
ECHO.

PAUSE

GOTO :EOF
:error0
ECHO At least one needed file is missing: %Mia%
PAUSE
GOTO :EOF

:error1
ECHO Disk number not valid, exiting ...
PAUSE
GOTO :EOF
:error2
ECHO No protective MBR entry, exiting ...
PAUSE
GOTO :EOF
:error3
ECHO First partition is not an EFIsys one, exiting ...
PAUSE
GOTO :EOF
:error4
ECHO EFIsys partition does not start at LBA 2048, exiting ...
PAUSE
GOTO :EOF
:error5
ECHO Partition is not FAT32 or does not start at LBA 2048, exiting ...
PAUSE
GOTO :EOF
:error6
ECHO Program terminated by user, exiting ...
PAUSE
GOTO :EOF

 

I have tried above 'mkgrldrGPT.cmd' script in my Samsung 32 GB GPT FAT32 Removable USB Drive as trial before testing in 4TB GPT USB-HDD . MBR written successfully ..But unable to write to PBR - 'Access is Denied' ? What may be reason ?

 

Output-  

Spoiler

Please enter the disk number: 3
Copying LBA0 to LBA0Disk3.ori ...
OK, 512 bytes, 0.016s, MD5 = 8a60306fe6eb461891daa4d30f2b8545
OK, Protective MBR entry found.

Copying LBA2 to LBA2Disk3.ori ...
OK, 512 bytes, 0.015s, MD5 = 98cbf2b07e421fd7baab5ea243d302a5

OK, EFIsys starts at LBA 2048

Copying LBA2048 to LBA2048Disk3.ori ...
OK, 512 bytes, 0.000s, MD5 = c2aa2a9047b99e069fc1c9ddd2a6011a
OK, FAT32 bootsector found at LBA 2048

OK, 512 bytes, 0.000s, MD5 = 8a60306fe6eb461891daa4d30f2b8545
OK, written 432 bytes at offset 0
Writing fake partition table entry at Offset 414:
80 00 00 00 0B 00 00 00 00 08 00 00 DE 3F BC 03
Patching successful

Creating the BPB file LBA2048BPBDisk3.ori
OK, 87 bytes, 0.000s, MD5 = 1cf7474941b8200b3b653898c3c02853

Creating the new PBR file LBA2048Disk3.mod from template
OK, 512 bytes, 0.000s, MD5 = 454212360fe56e1a15b1b44869d0b57f

Applying the BPB to the PBR ...
OK, written 87 bytes at offset 11

Applying the BPB to the MBR ...
OK, written 87 bytes at offset 0

Correcting Sectors Before to 0
Patching successful

Increasing Reserved Sectors +2048
Patching successful

The program has all the data, NO changes were made to the \\.\PhysicalDrive3.
Do you want to write the new MBR and PBR/VBR to the \\.\PhysicalDrive3?
Type YES to confirm: YES
Writing new MBR ...
OK, written 512 bytes at offset 0

Writing new PBR ...
\\.\PhysicalDrive3 - Access is denied.

Press any key to continue . . .

 

 1048576.png   11.37KB   0 downloads

Please help...