gptfdisk-general — General discussions of GPT fdisk

[Gptfdisk-general] [PATCH 0/4] Fix some assorted bugs noticed when running sgdisk on a beaglebone black (32bit arm)

[Cody P S. <de...@co...>]

 "IeeeToInt: initialize suffix" fixes an issue where sgdisk would occasionally
try to create partitions that started very far into the disk.

  "Always use off64_t to avoid overflow issues" fixes an issue on 32bit when
CFLAGS are overridden and as a result _FILE_OFFSET_BITS is not passed. Note
that with this change, I don't think we actually need to pass _FILE_OFFSET_BITS
any more.

  "if there is any error, report it via return value" ensures that if there is
an error writing data, the command does not return success, hiding it's failure
until later in the calling script.

  "seek: detect and complain about seek overflows" fixes a theoretical issue
related to the off64_t issue fixed above. I haven't actually triggered the bug
this fixes, though.

Cody P Schafer (4):
  IeeeToInt: initialize suffix
  if there is any error, report it via return value
  Always use off64_t to avoid overflow issues
  seek: detect and complain about seek overflows

 diskio-unix.cc | 11 ++++++++---
 gptcl.cc       |  5 ++++-
 support.cc     |  2 +-
 3 files changed, 13 insertions(+), 5 deletions(-)

-- 
2.4.3

[Gptfdisk-general] [PATCH 3/4] Always use off64_t to avoid overflow issues

[Cody P S. <de...@co...>]

---
 diskio-unix.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/diskio-unix.cc b/diskio-unix.cc
index 7be0bbe..71b4387 100644
--- a/diskio-unix.cc
+++ b/diskio-unix.cc
@@ -272,7 +272,7 @@ int DiskIO::DiskSync(void) {
 // Note that seeking beyond the end of the file is NOT detected as a failure!
 int DiskIO::Seek(uint64_t sector) {
    int retval = 1;
-   off_t seekTo, sought;
+   off64_t seekTo, sought;
 
    // If disk isn't open, try to open it....
    if (!isOpen) {
@@ -389,7 +389,7 @@ int DiskIO::Write(void* buffer, int numBytes) {
 // return correct values for disk image files.
 uint64_t DiskIO::DiskSize(int *err) {
    uint64_t sectors = 0; // size in sectors
-   off_t bytes = 0; // size in bytes
+   off64_t bytes = 0; // size in bytes
    struct stat64 st;
    int platformFound = 0;
 #ifdef __sun__
-- 
2.4.3

[Gptfdisk-general] [PATCH 2/4] if there is any error, report it via return value

[Cody P S. <de...@co...>]

---
 gptcl.cc | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gptcl.cc b/gptcl.cc
index 94709ec..7232a02 100644
--- a/gptcl.cc
+++ b/gptcl.cc
@@ -463,7 +463,10 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) {
          retval = 2;
       } // if/else loaded OK
       if ((saveData) && (!neverSaveData) && (saveNonGPT) && (!pretend)) {
-         SaveGPTData(1);
+         if (!SaveGPTData(1)) {
+            cout << "Error encountered; partial data may be written";
+            retval = 5;
+         }
       }
       if (saveData && (!saveNonGPT)) {
          cout << "Non-GPT disk; not saving changes. Use -g to override.\n";
-- 
2.4.3

[Gptfdisk-general] [PATCH 4/4] seek: detect and complain about seek overflows

[Cody P S. <de...@co...>]

---
 diskio-unix.cc | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/diskio-unix.cc b/diskio-unix.cc
index 71b4387..4a835a5 100644
--- a/diskio-unix.cc
+++ b/diskio-unix.cc
@@ -280,7 +280,12 @@ int DiskIO::Seek(uint64_t sector) {
    } // if
 
    if (isOpen) {
-      seekTo = sector * (uint64_t) GetBlockSize();
+      uint64_t b = (uint64_t) GetBlockSize();
+      if (UINT64_MAX / b <= sector) {
+         cerr << "Overflow in seek calculation: " << b << " * " << sector << endl;
+         return 0;
+      }
+      seekTo = sector * b;
       sought = lseek64(fd, seekTo, SEEK_SET);
       if (sought != seekTo) {
          retval = 0;
-- 
2.4.3

[Gptfdisk-general] [PATCH 1/4] IeeeToInt: initialize suffix

[Cody P S. <de...@co...>]

---
 support.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/support.cc b/support.cc
index 0833a3e..7a6354d 100644
--- a/support.cc
+++ b/support.cc
@@ -144,7 +144,7 @@ uint64_t GetSectorNum(uint64_t low, uint64_t high, uint64_t def, uint64_t sSize,
 uint64_t IeeeToInt(string inValue, uint64_t sSize, uint64_t low, uint64_t high, uint64_t def) {
    uint64_t response = def, bytesPerUnit = 1, mult = 1, divide = 1;
    size_t foundAt = 0;
-   char suffix, plusFlag = ' ';
+   char suffix = ' ', plusFlag = ' ';
    string suffixes = "KMGTPE";
    int badInput = 0; // flag bad input; once this goes to 1, other values are irrelevant
 
-- 
2.4.3

Re: [Gptfdisk-general] [PATCH] Add partition type GUIDs for encrypted Linux partitions

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

On 05/30/2015 12:41 PM, Daniel Milewski wrote:
> I saw them missing in gptfdisk. Here are the resources I took
> these types from:

The type codes you're suggesting be added were proposed on a mailing
list over a year ago:

http://www.saout.de/pipermail/dm-crypt/2014-January/thread.html#3855

I believe it was also posted to the parted mailing list, and maybe
even here.

The trouble is that the response from Linux developers was
overwhelmingly negative. No Linux developer found the case for the
existence of such a code to be compelling, and the redundant
information poses a risk of getting out of sync with actual partition
contents. No Linux partitioning tool or encryption utility actually
uses those codes. I just did a Google search and found no evidence of
greater acceptance since the code was proposed.

Furthermore, although the number of GUIDs is huge, supporting every
possible code somebody might dream up is impractical for GPT fdisk,
because it increases the size of the list shown when a user types "L"
to get that code list. An increased list size makes it harder to find
the codes that are actually being used, so supporting these codes
would degrade GPT fdisk's user interface experience.

Thus, unless and until I learn that these codes are actually being
used, I will not add them to GPT fdisk's code list. An individual who
wants to use them may still do so by entering the GUID value directly,
but there's really very little benefit to this. From a user interface
perspective, the partition description is a more flexible way to
identify the partition's purpose for humans. The type codes are most
useful for OSes and utilities.

> * 
> https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
>
> 
* https://en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs
> 
> I think they are reliable since they link to the previous
> discussion on the dm-crypt mailing list.
> 
> diff -ruN gptfdisk-1.0.0.original/parttypes.cc
> gptfdisk-1.0.0/parttypes.cc ---
> gptfdisk-1.0.0.original/parttypes.cc        2015-03-17
> 23:50:38.000000000 +0100 +++ gptfdisk-1.0.0/parttypes.cc 2015-05-30
> 17:06:36.976927570 +0200 @@ -203,6 +203,10 @@ AddType(0xc001,
> "75894C1E-3AEB-11D3-B7C1-7B03A0000000", "HP-UX data"); 
> AddType(0xc002, "E2A1E728-32E3-11D6-A682-7B03A0000000", "HP-UX
> service");
> 
> +   // Encrypted Linux partitions +   AddType(0xe800,
> "CA7D7CCB-63ED-4C53-861C-1742536059CC", "Linux LUKS"); +
> AddType(0xe801, "7FFEC5C9-2D00-49B7-8941-3EA10A5586B7", "Linux
> dm-crypt"); + // See
> http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec 
> AddType(0xea00, "BC13C2FF-59E6-4262-A352-B275FD6F7172",
> "Freedesktop $BOOT");
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
> 
> 
> _______________________________________________ Gptfdisk-general
> mailing list Gpt...@li... 
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general
> 


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

[Gptfdisk-general] [PATCH] Add partition type GUIDs for encrypted Linux partitions

[Daniel M. <nii...@ri...>]

I saw them missing in gptfdisk. Here are the resources I took these
types from:

* 
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
* https://en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs

I think they are reliable since they link to the previous discussion on
the dm-crypt mailing list.

diff -ruN gptfdisk-1.0.0.original/parttypes.cc gptfdisk-1.0.0/parttypes.cc
--- gptfdisk-1.0.0.original/parttypes.cc        2015-03-17 23:50:38.000000000 +0100
+++ gptfdisk-1.0.0/parttypes.cc 2015-05-30 17:06:36.976927570 +0200
@@ -203,6 +203,10 @@
    AddType(0xc001, "75894C1E-3AEB-11D3-B7C1-7B03A0000000", "HP-UX data");
    AddType(0xc002, "E2A1E728-32E3-11D6-A682-7B03A0000000", "HP-UX service");
 
+   // Encrypted Linux partitions
+   AddType(0xe800, "CA7D7CCB-63ED-4C53-861C-1742536059CC", "Linux LUKS");
+   AddType(0xe801, "7FFEC5C9-2D00-49B7-8941-3EA10A5586B7", "Linux dm-crypt");
+
    // See http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec
    AddType(0xea00, "BC13C2FF-59E6-4262-A352-B275FD6F7172", "Freedesktop $BOOT");
 

-- 
Daniel Milewski
GPG key ID: 8D43A4A1

Re: [Gptfdisk-general] merge requests

[Owen S. <os...@su...>]

> 
> I generally prefer getting a patch file, but a git merge request is OK, 
> too. I simply haven't gotten around to those merge requests yet.
> 

Dear Rod,

Thanks for letting me know you preferred getting a patch file.

I will send you patch files in future :)

Best regards

Owen

Re: [Gptfdisk-general] merge requests

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

On 08/05/2014 04:59 AM, Owen Synge wrote:
> Dear authors,
>
> I was looking at this page:
>
> https://sourceforge.net/p/gptfdisk/code/merge-requests/
>
> I saw no merges had been commented on rejected or merged by the authors?
>
> I know all 4 patches are quiet recent, but was wondering if this was the
> correct way to submit patches :)

I generally prefer getting a patch file, but a git merge request is OK, 
too. I simply haven't gotten around to those merge requests yet.

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

[Gptfdisk-general] merge requests

[Owen S. <os...@su...>]

Dear authors,

I was looking at this page:

https://sourceforge.net/p/gptfdisk/code/merge-requests/

I saw no merges had been commented on rejected or merged by the authors?

I know all 4 patches are quiet recent, but was wondering if this was the
correct way to submit patches :)

Best regards

Owen

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

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

Hi Rod -

To close on this topic.  The ONIE project documentation is now updated
and references the GUIDs for the partitions.  The relevant
documentation is here:

http://onie.github.io/onie/docs/design-spec/x86_boot_loader.html#initial-onie-install-embed

   Note: For GPT disk labels, the ONIE-BOOT partition type GUID is
   7412F7D5-A156-4B13-81DC-867174929325. This GUID is recognized by
   the gdisk and sgdisk utilities from the GPT fdisk package. See
   commit b784e0c95a11 for details.

Cheers,
Curt

On Sun Jan 26 11:08, Curt Brune wrote:
> On Sat Jan 25 22:54, Rod Smith wrote:
> > 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.).
> 
> Thanks for the prompt reply.
> 
> Also thanks for the whole gptfdisk project!  I am finding sgdisk
> *very* easy to use for our purposes.  Very nice.
> 
> The ONIE source code is available on github:
> https://github.com/onie/onie
> 
> The files that reference the GUIDs and gdisk partition types:
> 
> https://github.com/onie/onie/blob/master/rootconf/x86_64/sysroot-lib-onie/onie-blkdev-common
>   onie_boot_gfdisk_type="0x3000"
>   onie_config_gfdisk_type="0x3001"
>    
>   onie_boot_gpt_uuid="7412F7D5-A156-4B13-81DC-867174929325"
>   onie_config_gpt_uuid="D4E6E2CD-4469-46F3-B5CB-1BFF57AFC149"
> 
> The ONIE upgrader/installer looks for these GUIDs during
> installation.  That file is here, and see the verify_onie_partitions()
> function:
> https://github.com/onie/onie/blob/master/installer/x86_64/install-arch
> 
> The ONIE specification for x86 is WIP and it will reference these
> GUIDs.  The ONIE specification for powerpc (which does not use GPT) is
> available here:
> http://onie.github.io/onie/docs/design-spec/index.html
> 
> Cheers,
> Curt
> 
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Gptfdisk-general mailing list
> Gpt...@li...
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general

[Gptfdisk-general] [GPTfdisk][PATCH] Adding support for GPT recovery using sgdisk

[abhisek s. <abh...@gm...>]

Hi Roderick/Yves,

    The patch provided in the earlier email does not work with the
latter release. I have corrected the patch for version 0.8.10.

I have tested the following scenarios:
1. Primary GPT wiped out. Primary GPT successfully restored from the
Secondary GPT.
2. Secondary GPT wiped out. Secondary GPT header successfully restored
from Primary GPT header.

Following is the patch for you reference:

diff -u old/gptcl.cc new/gptcl.cc
--- old/gptcl.cc    2014-03-02 23:27:37.000000000 +0530
+++ new/gptcl.cc    2014-03-24 13:53:00.068018600 +0530
@@ -90,6 +90,7 @@
       {"load-backup", 'l', POPT_ARG_STRING, &backupFile, 'l', "load
GPT backup from file", "file"},
       {"list-types", 'L', POPT_ARG_NONE, NULL, 'L', "list known
partition types", ""},
       {"gpttombr", 'm', POPT_ARG_STRING, &mbrParts, 'm', "convert GPT
to MBR", "partnum[:partnum...]"},
+      {"fixgptcorruption", 'M', POPT_ARG_NONE, NULL, 'M', "Restores
the corrupt primary or secondary GPT header"},
       {"new", 'n', POPT_ARG_STRING, &newPartInfo, 'n', "create new
partition", "partnum:start:end"},
       {"largest-new", 'N', POPT_ARG_INT, &largestPartNum, 'N',
"create largest possible new partition", "partnum"},
       {"clear", 'o', POPT_ARG_NONE, NULL, 'o', "clear partition table", ""},
@@ -281,6 +282,11 @@
                      saveData = 0;
                   } // if
                   break;
+           case 'M':
+          JustLooking(0);
+          saveData = 1;
+            retval = 0;
+          break;
                case 'n':
                   JustLooking(0);
                   newPartNum = (int) GetInt(newPartInfo, 1) - 1;
@@ -427,6 +433,11 @@
                   free(backupFile);
                   retval = 0;
                   break;
+           case 'M':
+                  JustLooking(0);
+          saveData = 1;
+            retval = 0;
+          break;
                case 'o':
                   JustLooking(0);
                   ClearGPTData();



The benefit of having this option is that corrupt Primary/Secondary
GPT headers can be restored using a command line i.e. sgdisk. This
makes it easier to be used by programs/shell scripts. Kindly let me
know you views.


Thanks,
Abhisek



---------- Forwarded message ----------
From: abhisek shaw <abh...@gm...>
Date: Fri, Mar 14, 2014 at 3:30 PM
Subject: Adding support for GPT recovery using sgdisk
To: gpt...@li...


Hi All,

The sgdisk utility currently lacks options for correcting the
Primary/Secondary GPT headers if there is any corruption  If the
Primary GPT header is corrupted, it could be updated from the
Secondary GPT header and vice-verse.

I have prepared a patch for this(PFA). Kindly review it and add it the sources.

Please do let me if there are additional changes required. This patch
has been prepared on the latest version of the code i.e.  0.8.10

Thanks,
Abhisek

[Gptfdisk-general] Adding support for GPT recovery using sgdisk

[abhisek s. <abh...@gm...>]

Hi All,

The sgdisk utility currently lacks options for correcting the
Primary/Secondary GPT headers if there is any corruption  If the
Primary GPT header is corrupted, it could be updated from the
Secondary GPT header and vice-verse.

I have prepared a patch for this(PFA). Kindly review it and add it the sources.

Please do let me if there are additional changes required. This patch
has been prepared on the latest version of the code i.e.  0.8.10

Thanks,
Abhisek

[Gptfdisk-general] [BUG] gdisk exits with status 1 when successful

[Eric B. <ebi...@gm...>]

Since version 0.8.9 (commit 84aaff6b9cf3b802c621781cf9acd006aa5a3e66),
gdisk has exited with status 1 when listing the partition table with the
'l' option (and likely in other cases too, looking at the code).  The
success exit code should be changed back to 0 so that scripts don't think
there is an error.

Re: [Gptfdisk-general] strange sgdisk failure on ppc64el

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

On 02/26/2014 10:55 AM, Scott Moser wrote:
> Hi,
> We use gptfdisk (sgdisk) from growpart to grow gpt disks on boot grow the
> mounted root filesystem.  It may sound crazy, but it works really well.
>
> We're seeing an issue on ppc64el systems with gpt partition tables.  This
> reproduces only occasionally.
>
> I've opened an ubuntu bug at
>    https://bugs.launchpad.net/ubuntu/+source/gdisk/+bug/1285197

I've subscribed to that bug report. (Incidentally, I don't know if 
you're aware, but I was hired by Canonical in January. Maintaining gdisk 
isn't part of my Canonical job description, though, so it remains a 
hobby project.)

> The failure we saw was this (we only have logs), and subsequent run of
> identical 'growpart' finished fine:
> command: growpart /dev/sda 1
> exit code: 2
> stdout:
>    FAILED: disk=/dev/sda partition=1: failed to repartition
> stderr:
>    failed [sgdisk_mod:4] sgdisk --move-second-header --delete=1
>       --new=1:18432:20971486
>       --typecode=1:0FC63DAF-8483-4772-8E79-3D69D8477DE4
>       --partition-guid=1:53FFEF70-1623-46CC-AFB7-EBC1EB5340F2
>       --change-name=1:Linux filesystem /dev/sda
>    Could not create partition 1 from 40532396646334464 to 0
>    Could not change partition 1's type code to 0FC63DAF-8483-4772-8E79-3D69D8477DE4!
>    Unable to set partition 1's name to 'Linux filesystem'!
>    Error encountered; not saving changes.
>    ***** WARNING: Resize failed, attempting to revert ******
>    ***** Appears to have gone OK ****
>
> Note there the odd '1 from 40532396646334464 to 0'.

That caught my eye, too. If my calculator skills are intact, 
40,532,396,646,334,464 is 9 x 2^52, while the value you specified as the 
start point (18432) is 9 x 2^11. This is surely not a coincidence -- 
it's a bit shift of 41. The sporadic nature of the problem suggests some 
sort of issue with the machine state. (This isn't to say that I'm ruling 
out the possibility of an sgdisk bug; but if there is an sgdisk bug, 
it's probably interacting with something about the machine state that's 
unique for just some runs.)

The subsequent two failures (an inability to set the type code and name) 
naturally follow from an inability to create the partition.

> I'm wondering if you've seen anything like this.

No, this is the first I've heard of a problem that looks even remotely 
like this.

> I think its only fair to point out:
>   a.) this occured on a ppc64el guest running on ppc64 under kvm.
>       Its a new platform, and its possible that there are issues in kvm or
>       the underlying virtual hardware.
>   b.) it doens't occur that often
>   c.) in ppc64el the 'el' is "little endian".

I did do development and testing of gdisk on both an ancient PowerPC 
iMac and using KVM to emulate PowerPC hardware; however, that was 
big-endian. I no longer have the iMac, so I can't test on that hardware 
myself.

> All that said, most of the time it works fine.

Which of course makes it very hard to debug.

> To generally reproduce what is going on here via use of /dev/loop0, we can
> do the following.  Obviously you're not stressing the whole stack that was
> in play (not running a ppc64el guest or kernel).
>
>   imgurl="http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-ppc64el-gpt1.img"
>   imgdist="${imgurl##*/}"
>   wget "$imgurl" -O "$imgdist"
>   qemu-img convert -O raw "$imgdist" my.img
>   qemu-img resize my.img 10G
>   LODEV="/dev/loop0"
>   sudo losetup $LODEV "$PWD/my.img"
>   mkdir ./mp
>   sudo mount ${LODEV}p1 ./mp
>   sudo growpart "$LODEV" 1
>
>   sudo umount ./mp
>   sudo losetup -d "$LODEV"

I'll try to take a look at this over the weekend. In the meantime, if 
you uncover any additional data, feel free to contact me with it.

Incidentally, the version of gdisk in trusty is a little behind -- gdisk 
is now up to 0.8.9; however, there's a new bug in 0.8.9, so you might 
want to try experimenting with the version in the Sourceforge git 
repository, which fixes that bug. (I meant to release a new version with 
a fix last weekend, but didn't get around to it.) AFAIK, the 0.8.9 bug 
only affects the process of creating hybrid MBRs, so it shouldn't affect 
your issue. For that matter, the changes from 0.8.8 to 0.8.9 also don't 
seem like things that would affect your bug, so I doubt if that's really 
relevant. Still, it's best to test with the latest code, if at all 
possible....

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

[Gptfdisk-general] strange sgdisk failure on ppc64el

[Scott M. <sm...@ub...>]

Hi,
We use gptfdisk (sgdisk) from growpart to grow gpt disks on boot grow the
mounted root filesystem.  It may sound crazy, but it works really well.

We're seeing an issue on ppc64el systems with gpt partition tables.  This
reproduces only occasionally.

I've opened an ubuntu bug at
  https://bugs.launchpad.net/ubuntu/+source/gdisk/+bug/1285197

The failure we saw was this (we only have logs), and subsequent run of
identical 'growpart' finished fine:
command: growpart /dev/sda 1
exit code: 2
stdout:
  FAILED: disk=/dev/sda partition=1: failed to repartition
stderr:
  failed [sgdisk_mod:4] sgdisk --move-second-header --delete=1
     --new=1:18432:20971486
     --typecode=1:0FC63DAF-8483-4772-8E79-3D69D8477DE4
     --partition-guid=1:53FFEF70-1623-46CC-AFB7-EBC1EB5340F2
     --change-name=1:Linux filesystem /dev/sda
  Could not create partition 1 from 40532396646334464 to 0
  Could not change partition 1's type code to 0FC63DAF-8483-4772-8E79-3D69D8477DE4!
  Unable to set partition 1's name to 'Linux filesystem'!
  Error encountered; not saving changes.
  ***** WARNING: Resize failed, attempting to revert ******
  ***** Appears to have gone OK ****

Note there the odd '1 from 40532396646334464 to 0'.


I'm wondering if you've seen anything like this.

I think its only fair to point out:
 a.) this occured on a ppc64el guest running on ppc64 under kvm.
     Its a new platform, and its possible that there are issues in kvm or
     the underlying virtual hardware.
 b.) it doens't occur that often
 c.) in ppc64el the 'el' is "little endian".

All that said, most of the time it works fine.

To generally reproduce what is going on here via use of /dev/loop0, we can
do the following.  Obviously you're not stressing the whole stack that was
in play (not running a ppc64el guest or kernel).

 imgurl="http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-ppc64el-gpt1.img"
 imgdist="${imgurl##*/}"
 wget "$imgurl" -O "$imgdist"
 qemu-img convert -O raw "$imgdist" my.img
 qemu-img resize my.img 10G
 LODEV="/dev/loop0"
 sudo losetup $LODEV "$PWD/my.img"
 mkdir ./mp
 sudo mount ${LODEV}p1 ./mp
 sudo growpart "$LODEV" 1

 sudo umount ./mp
 sudo losetup -d "$LODEV"


Thoughts?
Scott

Re: [Gptfdisk-general] [PATCH] Fix problem resizing RAID disks

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

On 01/27/2014 06:20 AM, Frediano Ziglio wrote:
> This patch fix 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.

Thanks for the patch. I've accepted it into the next release of gdisk.

> 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.
>
> Signed-off-by: Frediano Ziglio <fre...@ci...>
> ---
>   gpt.cc |    1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/gpt.cc b/gpt.cc
> index fa7b661..3244cc9 100644
> --- a/gpt.cc
> +++ b/gpt.cc
> @@ -1314,6 +1314,7 @@ int GPTData::DestroyGPT(void) {
>      uint8_t* emptyTable;
>
>      memset(blankSector, 0, sizeof(blankSector));
> +   ClearGPTData();
>
>      if (myDisk.OpenForWrite()) {
>         if (!myDisk.Seek(mainHeader.currentLBA))
>


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

Re: [Gptfdisk-general] add GPT partition types for Haiku

[Alexander v. G. IV <kal...@un...>]

On Tue, 28 Jan 2014 18:05:41 -0500
Rod Smith <rod...@ro...> wrote:

> On 01/28/2014 05:31 PM, Alexander von Gluck IV wrote:
> > While the topic of UUID additions is open, I threw a request out a while ago
> > on adding the Haiku GPT UUID's but never heard back on it.
> >
> > http://lists.gnu.org/archive/html/bug-parted/2012-07/msg00006.html
> >
> > 42465331-3BA3-10F1-802A-4861696B7521  "Haiku BFS"
> 
> I added this some time ago to gdisk 0.8.7. (The current version is 0.8.8.)

Oops!  Thanks for confirming :-) Sorry I missed that.

 -- Alex

Re: [Gptfdisk-general] add GPT partition types for Haiku

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

On 01/28/2014 05:31 PM, Alexander von Gluck IV wrote:
> While the topic of UUID additions is open, I threw a request out a while ago
> on adding the Haiku GPT UUID's but never heard back on it.
>
> http://lists.gnu.org/archive/html/bug-parted/2012-07/msg00006.html
>
> 42465331-3BA3-10F1-802A-4861696B7521  "Haiku BFS"

I added this some time ago to gdisk 0.8.7. (The current version is 0.8.8.)

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

[Gptfdisk-general] add GPT partition types for Haiku

[Alexander v. G. IV <kal...@un...>]

While the topic of UUID additions is open, I threw a request out a while ago
on adding the Haiku GPT UUID's but never heard back on it.

http://lists.gnu.org/archive/html/bug-parted/2012-07/msg00006.html

42465331-3BA3-10F1-802A-4861696B7521  "Haiku BFS"

Can be confirmed in the Haiku source code, and on wikipedia...

http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/partitioning_systems/gpt/gpt_known_guids.h

Thanks!

 -- Alex

[Gptfdisk-general] add GPT partition types for plain dm-crypt and LUKS

[Christoph A. M. <cal...@sc...>]

Hi.

Recently a discussion[0] was initiated at the dm-crypt mailing list
about whether or not to have a GPT type for it.

In the end, upstream basically agreed[1][2] to the following
definitions:
plain dm-crypt   7FFEC5C9-2D00-49B7-8941-3EA10A5586B7
LUKS partition   CA7D7CCB-63ED-4C53-861C-1742536059CC

Could you please upgrade GPT fdisk accordingly?

Thanks, :-)
Chris.


[0] http://www.saout.de/pipermail/dm-crypt/2014-January/003837.html
[1] http://www.saout.de/pipermail/dm-crypt/2014-January/003855.html
[2] http://www.saout.de/pipermail/dm-crypt/2014-January/003859.html

[Gptfdisk-general] [PATCH] Fix problem resizing RAID disks

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

This patch fix 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.

Signed-off-by: Frediano Ziglio <fre...@ci...>
---
 gpt.cc |    1 +
 1 file changed, 1 insertion(+)

diff --git a/gpt.cc b/gpt.cc
index fa7b661..3244cc9 100644
--- a/gpt.cc
+++ b/gpt.cc
@@ -1314,6 +1314,7 @@ int GPTData::DestroyGPT(void) {
    uint8_t* emptyTable;
 
    memset(blankSector, 0, sizeof(blankSector));
+   ClearGPTData();
 
    if (myDisk.OpenForWrite()) {
       if (!myDisk.Seek(mainHeader.currentLBA))
-- 
1.7.10.4

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

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

On Sat Jan 25 22:54, Rod Smith wrote:
> 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.).

Thanks for the prompt reply.

Also thanks for the whole gptfdisk project!  I am finding sgdisk
*very* easy to use for our purposes.  Very nice.

The ONIE source code is available on github:
https://github.com/onie/onie

The files that reference the GUIDs and gdisk partition types:

https://github.com/onie/onie/blob/master/rootconf/x86_64/sysroot-lib-onie/onie-blkdev-common
  onie_boot_gfdisk_type="0x3000"
  onie_config_gfdisk_type="0x3001"
   
  onie_boot_gpt_uuid="7412F7D5-A156-4B13-81DC-867174929325"
  onie_config_gpt_uuid="D4E6E2CD-4469-46F3-B5CB-1BFF57AFC149"

The ONIE upgrader/installer looks for these GUIDs during
installation.  That file is here, and see the verify_onie_partitions()
function:
https://github.com/onie/onie/blob/master/installer/x86_64/install-arch

The ONIE specification for x86 is WIP and it will reference these
GUIDs.  The ONIE specification for powerpc (which does not use GPT) is
available here:
http://onie.github.io/onie/docs/design-spec/index.html

Cheers,
Curt

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

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

On 01/26/2014 01:55 AM, Edwin wrote:
> 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).

The GPT specification is quite clear on this: The MBR disk signature is 
"unused. Set to zero." (Table 14, on p. 97 of the UEFI 2.3.1 spec.) If 
you've got a GPT disk with a non-zero disk signature, then it's 
violating the GPT spec.

> 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.

If that's the case, then your firmware or boot loader is broken.

> Would it be safer to have the MakeProtectiveMBR function keep the
> existing signature when it auto-corrects?

The spec is quite explicit about this point. I'm reluctant to violate 
the spec in the interest of satisfying a buggy firmware's or boot 
loader's needs. It's possible that some other program requires a 
standards-compliant protective MBR, and doing as you suggest would break 
such a tool.

I sympathize with your problems, but they're caused by bugs somewhere 
other than in gdisk. Something (your OEM or possibly a Windows tool) 
created a non-compliant protective MBR, and your firmware or boot loader 
seems to be relying upon data in a field in the protective MBR that the 
spec explicitly says should be zeroed out. Unfortunately, the EFI world 
is filled with such problems. Fixes intended to work around them can 
often work on a specific computer, but cause problems on other computers.

> On Sat, Jan 25, 2014 at 11:00 PM, Rod Smith <rod...@ro...
> <mailto: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...>
>         <mailto: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...>
>         <mailto:rod...@ro... <mailto:rod...@ro...>__>
>         http://www.rodsbooks.com
>
>
>
>
>     --
>     Rod Smith
>     rod...@ro... <mailto:rod...@ro...>
>     http://www.rodsbooks.com
>
>


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

[Gptfdisk-general] gdisk and fixparts win64 binary for Win 7/8/8.1 x64 ISO WinPE env

[Keshav A. <the...@gm...>]

Hi,
     Windows x64  (Vista/7/8/8.1) ISO Installer/Setup environment (WinPE)
does not include the WoW64 subsystem (which provides win32 executables
support in win64 env). Due to this the official win32 executables of gdisk
and fixparts (from sourceforge) cannot be run inside the Windows x64 ISO
WinPE environment (I tried in Win 7 and Win 8.1 x64 ISO, UEFI USB boot).
Hence I request you to provide official win64 executables of gdisk and
fixparts for download in sourceforge. Thanks in advance.

With Best Regards,

Keshav