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

[Yann Dirson]

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:

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 :)

2016-11-23 15:45 GMT+01:00 Yann Dirson <address@hidden>:

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 <address@hidden>
Blade -- 90 avenue des Ternes, 75017 Paris

--

Yann Dirson <address@hidden>
Blade -- 90 avenue des Ternes, 75017 Paris