Re: GPT - (last) call for action
At Mon, 11 Jun 2007 13:12:04 -0700, Chuck Swiger wrote: If you ever use it, fdisk /dev/rdisk0 will show things differently. The first partition with id 0xEE will should start at LBA 40 and end at LBA 409640. OK: although that surprises me a bit, perhaps trying to get Windows XP (which may not understand the ~32 sector GPT header+table) means that claiming the first partition in the MBR starts at 40 works better...? Well, yes. I think it's like a safe keeping issue so that the user doesn't overwrite the GPT info. The first, small partition is almost certainly a boothfs boot partition, as described in the man page for Apple's version of fdisk: I don't think so. The boothfs partition doesn't seem to be used on Intel Macs no longer. The EFI boot loader that comes with Intel Macs can read HFS+ without any help (actually it's an EFI module), so bootufs/boothfs partitions are no longer required. It looks like you're right-- the OS-X formatting utilities still reserve space for the boot partition, but they just scribble enough to this space to indicate that the partition isn't actually bootable: # dd if=/dev/disk0s1 bs=512 count=409600 | hexdump -C Yes, this partition is just FAT32 without anything in it. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
Matthew Dillon wrote: It really sounds like they are making an accomodation for BIOS booting or older Windows booting... or *something* of that sort. The fact that the bootability bit is not set in the MBR (I'm not sure about that, is it set or not?)... that seems to imply a compatibility issue The spec forbids bootable flag in the protective MBR with other OS's like Windows in a multi-boot environment. They are just doing it all with a single slice instead of having two slices. This is more conformant to the spec, which says the protective MBR should have only one partition which covers the whole disk. I think that we can get away with 1 fdisk slices which mirror the first four GPT partitions on non-EFI machines. This would probably mean modifying the gpt utility and module to mirror the EFI partitions in the PMBR, controlled by a flag so that real EFI machines don't get choked. signature.asc Description: OpenPGP digital signature
Re: GPT - (last) call for action
At Mon, 11 Jun 2007 13:33:42 -0700 (PDT), Matthew Dillon wrote: : # gpt -r show /dev/rdisk0 :start size index contents :0 1 PMBR :1 1 Pri GPT header :2 32 Pri GPT table : 34 6 : 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- : : 409640 159414704 2 GPT part - 48465300--11AA-AA11- : :... : Well, what's happening is that Boot Camp syncs the BIOS partition : table with the GPT table, so the first partition should start at 40, : just like the GPT. : : Why does it start at 40 ? Because you need room for the PMBR, the : Primary GPT header and the Primary GPT table. : :Agreed, you need about 32 sectors for the GPT header+table. It makes sense for them to point the first MBR slice at the first partition in the GPT, even though the standard says something else. It really sounds like they are making an accomodation for BIOS booting or older Windows booting... or *something* of that sort. The fact that the bootability bit is not set in the MBR (I'm not sure about that, is it set or not?)... that seems to imply a compatibility issue with other OS's like Windows in a multi-boot environment. They are just doing it all with a single slice instead of having two slices. I'll bet they found that the two-slice method doesn't work in some cases and the one-slice method does. The standard document doesn't allow either method but it does seem to be a bit less insistent on the starting sector for slice 1 then it does on there only being one slice in the MBR, period. I can also see some OS's / disk managers barfing on having two slices which overlap each other. So it really does make sense for them to point the MBR at sector 40. The more I think about it, the more sense it makes. And also, if they used two partitions that would mean you would only have one partition left for installing Windows. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Mon, 11 Jun 2007 12:41:18 -0700, Chuck Swiger wrote: Hi, all-- On Jun 10, 2007, at 3:13 PM, Rui Paulo wrote: :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). I don't know why Apple does that. The offset of 40 sectors sounds like it is pointing to the first partition listed within the GPT? A typical Intel Mac system using GPT ought to look something like this: # fdisk /dev/rdisk0 Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] Unknown ID 2: 000 0 0 -0 0 0 [ 0 - 0] unused 3: 000 0 0 -0 0 0 [ 0 - 0] unused 4: 000 0 0 -0 0 0 [ 0 - 0] unused # gpt -r show /dev/rdisk0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- 409640 159414704 2 GPT part - 48465300--11AA-AA11- 159824344 262151 160086495 32 Sec GPT table 160086527 1 Sec GPT header Well, what's happening is that Boot Camp syncs the BIOS partition table with the GPT table, so the first partition should start at 40, just like the GPT. Why does it start at 40 ? Because you need room for the PMBR, the Primary GPT header and the Primary GPT table. Now, you don't seem to have used Boot Camp on your Mac, right? If you ever use it, fdisk /dev/rdisk0 will show things differently. The first partition with id 0xEE will should start at LBA 40 and end at LBA 409640. The first, small partition is almost certainly a boothfs boot partition, as described in the man page for Apple's version of fdisk: I don't think so. The boothfs partition doesn't seem to be used on Intel Macs no longer. The EFI boot loader that comes with Intel Macs can read HFS+ without any help (actually it's an EFI module), so bootufs/boothfs partitions are no longer required. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Sun, 10 Jun 2007 23:13:59 +0100, Rui Paulo wrote: At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), Matthew Dillon wrote: :No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :*** Working on device /dev/ad0 *** :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). I don't know why Apple does that. Actually, I think I do. See my other email. Regards. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
Hi, all-- On Jun 10, 2007, at 3:13 PM, Rui Paulo wrote: :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). I don't know why Apple does that. The offset of 40 sectors sounds like it is pointing to the first partition listed within the GPT? A typical Intel Mac system using GPT ought to look something like this: # fdisk /dev/rdisk0 Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] Unknown ID 2: 000 0 0 -0 0 0 [ 0 - 0] unused 3: 000 0 0 -0 0 0 [ 0 - 0] unused 4: 000 0 0 -0 0 0 [ 0 - 0] unused # gpt -r show /dev/rdisk0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- 409640 159414704 2 GPT part - 48465300--11AA-AA11- 159824344 262151 160086495 32 Sec GPT table 160086527 1 Sec GPT header The first, small partition is almost certainly a boothfs boot partition, as described in the man page for Apple's version of fdisk: In the default template, partition number 1 will be configured as a Dar- win boot partition spanning from cylinder 0, head 1, sector 1, and extending for 8 megabytes. Partition number 2 will be configured as a Darwin HFS partition spanning the rest of the disk. This mode is designed to initialize an MBR the very first time, or when it has been corrupted beyond repair. You can specify other default partition styles with the -a flag. The available styles are: boothfs Creates an 8Mb boot partition (type AB hex) and makes the rest of the disk a Darwin HFS partition (type AF hex). bootufs Creates an 8Mb boot partition (type AB hex) and makes the rest of the disk a Darwin UFS partition (type A8 hex). hfs Makes the entire disk one Darwin UFS partition (type A8 hex). ufs Makes the entire disk one HFS+ partition (type AF hex). dos Makes the entire disk one DOS partition (type 0C hex). raidMakes the entire disk one type AC hex partition. The -u flag is used to update the MBR code on a given drive. The MBR code extends from offset 0x000 to the start of the partition table at offset 0x1BE. It is similar to the -i flag, except the existing parti- tion table is preserved. This is useful for writing new MBR code onto an existing drive, and is equivalent to the DOS command ``FDISK / MBR''. Note that this option will overwrite the NT disk signature, if present. The -u and -i flags may not be specified together. Also cf: http://en.wikipedia.org/wiki/GUID_Partition_Table -- -Chuck ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 11, 2007, at 12:52 PM, Rui Paulo wrote: A typical Intel Mac system using GPT ought to look something like this: # fdisk /dev/rdisk0 Disk: /dev/rdisk0 geometry: 9964/255/63 [160086528 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] - --- 1: EE 1023 254 63 - 1023 254 63 [ 1 - 160086520] Unknown ID 2: 000 0 0 -0 0 0 [ 0 - 0] unused 3: 000 0 0 -0 0 0 [ 0 - 0] unused 4: 000 0 0 -0 0 0 [ 0 - 0] unused # gpt -r show /dev/rdisk0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- 409640 159414704 2 GPT part - 48465300--11AA-AA11- 159824344 262151 160086495 32 Sec GPT table 160086527 1 Sec GPT header Well, what's happening is that Boot Camp syncs the BIOS partition table with the GPT table, so the first partition should start at 40, just like the GPT. Why does it start at 40 ? Because you need room for the PMBR, the Primary GPT header and the Primary GPT table. Agreed, you need about 32 sectors for the GPT header+table. Now, you don't seem to have used Boot Camp on your Mac, right? It's true that the machine in question has never used BootCamp, correct. If you ever use it, fdisk /dev/rdisk0 will show things differently. The first partition with id 0xEE will should start at LBA 40 and end at LBA 409640. OK: although that surprises me a bit, perhaps trying to get Windows XP (which may not understand the ~32 sector GPT header+table) means that claiming the first partition in the MBR starts at 40 works better...? The first, small partition is almost certainly a boothfs boot partition, as described in the man page for Apple's version of fdisk: I don't think so. The boothfs partition doesn't seem to be used on Intel Macs no longer. The EFI boot loader that comes with Intel Macs can read HFS+ without any help (actually it's an EFI module), so bootufs/boothfs partitions are no longer required. It looks like you're right-- the OS-X formatting utilities still reserve space for the boot partition, but they just scribble enough to this space to indicate that the partition isn't actually bootable: # dd if=/dev/disk0s1 bs=512 count=409600 | hexdump -C eb 58 90 42 53 44 20 20 34 2e 34 00 02 01 20 00 |.X.BSD 4.4... .| 0010 02 00 00 00 00 f0 00 00 00 00 00 00 28 00 00 00 |(...| 0020 00 40 06 00 67 0c 00 00 00 00 00 00 02 00 00 00 |[EMAIL PROTECTED]| 0030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0040 00 00 29 f4 11 60 28 45 46 49 20 20 20 20 20 20 |..)..` (EFI | 0050 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d0 bc | FAT32 .1| 0060 00 7c fb 8e d8 e8 00 00 5e 83 c6 19 bb 07 00 fc |.|..^...| 0070 ac 84 c0 74 06 b4 0e cd 10 eb f5 30 e4 cd 16 cd |...t...0| 0080 19 0d 0a 4e 6f 6e 2d 73 79 73 74 65 6d 20 64 69 |...Non- system di| 0090 73 6b 0d 0a 50 72 65 73 73 20 61 6e 79 20 6b 65 | sk..Press any ke| 00a0 79 20 74 6f 20 72 65 62 6f 6f 74 0d 0a 00 00 00 |y to reboot.| 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 | RRaA| 0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 03e0 00 00 00 00 72 72 41 61 ff ff ff ff ff ff ff ff |rrAa| 03f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0c00 eb 58 90 42 53 44 20 20 34 2e 34 00 02 01 20 00 |.X.BSD 4.4... .| 0c10 02 00 00 00 00 f0 00 00 00 00 00 00 28 00 00 00 |(...| 0c20 00 40 06 00 67 0c 00 00 00 00 00 00 02 00 00 00 |[EMAIL PROTECTED]| 0c30 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0c40 00 00 29 f4 11 60 28 45 46 49 20 20 20 20 20 20 |..)..` (EFI | 0c50 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d0 bc | FAT32 .1| 0c60 00 7c fb 8e d8 e8 00 00 5e 83 c6 19 bb 07 00 fc |.|..^...| 0c70 ac 84 c0 74 06 b4 0e cd 10 eb f5 30 e4 cd 16 cd |...t...0| 0c80 19 0d 0a 4e 6f 6e 2d 73 79 73 74 65 6d 20 64 69 |...Non- system di| 0c90 73 6b 0d 0a 50 72 65 73 73 20 61 6e 79 20 6b 65 | sk..Press any ke| 0ca0 79 20 74 6f 20 72 65 62 6f 6f 74 0d 0a
Re: GPT - (last) call for action
: # gpt -r show /dev/rdisk0 :start size index contents :0 1 PMBR :1 1 Pri GPT header :2 32 Pri GPT table : 34 6 : 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B- : : 409640 159414704 2 GPT part - 48465300--11AA-AA11- : :... : Well, what's happening is that Boot Camp syncs the BIOS partition : table with the GPT table, so the first partition should start at 40, : just like the GPT. : : Why does it start at 40 ? Because you need room for the PMBR, the : Primary GPT header and the Primary GPT table. : :Agreed, you need about 32 sectors for the GPT header+table. It makes sense for them to point the first MBR slice at the first partition in the GPT, even though the standard says something else. It really sounds like they are making an accomodation for BIOS booting or older Windows booting... or *something* of that sort. The fact that the bootability bit is not set in the MBR (I'm not sure about that, is it set or not?)... that seems to imply a compatibility issue with other OS's like Windows in a multi-boot environment. They are just doing it all with a single slice instead of having two slices. I'll bet they found that the two-slice method doesn't work in some cases and the one-slice method does. The standard document doesn't allow either method but it does seem to be a bit less insistent on the starting sector for slice 1 then it does on there only being one slice in the MBR, period. I can also see some OS's / disk managers barfing on having two slices which overlap each other. So it really does make sense for them to point the MBR at sector 40. The more I think about it, the more sense it makes. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
:Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I like the mirroring approach, because I can make the label manager just treat the special MBR slice (s2) as being part of the integrated GPT spec (which it is). From the end-user's point of view he would just do something like 'gptlabel -e ad0' and one of the GPT partitions listed would be the 'boot' partition. gptlabel would recognize the special nature of the partition and automatically and silently adjust the special MBR slice (s2) to match it. I don't like the out-of-band approach... I definitely want the partitions to be within GPTs managed area, at least for newly minted disks. With the in-band approach the gpt labeling program can take care of any special compatibility cases in a fairly straightforward and controlled manner. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: :Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I seem to recall that the 0xEE partition is not the first, but rather the second or third. It would make sense, because it has no function other than to have the disk appear used. Bootcamp uses the mirroring approach. -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
:No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :*** Working on device /dev/ad0 *** :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Sun, 10 Jun 2007 11:08:47 -0700, Marcel Moolenaar wrote: On Jun 10, 2007, at 10:52 AM, Matthew Dillon wrote: :Technically speaking, the MBR can only have a single partition of :type 0xEE that covers the whole disk. This is to protect the GPT :from MBR-specific tools that do not know about the GPT. This is :not a bootable slice by definition. : :Practice is different. To support bootcamp on Intel-based Macs, :the MBR will have real partitions that mirror GPT partitions or :otherwise describe partitions outside the GPT controlled area. :These can be bootable partitions and the protective partition :(the one with type 0xEE) will not cover the whole disk anymore. : :The nasty part is keeping MBR and GPT partitions in sync, so it :may be better to have the MBR partition fall outside the GPT :controlled area. This can be done because the GPT header contains :the LBA of the first and last sectors on the disk that can be :assigned to a partition. You can free up space for MBR partitions :after the primary GPT table by adjusting the first LBA. In the :MBR partition you can put a GPT aware boot loader that uses the :GPT to find the real partitions... : :-- :Marcel Moolenaar In the bootcamp approach, is the GPT (0xEE) slice the first slice, and the bootcamp slice the second slice? I'm assuming it is. Do they mirror a GPT partition or do they use the uncontrolled area approach? I seem to recall that the 0xEE partition is not the first, but rather the second or third. It would make sense, because it has no function other than to have the disk appear used. Bootcamp uses the mirroring approach. No. The first partition is the EFI GPT (0xee): % fdisk -1 *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 40, size 409600 (200 Meg), flag 0 beg: cyl 0/ head 0/ sector 41; end: cyl 406/ head 6/ sector 14 % gpt -r show ad0 gpt show: ad0: Suspicious MBR at sector 0 start size index contents 0 1 MBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - EFI System 409640 41943040 2 GPT part - Apple HFS 42352680 74857527 3 GPT part - FreeBSD UFS/UFS2 117210207 32 Sec GPT table 117210239 1 Sec GPT header -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
At Sun, 10 Jun 2007 14:43:26 -0700 (PDT), Matthew Dillon wrote: :No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :*** Working on device /dev/ad0 *** :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with sector 1 :Information from DOS bootblock is: :The data for partition 1 is: :sysid 238 (0xee),(EFI GPT) :start 40, size 409600 (200 Meg), flag 0 :beg: cyl 0/ head 0/ sector 41; :end: cyl 406/ head 6/ sector 14 I think I have it mostly figured out, but the 'start 40' in your output can't be right. The intel documentation says that the starting LBA in a PMBR record must be set to 1 by definition (table 11-7 in the 1.10 documentation). I don't know why Apple does that. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 9, 2007, at 9:22 AM, Ivan Voras wrote: Another thing that would be nice to have is support for fdisk and disklabel partitions inside geom_part, so it's management utility can be used for both GPT and old style partition management (instead of currently used two tools: fdisk and disklabel). I do have to make FreeBSD/ia64 boot on a rx2660, but after that I may be able to take a look at it. I know what's there and I know what's missing, so I should be able to get the partitioning stuff working soon-ish. The bootblock requirements may take little longer, because there's where g_part is missing features. Keep me in the loop. FYI, -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 9, 2007, at 1:04 PM, Ivan Voras wrote: Marcel Moolenaar wrote: On Jun 9, 2007, at 9:22 AM, Ivan Voras wrote: Another thing that would be nice to have is support for fdisk and disklabel partitions inside geom_part, so it's management utility can be used for both GPT and old style partition management (instead of currently used two tools: fdisk and disklabel). I do have to make FreeBSD/ia64 boot on a rx2660, but after that I may be able to take a look at it. I know what's there and I know what's missing, so I should be able to get the partitioning stuff working Thanks! soon-ish. The bootblock requirements may take little longer, because there's where g_part is missing features. Do you mean installing boot blocks into the protective MBR via geom_part or something else? Yep. Both MBR and BSD have boot code and we need to be able to install it through the GEOM ctlreq I/F. It's not a big problem per se, but it's something that needs to be implemented. I'm thinking of a new verb (say install) that takes one or more blobs of code that the scheme knows how to handle. The boot code is installed after the partitioning scheme has been created on the disk... -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
I'm having to tackle this issue right now in DFly. With GPT having to start at sector 1 (no choice there), the compatible MBR in sector 0 presumably must have a slice (#1) which covers the entire disk. But do we have to make slice #1 bootable? Could we also create a slice #2 in the MBR that points into the GPT's first partition, mark it bootable, and thus be able to put boot1 in the GPT's first partition? Or will the BIOS fart on the overlapping MBR slices? -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 9, 2007, at 2:28 PM, Matthew Dillon wrote: I'm having to tackle this issue right now in DFly. With GPT having to start at sector 1 (no choice there), the compatible MBR in sector 0 presumably must have a slice (#1) which covers the entire disk. But do we have to make slice #1 bootable? Could we also create a slice #2 in the MBR that points into the GPT's first partition, mark it bootable, and thus be able to put boot1 in the GPT's first partition? Or will the BIOS fart on the overlapping MBR slices? Technically speaking, the MBR can only have a single partition of type 0xEE that covers the whole disk. This is to protect the GPT from MBR-specific tools that do not know about the GPT. This is not a bootable slice by definition. Practice is different. To support bootcamp on Intel-based Macs, the MBR will have real partitions that mirror GPT partitions or otherwise describe partitions outside the GPT controlled area. These can be bootable partitions and the protective partition (the one with type 0xEE) will not cover the whole disk anymore. The nasty part is keeping MBR and GPT partitions in sync, so it may be better to have the MBR partition fall outside the GPT controlled area. This can be done because the GPT header contains the LBA of the first and last sectors on the disk that can be assigned to a partition. You can free up space for MBR partitions after the primary GPT table by adjusting the first LBA. In the MBR partition you can put a GPT aware boot loader that uses the GPT to find the real partitions... -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
