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.dir...@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 <y...@blade-group.com>
> Blade -- 90 avenue des Ternes, 75017 Paris
>
>
--
Yann Dirson <y...@blade-group.com>
Blade -- 90 avenue des Ternes, 75017 Paris
