bug#25006: Non-interactively extending a GPT disklabel to cover all disk

[Phil Susi]

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.