-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPT disk is not fixed before resizing it #1461
Comments
Files identified in the description: If these files are inaccurate, please update the |
Could you give a bit more detail about the disk setup (as in if you've just expand a virtual disk etc), and the OS + parted version? I'll try and replicate on Centos8. Note that the module shells out to parted, which possibly might not support fixing the GPT table in script mode (see here). That would require a bit more reworking of the module. |
[edited] The parted command used by ansible module (resizepart 1 100%) seems valid. @smutel: could you please run the comman /usr/sbin/parted -s -m -a optimal /dev/mapper/mpatha -- resizepart 1 100% outside of ansible and see what happens? Also: try without -s option and see what happens. I've noticed you used /dev/mapper path to your device. Did you use LVM or similar to increase its size before using parted module? Parted seems to be confused that underlying device size has changed; resize command was meant to increase size of partition, not whole device and that could cause your problem too. |
I reproduced this situtaion on my PC. If you increase underlying device size, parted asks for permission to adjust GPT table for new size and with -s option it chooses safe exit (cancel). I'm afraid there's little we can do here due to parted (tool, not module) limitations. Maybe you could skip creating partitions anyway and use /dev/mapper/device_name directly? You want to use 100% of it anyway... |
What about executing something like this: printf "fix\n" | parted ---pretend-input-tty /dev/vda print |
I wouldn't trust that at all; what if parted asks about something else
(like differrent error in table, not size mismatch) and we'll "fix" it by
blowing whole table up :-/ so we should at least agree only for certain
well defined problems, and not blindly fix everything parted may come up
with. I can imagine parameter like input or expect (see: man expect) script
to pipe to or interact with parted and hope the user knows the best... but
then: why not use shell module instead? Parted module works by preparing
and executing non-interactive parted scripts: extending it to overcome
parted's limitations is not a trivial fix, I'm afraid.
|
I've poked around with the module and got it work as requested using I understand the request, as I use the module in a similar way (growing partitions on a disk after it was expanded), and would hit the same problem if the disks had GTP tables. However I think the cleanest workaround is to either fork/extend the module yourself (where you have contextual knowledge so can apply the fix command more safely in the module) or to use |
And if before executing the fix, we test the need to fix the GPT with something like: command = "echo \"check\" | parted /dev/vdd print"
rc, out, err = module.run_command(command)
if "Warning: Not all of the space available" in out:
... |
Could use this to fix just the gpt issue and not blindly fix all errors:
|
parted has an option "-f" which causes he gpt issue to be fixed without asking. |
Files identified in the description: If these files are incorrect, please update the |
SUMMARY
An error message is displayed when we would like to increase the size of disk using collection parted.
ISSUE TYPE
COMPONENT NAME
parted
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
STEPS TO REPRODUCE
EXPECTED RESULTS
Disk is resized correctly.
ACTUAL RESULTS
The text was updated successfully, but these errors were encountered: