After a side by side installation, resized filesystem is corrupted

Bug #1798562 reported by Jean-Baptiste Lallement on 2018-10-18
50
This bug affects 6 people
Affects Status Importance Assigned to Milestone
e2fsprogs (Ubuntu)
Critical
Unassigned

Bug Description

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, ...

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)

Jean-Baptiste Lallement (jibel) wrote :
APolihron (apolitech) wrote :

Do you get this screen?

APolihron (apolitech) wrote :

Last night this problem made me go crazy. Because if you install again 2 os's for dual boot the problem will NOT persists. I can't reproduce this problem the second time.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1798562

tags: added: iso-testing
Jean-Baptiste Lallement (jibel) wrote :

@Apolihron, yes but depending on the corruption the system can go into initramfs if it completely fails to boot (your screenshot), it may boot but the FS will be RO, or it may recover transparently and all sort of other side effects are possible.

Jean-Baptiste Lallement (jibel) wrote :

@APoliihron, when it happened to you what was the original operating system that you resized? Was it cosmic on cosmic or something else?

APolihron (apolitech) wrote :

Cosmic entire disk + cosmic auto-resize (install alongside)
P.S uifi version

APolihron (apolitech) wrote :

I had this problem after the uefi fix.in Ubuntu Mate 20181017.1

Rik Mills (rikmills) wrote :

In Kubuntu with Virtualbox, I end up with the resized Cosmic partition bootable and starts, but read is read only.

Plenty of KDE error not being able to write config files to the user home.

Ext4 errors shown in attached screenshot.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Rik Mills (rikmills) on 2018-10-18
Changed in ubiquity (Ubuntu):
importance: Undecided → High

Apparently it's clearly reproducible with Cosmic alongside Cosmic.

Has anyone been able to reproduce with Cosmic alongside something else than Cosmic such as an earlier release, another distribution or operating system?

Łukasz Zemczak (sil2100) wrote :

Just reporting that I was unable to reproduce it in any system combination, even in the original cosmic next to cosmic case. Same for bionic on cosmic, cosmic on bionic, cosmic on fedora. So it seems the issue is not easily reproducible in all cases, must be some specific combination of components and/or race?

APolihron (apolitech) wrote :

Personally I've fone this first install entire disk ->boot in the os and restart it -> install alongside-> boot in the second os and then restart and boot in the first one.all in uefi mode.

With e2fsprogs 1.44.4-2:

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>?

affects: ubiquity (Ubuntu) → e2fsprogs (Ubuntu)
Changed in e2fsprogs (Ubuntu):
importance: High → Critical
tags: added: rls-dd-incoming
description: updated
Theodore Ts'o (tytso) wrote :

Thanks for the very nice repro! I've created a fix which will be going into the maint branch of the e2fsprogs tree. The commit description:

    resize2fs: update checksums in the extent tree's relocated block

    When shrinking an file system, and we need to relocate an inode, the
    checksums in its extent tree must get updated to reflect its new inode
    number. When doing this, we need to do this *after* we update the
    extent tree to reflect any blocks which need to be relocated due to
    the file system shrink operation.

    Otherwise, in the case where only an interior node of the extent tree
    needs to get relocated, and none of the entries in that node need to
    be adjusted, the checksum for that interior node is updated in the old
    copy of that block, and then after the extent tree is updated to use
    the new copy of that interior node, the extent tree is left with an
    invalid checksum.

    This is a relatively rare case, since it requires the following
    conditions to be true:

    *) The metadata checksum feature must be enabled.
    *) An inode needs to be relocated.
    *) The inode needs to have an interior node.
    *) The block for that interior node needs to be relocated.
    *) None of blocks addressed by entries in that interior node needs
        to be relocated.

    When all of these conditions are true, though, the file system is left
    with corrupted with bad checksum for the extent tree block.

    Addresses-Launchpad-Bug: 1798562

    Signed-off-by: Theodore Ts'o <email address hidden>
    Reported-by: Jean-Baptiste Lallement <email address hidden>

I've tested e2fsprogs with this change and it fixes your repro. I also have a regression test in the subsequent commit which reproduces the problem with a smaller test file system.

The attachment "resize2fs: update checksums in the extent tree's relocated block" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers