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

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 <[email protected]>:

> 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 <[email protected]>
> Blade -- 90 avenue des Ternes, 75017 Paris
>
>


-- 
Yann Dirson <[email protected]>
Blade -- 90 avenue des Ternes, 75017 Paris