Jump to content











Photo
* * * * * 1 votes

Grub4dos and GPT support


  • Please log in to reply
54 replies to this topic

#1 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 08 December 2018 - 09:18 AM

I have not been keeping track of Grub4dos development. I had mistakenly believed that Grub4dos is not able to access GPT type disks. I was very pleasantly surprised to find that this is not the case.

Set my firmware to boot from legacy (CSM support) and booted Grub4dos from a USB drive.

Using GRUB4DOS 0.4.5c 2016-01-18 and entering the following at the commandline, followed by the [TAB] key...
grub> root (hd1,
...returned the following -
Possible partitions are:
 Partition num: 0, Filesystem type is fat, partition type 0xEE
 Partition num: 2, Filesystem type is ntfs, partition type 0xEE
 Partition num: 3, Filesystem type is ntfs, partition type 0xEE
 Partition num: 4, Filesystem type is ntfs, partition type 0xEE
 Partition num: 5, Filesystem type is ntfs, partition type 0xEE
Partition 1 (grub4dos device (hd1,1)) is a Microsoft Reserved partition (MSR) and is not displayed in the Grub4dos output.

Partitions are numbered sequentially from (hd#,0). As this is a GPT disk, there is no extended partition with logical volumes - consequently there is no jump from (hd#,2) to (hd#,4).

I was able to map a .vhd from (hd1,2) to memory and successfully boot from it using the following commands (please note wonko, that these were entered at the commandline as per your recommendation(s)) -
map --mem (hd1,2)/test.vhd (hd0)
map --hook
root (hd0,0)
chainloader +1
boot
I also noticed in the readme for GRUB4DOS 0.4.6a 2018-09-19 that bootlace.com (and bootlace64.com) now support a --gpt switch ("Install the grldr.mbr to the GPT partition type device."). I'm not in a position to test this at the moment - does anyone know how this works. E.g. where is the grub4dos MBR code written on a GPT disk - it would appear to be too large to fit in the MBR only.

GRUB4DOS 0.4.6a 2018-09-19 also contains grldr.pbr - presumably this is partition boot record code? Any information on usage and why/when this might be used instead of grldr.mbr?

:cheers:

Misty
  • devdevadev likes this

#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 December 2018 - 11:24 AM

Before and besides the new developments (if any), grub4dos access (in BIOS) to GPT disks is a long standing feature, and we already have a couple ways to boot grub4dos (again on BIOS) from GPT disks, including the UMBR and a couple half-@§§ed ways by yours truly.

The thread is here (terribly titled):

http://reboot.pro/to...in-bios-to-gpt/

 

UMBR and other methods:

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

 

In the thread there are already reports of success by cdob with VHD's.

 

 

And here is a recent one about UMBR usage:

http://reboot.pro/to...b-with-bootice/

 

The grldr.pbr is not a "single" partition bootsector (or more properly a single volume bootrecord) it is a collection of bootrecords for various filesystems, there is in it FAT12/16, FAT32, EXT2/3, EXFAT and NTFS, at first sight.

 

No idea on the intended usage (possibly bootlace has also been updated), but you can extract them (and deploy the "right" one to an existing volume - of course keeping the BPB) to make the volume chainload grldr, not entirely unlike (actually exactly like) a grub4dos floppy is bootable.

 

 

:duff:

Wonko


  • misty likes this

#3 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 08 December 2018 - 04:53 PM

@Wonko
Thanks as always for the information. There is a lot to try and take in in the Hack Bootmgr to boot Windows in BIOS to GPT topic!

:cheers:

#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 December 2018 - 08:07 PM

@Wonko
Thanks as always for the information. There is a lot to try and take in in the Hack Bootmgr to boot Windows in BIOS to GPT topic!

:cheers:

Good. :)

 

In the meantime, devdevadev is currently looking for new troubles here:

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

 

After having looked for troubles here:

http://reboot.pro/to...able-usb-drive/

 

and both threads offer some additional info/explanations that you may find of interest

 

:duff:

Wonko



#5 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 08 December 2018 - 08:37 PM

Thanks Wonko - more homework :whip:

No disrespect to devdevadiv but he/she? sure seems to enjoy making life difficult!

So to satisfy my curiosity I used a VM (VMWare Workstation) to test the bootlace.com --gpt command (using bootlace.com from GRUB4DOS 0.4.6a 2018-09-19).

Booted to WinPE (10) and created a GPT disk partition structure.

used DD (for Windows) to copy the first 10 MiB of the GPT disk. This was clearly overkill in regards to the number of sectors copied, but better safe than sorry! File name = mbr_unmodified.bin.

I was not able to run bootlace.com/bootlace64.com from my WinPE. Error message that 16-bit apps are not supported.

Copied bootlace.com to a Windows 98 floppy disk image. Booted from the floppy disk image and ran the command -
bootlace.com --gpt 0x80
Booted from the GPT disk. Grub4dos code had clearly been added to the disk, as it searched for grldr in the available partitions/devices.

Rebooted to WinPE and copied the first 10 MiB of the GPT disk - now modified by bootlace.com. File name = mbr_modified.bin.

Used TinyHexer to compare mbr_modified.bin with mbr_unmodified.bin

The following bytes have been modified -

Sector 0 - bytes 0x00 to 0x66.
Sector 35 to 36 - bytes 0x4600 to 0x486F - majority of bytes modified
Sector 37 to 50 - bytes 0x4A00 to 0x65FF - majority of bytes modified

I have attached the first 100 sectors of mbr_modified.bin and mbr_unmodified.bin if anyone wants to compare the code.

Misty

Attached Files



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 December 2018 - 01:46 PM

Nice. :)

 

What is written starting from sector LBA 35 is grldr.mbr (unmodified, 8192 bytes in length).

 

So basically the first few bytes (102) of the MBR are written with a small code that chainloads the grldr.mbr on sector 35, then grldr.mbr "behaves normally" (i.e. it looks for grldr in available partition/volumes).

 

This is yet another way to BIOS-boot a GPT (or even a MBR) disk.

 

The area occupied is past sector 33 (which is usually the last one that thoretically may be used by the GPT partition table).

Since:

MBR is LBA 0

EFI Partition sector is LBA 1

Partition table starts at LBA 2 and since each entry takes 128 bytes (or 4 partition entries per sector) it normally extends (for the commonly recognized max of 128 partition entries) for 128/4=32 sectors 

 

so it is "safe" both from a EFI/UEFI/GPT and BIOS/MBR standing point, and since it is only 16 sectors in size, it ends well before both either the 63 or 2048 "sectors before" the first partition.

 

:duff:

Wonko



#7 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 December 2018 - 08:58 PM

Comparing the bootcode on your hard disk image, there is the same code embedded in bootlace.com.

 

This is in the image Misty posted:

 

 

FA 66 31 C9 8E D1 BC 00 7C 51 1F FB 80 3E C2 7D
EE 75 25 BF 03 00 60 66 51 66 68 23 00 00 00 68
00 0D 51 6A 10 6A 10 89 E6 B4 42 CD 13 61 61 73
17 31 C0 CD 13 4F 75 DE BE 4F 7C AC 3C 00 74 06
B4 0E CD 10 EB F5 EB FE 68 00 0D 68 56 02 CB 45
72 72 6F 72 20 6C 6F 61 64 69 6E 67 20 67 72 6C
64 72 2E 6D 62 72

 

and this is in bootlace.com (starting at offset 0x0F15):

 

 

 

FA 66 31 C9 8E D1 BC 00 7C 51 1F FB 80 3E C2 7D
EE 75 25 BF 03 00 60 66 51 66 68 22 00 00 00 68
00 0D 51 6A 10 6A 10 89 E6 B4 42 CD 13 61 61 73
17 31 C0 CD 13 4F 75 DE BE 4F 7C AC 3C 00 74 06
B4 0E CD 10 EB F5 EB FE 68 00 0D 68 56 02 CB 45
72 72 6F 72 20 6C 6F 61 64 69 6E 67 20 67 72 6C
64 72 2E 6D 62 72

 

The underlined bytes are clearly an offset in sectors.

0x00000023 = 35

0x00000022 = 34

 

Once set aside the difference (maybe there is some logic in the bootlace.com that "adapts" the offset), it should mean that one can use dsfo/dsfi or similar to write the code to the MBR and the grldr.mbr to disk, without using bootlace.com (and without needing workarounds in VM's with Win 98 floppies).

 

:duff:

Wonko


  • misty likes this

#8 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 11 December 2018 - 09:31 PM

Once set aside the difference (maybe there is some logic in the bootlace.com that "adapts" the offset), it should mean that one can use dsfo/dsfi or similar to write the code to the MBR and the grldr.mbr to disk, without using bootlace.com (and without needing workarounds in VM's with Win 98 floppies).

BOOTLACE.COM cannot function well under Windows NT/2000/XP/2003. It is expected
(and designed) to run under DOS/Win9x and Linux. Update: For image FILES,
bootlace.com function well under Windows NT/2000/XP/2003. For devices,
bootlace.com will not work under Windows NT/2000/XP/2003 because bootlace.com
is a DOS utility and Windows NT/2000/XP/2003 does not allow bootlace.com to
access devices.

Will be nice if we can Install GRLDR boot code to a harddisk image under DOS ¡¢Windows or Linux:

bootlace.com --gpt hd.img

and then wrote those GRLDR boot code sectors from hd.img to the MBR sector of GPT disk) using dd.exe, bootsector.exedsfo/dsfi ?



#9 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 11 December 2018 - 10:42 PM

Comparing the bootcode on your hard disk image, there is the same code embedded in bootlace.com.
 
This is in the image Misty posted:
 
and this is in bootlace.com (starting at offset 0x0F15):
 
 
The underlined bytes are clearly an offset in sectors.
0x00000023 = 35
0x00000022 = 34
 
Once set aside the difference (maybe there is some logic in the bootlace.com that "adapts" the offset), it should mean that one can use dsfo/dsfi or similar to write the code to the MBR and the grldr.mbr to disk, without using bootlace.com (and without needing workarounds in VM's with Win 98 floppies).
 
:duff:
Wonko

@Wonko
Interesting findings. Thank you for your investigations and for reporting this.

:cheers:

Misty

#10 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 11 December 2018 - 11:14 PM

Cheers for the tip Wonko.

The following files are from the attachment in post #5
- mbr_unmodified_100sectors.bin
- mbr_modified_100sectors.bin

Saved the byte range 0x00 to 0x65 in mbr_modified_100sectors.bin as file Part1.bin

Used dd for Windows to copy Part1.bin to mbr_unmodified_100sectors.bin -
dd.exe if=Part1.bin of=mbr_unmodified_100sectors.bin
Used dd for Windows to copy grldr.mbr to mbr_unmodified_100sectors.bin - skipping the first 35 sectors of the output file (mbr_unmodified_100sectors.bin) -
dd.exe bs=512 if=grldr.mbr of=mbr_unmodified_100sectors.bin seek=35
Compared the new (and now modified using dd.exe) mbr_unmodified_100sectors.bin with mbr_modified_100sectors.bin - both files are identical.

So to avoid the need for bootlace.com --gpt, it should be possible to use dd.exe. E.g. -
dd.exe bs=512 count=60 if=\\.\PhysicalDrive0 of=gpt.bin
dd.exe if=Part1.bin of=gpt.bin
dd.exe bs=512 if=grldr.mbr of=gpt.bin seek=35
dd.exe if=gpt.bin of=\\.\PhysicalDrive0
Copying the first 60 sectors from \\.\PhysicalDrive0 will ensure that the Partition Table and protective MBR are kept intact.

:cheers:

Misty

@Wonko - it's getting late and I'm tired. It would be very much appreciated if you could double check my findings.

Attached Files


  • devdevadev likes this

#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 December 2018 - 02:10 PM

Yep, everything seems fine, but I would go a little further.

 

Simply write the 102 bytes to the MBR and the grldr.mbr on sector 35 and following

Assuming the GPT disk is \.\\PhysicalDrive1

 

dsfo \\.\Physicaldrive1 0 512 temp.mbr

dsfi temp.mbr 0 0 part1.bin

dsfi \\.\Physicaldrive1 0 512 temp.mbr

dsfi \\.\Physicaldrive1 17920 8192 grldr.mbr

 

AND there is even an (IMHO better if it works) possibility.

The grldr.mbr has a "hole" for the BPB, i.e. it can be used as bootsector also.

It should be possible to write the grldr.mbr as bootsector of the FAT32 "EFI System" partition (of course making sure that there is an adequate number of "reserved sectors" and/or using a custom program to create the FAT32 filesystem (please read as "format" that partition).

This way none of the "hidden sectors" before the first partition would be used.

 

:duff:

Wonko


  • devdevadev likes this

#12 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 12 December 2018 - 06:56 PM

And another alternative. Olof's rawcopy :thumbsup:

rawcopy is a very small executable that has the advantage of being available in 32-bit and 64-bit versions. This may be very useful in WinPE - particularly 64-bit WinPE without SysWoW64 support.

Copy protective mbr from disk 0 as file gpt.bin -
rawcopy -v 512 \\.\PhysicalDrive0 gpt.bin
Write Part1.bin to gpt.bin (created in preceding step) -
rawcopy -v Part1.bin gpt.bin
Write modified gpt.bin back to disk 0 -
rawcopy -v gpt.bin \\.\PhysicalDrive0
Write grldr.mbr to disk 0 from offset 17920 (35sectors x512 bytes = 17920) -
rawcopy -v -o:17920 grldr.mbr \\.\PhysicalDrive0
:cheers:

Misty
  • devdevadev likes this

#13 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 14 December 2018 - 02:44 AM

And another alternative. Olof's rawcopy :thumbsup:

rawcopy -v 512 \\.\PhysicalDrive0 gpt.bin
rawcopy -v Part1.bin gpt.bin
rawcopy -v gpt.bin \\.\PhysicalDrive0
rawcopy -v -o:17920 grldr.mbr \\.\PhysicalDrive0

First I have tried this approach on my 32 GB GPT USB Drive and it worked fine as expected. But when I tried this in 4TB GPT USB-HDD and boot in MBR  only Sony VAIO VPCEB3TFX then got following error message ??  

4.jpg

 

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

Also seen strange results in this approach but at least Grub4dos loaded here.... 



#14 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 14 December 2018 - 06:35 AM

@devdevadev
Just out of curiosity, what is the sector size of the 4TB GPT USB-HDD you have been testing?

#15 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 14 December 2018 - 01:45 PM

@devdevadev
Just our of curiosity, what is the sector size of the 4TB GPT USB-HDD you have been testing?

http://reboot.pro/to...-15#entry208337



#16 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 15 December 2018 - 11:01 AM

@devdevadev
Your disk appears to have a 4K sector size. I do not have access to any hardware with 4K sectors, but have managed to do a bit of testing with a virtual disk with 4K sectors. I utilised Olof's excellent Arsenal Image Mounter (Low Level) - see here. Great work Olof :thumbsup:

Having created a GPT disk structure using DiskPart, I extracted 60x4K sectors using DD (for Windows) > copied to Windows 98 floppy disk image > booted in QEMU > ran bootlace --gpt 4K.bin. bootlace failed to recognise the file as having a GPT disk structure. Note that the exact same process worked fine when the source was a 512 byte sector disk image. I am guessing here that bootlace.com may not be compatible with 4K sector size.

Please note that I have not actually tested the following due to time constraints and hardware limitations.

You appear to have used the code I posted previously -
rawcopy -v 512 \\.\PhysicalDrive0 gpt.bin
rawcopy -v Part1.bin gpt.bin
rawcopy -v gpt.bin \\.\PhysicalDrive0
rawcopy -v -o:17920 grldr.mbr \\.\PhysicalDrive0
Looking at the last line...
rawcopy -v -o:17920 grldr.mbr \\.\PhysicalDrive0
...this is for hardware with a 512 byte sector size (35(sectors) x 512(bytes)=17920).

Try adjusting and using the following on your 4K sector size disk (35(sectors) x 4096(bytes)=143360) -
rawcopy -v -o:143360 grldr.mbr \\.\PhysicalDrive0
:cheers:

Misty

EDIT
You may also need to edit the first rawcopy command to -
rawcopy -v 4096 \\.\PhysicalDrive0 gpt.bin

  • devdevadev likes this

#17 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 December 2018 - 12:04 PM

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


No, it DOES NOT.
 
 
 

Quote
LogicalBytesPerSector : 512
PhysicalBytesPerSectorForAtomicity : 4096
PhysicalBytesPerSectorForPerformance : 4096
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 4096

 
The thingy boots just fine with my "underfloppy" method that - rest assured - won't work with a 4 KB sectored disk:
http://reboot.pro/to...drive/?p=208545
 
the (stupid) SONY BIOS behaves different in the mapping of devices, but grub4dos boots just fine, once (again likely fault of the SONY BIOS) the protective MBR entry has been set to active (or maybe that wasn't necessary, you never know with this partial, spread a bit here, a bit over there reports):
http://reboot.pro/to...e-from-windows/

 

As a matter of fact NO (or maybe only a very selected, few ones) BIOSes can boot at all a "Native" 4KB sectored disk (and anyway most of the MBR code would need to be modified.

 

:duff:

Wonko



#18 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 15 December 2018 - 03:26 PM

Hi Wonko
I'm not going to pretend to know much about disks with 4K sector size and as I started earlier, I do not have any hardware to test.

Based on devdevadev's hardware report and a quick google search, I had made an assumption that his disk is an Advanced Format 512e (emulated) type disk. This is based on -
  • 512 - logical sector size
  • 4096 - physical sector size
If my assumption is correct, then who knows how grub4dos gpt/mbr code handles this type of disk. I certainly do not, and am not in a position to test.

Maybe if devdevadev is willing to take the risk, he can try following my suggestion and hope for the best - after taking reasonable precautions in regards to backing up the relevant sectors.

Misty

#19 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 December 2018 - 03:52 PM

If my assumption is correct, then who knows how grub4dos gpt/mbr code handles this type of disk. I certainly do not, and am not in a position to test.


Maybe if devdevadev is willing to take the risk, he can try following my suggestion and hope for the best - after taking reasonable precautions in regards to backing up the relevant sectors.
 

Well, your assumption is correct, BUT I know, and I am telling you that.

 

The logical size is what is exposed by the interface, and it is 512 bytes, exactly because it is 512e (internally - and internally only - it is 4 Kb, externally, i.e. at OS level, it is 512 bytes).

 

Since the way my "half@§§ed" under-floppy approach can work ONLY IF the OS sees the disk as 512 bytes sectors and specifically works in this specific case, the issue is not related to the (I repeat internal only) sector size. 

 

:duff:

Wonko



#20 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 15 December 2018 - 05:03 PM

Well, your assumption is correct, BUT I know, and I am telling you that.
 
The logical size is what is exposed by the interface, and it is 512 bytes, exactly because it is 512e (internally - and internally only - it is 4 Kb, externally, i.e. at OS level, it is 512 bytes).
 
Since the way my "half@§§ed" under-floppy approach can work ONLY IF the OS sees the disk as 512 bytes sectors and specifically works in this specific case, the issue is not related to the (I repeat internal only) sector size. 
 
:duff:
Wonko

Looks like I've managed to learn some new things today, that are likely to be useful in the future. :cheers:

Thanks Wonko
  • devdevadev likes this

#21 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 15 December 2018 - 05:15 PM

Output from running fsutil fsinfo sectorinfo d: on my latest system - a Thinkpad W530 with a Crucial BX300 SSD (D: is a volume on the BX300 SSD) -
LogicalBytesPerSector :                                 512
PhysicalBytesPerSectorForAtomicity :                    4096
PhysicalBytesPerSectorForPerformance :                  4096
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 4096
Device Alignment :                                      Aligned (0x000)
Partition alignment on device :                         Aligned (0x000)
No Seek Penalty
Trim Supported
Looks like my own system has a 512e type disk after all! Hahahahahahaha!!!!!

Misty

P.s. Looks like aim_ll.exe using the -S 4096 parameter creates a native 4K disk -
LogicalBytesPerSector :                                 4096
PhysicalBytesPerSectorForAtomicity :                    4096
PhysicalBytesPerSectorForPerformance :                  4096
FileSystemEffectivePhysicalBytesPerSectorForAtomicity : 4096
Device Alignment :                                      Aligned (0x000)
Partition alignment on device :                         Aligned (0x000)
Performs Normal Seeks
Trim Supported

  • devdevadev likes this

#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 December 2018 - 05:25 PM

 

Looks like my own system has a 512e type disk after all! Hahahahahahaha!!!!!

 

Yep :).

 

 

 

 

P.s. Looks like aim_ll.exe using the -S 4096 parameter creates a native 4K disk -

 

and sure :).

 

A disk sector (as seen by the OS) is in practice EITHER 512 bytes OR 4 Kbytes (all the other babbling is mostly senseless fluff and theories and UEFI world domination and stuff) , similarly a virtual disk is either 512 or 4Kb sectored.

 

And SSD's are all 512e at least for the moment.

 

Maybe (and I do mean maybe ) some largish hard disks, intended for storage only, are Native 4K.

 

The whole point being that no BIOS seemingly can boot off a 4K Native, only UEFI (and I believe only some OS among the UEFI compatible ones) may.

 

:duff:

Wonko



#23 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 15 December 2018 - 05:56 PM

:offtopic:



...similarly a virtual disk is either 512 or 4Kb sectored...

In the case of Arsenal Image Mounter, the virtual disk is whatever it's set to. I used the following command initially, assuming that the K suffix would be interpreted as KiB (the K (and b, k, m, g, t, M, G or T) suffix is supported with the lowercase -s parameter used to set the size of the virtual disk) -
aim_ll.exe -a -s 5G -f d:\aim_gpt.ima -S 4K
The disk was created and mounted successfully, however DiskPart failed to partiton the disk and Windows crashed!!!!!

On further investigation I realised that the K suffix was being ignored and I appeared to have accidentally created a disk with 4 byte sectors!!!!!!!!!

The following command was successful -
aim_ll.exe -a -s 5G -f d:\aim_gpt.ima -S 4096


#24 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 December 2018 - 11:21 AM

Yep, it is not entirely unlike the MS original VSS driver (which is what I normally use to make "queer" 4K tests), JFYI:

http://reboot.pro/to...storage-driver/

 

If you have time, have a look at this old thingy (a hard disk formatting that is accessible both when the OS sees it as 512 byte and when it sees it as 4 KB :w00t: by changing a few values):

https://msfn.org/boa...comment=1095185

 

:duff:

Wonko



#25 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 21 December 2018 - 02:46 AM

devdevadev
Your disk appears to have a 4K sector size. I do not have access to any hardware with 4K sectors, but have managed to do a bit of testing with a virtual disk with 4K sectors. I utilised Olof's excellent Arsenal Image Mounter (Low Level) - see here. Great work Olof  :thumbsup:

Having created a GPT disk structure using DiskPart, I extracted 60x4K sectors using DD (for Windows) > copied to Windows 98 floppy disk image > booted in QEMU > ran bootlace --gpt 4K.bin. bootlace failed to recognise the file as having a GPT disk structure. Note that the exact same process worked fine when the source was a 512 byte sector disk image. I am guessing here that bootlace.com may not be compatible with 4K sector size.

Please note that I have not actually tested the following due to time constraints and hardware limitations.

You appear to have used the code I posted previously -

rawcopy -v 512 \\.\PhysicalDrive0 gpt.bin
rawcopy -v Part1.bin gpt.bin
rawcopy -v gpt.bin \\.\PhysicalDrive0
rawcopy -v -o:17920 grldr.mbr \\.\PhysicalDrive0
Looking at the last line...
rawcopy -v -o:17920 grldr.mbr \\.\PhysicalDrive0
...this is for hardware with a 512 byte sector size (35(sectors) x 512(bytes)=17920).

Try adjusting and using the following on your 4K sector size disk (35(sectors) x 4096(bytes)=143360) -
rawcopy -v -o:143360 grldr.mbr \\.\PhysicalDrive0
EDIT
You may also need to edit the first rawcopy command to -
rawcopy -v 4096 \\.\PhysicalDrive0 gpt.bin
@echo on
cd /d "%~dp0"
rawcopy -v 4096 \\.\PhysicalDrive1 gpt.bin
rawcopy -v Part1.bin gpt.bin
rawcopy -v gpt.bin \\.\PhysicalDrive1
rawcopy -v -o:143360 grldr.mbr \\.\PhysicalDrive1
pause

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

4096.jpeg






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users