Root filesystem not resized if e2fsck repairs any issues

Bug #1928741 reported by Aaron Jones
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
initramfs-tools-ubuntu-core (Ubuntu)
New
Undecided
Unassigned

Bug Description

Observed on Ubuntu Core 18, which uses initramfs-tools-ubuntu-core_0.7.45+ppa5_all.deb (see https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/11283241/+listing-archive-extra), but this issue appears to affect the official package in addition to the one in the PPA.

The script which resizes the writable partition (scripts/local-premount/resize) invokes "e2fsck -fy $writable_part" but it does not pay attention to the exit code. Since the script is invoked with "-e" any nonzero exit code will cause the script to exit. Looking at the manpage for e2fsck (https://man7.org/linux/man-pages/man8/e2fsck.8.html) an exit code of 1 means "File system errors corrected". It seems likely that if there were only correctable errors that the script should continue and run resize2fs.

The current behavior is that the script exits prematurely. The partition has been resized, but the filesystem has not. Because Ubuntu Core 18 lacks the fix that will resize the filesystem even when the partition is the correct size (https://git.launchpad.net/ubuntu/+source/initramfs-tools-devices/tree/scripts/local-premount/resize?h=ubuntu/focal#n143) this issue is not corrected even on a reboot. The issue can be worked around by manually running resize2fs.

I found this issue because I was improperly ejecting an SD card after flashing it with the Ubuntu Core 18 image, and wound up with ext4 filesystem issues. I was waiting for the flashing command to sync, so all of the files were intact, but parts of Gnome were automouting it and doing something with it, which I believe lead to the issues with the filesystem that were correctable by e2fsck. I totally admit the root cause here was due to operator error, and any image made with ubuntu-image that is not accidentally corrupted due to premature ejection would not exhibit this issue. That said, the end result was fairly difficult to diagnose and the fix seems straightforward -- look at the exit code from e2fsck -- so I figured I would report it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.