Jump to content











Photo

How to boot Windows Installer/WTG through BIOS off GPT partitioned Removable USB Drive ?

gpt mbr bios uefi bootmgr grub4dos wtg

  • Please log in to reply
135 replies to this topic

#51 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 13 December 2018 - 06:07 PM

Sorry Wonko for providing half details....

Today we have tested it again for more clear understandings....

post-65263-0-63857700-1544723031.png

 

I have tried following approach in 4TB GPT USB-HDD by using grub4dos-0.4.5c-2015-05-18

\root-
      |- grldr                                   (grub4dos-0.4.5c-2015-05-18)
mkhidGPT.cmd myimage.img 1

We have tested in QEMU and seen NORMAL results.

post-65263-0-23201100-1544723039.png

 

Then we have MBR booted in Sony VAIO VPCEB3TFX and seen STRANGE mapping ?

post-65263-0-52322200-1544723047.jpg

 

Why (hd0) and (hd0,0) are treated as (fd0) and (fd0,0) in above BIOS ?

May be Grub4dos treat 4TB GPT USB-HDD differently ? or May be this old stupid BIOS ?

\root-
|- grldr
|- menu.lst 

Should I try following menu.lst for this BIOS in order to boot AIOBOOT Grub4dos menu ? 

title AIOBOOT Grub4dos Menu
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (hd0,0)
configfile /AIO/Tools/grub4dos/menu.lst

Attached Files

  • Attached File  1.png   99.77KB   0 downloads
  • Attached File  2.png   103.69KB   0 downloads
  • Attached File  3.jpg   165.35KB   0 downloads


#52 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 December 2018 - 07:52 PM

Why (hd0) and (hd0,0) are treated as (fd0) and (fd0,0) in above BIOS ?
May be Grub4dos treat 4TB GPT USB-HDD differently ? or May be this old stupid BIOS ?

 
I am not sure to understand the reason.
 
Maybe the BIOS *assumes* that a USB connected device is anyway a "floppy" or "superfloppy" device, i.e. unpartitioned and maps it to first floppy, then the small code in the GPT loads grldr, and grldr is happy enough to have two devices:
1) first floppy aka (fd0), even if it is a partitioned device, that would be "drive 0" in DOS/BIOS
2) first hard disk aka (hd0) which is actually second disk, but since first one (boot device) has been recognized as floppy, it "shifts" and becomes first hard disk, i.e. that would be "drive 129" but since there is not a "drive 128", it shifts down to become "drive 128"
 
 
 

Should I try following menu.lst for this BIOS in order to boot AIOBOOT Grub4dos menu ? 

title AIOBOOT Grub4dos Menu
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
root (hd0,0)
configfile /AIO/Tools/grub4dos/menu.lst

NO, NO, NO.
You may try those commands on COMMAND LINE (yes, they look fine :) )and actually see what happens, AGAIN, a bunch of commands in a menu.lst give no feedback, if they work they work, etc. it was the recommendation I provided you ONLY one post before yours.
 
namely, run only the:
map (hd0) (hd1)
map (fd0) (hd0)
map --hook
then check if the devices are recognized as they should, and if yes, then run the rest of the commands.
 
:duff:
Wonko

#53 tinybit

tinybit

    Gold Member

  • Developer
  • 1117 posts
  •  
    China

Posted 13 December 2018 - 10:10 PM

grub4dos will never change the drive number for any BIOS drive, unless you use a map command.

What's more, grub4dos won't add a new drive number for non-existent BIOS drives, if you don't use a mapping.

Similarly, without a mapping, grub4dos won't remove a drive number for any existing BIOS drive, nor it would change the order (of BIOS drives) in any way.

The BIOS drives will remain intact ( keep as it is ), until you explicitly change something.

You may check the INT13 BIOS Call with DOS and/or a realmode debugger.

#54 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 December 2018 - 10:38 AM

grub4dos will never change the drive number for any BIOS drive, unless you use a map command.

What's more, grub4dos won't add a new drive number for non-existent BIOS drives, if you don't use a mapping.

Similarly, without a mapping, grub4dos won't remove a drive number for any existing BIOS drive, nor it would change the order (of BIOS drives) in any way.

The BIOS drives will remain intact ( keep as it is ), until you explicitly change something.

Sure :) , and noone accused grub4dos of changing anything.
But the (stupid) SONY BIOS may well behave differently from other BIOSes with bootable USB devices, particulatly with a (stupidly large) 4TB hard disk.

:duff:
Wonko



#55 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 15 December 2018 - 03:38 PM

run only the:

map (hd0) (hd1)
map (fd0) (hd0)
map --hook
then check if the devices are recognized as they should, and if yes, then run the rest of the commands.

Attached File  1.jpeg   176.88KB   3 downloadsAttached File  2.jpeg   144.9KB   2 downloadsAttached File  3.jpeg   133.91KB   2 downloadsAttached File  4.jpeg   140.43KB   2 downloadsAttached File  5.jpeg   216.9KB   1 downloadsAttached File  6.jpeg   119.52KB   2 downloadsAttached File  7.jpeg   144.21KB   2 downloadsAttached File  8.jpeg   123.46KB   2 downloadsAttached File  9.jpeg   72.1KB   2 downloadsAttached File  10.jpeg   69.72KB   2 downloads



#56 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 December 2018 - 04:11 PM

So, it is untrue, but anyway you should root to (hd0,0) before using the configfile with a relative path.

 

 

map (hd0) (hd1)
map (fd0) (hd0)
map --hook

root (hd0,0)

...

 

otherwise you are trying to run the configfile on (fd0,0). 

 

What happens with (say)

cat (hd0,0)/AIO/Tools/grub4dos/menu.lst

and with:

blocklist (hd0,0)/AIO/Tools/grub4dos/menu.lst

 

:duff:

Wonko



#57 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 15 December 2018 - 04:17 PM

So, it is untrue, but anyway you should root to (hd0,0) before using the configfile with a relative path.

 

map (hd0) (hd1)
map (fd0) (hd0)
map --hook

root (hd0,0)

...

 

otherwise you are trying to run the configfile on (fd0,0). 

Please explain what is the EXACT meaning of 'it is untrue' in last post ....it will be easy for me to recall the exact problem more freshly...

 

Attached File  5.jpeg   216.9KB   2 downloads



#58 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 December 2018 - 04:32 PM

Please explain what is the EXACT meaning of 'it is untrue' in last post ....it will be easy for me to recall the exact problem more freshly...

You started it:

http://reboot.pro/to...e-2#entry208601

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

 

You assumed it to be true, I suggested you to first check whether it was true or not.

 

:duff:

Wonko 



#59 tinybit

tinybit

    Gold Member

  • Developer
  • 1117 posts
  •  
    China

Posted 16 December 2018 - 01:20 AM

picture 3:

 

root  (fd0,0)

configfile /AIO/Tools/grub4dos/menu.lst

Error 25: Disk read error

 

Emm.... It's obvious, the file (name) menu.lst exists and was found, but its contents (sector data) cannot be accessed.

 

Why? Well, this bad situation is rather common. It is because the BIOS is limited and cannot access sectors with a large sector number.

 

To get the maximum sector number (with which the BIOS can access sector data), you may have a test as follows:

 

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

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

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

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

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

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

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

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

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

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

.....................................

 

at some point, you will encounter "disk read error". Suppose starting at (fd0,0)10000+1 it failed, then you will know that the Maximum sector number is in the range from 1000 to 9999. You may continue to test and find the exact value of the maximum sector number.

 

Note: You may successfully access all data on the whole drive under Windows or other protected-mode OSes. But most BIOSes have their limit. The limit value will vary with the manufacturer.

 

EDIT:

 

I am sorry. A big mistake. It is wrong using (fd0,0). Please use (fd0) instead.


Edited by tinybit, 17 December 2018 - 03:44 AM.

  • devdevadev likes this

#60 tinybit

tinybit

    Gold Member

  • Developer
  • 1117 posts
  •  
    China

Posted 16 December 2018 - 01:28 AM

Please explain what is the EXACT meaning of 'it is untrue' in last post ....it will be easy for me to recall the exact problem more freshly...

 

attachicon.gif5.jpeg

 

Mappings will not change the BIOS limit. So you get the same error.


  • devdevadev likes this

#61 steve6375

steve6375

    Platinum Member

  • Developer
  • 6937 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 16 December 2018 - 08:39 AM

If you are booting using grub4dos 0.4.6a from a USB drive then try 

usb --init

first and use a USB 2 port  (or if you only have a USB 3 drive and port, try connecting it to the USB 3 port using a USB 2 cable).


  • devdevadev likes this

#62 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 16 December 2018 - 06:13 PM

map (hd0) (hd1)

map (fd0) (hd0)
map --hook

root (hd0,0)

...

otherwise you are trying to run the configfile on (fd0,0). 

 

What happens with (say)

cat (hd0,0)/AIO/Tools/grub4dos/menu.lst

and with:

blocklist (hd0,0)/AIO/Tools/grub4dos/menu.lst

Attached File  0.jpeg   98.07KB   0 downloadsAttached File  1.jpeg   173.11KB   0 downloads

 

If you are booting using grub4dos 0.4.6a from a USB drive then try 

usb --init

first and use a USB 2 port  (or if you only have a USB 3 drive and port, try connecting it to the USB 3 port using a USB 2 cable).

 Attached File  2.jpeg   103.8KB   1 downloadsAttached File  3.jpeg   164.12KB   1 downloadsAttached File  4.jpeg   154.39KB   1 downloads

 

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

Attached File  Grub4dos.jpeg   36.84KB   1 downloads

 

And also successfully chainload AIO Grub2 Menu from AIO Grub4dos Menu 

Attached File  Grub2.jpeg   111.92KB   1 downloads



#63 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 December 2018 - 06:35 PM

So, the menu.lst is simply beyond the BIOS USB capabilities/reach. 

27293088 (if I read correctly the screenshot) is 27293088*512=13,974,061,056 roughly 13 GB, maybe the BIOS limit (for the built-in USB driver) is around the 8 GB.

I.e. likely corresponding to the second big CHS limit.

https://www.win.tue....rge-Disk-4.html

 

 

 

The 8.4 GB limit

Finally, if the BIOS does all it can to make this translation a success, and uses 255 heads and 63 sectors/track (`assisted LBA' or just `LBA') it may reach 1024*255*63*512=8422686720 bytes,

 

You can try moving the menu.lst (and the related files) to a more reasonable address, or use the more recent grub4dos and its USB driver.

 

:duff:

Wonko


  • devdevadev likes this

#64 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 16 December 2018 - 06:36 PM

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

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

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

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

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

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

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

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

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

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

.....................................

 It is wrong using (fd0,0). Please use (fd0) instead.

cat --hex (fd0)0+1  ok  
cat --hex (fd0)10+1  ok
cat --hex (fd0)100+1  ok
cat --hex (fd0)1000+1  ok
cat --hex (fd0)10000+1  ok
cat --hex (fd0)100000+1  ok
cat --hex (fd0)1000000+1  ok 
cat --hex (fd0)100000000+1 fail

gives following error.....

 

Attached File  1.jpeg   235.77KB   0 downloads



#65 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 16 December 2018 - 06:54 PM

usb --init 
cat --hex (fd0)0+1  ok  
cat --hex (fd0)10+1  ok
cat --hex (fd0)100+1  ok
cat --hex (fd0)1000+1  ok
cat --hex (fd0)10000+1  ok
cat --hex (fd0)100000+1  ok
cat --hex (fd0)1000000+1  ok
cat --hex (fd0)10000000+1  ok
cat --hex (fd0)100000000+1  ok
.........................    ok 

cat --hex (fd0)1000000000000000000+1  ok
cat --hex (fd0)10000000000000000000+1 fail 

Attached File  2.jpeg   148.35KB   0 downloadsAttached File  3.jpeg   105.3KB   0 downloads



#66 misty

misty

    Silver Member

  • Developer
  • 969 posts
  •  
    United Kingdom

Posted 16 December 2018 - 07:22 PM

@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
cat --hex (fd0,0)16450560+1
cat --hex (fd0,0)16450561+1
:cheers:

Misty

#67 tinybit

tinybit

    Gold Member

  • Developer
  • 1117 posts
  •  
    China

Posted 17 December 2018 - 01:54 AM

 

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

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

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

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

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

.....................................

 

at some point, you will encounter "disk read error". Suppose starting at (fd0,0)10000+1 it failed, then you will know that the Maximum sector number is in the range from 1000 to 9999. You may continue to test and find the exact value of the maximum sector number.

 

Note: You may successfully access all data on the whole drive under Windows or other protected-mode OSes. But most BIOSes have their limit. The limit value will vary with the manufacturer.

 

 

I am awfully sorry. I made a mistake. Instead of (fd0,0), It should be (fd0).

 

The error info in the last picture is "outside partition" (logical soft error), not "disk read error" (real hard error).

 

BTW, you needn't take photos. Only the last encountered error info is needed.

 

Please use (fd0) to take the place of (fd0,0), and re-try the test. Note that the last error info should say "Error 25: disk read error" or another info that shows it could not get the sector data.

 

------------------------------------------

 

The idea is to find a number M such that

 

cat --hex (fd0)M+1

 

succeeded, but

 

cat --hex (fd0)N+1   <-------here N stands for the next sector number that follows M, ie., N = M+1.

 

failed.

 

 

Take an example, if

 

cat --hex (fd0)12345678+1

 

succeeds, whereas

 

cat --hex (fd0)12345679+1

 

encounters "disk read error", then the maximum sector number is 12345678, which denotes, the maximum accessibility of the USB-storage BIOS on this machine.



#68 tinybit

tinybit

    Gold Member

  • Developer
  • 1117 posts
  •  
    China

Posted 17 December 2018 - 03:30 AM

@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
cat --hex (fd0,0)16450560+1
cat --hex (fd0,0)16450561+1
:cheers:

Misty

 

devdevadev 's pictures show that (fd0,0)10000000+1 is successful. It means, at least 10000000 sectors are supported.

 

10000000 sectors = 5 GB.

 

If BIOS does not support EBIOS/LBA, then the geometry command can report it.

 

If that is the case, the "geometry (fd0)" command should say "CHS", not "LBA".

 

If BIOS has no LBA support, then it cannot access across the 8.4G limit.

 

Also its wrong using (fd0,0). It should be (fd0). I am so sorry for that post of mine.



#69 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 December 2018 - 01:20 PM

I am so sorry for that post of mine.

Don't worry :) , it can happen to anyone.

And it wouldn't really cause any "big" issue, since the (fd0,0) partition should start on LBA 2048.

 

@Misty

You are putting in my (educated) guess too much confidence, those ranges are too narrow, as well as the suggestion by tinybit (set aside the mistake between (fd0) and (fd0,0) ) was "wrong" in the sense of being composed of "fixed" steps, the x10 between 1 and 10 is 9 sectors (too few) the x10 between 10,000,000 and 100,000,000 sectors is 90,000,000 sectors (too many).

 

devdevadev (that insists on senselessly posting the second screen of the result :frusty: )  hit the outside of the partition at 100,000,000 sectors, i.e. roughly 48 GiB, which is normal, since the partition is 29 GB in size, but when he used the USB  stack/driver in 0.4.6a he found the actual blocklist start address of the file (relative to (fd0,0):

27293088, and since that address could not be reached before, that is clearly already beyond reach (and thus it makes no sense to probe for higher than 27,293,088 values).

 

The "right" way to find an unknown limit (setting aside my guess) is to use a "converging" algorithm.

 

We know that limit "x" is:

0<x<27293088

 

We can take for simplicity a slightly higher "rounded" value, 28,000,000

and have:

0<x<28,000,000

 

then you try for the first term + half the difference:

0+(28,000,000-0)/2=14,000,000

so you test:

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

which equates to:

0<x<14,000,000

 

IF you have the error, than you half again:

0+(14,000,000-0)/2=7,000,000

and check that:

0<x<7,000,000

 

IF you don't have the error you are now in:

14,000,000 < x < 28,000,000

now you half again the difference and sum it to the lower limit:

14,000,000+(28,000,000-14,000,000)/2=21,000,000

and check that:

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

 

and so on...

 

:duff:

Wonko



#70 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 18 December 2018 - 02:51 PM

@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
cat --hex (fd0,0)16450560+1
cat --hex (fd0,0)16450561+1

 

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 fail
cat --hex (fd0)16450561+1 

Attached File  4.jpeg   98.92KB   0 downloads

usb --init

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

Attached File  5.jpeg   130.3KB   0 downloads

If I execute usb --init at beginning then no error found ? why ?



#71 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 18 December 2018 - 07:28 PM

so you test:

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

which equates to:

0<x<14,000,000

 

IF you have the error, than you half again:

0+(14,000,000-0)/2=7,000,000

and check that:

0<x<7,000,000

 

IF you don't have the error you are now in:

14,000,000 < x < 28,000,000

now you half again the difference and sum it to the lower limit:

14,000,000+(28,000,000-14,000,000)/2=21,000,000

and check that:

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

 

and so on...

cat --hex (fd0,0)14000000+1 ok
cat --hex (fd0,0)21000000+1 fail

Attached File  6.jpeg   155.1KB   0 downloads

 

usb --init

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

Attached File  7.jpeg   144.11KB   0 downloads

If I use usb --init at beginning then no error found ?

 

Please use (fd0) to take the place of (fd0,0), and re-try the test. Note that the last error info should say "Error 25: disk read error" or another info that shows it could not get the sector data.

Please also check previous updated post #64 and #65



#72 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 18 December 2018 - 09:08 PM

Oww, my.

 

grub4dos 0.4.6 has added a proprietary USB "stack" that is in part a "BIOS extension".

 

When you use 0.4.5 or 0.4.6a WITHOUT running usb --init you are booting with the capabilities of your BIOS.

When you use 0.4.6a running usb --init you are booting with the capabilities of the USB stack provided by grub4dos (which is evidently "better", or at least "more far reaching" than your BIOS).

 

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.

 

:duff:

Wonko



#73 tinybit

tinybit

    Gold Member

  • Developer
  • 1117 posts
  •  
    China

Posted 19 December 2018 - 02:32 AM

devdevadev, on 17 Dec 2018 - 02:54 AM, said:

usb --init
cat --hex (fd0)100000000+1
cat --hex (fd0)10000000000000000000+1
If I execute usb --init at beginning then no error found at all ? why ?

attachicon.gif2.jpegattachicon.gif3.jpeg

cat --hex (fd0)100000000+1 with success: your USB has 50GB total size? If yes, that would be normal. If you only have 13GB, that would be terrible (for a 13GB drive, trying to read 50GB should give "disk read error").

cat --hex (fd0)10000000000000000000+1 with failure: you specified a number that is too large, and it is treated as invalid. Try these:

cat --hex (fd0)1000000000000000000+1
cat --hex (fd0)100000000000000000+1
cat --hex (fd0)10000000000000000+1
cat --hex (fd0)1000000000000000+1
cat --hex (fd0)100000000000000+1
cat --hex (fd0)10000000000000+1
cat --hex (fd0)1000000000000+1
cat --hex (fd0)100000000000+1

and see what happens.

EDIT:

To avoid dumping the whole sector, you may dump only the beginning 16 bytes of the sector:

cat --hex (fd0)1000000000000000000+1,16
cat --hex (fd0)100000000000000000+1,16
cat --hex (fd0)10000000000000000+1,16
cat --hex (fd0)1000000000000000+1,16
cat --hex (fd0)100000000000000+1,16
cat --hex (fd0)10000000000000+1,16
cat --hex (fd0)1000000000000+1,16
cat --hex (fd0)100000000000+1,16

Edited by tinybit, 19 December 2018 - 03:04 AM.


#74 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 19 December 2018 - 02:58 AM

cat --hex (fd0)1000000000000000000+1

cat --hex (fd0)100000000000000000+1

cat --hex (fd0)10000000000000000+1

cat --hex (fd0)1000000000000000+1

cat --hex (fd0)100000000000000+1

cat --hex (fd0)10000000000000+1

cat --hex (fd0)1000000000000+1

cat --hex (fd0)100000000000+1

 

and see what happens.

http://reboot.pro/to...e-3#entry208688

 

 

UPDATE:

EDIT:
To avoid dumping the whole sector, you may dump only the beginning 16 bytes of the sector:
cat --hex (fd0)1000000000000000000+1,16
cat --hex (fd0)100000000000000000+1,16
cat --hex (fd0)10000000000000000+1,16
cat --hex (fd0)1000000000000000+1,16
cat --hex (fd0)100000000000000+1,16
cat --hex (fd0)10000000000000+1,16
cat --hex (fd0)1000000000000+1,16
cat --hex (fd0)100000000000+1,16

Attached File  1.jpeg   110.96KB   0 downloadsAttached File  2.jpeg   126.31KB   0 downloadsAttached File  3.jpeg   111.09KB   0 downloads


#75 tinybit

tinybit

    Gold Member

  • Developer
  • 1117 posts
  •  
    China

Posted 19 December 2018 - 03:26 AM

usb --init 
cat --hex (fd0)0+1  ok  
cat --hex (fd0)10+1  ok
cat --hex (fd0)100+1  ok
cat --hex (fd0)1000+1  ok
cat --hex (fd0)10000+1  ok
cat --hex (fd0)100000+1  ok
cat --hex (fd0)1000000+1  ok
cat --hex (fd0)10000000+1  ok
cat --hex (fd0)100000000+1  ok
.........................    ok 

cat --hex (fd0)1000000000000000000+1  ok
cat --hex (fd0)10000000000000000000+1 fail 

 

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.







Also tagged with one or more of these keywords: gpt, mbr, bios, uefi, bootmgr, grub4dos, wtg

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users