GNU bug report logs - #25006
Non-interactively extending a GPT disklabel to cover all disk

Previous Next

To reply to this bug, email your comments to 25006 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yann Dirson <yann.dirson <at> blade-group.com>
To: bug-parted <at> gnu.org
Cc: tech <tech <at> blade-group.com>
Subject: Non-interactively extending a GPT disklabel to cover all disk
Date: Wed, 23 Nov 2016 15:45:57 +0100

[Message part 1 (text/plain, inline)]

If we build a GPT image for flashing on arbitrary disks, chances are there
is space left after
that second partition-table, placed at end of image.

When launching parted interactively, we get asked "Not all of the space
available to ... appears to be used" and asked "Fix/Ignore?".

The code does not look like the job done on "fix" is available from any
other mean, whether lib or parted command. And the exception system does
not look like it will work with no tty attached, so
just using "echo fix | parted /dev/whatever print" will just not workaround
this.

Did I miss something ?

What would be the preferred approach ?  What about adding a flag to
auto-fix this ?

Best regards,
-- 
Yann Dirson <yann <at> blade-group.com>
Blade -- 90 avenue des Ternes, 75017 Paris

[Message part 2 (text/html, inline)]

Message #8 received at 25006 <at> debbugs.gnu.org (full text, mbox):

From: Yann Dirson <yann.dirson <at> blade-group.com>
To: 25006 <at> debbugs.gnu.org
Cc: tech <tech <at> blade-group.com>
Subject: Re: bug#25006: Non-interactively extending a GPT disklabel to cover
 all disk
Date: Thu, 1 Dec 2016 11:08:11 +0100

[Message part 1 (text/plain, inline)]

In fact, this issue and the "command parameters ignored when parted sees
need to fix GPT" I also reported work together in a surprising way:
<http://lists.gnu.org/archive/html/bug-parted/2016-11/msg00003.html>
If the GPT needs to be extended, then the following command will just fix
it, as arguments on the commandline appear to be emulating user input in
some way :

parted /dev/whatever print fix

However, somewhat expectedly, issuing this command when there is nothing to
fix will result in an error message with full usage text etc.

Side note: testing a grep pattern to just run the fix command when needed,
I noticed that surprisingly, the output, which is on a single line, gets
split to fit in 80 colums when fed into a pipe. Not sure it is really
useful, but confusing for sure...

Thus ending with this hack to get the GPT back on its feet:

if parted $DISK print 2>&1 | grep -q 'Not all of the space available .*
appears to be used'; then
    parted $DISK print fix
fi

Hope it will help someone out there :)
<http://lists.gnu.org/archive/html/bug-parted/2016-11/msg00003.html>

2016-11-23 15:45 GMT+01:00 Yann Dirson <yann.dirson <at> blade-group.com>:

> If we build a GPT image for flashing on arbitrary disks, chances are there
> is space left after
> that second partition-table, placed at end of image.
>
> When launching parted interactively, we get asked "Not all of the space
> available to ... appears to be used" and asked "Fix/Ignore?".
>
> The code does not look like the job done on "fix" is available from any
> other mean, whether lib or parted command. And the exception system does
> not look like it will work with no tty attached, so
> just using "echo fix | parted /dev/whatever print" will just not
> workaround this.
>
> Did I miss something ?
>
> What would be the preferred approach ?  What about adding a flag to
> auto-fix this ?
>
> Best regards,
> --
> Yann Dirson <yann <at> blade-group.com>
> Blade -- 90 avenue des Ternes, 75017 Paris
>
>


-- 
Yann Dirson <yann <at> blade-group.com>
Blade -- 90 avenue des Ternes, 75017 Paris

[Message part 2 (text/html, inline)]

Message #11 received at 25006 <at> debbugs.gnu.org (full text, mbox):

From: Phil Susi <psusi <at> ubuntu.com>
To: Yann Dirson <yann.dirson <at> blade-group.com>, 25006 <at> debbugs.gnu.org
Cc: tech <tech <at> blade-group.com>
Subject: Re: bug#25006: Non-interactively extending a GPT disklabel to cover
 all disk
Date: Wed, 19 Apr 2017 09:44:18 -0400

On 12/1/2016 5:08 AM, Yann Dirson wrote:
> In fact, this issue and the "command parameters ignored when parted sees
> need to fix GPT" I also reported work together in a surprising way:
> <http://lists.gnu.org/archive/html/bug-parted/2016-11/msg00003.html>
> If the GPT needs to be extended, then the following command will just fix
> it, as arguments on the commandline appear to be emulating user input in
> some way :
> 
> parted /dev/whatever print fix
> 
> However, somewhat expectedly, issuing this command when there is nothing to
> fix will result in an error message with full usage text etc.

Indeed, and I have been struggling with what to do about this for a long
time now.  As you noted in your other bug report, it can be problematic
if you get an exception and it looks at the command line arguments for
an answer.  I think the fix for that is that the exception handler
should never take input from the command line buffer, but then you would
not be able to use this trick to fix the table.

There is an undocumented parted switch used for internal testing... iirc
it was ---pretend-input-tty.  Using that will let you pipe the exception
handler responses in.  You can also use expect to script responses.

That said, it would be nice to be able to specify some sort of
--auto-fix-foo switch, but the switches are processed by parted, and the
exceptions are thrown by libparted.  Parted is given a localized text
description of the error, so it is difficult to recognize the exception
as the specific one it has been asked to auto fix.  Because the strings
often have substituted strings, we can't just strcmp().  Now that I
think about it again though, I may be able to pull it off using
sscanf().  This might work for parted though, where we can make sure to
keep parted and libparted in sync with respect to the exact exception
strings, but other tools that rely on libparted would get out of sync
and this string comparison would break.

> Side note: testing a grep pattern to just run the fix command when needed,
> I noticed that surprisingly, the output, which is on a single line, gets
> split to fit in 80 colums when fed into a pipe. Not sure it is really
> useful, but confusing for sure...
> 
> Thus ending with this hack to get the GPT back on its feet:
> 
> if parted $DISK print 2>&1 | grep -q 'Not all of the space available .*
> appears to be used'; then
>     parted $DISK print fix
> fi
> 
> Hope it will help someone out there :)
> <http://lists.gnu.org/archive/html/bug-parted/2016-11/msg00003.html>

Nice.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.