374 replies to this topic

[Wonko the Sane]

Seemingly none of the other kids want to play with me.

 

I did a few more tests.

 

Windows 7 disk management will "blank" first 440 bytes of the MBR and will make first GPT partition starting on LBA 128 (on the small test image I made), this would likely depend on the known Registry settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VDS\ALIGNMENT

 

Which normally are (for disks below 4Gb in size aka "LessThan4GB") 65536 bytes (please read as "LBA 128 for the first partition") and 1048576 (please read as "LBA 2048 for the first partition") for bigger disks (aka "Between4_8GB", "Between8_32GB", "GreaterThan32GB").

 

In real life, I doubt that anyone will have a GPT disk in size less than 32 Gb, so using the area from sector 63 up to LBA 2047 is "safe" and can be a good way to make - even "temporarily" a GPT disk bootable on BIOS.

 

We could in theory extend the image a little bit, having it begin on sector 34, as the sectors occupied are normally:

LBA 0 <- the MBR 

LBA 1 <- the EFI PART header sector

LBA 2-33 <- the actual GPT partition entries

 

But - since grub4dos in it's latest releases "understands" EFI partitioning (seemingly fine ) - it would be smarter (for a "permanent" BIOS boot GPT disk) to create an actual GPT partition "covering" the range 63-2047, something that can be easily done with GPT gdisk.

This would avoid the need for a grldr with a  "modified" embedded menu.lst.

To make it "standard" we could use the gdisk partition type EF01 (which would allow to distinguish it from a EF02 or "GRUB2 BIOS boot partition" ).

gdisk32 \\.\PhysicaldriveN
x
l
1
m
n
1
63
2047
EF01
p
v
w

and then dd the two images attached to previous post (and later replace the "modified" grldr with a "normal" one).

 

Since we don't normally really *need* the whopping "almost 1 Mb" volume size , we could even reduce this partition to the range 128 to 2047, which would be still large enough to hold (say) a grldr, menu.lst and (say) a BOOTMGR+\boot\BCD.

 

I'll have a look for an alternative to the "hacked" MBLDR:

http://mbldr.sourceforge.net/

that I used, so that we can get rid of the need to press ENTER to boot (though all in all it would come useful if we add to it a message warning that the disk is being booted in BIOS mode and not in EFI/UEFI )

 

Wonko

[Wonko the Sane]

Attached is an extremely simplified (actually really "bare") modified MBLDR, stripped of any and all (already limited) "checks" (besides choices, messages and timers), fitting in 96 bytes.
This should simply chainload the bootsector @LBA63, no questions asked.

 

THIS IS REALLY EXPERIMENTAL, USE AT YOUR OWN RISK.

The offset is a 32 bit address at offset 0x5B and can be changed, in most hex editors you will see >?...< and 3E 3F 00 00 00 3C.

 

BUT there is another (better/safer) solution.

MakebootFAT:

http://advancemame.s...akebootfat.html

has a "special" MBR with a "hole" for behaving as a (FAT) bootsector in case of need.

The "hole" corresponding to the BPB is large enough to hold a full set of four partition entries and all is needed is to "relocate" the BIOS partition table from 0x1BE to 0x00E, which is as simple as changing the:

00007C9C BEBE07 mov si,0x7be

to:

00007C9C BEFE05 mov si,0x5fe

Find it also attached (with already in it a relocated partition table entry for the partition on LBA 63-2047.

 

Wonko

Attached Files

•  GPT_MBLDR_mod.zip   264bytes   828 downloads
•  MkbootFatMOD.zip   521bytes   874 downloads

[Icecube]

Wow, so it's diskpart's fault, not letting me to create NTFS partition smaller than 8 MiB? I see.

 

At least with mkntfs it is possible to create smaller NTFS filesystems.

The smallest size of NTFS filesystem that it allows to create is an NTFS volume of at least 1MiB (>= 2049 512 byte sectors).

 

 

Here are the commands to create a 1.44MiB floppy image formatted with NTFS:

# Create an empty floppy 1.44MB floppy image file.
$ dd if=/dev/zero of=floppy-ntfs.img count=1 bs=1440k


# Associate loop device with our empty floppy image file.
$ sudo losetup /dev/loop5 floppy-ntfs.img 


# Format the floppy image with mkntfs: http://linux.die.net/man/8/mkntfs
$ sudo mkntfs --partition-start 0 \
              --cluster-size 4096 \
              --sector-size 512 \
              --heads 2 \
              --sectors-per-track 18 \
              --mft-zone-multiplier 1 \
              --no-indexing \
              --label NTFSFLOPPY \
              /dev/loop5 \
              2880


# Display some info about our NTFS floppy image.
$ sudo ntfsinfo --mft -v  /dev/loop5
Volume Information 
	Name of device: /dev/loop5
	Device state: 11
	Volume Name: NTFSFLOPPY
	Volume State: 27
	Volume Version: 3.1
	Sector Size: 512
	Cluster Size: 4096
	Index Block Size: 4096
	Volume Size in Clusters: 359
MFT Information 
	MFT Record Size: 1024
	MFT Zone Multiplier: 0
	MFT Data Position: 24
	MFT Zone Start: 0
	MFT Zone End: 48
	MFT Zone Position: 4
	Current Position in First Data Zone: 48
	Current Position in Second Data Zone: 0
	LCN of Data Attribute for FILE_MFT: 4
	FILE_MFTMirr Size: 4
	LCN of Data Attribute for File_MFTMirr: 179
	Size of Attribute Definition Table: 2560
FILE_Bitmap Information 
	FILE_Bitmap MFT Record Number: 6
	State of FILE_Bitmap Inode: 80
	Length of Attribute List: 0
	Attribute List: (null)
	Number of Attached Extent Inodes: 0
FILE_Bitmap Data Attribute Information
	Decompressed Runlist: not done yet
	Base Inode: 6
	Attribute Types: not done yet
	Attribute Name Length: 0
	Attribute State: 3
	Attribute Allocated Size: 4096
	Attribute Data Size: 48
	Attribute Initialized Size: 48
	Attribute Compressed Size: 0
	Compression Block Size: 0
	Compression Block Size Bits: 0
	Compression Block Clusters: 0


# Delete loop device.
$ sudo losetup -d /dev/loop5

The floppy image is attached (just in case it it useful for something).

Attached Files

•  floppy-ntfs.img.7z   85.55KB   952 downloads

[cdob]

Seemingly none of the other kids want to play with me.

If the guru is speaking, kids are listening and don't speak.

Keep on the good work. Thanks.

Just dreaming:
Given a bootmgr PBR:
joakim's bootmgr with included bcd is inside LBA 63-2047.
Files bootmgr and bcd are inside LBA 63-2047.

[Wonko the Sane]

@Icecube

The issue in your reference is not about the filesystem, it is about the "minimum size" of a partition that diskpart and most other partition tools (at least up to XP) will use.

This equates to the 8 Mb Sascha Weaver found if the alignment is done on CHS, as 255x63x512= 8,225,280 bytes.

 

The normal "FORMAT" command under NT systems will allow for smaller filesystems, BUT there are some limits with the "minimum" size of some structures.

 

Using IMDISK (i.e. bypassing the MBR or the concept of "partition" the minimum size of a formatted NTFS volume is 2,304,000 bytes BUT you will have 0 Kb free space in it!

Under XP he smallest "valid" NTFS you can make is on an image 2,585,600 bytes in size, and you will have a whopping 35 Kb available..

 

BUT NTFS formatted floppies have been possible since NT 4.0 times:

http://web.archive.o...com/ntfsflp.htm

 

And in case someone needs a smaller NTFS, joakim made a few ones using some clever tricks, inspired by the above tool by Mark Russinovich :

http://www.msfn.org/...ize-of-bootsdi/

 

Unfortunately, the nice floppy image you created (just like some of the ones joakim created) is not recognized as NTFS under XP.

(which should mean that in order to add files to it one will need anyway to mount it in a Linux system)

 

As a side note, it appears as having a /NT60 $Boot (i.e. the bootable record invoking BOOTMGR) .

 

Wonko

 

 

 

[Wonko the Sane]

Just dreaming:
Given a bootmgr PBR:
joakim's bootmgr with included bcd is inside LBA 63-2047.
Files bootmgr and bcd are inside LBA 63-2047.

I don't know.

 

The issue (at least with the modified MBR) seems to me that once the bootsector on LBA 63 is loaded, there is no established root.

This is the reason why I made the modified embedded menu.lst for the experiment with the mapping to (fd2).

 

I haven't tried with a /NT60 bootrecord, but I believe (unless it works in the version where the first GPT partition is actually pointing to the LBA 63-2047 AND the BOOTMGR can recognize this partition) thus it may have difficulties in finding the \boot\BCD (even because of the seen before issue that it is needed on (fd0))

 

The "current" grldr bootsector, if the GPT partitioning has the entry for the LBA 63-2047 partition) should instead work fine with a "standard" grldr IF a menu.lst is added to the partition, because the search for menu.lst will result in a root established to the "correct" device (hd0,0).

 

If the BOOTMGR behaves like this and recognizes the GPT partition everything should work fine.

In the case with no GPT partition entry, I doubt it can work if not with the "special" BOOTMGR with "embedded" the \boot\BCD

 

We need to experiment with these...

 

Wonko 

[milindsmart]

Bootmgr did not boot even if given Joakim's bootmgr with embedded BCD on a GPT disk. It gave 0xc00000d0, no idea what it means. So I doubt it'll boot when read from raw sectors(!).

Bootmgr's sequence of calls is complex, has multiple invocations of the same function in the call stack... At the heart of the trouble is detecting and opening a disk/partition. It always compares with a place in memory that is written to only by the PBR... So I am curious about how GRUB, Grub4dos, syslinux manage to make bootmgr boot... I am going to dig into the source of the Grub ntldr module, but would love it if someone could explain in short.

Edited by milindsmart, 15 August 2014 - 12:06 PM.

[milindsmart]

Update : Well (0x25592) is written to by 16-bit stub. So how does wimboot manage?

[Wonko the Sane]

Bootmgr boots fine from RAW sectors mapped to (fd0), at least until it finds the \boot\BCD.

Whether later on the booting will stop on an error is another thing (and is part of the experiments/tests that are needed).

As well it is entirely possible to map to a a hd like device the whole GPT partition(s) where the Windows resides, but is also to be seen whether it is needed (or not) or if it helps (or not) to actually boot the Windows 7 or 8.

 

In the meantime a made a couple changes at the modified Makebootfat MBR, moving the "BIOS" partition entry to a place that allows the coexistence with the FAT12 bootsector inside the MBR (and limiting the "loop" for parsing the partition table entries from 4 to 1).

Find the modified MBR attached.

 

This provides the (slight) advantage that when booted the root is established to (hd0), i.e. the "whole" device.

The effect is that the FAT12 volume is seen in grub4dos BOTH as a "super-floppy" as (hd0) AND as GPT partition (hd0,0).

So it is possible to ls files in it directly.

Still the drive "at hand" is drive 0x80, and it need to be remapped to (fd0):
map () (fd0)

map --hook

root (fd0)

chainloader /NTLDR (or chainloader /BOOTMGR)

 

The BOOTMGR however has some added checks when compared to NTLDR.

NTLDR can be chainloaded fine (and finds it's BOOT.INI) while BOOTMGR doesn't like it.

 

If you do it with the RAW sectors, i.e.

map ()63+1985 (fd0)

map --hook

root (fd0)

chainloader /NTLDR (or chainloader /BOOTMGR)

 

Both NTLDR and BOOTMGR work as expected.

 

As well, if you map as:

map ()+2048

map --hook

root (fd0)

chainloader /NTLDR (or chainloader /BOOTMGR)

 

Both NTLDR and BOOTMGR work as expected.

 

I also found a strange "quirk" (possibly due to the still early/partial support of GPT partitions in grub4dos), in theory:

map (hd0)63+1985 (fd0)

and

map (hd0,0)0+1985 (fd0)

should work exactly the same, but the first works while the second throws an error about attempting to access a sector outside the partition.

In practice one can map (hd0,0)0+1984 (fd0) and surely grub4dos warns that last sector will not be accessible.

 

Wonko

Attached Files

•  MkbootFatMOD2.zip   561bytes   916 downloads

[milindsmart]

@Wonko the Sane, this time it's my turn to be confused...

What are you and cdob trying to do here? stuff bootmgr and BCD in gaps rather than use a partition? Or is it more advanced an aim than that?

Oh and btw, interesting to know you used to be jaclaz. Never really got to know why you changed that to "was_jaclaz". I noticed that the writing content and style between both these accounts was so similar, but never suspected that they might be the same person

Edited by milindsmart, 16 August 2014 - 08:49 AM.

[Wonko the Sane]

As a matter of fact if you re-read from post #76 I am not "trying", I am "succeeding" in putting an alternate bootloader (grub4dos) INSIDE a (small) GPT partition, with the not so trifling advantage of being able to boot to this partition from BIOS, keeping *everything* fully compliant with UEFI (i.e. without the need for a "Hybrid" or "semi-hybrid" setup).

 

Alternatively I am able to "add" a (small) partition (bootable from BIOS) to an already existing GPT disk without changing the GPT partition table or to boot from BIOS *any* pre-existing GPT partition (within the 2.2 TB addressing limit).

 

I will repeat how the idea is not to make something "solid" or "proper", just an added a way to play a few tricks in case of *need*, considering that small as it might be grub4dos has become to all effects a minimal "real mode" operating system, not entirely unlike DOS was, with a number of features/capabilities that are very useful to solve issues on disks.

 

JFYI, about the reasons why jaclaz's account became on reboot.pro was_jaclaz, and jaclaz got a new account as Wonko the Sane, it is not at all a secret, everything has been done in the open:

http://reboot.pro/to...-all-the-bytes/

 

Wonko

[milindsmart]

To make it "standard" we could use the gdisk partition type EF01 (which would allow to distinguish it from a EF02 or "GRUB2 BIOS boot partition" ).

This shows 2 instances of incorrect understanding:

• Just use ANY GUID generated by any good tool, and CLAIM it for your own special use of putting GRLDR, if you're so convinced that EF02 is exclusively for Grub2. That will be ENTIRELY and PERFECTLY according to the standard ; that's what GUIDs are meant to enable, rather than the old 1-byte, or even 2-byte and further partition type codes... freedom to designate your own special partition, that disk tools WILL IGNORE. That is the difference w.r.t MBR, where the tools assume it's RAW and allow you to format it.
• Further, EF01 is meant to hold an ENTIRE MBR disk as its content... with primary, extended, logical partitions intact... to repeat, the ENTIRE range of sectors constitute one large MBR disk. It was intended to facilitate migration, but no one produced a tool to map such a partition onto a virtual device that is compatible with most OSes. If it was, compatibility problems with GPT would be a thing of the past. After all, a very similar thing was done with booting of CDs in El Torito : http://mjg59.dreamwidth.org/4957.html

The second thing you're talking about, booting from a GPT partition in a spec-compliant manner, is already implemented by gptmbr.bin from Syslinux, linked in http://reboot.pro/to...pt/#entry181908 . How is this solution any different? gptmbr just finds the partition marked legacy bootable, and executes the PBR.

[Wonko the Sane]

This shows 2 instances of incorrect understanding:

Yep, it shows that you do not understand (or don't want to understand, whichever comes first) what I wrote.

 

#1. The good GRUB2 guys NEVER used the "EF02" as an identifier for the partition with GPT ID "21686148-6449-6E6F-744E-656564454649" or "Hah!IdontNeedEFI", the Author of the tool gdisk, in order to make life easier to the users of the tool, created in it an "internal ID", in which the "EF02" is just an easier way to write ID for "21686148-6449-6E6F-744E-656564454649"

#2. Someone (cannot say who) started calling the partition with GPT ID 21686148-6449-6E6F-744E-656564454649" as "BIOS boot partition", thus attributing to it a "generic" connection to BIOS booting, whilst in reality it is connected  (till now) ONLY to GRUB2 booting (from BIOS).

#3. The good Author of the gdisk tool, Rod Smith, also added a "EF01" identifier to a GPT partition ID that (UNLIKE the above one) is defined in the UEFI specification BUT that no actual BIOS use (or can use) by itself and that corresponds to "024DEE41-33E7-11D3-9D69-0008C781F39F".

#4. You are mistaken if you think that the MBR "standard" (or BIOS if you like) or any recent OS use the partition ID field to identify the partition or filesystem type, that byte is used in the same way as the "protective MBR entry type EE" is used, as a "protective ID", see: 

http://homepage.ntlw...ystem-type.html

#5. As declared, the scope of the exercise is to find strange, new ways to deal with GPT partitioned disks on BIOS PC's, and while experimenting I find perfectly "normal" to re-use (since it has already a nice "shortname" as EF01) the "024DEE41-33E7-11D3-9D69-0008C781F39F" GPT partition ID, as it is not used by *anything* so that it is also a relatively "safe" temporary solution, and it is handier to type "EF01" than a 16 byte string. AND it allows (when checking the disk in gdisk) to distinguish it easily from a possible EF02 one.

You know, like in :

Command (? for help): p
Disk \\.\Physicaldrive6: 1228800 sectors, 600.0 MiB
Logical sector size: 512 bytes
Disk identifier (GUID): F361E731-8686-4EAC-BA7D-6BBDEBC237CC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1228766
Partitions will be aligned on 1-sector boundaries
Total free space is 29 sectors (14.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              63            2047   992.5 KiB   EF01  MBR partition scheme
   2            2048          500000   243.1 MiB   EF02  BIOS boot partition
   3          500001         1228766   355.8 MiB   FFFF  Unknown

#6. Rest assured that once (if ) these experiments will lead to anything even partially usable by "final users", I will claim my own GPT partition GUID,  possibly as "57745348-616C-6640-7373-656450617274" , but right now it makes no sense to reduce the available GUID's.

#7. The whole idea of a 16 byte/128 bit GUID for partitions is of course senseless, the gdisk lists at the moment 70 (seventy) "known partition GUIDs", that cover - I believe - all Operating Systems in use that "understand" GPT, as a matter of fact the GPT GUID derives from the more "general" UUID, which has some merits  (as it was designed to avoid probability of collisions in "random" or "semi-random" generated UUID's):

http://en.wikipedia....ique_identifier

http://en.wikipedia....ique_identifier

but when it comes to identify partition types, if you claim a new partition type every second, it will take you roughly 1.6859817e+29 years to use all available ID's ....

 

About the (BTW nice) Syslinux way, please read:

http://jamesbond3142...cgi/BIOSBootGPT

http://www.lightofda...cgi/BIOSBootGPT

the idea (much more correct) is to make a "valid" GPT partition bootable from BIOS (which as said my half@ssed hack can also do, though in a different way), what I offer is (alternatively and NOT "in competition" with any other bootloader/bootmanager) the possibility of reaching "directly" a grub4dos environment (and usually what can be reached from it is limited only by fantasy ) ALSO by "inserting" a small partition in a completely "stealth" way from a UEFI/GPT viewpoint without altering (hopefully) the normal functionality of the GPT disk under UEFI. 

 

Wonko

[Wonko the Sane]

This provides the (slight) advantage that when booted the root is established to (hd0), i.e. the "whole" device.
The effect is that the FAT12 volume is seen in grub4dos BOTH as a "super-floppy" as (hd0) AND as GPT partition (hd0,0).
So it is possible to ls files in it directly.
Still the drive "at hand" is drive 0x80, and it need to be remapped to (fd0):
map () (fd0)
map --hook
root (fd0)
chainloader /NTLDR (or chainloader /BOOTMGR)
 
The BOOTMGR however has some added checks when compared to NTLDR.
NTLDR can be chainloaded fine (and finds it's BOOT.INI) while BOOTMGR doesn't like it.

The above is actually a mistake of mine (though I still wonder why NTLDR finds boot.ini), the grub4dos syntax is actually "wrong"  
I was confused (and it is not the first time) by the use of the +1 to mean a "whole device" when mapping.
ALL of these work with BOOTMGR as well:

map ()+1 (fd0)
or
map (hd0)+1 (fd0)

(the above - correctly - will inform you that what is mapped is larger than the actual volume found)

map (,0)+1 (fd0)
or
map (hd0,0)+1 (fd0)

these two latter ones are fine as you are actually mapping to (fd0) exactly the volume (just like the (hd0)63+1985 that worked fine).

 

As a side note, the "EF01" partition is NOT mounted (and I believe also not easily mountable) under Windows 7 (as it is "by design" a "protected" kind of partition on GPT), whilst the "EF02" is mounted normally.


Wonko

[milindsmart]

Oh come on, you thought I was misled by the gdisk abbreviated disk type codes?
 

#1 [...]the "EF02" is just an easier way to write ID for "21686148-6449-6E6F-744E-656564454649"

I always knew... Did I seem ignorant?
 

#2. Someone (cannot say who) started calling the partition with GPT ID 21686148-6449-6E6F-744E-656564454649as "BIOS boot partition", thus attributing to it a "generic" connection to BIOS booting, whilst in reality it is connected (till now) ONLY to GRUB2 booting (from BIOS).

While it started out being specific to Grub, there is currently ZERO technical reason for preference to Grub : ANY bootloader with a raw image to run can use it. Grub is doing NO magic here currently. For future use though, it all comes down to what the Grub guys think of it : if they have proprietary ideas about that disk type GUID, then other applications should use new GUID; if not, then they all can use it, in the exact same way.
 

#4. You are mistaken if you think that the MBR "standard" (or BIOS if you like) or any recent OS use the partition ID field to identify the partition or filesystem type, that byte is used in the same way as the "protective MBR entry type EE" is used, as a "protective ID" [...]

Yes, I concede.
 

Quote
#5. As declared, the scope of the exercise is to find strange, new ways to deal with GPT partitioned disks on BIOS PC's, and while experimenting I find perfectly "normal" to re-use (since it has already a nice "shortname" as EF01) the "024DEE41-33E7-11D3-9D69-0008C781F39F" GPT partition ID, as it is not used by *anything* so that it is also a relatively "safe" temporary solution, and it is handier to type "EF01" than a 16 byte string. AND it allows (when checking the disk in gdisk) to distinguish it easily from a possible EF02 one.

While that ID is defined in the spec, it does NOT mean the same thing or even similar thing, as the type implied by the GUID abbreviated as EF02(happy?).
From http://homepage.ntlw...ystem-type.html :

These EFI partition table types are used to protect physical discs partitioned with other partitioning schemes from softwares that do not understand those schemes and that only understand the EFI GUID partitioning scheme. They encompass the entire slice of the disc that is partitioned using the other partitioning scheme, including its partition tables.

Safe to say, EXTREMELY different from BIOS boot partition type. Software (potentially) seeing this will try to find an MBR, scan for a partition table, and try to mount them. We don't know if it's not being used by ANYONE else, and it's not safe if some poor chap IS following the spec, not even temporarily.
So yeah, you could use it while experimenting, but considering my reply to #2, using EF02 is far more suitable.

#6 : Yeah, but see previous sentence.
#7 : Is the loss of 16 bytes so bothersome? They just made all ID and type fields GUIDs for uniformity I suspect.

Edited by milindsmart, 19 August 2014 - 09:56 AM.

[Wonko the Sane]

Safe to say, EXTREMELY different from BIOS boot partition type. Software (potentially) seeing this will try to find an MBR, scan for a partition table, and try to mount them. We don't know if it's not being used by ANYONE else, and it's not safe if some poor chap IS following the spec, not even temporarily.
So yeah, you could use it while experimenting, but considering my reply to #2, using EF02 is far more suitable.

Well, you probably missed this note:
 

As a side note, the "EF01" partition is NOT mounted (and I believe also not easily mountable) under Windows 7 (as it is "by design" a "protected" kind of partition on GPT), whilst the "EF02" is mounted normally.

Of course I could use the "EF02" (or another Partition GUID) and experiment with the "flags" of the partition, but having already a simple way to have that partition almost invisible in Windows 7 seems to me simpler while experimenting.
 

#7 : Is the loss of 16 bytes so bothersome? They just made all ID and type fields GUIDs for uniformity I suspect.

Naah, of course I am joking.
But still it makes little sense to use such a vast "container" to "fill it" with just a bunch of senceful values.
The "old" partiition ID field, allowing 255+1 values has some 200 values used (with more than a few overlappings, and even more ID's taken by OS's that either do not exist anymore, never existed, or anyway are of next to none "rilevance):
http://www.win.tue.n...on_types-1.html
BUT the "field" has become a bit "tight", so it is a good idea to "widen it".
The way the gdisk Author used, using two bytes, has enlarged it to 32255+1 values of which - as said - only some 70 are currently used, in our dialog is it easier (while still being accurate) if we talk of "EF01" or "EF02" or if we talk exclusively of "024DEE41-33E7-11D3-9D69-0008C781F39F" and "21686148-6449-6E6F-744E-656564454649"? .

 

If the specifications had used two bytes instead the "container" would have been large enough to contain more partition ID's then what may ever be needed, unless, like it has happened for the IPV4 addresses (where the need for passing to IPV6 may actually be needed) it is foreseen that each single inhabitant of the planet will claim his/her set of own partition ID's .



Wonko

[milindsmart]

Ah yes I did miss that... WHY of all things is Windows mounting (or trying to mount) partitions with types it has NO idea about?

I guess EF01 can be (ab)used for this purpose temporarily.

[Wonko the Sane]

Ah yes I did miss that... WHY of all things is Windows mounting (or trying to mount) partitions with types it has NO idea about?

Most probably it probes anyway for the filesystem on any non-hidden GPT partition (in my example they were respectively FAT16 and NTFS) and if the IFS chooser recognizes it, it automounts and assigns to it a drive letter.

 

For the record (and to underline how the GUID are not really handy) the diskpart (or diskpart.efi) tool uses ALIASes as well:

http://support.micro...kb/297800/en-us

 

With the usual MS arrogance "their" aliases are promoted to "definitions" , though of course they do not use the same aliases elesewhere):

 

The definitions of the GPT-type partitions are:
Msres: The Microsoft reserved partition for feature support that is used to convert a basic disk to dynamic.
Efisys: The EFI system partition that is required for boot operations.
Msdata: The user data partition that is used by Microsoft Windows.

 

 

Msres should be "0C01" or "E3C9E316-0B5C-4DB8-817D-F92DF00215AE" or "MSR":

http://msdn.microsof...5(v=vs.85).aspx

 

The MSR has the Partition GUID:

DEFINE_GUID (PARTITION_MSFT_RESERVED_GUID, 0xE3C9E316L, 0x0B5C, 0x4DB8, 0x81, 0x7D, 0xF9, 0x2D, 0xF0, 0x02, 0x15, 0xAE)

 

 

Efisys should be "EF00" or "C12A7328-F81F-11D2-BA4B-00A0C93EC93B" or "ESP":

http://msdn.microsof...5(v=vs.85).aspx

 

The Partition GUID defines the ESP:

DEFINE_GUID (PARTITION_SYSTEM_GUID, 0xC12A7328L, 0xF81F, 0x11D2, 0xBA, 0x4B, 0x00, 0xA0, 0xC9, 0x3E, 0xC9, 0x3B)

 

 

 

Msdata should be "0700" or "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7" or "basic data partition" (I mean why not "BDP" ):

 

How is a basic data partition identified?

It has the following partition type GUID:

DEFINE_GUID (PARTITION_BASIC_DATA_GUID, 0xEBD0A0A2L, 0xB9E5, 0x4433, 0x87, 0xC0, 0x68, 0xB6, 0xB7, 0x26, 0x99, 0xC7);

 

 

To which you have to add the "nameless" (for Windows RE) "de94bba4-06d1-4d40-a16a-bfd50179d6ac" 

http://technet.micro...301(WS.10).aspx

 

And the ones for Dynamic disks (also nameless):

 

What about dynamic disks?

Dynamic disks use two different GPT partitions?
A data container partition that corresponds to the MBR partition 0x42, with the following GUID:

DEFINE_GUID (PARTITION_LDM_DATA_GUID, 0xAF9B60A0L, 0x1431, 0x4F62, 0xBC, 0x68, 0x33, 0x11, 0x71, 0x4A, 0x69, 0xAD);
A partition to contain the dynamic configuration database, with the following GUID:

DEFINE_GUID(PARTITION_LDM_METADATA_GUID, 0x5808C8AAL, 0x7E8F, 0x42E0, 0x85, 0xD2, 0xE1, 0xE9, 0x04, 0x34, 0xCF, 0xB3);

 

 

Now, think how a computer archeologist from year (say) 20000 AD (or an alien landed on earth in the future) will use these info to rebuild the logic processes that led to this simplification and how they will conclude that humanity was doomed since the advent of UEFI/GPT.

 

 

Wonko

[Icecube]

According to wikipedia, this are all the Windows partition type GUIDs:

Microsoft Reserved Partition (MSR)                 E3C9E316-0B5C-4DB8-817D-F92DF00215AE
Basic data partition[C]                            EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
Logical Disk Manager (LDM) metadata partition      5808C8AA-7E8F-42E0-85D2-E1E90434CFB3
Logical Disk Manager data partition                AF9B60A0-1431-4F62-BC68-3311714A69AD
Windows Recovery Environment                       DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
IBM General Parallel File System (GPFS) partition  37AFFC90-EF7D-4E96-91C3-2D7AE055B174
Storage Spaces partition                           E75CAF8F-F680-4CEE-AFA3-B001E56EFC2D

http://en.wikipedia....tion_type_GUIDs

[milindsmart]

Bootmgr boots fine from RAW sectors mapped to (fd0), at least until it finds the \boot\BCD.
Whether later on the booting will stop on an error is another thing (and is part of the experiments/tests that are needed).

Of course it starts up fine, but does it find \Boot\BCD? Have you seen it find BCD, and then proceed to fully boot Windows? I doubt it... so many sanity checks.

And do tell, I'd love to conduct some of those experiments... what (weird crazy) boot process needs to be tested?

As well it is entirely possible to map to a a hd like device the whole GPT partition(s) where the Windows resides, but is also to be seen whether it is needed (or not) or if it helps (or not) to actually boot the Windows 7 or 8.

Not necessary. Windows just needs to be in some partition, in MBR or GPT. I don't see how it helps either...

[Wonko the Sane]

Sure it finds the \boot\BCD on "virtual floppy" (fd0), that was the whole point of the exercise.

 

The "Vista boot floppy" (just like the NT/2K/XP boot floppy) has always worked and the various methods we have seen (as well as the "small" HD image Sascha Weaver and you tested successfuly) are nothing but variations of it.

Most notably, starting from here:

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

a number of experiments were made.

 

The "news" in the latest experiments (starting on this thread from post #63) is that I *somehow* devised a way to have the thingy working with a few different approaches.

Besides modifying the placement of the GPT partition table (that before or later may easily become an issue in the sense that some tools/OS may not like it) we can, in the latest deelopments, have (it is a choice) an "invisible to GPT" partition on sectors 63-2047 OR "map" that partition in the GPT partition table.  

 

To recap:

1. make sure that the GPT partitions on disk are "Mb aligned" AND that first partition on it starts on sector 2048
2. dd to first sector (the MBR) the contents of MkbootFatMOD2.zip  http://reboot.pro/to...o-gpt/?p=186471
3. dd to sectors 63-2047 the file GPT_GRLDR.ima which is inside  GPT_grub4dos.zip  http://reboot.pro/in...attach_id=15016
4. try booting (from BIOS) the GPT disk

You will (should) land to a grub4dos prompt.

If you issue in it a root command, root will be (fd2).

 

Now:

1. reboot from a "normal" NT OS
2. make a copy of the GPT_GRLDR.ima to GPT_GRLDR_mod.ima
3. use (say) IMDISK to mount it (the copy)
4. replace the grldr in the image with any recent "standard" one
5. dd the modified image to sectors 63-2047 of the GPT disk
6. try booting (from BIOS) the GPT disk

You will (should) land to a grub4dos prompt.

If you issue in it a root command, root will be (hd0).

 

Now:

 

1. reboot from a "normal" NT OS
2. make a copy of the GPT_GRLDR_mod.ima to GPT_GRLDR_mod.ima
3. use (say) IMDISK to mount it
4. copy to the image a BOOTMGR and a (valid) \boot\BCD
5. add to the image a file BOOT.INI with an entry for grub4dos, you can use this one for the test: http://diddy.boot-la...ws.htm#windows1
6. dd the modified image to sectors 63-2047 of the GPT disk
7. try booting (from BIOS) the GPT disk

 

You will (should) land to a grub4dos prompt.

If you issue in it a root command, root will be (hd0).

Now issue the commands:

map (hd0)63+1985 (fd0)
map --hook
root (fd0)
chainloader /bootmgr
boot

What happens?

 

Try again with

map (hd0)+1 (fd0)
 map --hook
 root (fd0)
 chainloader /bootmgr
 boot

What happens?

 

Wonko

 

[milindsmart]

The "Vista boot floppy" (just like the NT/2K/XP boot floppy) has always worked and the various methods we have seen (as well as the "small" HD image Sascha Weaver and you tested successfuly) are nothing but variations of it.

 

Hehe yeah, never realized.... this is exactly the boot floppy. So the concise, compact summary of the basic result of this thread's investigation is : the bootmgr "Vista" boot floppy can let you boot Windows 7+ (maybe Vista too? gotta check it out) from GPT on a BIOS system.

 

Windows 7 disk management will "blank" first 440 bytes of the MBR and ...

 

When does this happen? At disk creation? on conversion to GPT from MBR? Every time disk management opens? Everytime Windows boots?

[Wonko the Sane]

So the concise, compact summary of the basic result of this thread's investigation is : the bootmgr "Vista" boot floppy can let you boot Windows 7+ (maybe Vista too? gotta check it out) from GPT on a BIOS system.

Yes and no.

The possible "evolution" of this method is combining it with the one hinted here:

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

 

You have the "special" MBR booting the "special" invisible partition that contains grub4dos and a "blank" floppy image (optionally gzipped) with a pre-made entry for \boot\BCD (and optionally for BOOTMGR, see below).

 

Then you have a menu.lst (or edit the embedded one) that will:

• map the "blank" image to first floppy (fd0)
• find among the GPT partitions the one containing the BOOTMGR and the \boot\BCD
• either dd the \boot\BCD to the (fd0) and chainload the BOOTMGR on the found GPT partition or dd both the BOOTMGR and \boot\BCD to the (fd0) and chainload the BOOTMGR on (fd0).

 

The advantage being that while the "Vista Boot floppy" (and it's variations) need to be "tailored" on the specific System, this method will be portable, i.e. the BOOTMGR and \boot\BCD used in the booting will be the ones on the GPT partition, i.e. unlike the other method that requires if you do changes to the \boot\BCD to replicate the files somwhere else, this one - since it uses the same modified \boot\BCD file - will be automatically "updated".

 

When does this happen? At disk creation? on conversion to GPT from MBR? Every time disk management opens? Everytime Windows boots?

Naah, only when you create/recreate partitions on the disk, AFAICR, but I didn't tested this extensively, from experience, *any* change you do in disk management to a GPT disk will probably re-scan and re-verify (possibly "botching" it) what is already there, see below.

 

It seems like the old defects of Disk Manager (not minding it's own business/doing more things you would expect it to do) remain.

 

See (for a loose comparison) what may happen (on particular disk configurations) if you just toggle the active partition with XP Disk Management:

http://reboot.pro/to...itioning-issue/

 

As always ONLY part of the truth from the mouth of the wolf:

http://support.micro...kb/931854/en-us

 

And some more accurate experiments:

http://www.dcr.net/~...gPartitions.htm

 

Though the SERIOUS thing is that it is triggered also by an "innocent" change of the active status of a primary partition which obviously should not affect anything if not replacing a 00 with an 80 or viceversa in a MBR partition entry related to a primary partition.

 

Wonko

[devdevadev]

I think you should take a look of following post. I think it is exactly what you want............

 

http://manian.com/in...ent_srl=5956541

 

In Above post, Writer had installed 'Win 7 Ent' with he help of RsimageX Tool within from PE into 119 GB GPT Disk. So it's looking that It is possible to boot Windows within from GPT Disk in BIOS mode if we install it from PE.....

 

Is you goal is different from the goal of above post ?

 

Regards.........

[milindsmart]

Nice find...

 

They seem to be doing the exact same thing as us... even though they do mention RsimageX, it doesn't seem a necessary step. I don't know if PE installation is even part of the tweak. But yes, the aim seems to be the same.

 

But I really don't know, someone who knows Korean is essential here, google translate cannot convey the meaning...

 

BTW, use @ [ member = "devdevadev" ] , (example) removing all spaces, to mention members, so that it appears like @devdevadev (move mouse over your username to see the effect).

Edited by milindsmart, 29 August 2014 - 03:29 PM.