Skip to content
This repository has been archived by the owner on Jan 16, 2024. It is now read-only.

Growing root volume doesn't work on Minimal Ubuntu #116

Closed
vholer opened this issue Jul 12, 2018 · 3 comments
Closed

Growing root volume doesn't work on Minimal Ubuntu #116

vholer opened this issue Jul 12, 2018 · 3 comments

Comments

@vholer
Copy link
Contributor

vholer commented Jul 12, 2018

Identified problems:

  1. Proc mounts doesn't contain valid root volume device:
# cat /etc/mtab | grep ' / ' | grep -v '^rootfs'
/dev/root / ext4 rw,relatime,data=ordered 0 0
# ls -la /dev/root
ls: cannot access '/dev/root': No such file or directory

It would be good to start using findmnt instead, e.g.:

# findmnt -ln -o SOURCE,FSTYPE /
/dev/vda1 ext4
# findmnt -ln -o SOURCE,FSTYPE /
/dev/mapper/centos_nessos-root xfs
  1. Non-LVM device name always stripped

This part:

DISK=$(echo "$DEVICE" | sed 's/.$//')

always removes last character from the device name, no matter if it is a partition number or not. Should strip only all trailing number. Error from log:

Jul 12 10:02:55 ubuntu one-contextd[457]: Script loc-05-grow-rootfs: Starting ...
Jul 12 10:02:55 ubuntu one-contextd[486]: Script loc-05-grow-rootfs output: FAILED: /dev/roo: does not exist
Jul 12 10:02:55 ubuntu one-contextd[486]: resize2fs 1.42.13 (17-May-2015)
Jul 12 10:02:55 ubuntu one-contextd[486]: open: No such file or directory while opening /dev/root
Jul 12 10:02:55 ubuntu one-contextd[487]: Script loc-05-grow-rootfs: Finished with exit code 1
@vholer vholer added this to the v5.6.0.1 milestone Jul 12, 2018
@vholer
Copy link
Contributor Author

vholer commented Jul 12, 2018

Just a note: The difference in the contextualized sizes of the base and minimal appliances would be:

  • Ubuntu 16.04: base 306 MiB vs. minimal 195 MiB
  • Ubuntu 18.04: base 351 MiB vs. minimal 212 MiB

@tubemeister
Copy link

There are still too many assumptions in this, even after your suggestions for improvement.

My root fs lives on /dev/mapper/LVM0-root, which readlink translates to /dev/dm-0, which breaks the assumption that deleting the trailing digit gets you a valid $DISK.

My /etc/fstab has UUIDs in it, which breaks the "grep mapper" LVM detection.

The "parted $DISK print" command hangs on interactive user input:

parted /dev/vda print
Warning: Not all of the space available to /dev/vda appears to be used, you can fix the GPT to use all of the space (an extra 12582912 blocks) or continue with the current setting?
Fix/Ignore?

I've put in the following to test with:

if [ $(grep ' / ' /etc/mtab | grep -v '^rootfs' | grep LVM |wc -l) -ne 0 ]; then
  LVM="yes"

With this and fixing the GPT before running the script, the rest works for me.

@vholer vholer modified the milestones: v5.6.0.1, v5.10.0 Nov 19, 2018
vholer pushed a commit that referenced this issue May 21, 2019
@vholer
Copy link
Contributor Author

vholer commented May 21, 2019

Following fixes applied:

  • 61901fd (detect LVM / rootfs device)
  • 337b52c (non-interactive parted)

Closing.

@vholer vholer closed this as completed May 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants