This bug was fixed in the package e2fsprogs - 1.44.4-2ubuntu0.2
---------------
e2fsprogs (1.44.4-2ubuntu0.2) cosmic; urgency=medium
* d/patches/0001-resize2fs-update-checksums-in-the-extent-tree-s-relo.patch:
do the checksum update later in extent tree relocated block to denote the
inode number change, otherwise the checksum update might be done in the old
copy of the block. (LP: #1798562)
-- Mathieu Trudel-Lapierre <cypher...@ubuntu.com> Fri, 25 Jan 2019
10:02:34 -0500
** Changed in: e2fsprogs (Ubuntu Cosmic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1798562
Title:
After a side by side installation, resized filesystem is corrupted
Status in e2fsprogs package in Ubuntu:
Fix Released
Status in e2fsprogs source package in Bionic:
Fix Committed
Status in e2fsprogs source package in Cosmic:
Fix Released
Bug description:
[Impact]
- Users resizing filesystems using resize2fs.
- Resizing an existing Linux filesystem from the Ubuntu installer.
[Test cases]
Test Case 1:
With e2fsprogs 1.44.4-2:
Download this file system image:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+attachment/5203159/+files/vda1b.qcow2.bz
Run the following commands:
bunzip2 vda1b.qcow2.bz
qemu-img convert vda1b.qcow2 vda1b.raw
e2fsck -f vda1b.raw
resize2fs vda1b.raw 6200M
e2fsck -f vda1b.raw
e2fsck 1.44.4 (18-Aug-2018)
Pass 1: Checking inodes, blocks, and sizes
Inode 45746 extent block passes checks, but checksum does not match extent
(logical block 1272, physical block 466167, len 776)
Fix<y>?
Test Case 2 (Use case of the installer):
1. Perform a first installation of Ubuntu
2. Reboot into the freshly installed system and verify everything works as
expected
3. Do a second installation and select "Install alonogside". Keep the size
proposed by the installer and proceed to the end of installation
4. Reboot
5. On boot, in the list of installed systems, select the first system
installed on the machine
6. Verify that it boots, you can login and it works as expected
Actual Result
The FS is corrupted and depending on the corruption it goes to initramfs,
boots but cannot login, ...
[Regression potential]
This changes behavior in the update logic for extent blocks; as such, care
should be taken to make sure that testing takes into account the possibility to
introduce filesystem corruption while resizing. This is why the test cases
include running e2fsck as last step.
---
Attached is the journal of the system installed on the corrupted
partition.
ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
Uname: Linux 4.18.0-10-generic x86_64
ApportVersion: 2.20.10-0ubuntu13
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct 18 10:53:57 2018
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed
boot=casper only-ubiquity quiet splash ---
InstallationDate: Installed on 2018-10-18 (0 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64
(20181017.3)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
