gptfdisk-general — General discussions of GPT fdisk

Re: [Gptfdisk-general] GPT fdisk: problem with pre-existing Protective MBR when writing table to disk (w)

[Edwin <edw...@gm...>]

Not sure if it makes sense for GPT disks, but my existing protective MBR
has a non-zero disk signature (the 4-byte one). The auto-correct will
change it to a zero disk signature (of course there still is the GPT header
disk guid).

Does the MBR disk signature matter for any OS/firmware (perhaps for windows
that could have set this in the first place)?

I actually just tried to create a new MBR with a zero disk signature and
that caused my laptop not to boot anymore from HD. Somehow the UEFI
firmware / boot loader must depend on the disk signature since the machine
did not progress past the "bios" screen. Anyway when I reset the disk
signature back to what it was earlier the machine booted from HD again.
Would it be safer to have the MakeProtectiveMBR function keep the existing
signature when it auto-corrects?

Edwin


On Sat, Jan 25, 2014 at 11:00 PM, Rod Smith <rod...@ro...> wrote:

> On 01/25/2014 10:59 PM, Edwin wrote:
>
>> Hi Rod,
>>
>> Thanks for your quick reply. Your explanation makes sense and it
>> explains the error I got.
>>
>> Is there a way in gdisk to fix my MBR? In other words to set the
>> non-compliant end-sector to the right value?
>>
>
> Yes; you just need to re-create the protective MBR. This can be done with
> the "n" option on the experts' menu.
>
>
>  Actually you might be right about another cause. In hind-sight I did use
>> the built-in windows disk management tool to shrink the windows
>> partition. Should have thought of that earlier... also did not realize
>> that would have changed the MBR but as you said that probably was the
>> cause then.
>>
>
> The Windows partitioning tools have many problems, but I don't think I've
> heard of them creating invalid protective MBRs. I don't know offhand if
> they re-create or modify protective MBRs as a matter of course, the way
> GParted and parted do. Of course, this could be a new bug -- say,
> introduced in Windows 8.1.
>
> FWIW, I've just revised gdisk to auto-correct this problem when loading
> the partition table, assuming everything else looks OK. If there are other
> problems when loading, a verify ("v" on any menu) operation should display
> a warning, and a write operation will also warn about the issue. The
> changes are in the GPT fdisk git repository, in case you want to check it
> out.
>
>  On Sat, Jan 25, 2014 at 9:45 PM, Rod Smith <rod...@ro...
>> <mailto:rod...@ro...>> wrote:
>>
>>     On 01/25/2014 10:17 PM, Edwin wrote:
>>
>>         When using gdisk on my disk (in the state as it was
>>         pre-installed by OEM
>>         for Windows 8) I encountered an error writing a new partition
>>         table to
>>         my disk with gdisk.
>>
>>         After creating new partitions and writing to disk (w) I get this
>>         error:
>>
>>           >>Warning! An error was reported when writing the partition
>>         table! This
>>         error
>>           >>MIGHT be harmless, or the disk might be damaged! Checking it
>> is
>>         advisable.
>>
>>         After a bit of debugging this turned out to be caused by
>>         WriteMBRData
>>         returning a failure code.
>>
>>         This is caused by one of the checks in WriteMBRData:
>>         CreateExtended() -> IsLegal() -> DoTheyFit()
>>
>>         DoTheyFit() returns a failure in this case which is as far as I
>>         can tell
>>         due to the pre-existing protective MBR on my disk.
>>
>>         Printing the MBR using recovery (r) and (o) for the existing MBR
>>         gives:
>>
>>           >>Recovery/transformation command (? for help): o
>>           >>
>>           >>Disk size is 1000215216 sectors (476.9 GiB)
>>           >>MBR disk identifier: 0xB65D55C8
>>           >>MBR partitions:
>>           >>
>>           >>Number  Boot  Start Sector   End Sector   Status      Code
>>           >>   1                     1   4294967295   primary     0xEE
>>
>>
>>         The End Sector being larger than the disk size causes the
>>         DoTheyFit()
>>         check to fail. Since I am not an expert in this area I am not
>>         sure if it
>>         is safe to remove this check.
>>
>>
>>     No, it's not. Your protective MBR violates the GPT specification.
>>     The GPT specification (on pp. 97-98 of the EFI 2.3.1 specification)
>>     clearly states that the protective MBR's 0xEE partition should begin
>>     on sector 1 and have a size of one minus the size of the disk, or
>>     0xFFFFFFFF *if the disk is larger than can be represented in that
>>     field*. Yours has that larger size but the disk is small enough that
>>     a smaller protective MBR *should have* been used.
>>
>>     That said, gdisk could handle the problem better than it does. I'll
>>     look into improving it.
>>
>>
>>         It makes some sense to me to remove this
>>         check since as far as I understand the protective MBR should
>>         cover at
>>         least the entire disk.
>>
>>
>>     No; as I say, the spec doesn't permit the field to be larger than
>>     the disk size.
>>
>>
>>         In fact for the protective MBR a more logical
>>         check might be to fail if End Sector is smaller than disk size?
>>
>>
>>     That would fail for over-2TiB disks and for disks that use hybrid
>>     MBRs. (The latter technically violate the GPT spec, but Apple uses
>>     them heavily on Macs that dual-boot with Windows, and sometimes with
>>     other OSes. Thus, gdisk supports hybrid MBRs.)
>>
>>
>>         I assume that gdisk normally creates a new protective MBR on an
>>         empty
>>         disk exactly equal to the size of the disk?
>>
>>
>>     On sub-2TiB disks, yes. On larger disks, it creates a 0xEE partition
>>     of the maximum possible size, as per the spec.
>>
>>
>>         Since this error made me nervous about the health of my disk/data
>> at
>>         first and since my OEM (Lenovo) delivered this MBR in this state
>>         from
>>         factory, this could probably happen to others as well. Therefore I
>>         wanted to share my findings in the hope that others may benefit.
>>
>>
>>     You might consider filing a bug report with Lenovo, since their
>>     as-delivered protective MBR was defective. Be sure it was as
>>     delivered, though; if you used some other tool to resize your
>>     Windows partitions, THAT tool may have damaged the protective MBR.
>>     (Because gdisk can't shrink filesystems and most OEMs deliver
>>     computers with all but trivial amounts of disk space pre-allocated,
>>     I suspect that you did use something else to resize at least one
>>     partition.) Some tools create fresh protective MBRs as a matter of
>>     course. GParted and parted both do this, for instance, although
>>     these tools create protective MBRs with appropriately-sized 0xEE
>>     partitions.
>>
>>     --
>>     Rod Smith
>>     rod...@ro... <mailto:rod...@ro...>
>>     http://www.rodsbooks.com
>>
>>
>>
>
> --
> Rod Smith
> rod...@ro...
> http://www.rodsbooks.com
>

Re: [Gptfdisk-general] GPT fdisk: problem with pre-existing Protective MBR when writing table to disk (w)

[Rod S. <rod...@ro...>]

On 01/25/2014 10:59 PM, Edwin wrote:
> Hi Rod,
>
> Thanks for your quick reply. Your explanation makes sense and it
> explains the error I got.
>
> Is there a way in gdisk to fix my MBR? In other words to set the
> non-compliant end-sector to the right value?

Yes; you just need to re-create the protective MBR. This can be done 
with the "n" option on the experts' menu.

> Actually you might be right about another cause. In hind-sight I did use
> the built-in windows disk management tool to shrink the windows
> partition. Should have thought of that earlier... also did not realize
> that would have changed the MBR but as you said that probably was the
> cause then.

The Windows partitioning tools have many problems, but I don't think 
I've heard of them creating invalid protective MBRs. I don't know 
offhand if they re-create or modify protective MBRs as a matter of 
course, the way GParted and parted do. Of course, this could be a new 
bug -- say, introduced in Windows 8.1.

FWIW, I've just revised gdisk to auto-correct this problem when loading 
the partition table, assuming everything else looks OK. If there are 
other problems when loading, a verify ("v" on any menu) operation should 
display a warning, and a write operation will also warn about the issue. 
The changes are in the GPT fdisk git repository, in case you want to 
check it out.

> On Sat, Jan 25, 2014 at 9:45 PM, Rod Smith <rod...@ro...
> <mailto:rod...@ro...>> wrote:
>
>     On 01/25/2014 10:17 PM, Edwin wrote:
>
>         When using gdisk on my disk (in the state as it was
>         pre-installed by OEM
>         for Windows 8) I encountered an error writing a new partition
>         table to
>         my disk with gdisk.
>
>         After creating new partitions and writing to disk (w) I get this
>         error:
>
>           >>Warning! An error was reported when writing the partition
>         table! This
>         error
>           >>MIGHT be harmless, or the disk might be damaged! Checking it is
>         advisable.
>
>         After a bit of debugging this turned out to be caused by
>         WriteMBRData
>         returning a failure code.
>
>         This is caused by one of the checks in WriteMBRData:
>         CreateExtended() -> IsLegal() -> DoTheyFit()
>
>         DoTheyFit() returns a failure in this case which is as far as I
>         can tell
>         due to the pre-existing protective MBR on my disk.
>
>         Printing the MBR using recovery (r) and (o) for the existing MBR
>         gives:
>
>           >>Recovery/transformation command (? for help): o
>           >>
>           >>Disk size is 1000215216 sectors (476.9 GiB)
>           >>MBR disk identifier: 0xB65D55C8
>           >>MBR partitions:
>           >>
>           >>Number  Boot  Start Sector   End Sector   Status      Code
>           >>   1                     1   4294967295   primary     0xEE
>
>
>         The End Sector being larger than the disk size causes the
>         DoTheyFit()
>         check to fail. Since I am not an expert in this area I am not
>         sure if it
>         is safe to remove this check.
>
>
>     No, it's not. Your protective MBR violates the GPT specification.
>     The GPT specification (on pp. 97-98 of the EFI 2.3.1 specification)
>     clearly states that the protective MBR's 0xEE partition should begin
>     on sector 1 and have a size of one minus the size of the disk, or
>     0xFFFFFFFF *if the disk is larger than can be represented in that
>     field*. Yours has that larger size but the disk is small enough that
>     a smaller protective MBR *should have* been used.
>
>     That said, gdisk could handle the problem better than it does. I'll
>     look into improving it.
>
>
>         It makes some sense to me to remove this
>         check since as far as I understand the protective MBR should
>         cover at
>         least the entire disk.
>
>
>     No; as I say, the spec doesn't permit the field to be larger than
>     the disk size.
>
>
>         In fact for the protective MBR a more logical
>         check might be to fail if End Sector is smaller than disk size?
>
>
>     That would fail for over-2TiB disks and for disks that use hybrid
>     MBRs. (The latter technically violate the GPT spec, but Apple uses
>     them heavily on Macs that dual-boot with Windows, and sometimes with
>     other OSes. Thus, gdisk supports hybrid MBRs.)
>
>
>         I assume that gdisk normally creates a new protective MBR on an
>         empty
>         disk exactly equal to the size of the disk?
>
>
>     On sub-2TiB disks, yes. On larger disks, it creates a 0xEE partition
>     of the maximum possible size, as per the spec.
>
>
>         Since this error made me nervous about the health of my disk/data at
>         first and since my OEM (Lenovo) delivered this MBR in this state
>         from
>         factory, this could probably happen to others as well. Therefore I
>         wanted to share my findings in the hope that others may benefit.
>
>
>     You might consider filing a bug report with Lenovo, since their
>     as-delivered protective MBR was defective. Be sure it was as
>     delivered, though; if you used some other tool to resize your
>     Windows partitions, THAT tool may have damaged the protective MBR.
>     (Because gdisk can't shrink filesystems and most OEMs deliver
>     computers with all but trivial amounts of disk space pre-allocated,
>     I suspect that you did use something else to resize at least one
>     partition.) Some tools create fresh protective MBRs as a matter of
>     course. GParted and parted both do this, for instance, although
>     these tools create protective MBRs with appropriately-sized 0xEE
>     partitions.
>
>     --
>     Rod Smith
>     rod...@ro... <mailto:rod...@ro...>
>     http://www.rodsbooks.com
>
>


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

Re: [Gptfdisk-general] [PATCH 0/1] Add partition GUIDs for the Open Network Install Environment project

[Rod S. <rod...@ro...>]

On 01/25/2014 01:13 PM, Curt Brune wrote:
> This patch adds two partition GUIDs for the Open Network Install
> Environment project.
>
> The choice of 0x3000 and 0x3001 was arbitrary.  From
> http://en.wikipedia.org/wiki/Partition_type I did not see an existing
> project using MBR type 0x30.
>
> The Open Network Install Environment (ONIE) is a software project
> under the umbrella of the Open Compute Project (OCP).
>
> ONIE comes pre-installed on bare metal network switches, providing a
> standard environment for installing network operating systems.  This
> opens the switch up to multiple network operating system vendors.
>
> References:
>   - http://www.onie.org/
>   - http://www.opencompute.org/assets/Uploads/ONIE-Open-Compute-Proposed-Charter-07082013-2.pdf

Thanks for the patch. I've tentatively accepted it, but I'd appreciate 
seeing a reference that identifies the GUIDs specifically (source code, 
a standards document, etc.).

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

Re: [Gptfdisk-general] GPT fdisk: problem with pre-existing Protective MBR when writing table to disk (w)

[Rod S. <rod...@ro...>]

On 01/25/2014 10:17 PM, Edwin wrote:
> When using gdisk on my disk (in the state as it was pre-installed by OEM
> for Windows 8) I encountered an error writing a new partition table to
> my disk with gdisk.
>
> After creating new partitions and writing to disk (w) I get this error:
>
>  >>Warning! An error was reported when writing the partition table! This
> error
>  >>MIGHT be harmless, or the disk might be damaged! Checking it is
> advisable.
>
> After a bit of debugging this turned out to be caused by WriteMBRData
> returning a failure code.
>
> This is caused by one of the checks in WriteMBRData:
> CreateExtended() -> IsLegal() -> DoTheyFit()
>
> DoTheyFit() returns a failure in this case which is as far as I can tell
> due to the pre-existing protective MBR on my disk.
>
> Printing the MBR using recovery (r) and (o) for the existing MBR gives:
>
>  >>Recovery/transformation command (? for help): o
>  >>
>  >>Disk size is 1000215216 sectors (476.9 GiB)
>  >>MBR disk identifier: 0xB65D55C8
>  >>MBR partitions:
>  >>
>  >>Number  Boot  Start Sector   End Sector   Status      Code
>  >>   1                     1   4294967295   primary     0xEE
>
>
> The End Sector being larger than the disk size causes the DoTheyFit()
> check to fail. Since I am not an expert in this area I am not sure if it
> is safe to remove this check.

No, it's not. Your protective MBR violates the GPT specification. The 
GPT specification (on pp. 97-98 of the EFI 2.3.1 specification) clearly 
states that the protective MBR's 0xEE partition should begin on sector 1 
and have a size of one minus the size of the disk, or 0xFFFFFFFF *if the 
disk is larger than can be represented in that field*. Yours has that 
larger size but the disk is small enough that a smaller protective MBR 
*should have* been used.

That said, gdisk could handle the problem better than it does. I'll look 
into improving it.

> It makes some sense to me to remove this
> check since as far as I understand the protective MBR should cover at
> least the entire disk.

No; as I say, the spec doesn't permit the field to be larger than the 
disk size.

> In fact for the protective MBR a more logical
> check might be to fail if End Sector is smaller than disk size?

That would fail for over-2TiB disks and for disks that use hybrid MBRs. 
(The latter technically violate the GPT spec, but Apple uses them 
heavily on Macs that dual-boot with Windows, and sometimes with other 
OSes. Thus, gdisk supports hybrid MBRs.)

> I assume that gdisk normally creates a new protective MBR on an empty
> disk exactly equal to the size of the disk?

On sub-2TiB disks, yes. On larger disks, it creates a 0xEE partition of 
the maximum possible size, as per the spec.

> Since this error made me nervous about the health of my disk/data at
> first and since my OEM (Lenovo) delivered this MBR in this state from
> factory, this could probably happen to others as well. Therefore I
> wanted to share my findings in the hope that others may benefit.

You might consider filing a bug report with Lenovo, since their 
as-delivered protective MBR was defective. Be sure it was as delivered, 
though; if you used some other tool to resize your Windows partitions, 
THAT tool may have damaged the protective MBR. (Because gdisk can't 
shrink filesystems and most OEMs deliver computers with all but trivial 
amounts of disk space pre-allocated, I suspect that you did use 
something else to resize at least one partition.) Some tools create 
fresh protective MBRs as a matter of course. GParted and parted both do 
this, for instance, although these tools create protective MBRs with 
appropriately-sized 0xEE partitions.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

Re: [Gptfdisk-general] GPT fdisk: problem with pre-existing Protective MBR when writing table to disk (w)

[Edwin <edw...@gm...>]

Hi Rod,

Thanks for your quick reply. Your explanation makes sense and it explains
the error I got.

Is there a way in gdisk to fix my MBR? In other words to set the
non-compliant end-sector to the right value?

Actually you might be right about another cause. In hind-sight I did use
the built-in windows disk management tool to shrink the windows partition.
Should have thought of that earlier... also did not realize that would have
changed the MBR but as you said that probably was the cause then.

Thanks,
Edwin


On Sat, Jan 25, 2014 at 9:45 PM, Rod Smith <rod...@ro...> wrote:

> On 01/25/2014 10:17 PM, Edwin wrote:
>
>> When using gdisk on my disk (in the state as it was pre-installed by OEM
>> for Windows 8) I encountered an error writing a new partition table to
>> my disk with gdisk.
>>
>> After creating new partitions and writing to disk (w) I get this error:
>>
>>  >>Warning! An error was reported when writing the partition table! This
>> error
>>  >>MIGHT be harmless, or the disk might be damaged! Checking it is
>> advisable.
>>
>> After a bit of debugging this turned out to be caused by WriteMBRData
>> returning a failure code.
>>
>> This is caused by one of the checks in WriteMBRData:
>> CreateExtended() -> IsLegal() -> DoTheyFit()
>>
>> DoTheyFit() returns a failure in this case which is as far as I can tell
>> due to the pre-existing protective MBR on my disk.
>>
>> Printing the MBR using recovery (r) and (o) for the existing MBR gives:
>>
>>  >>Recovery/transformation command (? for help): o
>>  >>
>>  >>Disk size is 1000215216 sectors (476.9 GiB)
>>  >>MBR disk identifier: 0xB65D55C8
>>  >>MBR partitions:
>>  >>
>>  >>Number  Boot  Start Sector   End Sector   Status      Code
>>  >>   1                     1   4294967295   primary     0xEE
>>
>>
>> The End Sector being larger than the disk size causes the DoTheyFit()
>> check to fail. Since I am not an expert in this area I am not sure if it
>> is safe to remove this check.
>>
>
> No, it's not. Your protective MBR violates the GPT specification. The GPT
> specification (on pp. 97-98 of the EFI 2.3.1 specification) clearly states
> that the protective MBR's 0xEE partition should begin on sector 1 and have
> a size of one minus the size of the disk, or 0xFFFFFFFF *if the disk is
> larger than can be represented in that field*. Yours has that larger size
> but the disk is small enough that a smaller protective MBR *should have*
> been used.
>
> That said, gdisk could handle the problem better than it does. I'll look
> into improving it.
>
>
>  It makes some sense to me to remove this
>> check since as far as I understand the protective MBR should cover at
>> least the entire disk.
>>
>
> No; as I say, the spec doesn't permit the field to be larger than the disk
> size.
>
>
>  In fact for the protective MBR a more logical
>> check might be to fail if End Sector is smaller than disk size?
>>
>
> That would fail for over-2TiB disks and for disks that use hybrid MBRs.
> (The latter technically violate the GPT spec, but Apple uses them heavily
> on Macs that dual-boot with Windows, and sometimes with other OSes. Thus,
> gdisk supports hybrid MBRs.)
>
>
>  I assume that gdisk normally creates a new protective MBR on an empty
>> disk exactly equal to the size of the disk?
>>
>
> On sub-2TiB disks, yes. On larger disks, it creates a 0xEE partition of
> the maximum possible size, as per the spec.
>
>
>  Since this error made me nervous about the health of my disk/data at
>> first and since my OEM (Lenovo) delivered this MBR in this state from
>> factory, this could probably happen to others as well. Therefore I
>> wanted to share my findings in the hope that others may benefit.
>>
>
> You might consider filing a bug report with Lenovo, since their
> as-delivered protective MBR was defective. Be sure it was as delivered,
> though; if you used some other tool to resize your Windows partitions, THAT
> tool may have damaged the protective MBR. (Because gdisk can't shrink
> filesystems and most OEMs deliver computers with all but trivial amounts of
> disk space pre-allocated, I suspect that you did use something else to
> resize at least one partition.) Some tools create fresh protective MBRs as
> a matter of course. GParted and parted both do this, for instance, although
> these tools create protective MBRs with appropriately-sized 0xEE partitions.
>
> --
> Rod Smith
> rod...@ro...
> http://www.rodsbooks.com
>

[Gptfdisk-general] GPT fdisk: problem with pre-existing Protective MBR when writing table to disk (w)

[Edwin <edw...@gm...>]

When using gdisk on my disk (in the state as it was pre-installed by OEM
for Windows 8) I encountered an error writing a new partition table to my
disk with gdisk.

Some info on my gdisk / partition:

>>GPT fdisk (gdisk) version 0.8.8
>>
>>Partition table scan:
>>  MBR: protective
>>  BSD: not present
>>  APM: not present
>>  GPT: present
>>
>>Found valid GPT with protective MBR; using GPT.

After creating new partitions and writing to disk (w) I get this error:

>>Command (? for help): w
>>
>>Final checks complete. About to write GPT data. THIS WILL OVERWRITE
EXISTING PARTITIONS!!
>>
>>Do you want to proceed? (Y/N): y
>>OK; writing new GUID partition table (GPT) to /dev/sda.
>>Warning! An error was reported when writing the partition table! This
error
>>MIGHT be harmless, or the disk might be damaged! Checking it is advisable.

After a bit of debugging this turned out to be caused by WriteMBRData
returning a failure code.

This is caused by one of the checks in WriteMBRData:
CreateExtended() -> IsLegal() -> DoTheyFit()

DoTheyFit() returns a failure in this case which is as far as I can tell
due to the pre-existing protective MBR on my disk.

Printing the MBR using recovery (r) and (o) for the existing MBR gives:

>>Recovery/transformation command (? for help): o
>>
>>Disk size is 1000215216 sectors (476.9 GiB)
>>MBR disk identifier: 0xB65D55C8
>>MBR partitions:
>>
>>Number  Boot  Start Sector   End Sector   Status      Code
>>   1                     1   4294967295   primary     0xEE


The End Sector being larger than the disk size causes the DoTheyFit() check
to fail. Since I am not an expert in this area I am not sure if it is safe
to remove this check. It makes some sense to me to remove this check since
as far as I understand the protective MBR should cover at least the entire
disk. In fact for the protective MBR a more logical check might be to fail
if End Sector is smaller than disk size?

I assume that gdisk normally creates a new protective MBR on an empty disk
exactly equal to the size of the disk?

Since this error made me nervous about the health of my disk/data at first
and since my OEM (Lenovo) delivered this MBR in this state from factory,
this could probably happen to others as well. Therefore I wanted to share
my findings in the hope that others may benefit.

Best regards,
Edwin

(I am not subscribed to the mailing list so if you need more information
please e-mail me directly)

[Gptfdisk-general] [PATCH 1/1] Add Open Network Install Environment (ONIE) partition types

[Curt B. <cu...@cu...>]

Add GUIDs for two ONIE partition types:

   // Open Network Install Environment (ONIE) Boot Partition
   AddType(0x3000, "7412F7D5-A156-4B13-81DC-867174929325", "ONIE boot");

   // Open Network Install Environment (ONIE) Configuration Partition
   AddType(0x3000, "D4E6E2CD-4469-46F3-B5CB-1BFF57AFC149", "ONIE config");

Using standard GUIDs allows the ONIE self-updater to recoginize its
own partitions.

Signed-off-by: Curt Brune <cu...@cu...>
---
 parttypes.cc |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/parttypes.cc b/parttypes.cc
index 87f5c86..f78489b 100644
--- a/parttypes.cc
+++ b/parttypes.cc
@@ -89,10 +89,15 @@ void PartType::AddAllTypes(void) {
    AddType(0x1b00, "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "Microsoft basic data", 0); // Hidden FAT-32
    AddType(0x1c00, "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "Microsoft basic data", 0); // Hidden FAT-32 LBA
    AddType(0x1e00, "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "Microsoft basic data", 0); // Hidden FAT-16 LBA
    AddType(0x2700, "DE94BBA4-06D1-4D40-A16A-BFD50179D6AC", "Windows RE");
 
+   // Open Network Install Environment (ONIE) specific types.
+   // See http://www.onie.org/
+   AddType(0x3000, "7412F7D5-A156-4B13-81DC-867174929325", "ONIE boot");
+   AddType(0x3001, "D4E6E2CD-4469-46F3-B5CB-1BFF57AFC149", "ONIE config");
+
    // PowerPC reference platform boot partition
    AddType(0x4100, "9E1A2D38-C612-4316-AA26-8B49521E5A8B", "PowerPC PReP boot");
 
    // Windows LDM ("dynamic disk") types
    AddType(0x4200, "AF9B60A0-1431-4F62-BC68-3311714A69AD", "Windows LDM data"); // Logical disk manager
-- 
1.7.10.4

[Gptfdisk-general] [PATCH 0/1] Add partition GUIDs for the Open Network Install Environment project

[Curt B. <cu...@cu...>]

This patch adds two partition GUIDs for the Open Network Install
Environment project.

The choice of 0x3000 and 0x3001 was arbitrary.  From
http://en.wikipedia.org/wiki/Partition_type I did not see an existing
project using MBR type 0x30.

The Open Network Install Environment (ONIE) is a software project
under the umbrella of the Open Compute Project (OCP).

ONIE comes pre-installed on bare metal network switches, providing a
standard environment for installing network operating systems.  This
opens the switch up to multiple network operating system vendors.

References: 
 - http://www.onie.org/
 - http://www.opencompute.org/assets/Uploads/ONIE-Open-Compute-Proposed-Charter-07082013-2.pdf

Curt Brune (1):
  Add Open Network Install Environment (ONIE) partition types

 parttypes.cc |    5 +++++
 1 file changed, 5 insertions(+)

-- 
1.7.10.4

[Gptfdisk-general] Fixing problem resizing raid disks

[Frediano Z. <fre...@ci...>]

Hi,
  I found a nasty problem using -Z option in some cases if raid type is
change. The reason is that usually when you change raid type only first
part get cleaned so you end up with GPT backup copy (at end) still
present but at different location.

Imaging you have a RAID0 disk with 2 disk so you have clusters
alternated with last cluster ending at disk #2 containing the backup
GPT. You destroy the RAID and create another RAID0 with 4 disks. If disk
#2 now is disk #4 (last) of new RAID you end up with last cluster
containing the old GPT. However the LBA information still point to old
location which now point at the middle of the disk while protective MBR
and main GPT cleared. In this situation doing a --zap-all command gdisk
try to load GPTs headers finding the backup. Then it try to zero them
using LBA informations just read so it clear some sectors in the middle
of the disk. The result if that disk is not cleared correctly.

The patch fix LBA addresses before writing zeroes clearing correct
locations.

Frediano

Re: [Gptfdisk-general] Makefile Patch

[Bruce D. <bru...@gm...>]

Antoine Leca wrote:
> Bruce Dubbs wrote:
>> I'd like to suggest updating the Makefile.
> Can you explain why you want this project to use GNU make features, when
> it did not before?
>
> Not that it is not wrong to do so, just that it is a change which is
> worth mentioning since it cut compatibility (at least with BSD make, and
> to a lesser degree with POSIX make and Microsoft nmake), and which IMHO
> should warrant some documented reason.
>
> Also, perhaps it would be nicer for the path to the destination man page
> and program to be indexed by configurable variables like are CC, CFLAGS
> etc. (also perhaps consider replacing cp with ${INSTALL})

I'm not familiar with the limitations of the other make implementations, 
but since that's an issue, it would be nice if someone who is could 
implement the principles of the submitted patch.

   -- Bruce

Re: [Gptfdisk-general] Makefile Patch

[Antoine L. <Ant...@us...>]

Bruce Dubbs wrote:
> I'd like to suggest updating the Makefile.
Can you explain why you want this project to use GNU make features, when
it did not before?

Not that it is not wrong to do so, just that it is a change which is
worth mentioning since it cut compatibility (at least with BSD make, and
to a lesser degree with POSIX make and Microsoft nmake), and which IMHO
should warrant some documented reason.

Also, perhaps it would be nicer for the path to the destination man page
and program to be indexed by configurable variables like are CC, CFLAGS
etc. (also perhaps consider replacing cp with ${INSTALL})


Antoine

[Gptfdisk-general] Makefile Patch

[Bruce D. <bru...@gm...>]

I'd like to suggest updating the Makefile.  See 
http://www.linuxfromscratch.org/blfs/view/svn/postlfs/gptfdisk.html

   -- Bruce

[Gptfdisk-general] Devices on Debian GNU/kFreeBSD are character devices

[Guillaume D. <gu...@ir...>]

Hello,

A Debian user [0] reported an issue with Debian GNU/kFreeBSD (wrongly
not considered as FreeBSD system): please find attached a patch that fix
it on version 0.8.7.

[0]: http://bugs.debian.org/696813

-- 
Guillaume Delacour <gu...@ir...>

Re: [Gptfdisk-general] gdisk 32-bit overflow bug on >2TB disks

[Rod S. <rod...@ro...>]

On 04/19/2013 06:25 PM, Sage Weil wrote:
> Hi-
>
> We hit a bug on sgdisk where it would create a new partition of the
> wrong size, apparently due to a 32-bit field used in the partition
> creating/sizing code.  It appears to trigger when we use syntax like
>
> 2:-${size}M:0
>
> Switching to
>
> 2:0:${size}
>
> does not have the same problem.
>
> See this bug for details:
>
> http://tracker.ceph.com/issues/4757
>
> It wasn't immediately obvious if this was fixed in a newer version
> (we're on ubuntu precise, 0.8.1-1build1).

Please try using the latest version (0.8.6). Version 0.8.1 is OLD -- it
was released 1.5 years ago! Also, version 0.8.3 fixed what sounds like
the problem you're reporting; from
http://www.rodsbooks.com/gdisk/revisions.html:

: 0.8.3 (3/23/2012)—This version offers a few minor improvements and
: bug fixes. The gdisk program now states the name of the disk that's
: been modified after a write operation, and a bug has been fixed that
: caused sgdisk to incorrectly truncate the sizes of over-2TiB
: partitions on 32-bit (but not 64-bit) systems. This version also
: improves the handling of Ctrl+D on some systems and includes a fix to
: enable proper compilation under GCC 4.7.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] gdisk 32-bit overflow bug on >2TB disks

[Sage W. <sa...@in...>]

Hi-

We hit a bug on sgdisk where it would create a new partition of the wrong 
size, apparently due to a 32-bit field used in the partition 
creating/sizing code.  It appears to trigger when we use syntax like

 2:-${size}M:0

Switching to

 2:0:${size}

does not have the same problem.

See this bug for details:

	http://tracker.ceph.com/issues/4757

It wasn't immediately obvious if this was fixed in a newer version (we're 
on ubuntu precise, 0.8.1-1build1).

Thanks!
sage

Re: [Gptfdisk-general] sgdisk and Hybrid without prepend of EFI partition support

[Mario F. <mar...@gm...>]

The u-boot from these nas devices is not that cracy it just loads the
uImage from the partiton that is marked as the first in MBR nothing more
my request is to get sgdisk to support this (gdisk can do this already
commands from gdisk r h 1 n 83 y n w y) the important part is the first n
in this command sequence "Place EFI GPT (0xEE) partition first in MBR (good
for GRUB)? (Y/N):" this way it becomes the first after the speciefd to
adapt gpt parts. omly the first part of the mbr is the importatnt and ist
also the only one that got to the mbr


2012/11/22 Antoine Leca <Ant...@us...>

> Mario Fetka wrote:
> > small correction
> > fidsk sees it like that when i use the pipe version
> >
> >
> --------------------------------------------------------------------------
> >    Device Boot      Start         End      Blocks   Id  System
> > /dev/sda1   *        2048      616447      307200   83  Linux
> > /dev/sda4               1        2047        1023+  ee  GPT
> >
> > Partition table entries are not in disk order
> >
> > ------------------------------------------------------
> >
> > but sgdisk -h 1
> >
> > creates
> >
> > -------------------------------------------------------------
> > Command (m for help): p
> >    Device Boot      Start         End      Blocks   Id  System
> > /dev/sda1               1        2047        1023+  ee  GPT
> > /dev/sda2            2048      616447      307200   83  Linux
> >
> >
> >
> > and with this the u-boot of the device finds the GPT as first part and
> this
> > is not working
> > my request was the posiblity to change this also for the sgdisk so that i
> > can say the ee GPT disk is not part 1 in mbr
> >
> This can be awfully complex, and I wonder how can semi-complex cases
> could be sorted (and of course, if things are not crystal clear at
> design time, the probabilities for bugs + misuses are increasing
> steadily...)
>
> For an example, taking your case slightly edited, consider
>
> GenLSPro ~ # sgdisk -p /dev/sda
> Disk /dev/sda: 195371568 sectors, 93.2 GiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): xxxx-yyyyy...
> Partition table holds up to 128 entries
> First usable sector is 34, last usable sector is 195371534
> Partitions will be aligned on 2048-sector boundaries
> Total free space is 2541 sectors (1240.7 KiB)
>
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1            2048          616447 300.0 MiB   8300  Linux filesystem
>    2          616448       168388607   80.0 GiB    8300  Linux filesystem
>    3       168388608       170485759   1024.0 MiB  8200  Linux swap
>    4       170485760       195371007   11.9 GiB    8300  Linux filesystem
>
> (I rounded down sd4's size.) There are nine distinct areas across the disk:
> Number  Start (sector)    End (sector)  Size       Code  Name
>  a                 0               1                     MBR
>  b                 1              33                     GPTable
>  c                34            2047                     free space
>    1            2048          616447 300.0 MiB   8300  Linux filesystem
>    2          616448       168388607   80.0 GiB    8300  Linux filesystem
>    3       168388608       170485759   1024.0 MiB  8200  Linux swap
>    4       170485760       195371007   11.9 GiB    8300  Linux filesystem
>  d         195371008       195371534                     free space
>  e         195371535       195371567                     alternate GPTable
>
> Now, on what criteria could it be decided that using `sgdisk -H 1` makes
> area {a+b+c} to be covered under entry #4 typed EE, while the area
> {2+3+4+d+e} would not be covered? Why not {a+b} instead? Why to not have
> two EE entries (like some hybrid-making tools are already doing?)
>
> Same questions with `sgdisk -H 2`: should the #4 EE entry covers {a+b+c},
> or {a+b+c+1}? Why?
>
> And what to do when the command is `sgdisk -H 4:2` ?
> I guess the best answer is "Overtricky, giving up"...
>
>
> Antoine
>

Re: [Gptfdisk-general] sgdisk and Hybrid without prepend of EFI partition support

[Antoine L. <Ant...@us...>]

Mario Fetka wrote:
> small correction
> fidsk sees it like that when i use the pipe version
>
> --------------------------------------------------------------------------
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1   *        2048      616447      307200   83  Linux
> /dev/sda4               1        2047        1023+  ee  GPT
>
> Partition table entries are not in disk order
>
> ------------------------------------------------------
>
> but sgdisk -h 1
>
> creates
>
> -------------------------------------------------------------
> Command (m for help): p
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1               1        2047        1023+  ee  GPT
> /dev/sda2            2048      616447      307200   83  Linux
>
>
>
> and with this the u-boot of the device finds the GPT as first part and this
> is not working
> my request was the posiblity to change this also for the sgdisk so that i
> can say the ee GPT disk is not part 1 in mbr
>
This can be awfully complex, and I wonder how can semi-complex cases
could be sorted (and of course, if things are not crystal clear at
design time, the probabilities for bugs + misuses are increasing
steadily...)

For an example, taking your case slightly edited, consider

GenLSPro ~ # sgdisk -p /dev/sda
Disk /dev/sda: 195371568 sectors, 93.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): xxxx-yyyyy...
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 195371534
Partitions will be aligned on 2048-sector boundaries
Total free space is 2541 sectors (1240.7 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447   300.0 MiB   8300  Linux filesystem
   2          616448       168388607   80.0 GiB    8300  Linux filesystem
   3       168388608       170485759   1024.0 MiB  8200  Linux swap
   4       170485760       195371007   11.9 GiB    8300  Linux filesystem

(I rounded down sd4's size.) There are nine distinct areas across the disk:
Number  Start (sector)    End (sector)  Size       Code  Name
 a                 0               1                     MBR
 b                 1              33                     GPTable
 c                34            2047                     free space
   1            2048          616447   300.0 MiB   8300  Linux filesystem
   2          616448       168388607   80.0 GiB    8300  Linux filesystem
   3       168388608       170485759   1024.0 MiB  8200  Linux swap
   4       170485760       195371007   11.9 GiB    8300  Linux filesystem
 d         195371008       195371534                     free space
 e         195371535       195371567                     alternate GPTable

Now, on what criteria could it be decided that using `sgdisk -H 1` makes area {a+b+c} to be covered under entry #4 typed EE, while the area {2+3+4+d+e} would not be covered? Why not {a+b} instead? Why to not have two EE entries (like some hybrid-making tools are already doing?)

Same questions with `sgdisk -H 2`: should the #4 EE entry covers {a+b+c}, or {a+b+c+1}? Why?

And what to do when the command is `sgdisk -H 4:2` ?
I guess the best answer is "Overtricky, giving up"...


Antoine

Re: [Gptfdisk-general] sgdisk and Hybrid without prepend of EFI partition support

[Mario F. <mar...@gm...>]

small correction
fidsk sees it like that when i use the pipe version

--------------------------------------------------------------------------
GenLSPro ~ # fdisk /dev/sda
Welcome to fdisk (util-linux 2.22.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk
doesn't support GPT. Use GNU Parted.


Command (m for help): p

Disk /dev/sda: 100.0 GB, 100030242816 bytes, 195371568 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      616447      307200   83  Linux
/dev/sda4               1        2047        1023+  ee  GPT

Partition table entries are not in disk order

Command (m for help):

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

but sgdisk -h 1

creates

-------------------------------------------------------------
GenLSPro ~ # fdisk /dev/sda
Welcome to fdisk (util-linux 2.22.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk
doesn't support GPT. Use GNU Parted.


Command (m for help): p

Disk /dev/sda: 100.0 GB, 100030242816 bytes, 195371568 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        2047        1023+  ee  GPT
/dev/sda2            2048      616447      307200   83  Linux

Command (m for help): ^C



and with this the u-boot of the device finds the GPT as first part and this
is not working
my request was the posiblity to change this also for the sgdisk so that i
can say the ee GPT disk is not part 1 in mbr
(yes my explanation was not good)


2012/11/21 Mario Fetka <mar...@gm...>

> i am in the process of creating a gentoo based distributin for Buffalo nas
> devices from the version of MBR based u-boot to the new versions that only
> support GPT partitions. beacuase of the "be cost effevtive" these devices
> onyl support most of the times only mbr or gpt (small flash rom 512kb)
> i dont want to stress on creating 2 different versions of the disk images
> one for the old and one for the new devices
> so i use the hybrid and it works great
> let the first part appear as mbr and then linux will work on as gpt
> and the gpt based also work
> mbr is a woraround these old u-boot boot managers
>
> for ex
>
> GenLSPro ~ # sgdisk -p /dev/sda
> Disk /dev/sda: 195371568 sectors, 93.2 GiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): 45311E30-AEFA-454F-9A1A-E5DC2632D0D0
> Partition table holds up to 128 entries
> First usable sector is 34, last usable sector is 195371534
> Partitions will be aligned on 2048-sector boundaries
> Total free space is 2014 sectors (1007.0 KiB)
>
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1            2048          616447   300.0 MiB   8300  Linux filesystem
>    2          616448       168388607   80.0 GiB    8300  Linux filesystem
>    3       168388608       170485759   1024.0 MiB  8200  Linux swap
>    4       170485760       195371534   11.9 GiB    8300  Linux filesystem
>
>
> GenLSPro ~ # fdisk /dev/sda
> Welcome to fdisk (util-linux 2.22.1).
>
> Changes will remain in memory only, until you decide to write them.
>  Be careful before using the write command.
>
>
> WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk
> doesn't support GPT. Use GNU Parted.
>
>
> Command (m for help): p
>
> Disk /dev/sda: 100.0 GB, 100030242816 bytes, 195371568 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1   *        2048      616447      307200   83  Linux
>
> Partition table entries are not in disk order
>
> Command (m for help):
>
> yes its a special case but would simplyfy my automatic image creatin
> process
> now i am piping and its only working 2 of 3 times
> r
> h
> 1
> n
> 83
> y
> n
> w
> y | gdisk /dev/sda
>
>
> 2012/11/21 Rod Smith <rod...@ro...>
>
>> On 11/21/2012 06:45 AM, Mario Fetka wrote:
>> > sgdisk when run with -h to create a Hybrid part/tables will always add
>> > an EFI part bevore the specified partitons
>> > a EFI part is not needed on arm devices
>> >
>> > could you plz add for ex
>> >
>> > -H, --hybrid-noefi=partnum[:partnum...]
>> >                                create hybrid MBR without prepended EFI
>>
>> If I understand correctly, you're saying that you've got an ARM device
>> that will recognize a GPT disk even without a 0xEE protective partition
>> in the MBR. I've never before heard of an OS or utility that would
>> interpret a disk as GPT even when it's lacking a 0xEE protective MBR
>> partition. I'm reluctant to add support for creating such disks because
>> so many other OSes and utilities will NOT interpret them as you might
>> expect, so this will just end up creating more problems, beyond those
>> that hybrid MBRs already create.
>>
>> If you can point me to more detailed documentation of what can actually
>> use such an extreme configuration and why it might be helpful, I might
>> reconsider this decision.
>>
>> --
>> Rod Smith
>> rod...@ro...
>> http://www.rodsbooks.com
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Gptfdisk-general mailing list
>> Gpt...@li...
>> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general
>>
>
>

Re: [Gptfdisk-general] sgdisk and Hybrid without prepend of EFI partition support

[Mario F. <mar...@gm...>]

i am in the process of creating a gentoo based distributin for Buffalo nas
devices from the version of MBR based u-boot to the new versions that only
support GPT partitions. beacuase of the "be cost effevtive" these devices
onyl support most of the times only mbr or gpt (small flash rom 512kb)
i dont want to stress on creating 2 different versions of the disk images
one for the old and one for the new devices
so i use the hybrid and it works great
let the first part appear as mbr and then linux will work on as gpt
and the gpt based also work
mbr is a woraround these old u-boot boot managers

for ex

GenLSPro ~ # sgdisk -p /dev/sda
Disk /dev/sda: 195371568 sectors, 93.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 45311E30-AEFA-454F-9A1A-E5DC2632D0D0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 195371534
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          616447   300.0 MiB   8300  Linux filesystem
   2          616448       168388607   80.0 GiB    8300  Linux filesystem
   3       168388608       170485759   1024.0 MiB  8200  Linux swap
   4       170485760       195371534   11.9 GiB    8300  Linux filesystem


GenLSPro ~ # fdisk /dev/sda
Welcome to fdisk (util-linux 2.22.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk
doesn't support GPT. Use GNU Parted.


Command (m for help): p

Disk /dev/sda: 100.0 GB, 100030242816 bytes, 195371568 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      616447      307200   83  Linux

Partition table entries are not in disk order

Command (m for help):

yes its a special case but would simplyfy my automatic image creatin process
now i am piping and its only working 2 of 3 times
r
h
1
n
83
y
n
w
y | gdisk /dev/sda


2012/11/21 Rod Smith <rod...@ro...>

> On 11/21/2012 06:45 AM, Mario Fetka wrote:
> > sgdisk when run with -h to create a Hybrid part/tables will always add
> > an EFI part bevore the specified partitons
> > a EFI part is not needed on arm devices
> >
> > could you plz add for ex
> >
> > -H, --hybrid-noefi=partnum[:partnum...]
> >                                create hybrid MBR without prepended EFI
>
> If I understand correctly, you're saying that you've got an ARM device
> that will recognize a GPT disk even without a 0xEE protective partition
> in the MBR. I've never before heard of an OS or utility that would
> interpret a disk as GPT even when it's lacking a 0xEE protective MBR
> partition. I'm reluctant to add support for creating such disks because
> so many other OSes and utilities will NOT interpret them as you might
> expect, so this will just end up creating more problems, beyond those
> that hybrid MBRs already create.
>
> If you can point me to more detailed documentation of what can actually
> use such an extreme configuration and why it might be helpful, I might
> reconsider this decision.
>
> --
> Rod Smith
> rod...@ro...
> http://www.rodsbooks.com
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Gptfdisk-general mailing list
> Gpt...@li...
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general
>

Re: [Gptfdisk-general] sgdisk and Hybrid without prepend of EFI partition support

[Rod S. <rod...@ro...>]

On 11/21/2012 06:45 AM, Mario Fetka wrote:
> sgdisk when run with -h to create a Hybrid part/tables will always add
> an EFI part bevore the specified partitons
> a EFI part is not needed on arm devices
>
> could you plz add for ex
>
> -H, --hybrid-noefi=partnum[:partnum...]
>                                create hybrid MBR without prepended EFI

If I understand correctly, you're saying that you've got an ARM device 
that will recognize a GPT disk even without a 0xEE protective partition 
in the MBR. I've never before heard of an OS or utility that would 
interpret a disk as GPT even when it's lacking a 0xEE protective MBR 
partition. I'm reluctant to add support for creating such disks because 
so many other OSes and utilities will NOT interpret them as you might 
expect, so this will just end up creating more problems, beyond those 
that hybrid MBRs already create.

If you can point me to more detailed documentation of what can actually 
use such an extreme configuration and why it might be helpful, I might 
reconsider this decision.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] sgdisk and Hybrid without prepend of EFI partition support

[Mario F. <mar...@gm...>]

sgdisk when run with -h to create a Hybrid part/tables will always add an
EFI part bevore the specified partitons
a EFI part is not needed on arm devices

could you plz add for ex

-H, --hybrid-noefi=partnum[:partnum...]
                          create hybrid MBR without prepended EFI


thx
Mario

[Gptfdisk-general] Haiku GUID patch

[kallisti5 <kal...@un...>]

The Haiku project has defined a new GUID to identify it's GPT partition 
table entries.

Attached is a patch to the latest gptfdisk code to utilize this new 
GUID.

You can verify the same GUID in our code:
http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/partitioning_systems/efi/efi_gpt.cpp#n48

And on Wikipedia (not really hard proof :) )
https://en.wikipedia.org/wiki/GUID_Partition_Table

The 0xeb00 is the old BeOS partition type we generally use on MBR 
systems.

Thanks!

  -- Alex

[Gptfdisk-general] Should gdisk read optimal_io_size on Linux?

[Andy L. <lu...@am...>]

/sys/block/md0/queue/optimal_io_size says 2097152 (due to the raid
chunk size), but gdisk still defaults to 2048-sector alignment.  It
would be nice if it read optimal_io_size and increased its alignment
accordingly.

Re: [Gptfdisk-general] cgdisk: blank disk warning confusing (wishlist)

[David L. <lio...@co...>]

On 7/31/12 6:07 AM, notstop wrote:
> On 31/07/2012 13:16, David Liontooth wrote:
>> When I use gdisk on a new disk, it correctly detects there is nothing there:
>>
>> # gdisk /dev/sdae
>> GPT fdisk (gdisk) version 0.8.5
>>
>> Partition table scan:
>>      MBR: not present
>>      BSD: not present
>>      APM: not present
>>      GPT: not present
>>
>> Creating new GPT entries.
>>
>> Command (? for help):
>>
>> (Incidentally, the message "Creating new GPT entries" is confusing;
>> presumably the program does nothing until asked.
>> A better wording might be "Ready to create new GPT entries.")
> I think would be better to say "GTP partition created / modified.
> Remember to write changes to disk!"

Wait -- this is before making any changes at all; I'm talking about the 
message on the "welcome screen".

Dave

Re: [Gptfdisk-general] cgdisk: blank disk warning confusing (wishlist)

[notstop <no...@li...>]

On 31/07/2012 13:16, David Liontooth wrote:
>
> When I use gdisk on a new disk, it correctly detects there is nothing there:
>
> # gdisk /dev/sdae
> GPT fdisk (gdisk) version 0.8.5
>
> Partition table scan:
>     MBR: not present
>     BSD: not present
>     APM: not present
>     GPT: not present
>
> Creating new GPT entries.
>
> Command (? for help):
>
> (Incidentally, the message "Creating new GPT entries" is confusing;
> presumably the program does nothing until asked.
> A better wording might be "Ready to create new GPT entries.")
>
> In contrast, when I use cgdisk 0.8.5 on the same new disk, I get a loud
> warning:
>
> cgdisk /dev/sdae
>
> Warning! Non-GPT or damaged disk detected! This program will attempt to
> convert to GPT form or repair damage to GPT data structures, but may not
> succeed. Use gdisk or another disk repair tool if you have a damaged GPT
> disk.
>
>
> Wishlist: cgdisk should not needlessly induce heart attacks, but like
> gdisk confidently recognize a blank disk.
>
> Cheers,
> Dave
>

I think would be better to say "GTP partition created / modified. 
Remember to write changes to disk!"