Jump to content











Photo
* * * * * 1 votes

Grub4dos and GPT support


  • Please log in to reply
57 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 21 December 2018 - 09:20 AM

 

misty, on 15 Dec 2018 - 12:01 PM, said:
@devdevadev
Your disk appears to have a 4K sector size.


No, it DOES NOT.

 

@devdevadev

 

Misty posted an incorrect piece of info, making a wrong interpretation of the fsutil data you provided.

This has been corrected in the following posts.

You simply cannot ignore those and re-connect to an earlier, wrong but later corrected piece of info.

 

Again, WHAT (the heck) command have you run that results as:

 

 

 

Still getting same error in 4TB GPT USB-HDD ?

attachicon.gif4096.jpeg

 

 

Still getting same error doing WHAT and instead of the previous WHAT?  :frusty:

 

:duff:

Wonko



#27 tte

tte
  • Members
  • 9 posts
  •  
    Russian Federation

Posted 22 June 2019 - 03:59 PM

Hello

Tell me how to be in a different situation with GPT:

 

I'm not trying to boot from a GPT disk.

On a GPT disk (not bootable, just a non system disk with misc files - disk large and could only be formatted in GPT) there is an VHD image. I want to boot from this VHD image.

 

How can I specify the path to this vhd image?
In the title post of this thread, a method is proposed - it does not work for me. error 11 or 17 - unable to mount partition, unkown string from partition - or no such partition.

I tried all partitions of all my disks. non GPT mount, other not mount.

 

There is a particularity - on the my GPT disk, the partition with vhd is the second, ntfs, and the first = raw

(I address partition as 0 and 1)



#28 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 June 2019 - 05:27 PM

Which EXACT version of grub4dos are you using?

Maybe you are using an old version.

 

In case of doubt, get from Chenall's site the 0.4.6a 23-12-2018:

http://grub4dos.chen....6a-2018-12-23/

and try again with it.

 

Then, you need to post the EXACT commands you give AND the EXACT errors/warnings (if any) you get.

 

:duff:

Wonko



#29 tte

tte
  • Members
  • 9 posts
  •  
    Russian Federation

Posted 22 June 2019 - 06:51 PM

version

2019-06-17

grub4dos-0.4.6a-2019-06-17.7z

(and your version also tried)

http://grub4dos.chen...ries/downloads/

 

Im boot from flash - usb, not uefi

in menu grub4dos im press c and write

root ( <TAB>-button

or rootnoverify ( <TAB>-button

 

answer = "Possible disk are: hd0 hd1 hd2 hd3 rd"

write = rootnoverify (hd0,0) Enter ( =its flashdisk)

answer=

write = kernel / <TAB>

answer =files from partition

 

for hd1 = same, ssd with 2 partition, work ok

 

hd2, hd3 = GPT

write = rootnoverify (hd2,0) Enter

answer = Error 17 Cannot mount selected partition (=for each partition)

if № partition more than the number of partitions on the disk, then

answer = Error no such partition



#30 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 23 June 2019 - 11:04 AM

@tte

Have a test with these commands:

geometry (hd2)

geometry (hd3)

vol

cat --hex (hd2)+1

cat --hex (hd3)+1

setmenu

beep

Use the following 2 commands just to see if the disk sectors could be read OK (to confirm it could get that far):

cat --hex (hd2)200000000+1

cat --hex (hd3)200000000+1



#31 tte

tte
  • Members
  • 9 posts
  •  
    Russian Federation

Posted 23 June 2019 - 12:17 PM

geometry (hd2)

drive 0x82(LBA): C/H/S=26**/**/**, Sector Count/Size=42***/512  <= 4 terabyte

Partition num: 1, Filesystem type unkown, partition type 0xEE <= this is fine, RAW partition, but exist partition num 2, grub4dos not seen it

geometry (hd3)

same

cat --hex (hd2)+1

= 00 00 00 0* on in full screen

I'm afraid to damage my RAW partition, there are files there! The sector read command works, but the program does not see the second partition. This is the problem.

cat --hex (hd2)200000000+1

= 0d 0E G0 0* on in full screen, read ok

 

vol

Nothing happened, does not respond to buttons, only Ctrl Alt Del

 

setmenu
beep

did not do. I do not need a menu on that disk (and beep is also not needed :))
I'm afraid to damage the files. These GPT disks must be read-only for grub4dos, it should not try to write anything there.



#32 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 June 2019 - 12:36 PM

Can you check if the disk has a physical size of 4096 bytes sector?

I.e. it is a "native 4k"?

 

Is it an internal disk or an external (USB) one?

 

How (exactly) was the disk partitioned/formatted? (under which OS and using which tool)

 

There have been in the past issues with 4K disks or with enclosures that exposed 4K geometry.

 

Don't worry, cat is a read only command, no risk of damaging anything.

 

If you are running normally Windows (or Linux) have a look at the disk with gdisk (be careful, gdisk has write/change capabilities):

http://www.rodsbooks.com/gdisk/

 

 

The grub4dos sees "only" the 0xEE type partition (which is the "MBR protective one").

 

You should be able to see it as well running:

cat --hex --skip=446 --length=16 (hd2)0+1

 

Using your tool of choice, you could:

1) backup the first 32 sectors of the disk (using dsfo under windows or dd in Linux)

2) compress the resulting file in a .zip or .7z archive

3) upload the file to *any* free file hosting site

4) post a link to the uploaded file, so that we can have a look at the MBR and the GPT partition table

 

It is possible that (for *some reasons*) the GPT partition table is not sequential (or has the first slot empty or *whatever*) and then grub4dos cannot parse it.

 

:duff:

Wonko



#33 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 23 June 2019 - 01:03 PM

Another test. Try to display data on the second sector:

 

cat   --hex   (hd2)1+1

 

Please confirm it should have normal GPT structure.

 

If it was 4K sector in size, then the above command would show the sector starting at disk byte offset  0x1000 which could not have the GPT structure.

 

Your (hd0) is USB flash. (hd1) is the first internal drive. I suppose your BIOS on (hd2) and (hd3) is broken.

 

It is rather common that a BIOS only supports the first internal hard drive( all the rest are broken).

 

That means, even if you re-partition it with MBR, you still could not access it with the broken BIOS.

 

You may try to adjust the internal drive order in the BIOS/CMOS setup and let (hd2) be the first internal drive, and see if the BIOS works for it.



#34 tte

tte
  • Members
  • 9 posts
  •  
    Russian Federation

Posted 23 June 2019 - 01:16 PM

Yes, sector in second partition is 4096

Is it an internal disk.

1 partition Raw, second partition format in windows (7 or 8)

 

>backup the first 32 sectors of the disk

https://dropmefiles.com/SRLSj

 

tinybit

>Try to display data on the second sector

see file, there are 32 sectors of 4 kilobytes

 

As I see, program will not work yet.
but you please fix it,
the situation is simple - grub4dos should just read from the partition.



#35 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 23 June 2019 - 02:00 PM

See my previous post. 4K sector BIOS is not compatible with tons of legacy software. I treat it as broken.

 

Your may have a try to adjust the (hd2) to be the first internal and see if the BIOS would get fine.

 

Also note that, I am not a team member for now. I use ARM linux, and would nerver develop grub4dos any more.

 

You may ask chenall / yaya to do the job.



#36 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 June 2019 - 03:53 PM

From the file you posted the disk is not "native 4K", the GPT partition table is at offset 0x400 or 1024.

 

Thus the actual disk is definitely a 512e, but it is still entirely possible that it is "sensed" and accessed by the BIOS (or by an OS through a driver) as 4K.

 

I see traces of 4 (four) partitions in the GPT partition table, 1 MSR and 3 Basic Data partitions.

First partition LBA start 34 last  262177 <- this is 262144 sectors and should be 134217728 bytes in size

Second Partition LBA start 264192 last 4295231487  <- this is 4294967296 sectors and should be 2199023255552 bytes in size

Third partition LBA start 4295231488 last 5717170175  <- this is 1421938688 sectors and should be 728032608256 bytes in size

Fourth partition LBA start 5717170176 last 5860530175 <- this is 143360000 sectors and should be 73400320000 bytes in size

 

Summing it up, 3000590418944 seem allocated, it is probably a 3TB disk.

 

The size for the second partition is exactly 2^32 (2^32=4294967296) and thus it may be just beyond some limit (either in grub4dos or BIOS or both) of 32 bit math (the max number you can express in 32 bit is 2^32-1=4294967295).

 

You should try slightly resizing (shrink) that partition to be within the limit.

 

Provided that:

1) the .vhd image is of fixed type

2) the .vhd image file is contiguous

3) you won't ever "move" that file (or defragment that partition, etc.)

 

You might be able to determine the exact sector position of the image from Windows and then map that range (extents) directly with grub4dos.

It might be worth the effort for the experiment, but it is not IMHO a "safe" approach in the long term.

 

Anyway, see here:

http://reboot.pro/topic/18570-extents/

the nice little tool by erwan.l should be now compatible with GPT.

 

:duff:

Wonko



#37 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 23 June 2019 - 10:18 PM

@tte

 

>>> see file, there are 32 sectors of 4 kilobytes

 

I think your file was generated under Windows. That is a good work. But what I need is the output of

 

cat  --hex  (hd2)1+1

 

and use that output to determin / judge if the sector size is 4K under BIOS. You may take a picture of the output, or just show me the beginning 16 bytes.

 

If the output is like "EFI PART .....", then the BIOS sector size is 512 bytes and this is correct. Then I will report to yaya that grub4dos has a bug on this machine.

 

If the output is like "00 00 00 00......" (all zeroes), then the BIOS sector size is 4096 bytes, and IMO, the BIOS is broken and no further work should be done on the grub4dos side.

 

Also, last time, you used the "vol" command and it simply hanged up. Now you should (emmmm.......meaning "must") continue to run the "setmenu" and "beep" commands (these commands will not damage your disk data), just to confirm you are using the latest grub4dos, and not the case in some way that you might have mistakenly used a very old version of grub4dos.



#38 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 23 June 2019 - 10:51 PM


You might be able to determine the exact sector position of the image from Windows and then map that range (extents) directly with grub4dos.


:duff:

Wonko

 

 

If the BIOS sector size is 512 bytes, the "map" will work fine.

 

If the BIOS sector size is 4096 bytes, the "map" will not function as expected.

 

So first and foremost, we should figure out the BIOS sector size.



#39 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 24 June 2019 - 08:07 AM

see file, there are 32 sectors of 4 kilobytes

Well, no.

The file is 131072 bytes in size, and it contains data leading to believe that when on disk it is 256 sectors of 512 bytes, or at least, when it was partitioned, it was seen as being 512 bytes/sector..

 

@tinybit

The disk sector size is 512 and NOT 4096. (and yes, "EFI PART" is at offset 0x200)

 

 

From the file you posted the disk is not "native 4K", the GPT partition table is at offset 0x400 or 1024.

 

Besides that, if the sectors were 4096 bytes, given the GPT partition table values the whole disk would have been (roughly) 24 TB.

 

Let us stop going astray with the false 4096 bytes sector size, this is NOT the case.

 

:duff:

Wonko



#40 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 24 June 2019 - 10:19 AM

The disk sector size is 512 and NOT 4096. (and yes, "EFI PART" is at offset 0x200)

No. Data itself is just data. It has nothing to do with BIOS sector size. A buggy BIOS could do anything that is buggy.

Only a BIOS read could confirm the BIOS sector size.

So let's wait and see tte's result on (hd2)1+1.

In addition to the above test on sector size, one more test is required for reporting bugs to the developers. The required test is: trying to get the maximum sector number that BIOS can deal with. That is, find the maximum N such that

cat --hex (hd2)N+1

succeeds (that is, without failure).

In other words, find such an N that

cat --hex (hd2)N+1

succeeded, but

cat --hex (hd2)M+1, where M equals (N+1)

failed.

#41 tte

tte
  • Members
  • 9 posts
  •  
    Russian Federation

Posted 24 June 2019 - 02:49 PM

@ tinybit

 

Yes. EFI PART

18dc3feafd433fb0742612429c5e580e.jpg

I see in log windows checkdisk for partition on hd2, where my vhd file, log say sector 4k<
i use new version grub4dos. i know right, because old version frize, but new only on vol :)
Thank you for your participation!


Edited by tte, 24 June 2019 - 03:05 PM.


#42 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 24 June 2019 - 02:51 PM

Sure data in itself is just data :), but there is no way on earth that through BIOS, drivers and what not (short of sheer magic) a partitioning tool can write the GPT partition table to a fractional address on a 4K native disk.

So. at the time that disk was partitioned, it was seen as 512 or 512e.

 

It is of course possible the opposite, i.e. expose (via BIOS, driver, USB bridge or *whatever*) a 512 bytes sectored disk as 4K.

 

The only possible way for that disk to contain those leading 131072 bytes would be if it was dded from a 512 or 512e source.

 

:duff:

Wonko



#43 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 24 June 2019 - 02:54 PM

@tte

chkdisk is telling you cluster size, not sector size.

 

Re-read, attentively post #21 on this very thread:

http://reboot.pro/to...pport/?p=208666

 

You need to use fsutil to see that.

 

Your disk is NOT 4K native.

 

:duff:

Wonko



#44 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 24 June 2019 - 08:58 PM

@ tinybit

 

Yes. EFI PART

18dc3feafd433fb0742612429c5e580e.jpg

I see in log windows checkdisk for partition on hd2, where my vhd file, log say sector 4k<
i use new version grub4dos. i know right, because old version frize, but new only on vol :)
Thank you for your participation!

 

Sorry, your link to picture is dead link?

 

https://fastpic.ru/

 

It is just a site link, not a file link.

 

I would expect to see 2 things: one is the "sector size" and the other is "maximum BIOS accessibility".

 

EDIT:  actually your picture is at

https://i106.fastpic...2429c5e580e.jpg

 

It tells "EFI PART", so the BIOS sector size is 512 bytes, surely. Now to help developers addressing the bug, you'd better complete the other test, showing "maximum BIOS accessibility" on (hd2).



#45 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 24 June 2019 - 09:50 PM

@tte

>>> because old version frize, but new only on vol

 

To confirm that you are using the new version, you may take a picture on the grub4dos screen. On the top line of the screen, there is grub4dos version and build date. You may simply tell if the date matches your downloaded version that is in use.



#46 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 25 June 2019 - 05:03 AM

On grub4dos Chinese board, yaya posted this (translated):

 


 

At grub4dos command line prompt:

 

debug=3

 

and then:

 

vol

 



#47 tte

tte
  • Members
  • 9 posts
  •  
    Russian Federation

Posted 25 June 2019 - 02:37 PM

@ tinybit

 

1 pic = my version Grub4dos

 

>showing "maximum BIOS accessibility" on (hd2).

is the vol command used for this? If not, specify which command to use.

 

Further pic: - output for

debug=3 

and then:

vol

I use direct links:

https://i106.fastpic...a0e36ebb961.jpg
https://i106.fastpic...8efcbb39b4b.jpg
https://i106.fastpic...9cf1ccbbf16.jpg
https://i106.fastpic...e833580156a.jpg
https://i106.fastpic...53dad082ecc.jpg



#48 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 25 June 2019 - 10:43 PM

@tte


showing "maximum BIOS accessibility" on (hd2).

 

......specify which command to use.

 

As already posted previously:

 

find the maximum N such that

cat --hex (hd2)N+1

succeeds (that is, without failure).

In other words, find such an N that

cat --hex (hd2)N+1

succeeded, but

cat --hex (hd2)M+1, where M equals (N+1)

failed.

 

 

 

In case the above procedure is hard to understand, try this:

 

cat --hex (hd2)2000000000+1

cat --hex (hd2)20000000000+1

cat --hex (hd2)200000000000+1

 

if encountered failure, use a small sector number and continue to test. Suppose

 

cat --hex (hd2)20000000000+1

 

failed, then you continue with

 

cat --hex (hd2)10000000000+1

 

if it gains success, then continue to test this:

 

cat --hex (hd2)15000000000+1

 

else, continue to test this

 

cat --hex (hd2)5000000000+1

 

repeat this process, and finally you will gain a maximum sector number that can be accessed.



#49 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 25 June 2019 - 11:17 PM

And bugs (of vol and uuid commands) are found with grub4dos 0.4.6a.

 

You may try and see if grub4dos 0.4.5c could work:

 

http://grub4dos.chen...4-5c/#year_2016



#50 tte

tte
  • Members
  • 9 posts
  •  
    Russian Federation

Posted 26 June 2019 - 01:00 AM

@ tinybit

 

cat --hex (hd2)7814037167+1 work

 

Found out in the old version that you specified. In the old version, the program still does not see the partition with my vhd.
Moreover, only 2 partitions are seen, the new version sees more.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users