shrinking previous file systems makes them corrupted

[sudodus]

Booted in UEFI mode, running test example 'Install (auto-resize) in Kubuntu Desktop amd64 in Bionic Daily' the previous file system was shrunk in order to create space for the current one. But it was corrupted and must be fixed.

Workaround: sudo e2fsck -f /dev/sda2

The same thing happened when booted in UEFI mode, running test example 'Install (manual partitioning) in Kubuntu Desktop amd64 in Bionic Daily'

Workaround: sudo e2fsck -f /dev/sda3

(This current operating system's file system was fixed and made bootable again.)

---
tester@tester-SATELLITE-PRO-C850-19W:~$ sudo parted -ls
[sudo] password for tester:
Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
 1 2098kB 317MB 315MB fat32 boot, esp
 2 317MB 20,3GB 20,0GB ext4
 3 20,3GB 45,9GB 25,6GB ext4
 4 45,9GB 107GB 61,4GB ext4

tester@tester-SATELLITE-PRO-C850-19W:~$ sudo lsblk -fm
NAME FSTYPE LABEL UUID MOUNTPOINT SIZE OWNER GROUP MODE
sda 111,8G root disk brw-rw----
├─sda1 vfat 6106-B035 /boot/efi 300M root disk brw-rw----
├─sda2 ext4 d6df56de-4490-4508-beb4-8259dda193c4 18,6G root disk brw-rw----
├─sda3 ext4 e375e0d6-e162-4136-af21-377a635761a8 / 23,9G root disk brw-rw----
└─sda4 ext4 646734a2-45bf-4000-815e-31bbafcdfd29 57,2G root disk brw-rw----
sr0 1024M root cdrom brw-rw----
tester@tester-SATELLITE-PRO-C850-19W:~$ ubuntu-bug ubiquity
---

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
Uname: Linux 4.15.0-29-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: KDE
Date: Thu Jul 26 14:01:38 2018
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/kubuntu.seed boot=casper maybe-ubiquity quiet splash ---
InstallationDate: Installed on 2018-07-26 (0 days ago)
InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Ubuntu QA Website (ubuntuqa)]

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/1783757

[sudodus (nio-wiklund)]

I tested with the corresponding Lubuntu iso file, now released as

lubuntu-18.04.1-desktop-amd64.iso

and it is *not* affected by this bug.

So maybe there is some configuration in Kubuntu's implementation of ubiquity, that is borking the file system that is shrunk in order to create space for Kubuntu.

[Phillip Susi (psusi)]

What exactly does e2fsck say is wrong with the filesystem after resizing? Also can you run it before resizing to make sure it didn't start out damaged?

[sudodus (nio-wiklund)]

As described above, I tested this twice (and after the first test I had repaired it with e2fsck), so at least the second time, it did not start out damaged. (And in both cases, the file systems contained working operating systems.)

I don't remember what was wrong (what e2fsck complained about), so I guess I have to test again ...

[sudodus (nio-wiklund)]

It works, when I install today, and let the installer upgrade to the current program packages from the first point release, kubuntu-18.04.1-desktop-amd64.iso.

I did it in the same computer, but this time I used default choices when possible (so for example US English) and 'install alongside').

I will test also with the current daily iso file ...

[sudodus (nio-wiklund)]

The previous installed system seems to make a difference, or maybe there is a difference between the daily iso file and the first point release.

In comment #6 I had a Lubuntu 16.04.5 LTS system installed, and it was still healthy, when installing Kubuntu bionic (actually from the kubuntu-18.04.1-desktop-amd64.iso file).

Now I split the file system of the installed Kubuntu 18.04.1 LTS, and it was corrupted, when when installing Kubuntu bionic (actually from the current daily live bionic-desktop-amd64.iso file dated August 9).

---
Pass 1: Checking inodes, blocks, and sizes
Inode 3588 extent block passes checks, but checksum does not match extent
        (logical block 36864, physical block 760288, len 1241)
Fix<y>? yes
Inode 69150 extent block passes checks, but checksum does not match extent
        (logical block 12288, physical block 1026593, len 31)
Fix<y>? yes
---

After these fixes, Kubuntu 18.04.1 LTS on /dev/sda4 works again. But the bash history is lost, so we can guess that is was affected by one of the inode errors.

[sudodus (nio-wiklund)]

Now I split the file system of the installed system in /dev/sda5, and it was corrupted, when when installing Kubuntu bionic (actually from the first point release, the kubuntu-18.04.1-desktop-amd64.iso file) into /dev/sda6.

These two last installs were made in Swedish, 'alongside', and in both cases finished by reboot, when the installer finished.

This time I repaired the file system of /dev/sda5 from the installed system in /dev/sda6, and after that it works again. This time the bash history survived after repairing, so some other file(s) resided in the bad inodes.

---
tester@tester-SATELLITE-PRO-C850-19W:~$ sudo e2fsck -f /dev/sda5
e2fsck 1.44.1 (24-Mar-2018)
/dev/sda5: återhämtar journalen
Pass 1: Kontrollerar inoder, block och storlekar
Utsträckningsblocken för inod 25021 klarar kontroller, men kontrollsumman stämmer inte med utsträckningarna
        (logiskt block 9, fysiskt block 4806166, längd 1)
Fixa<j>? ja

Pass 2: Kontrollerar katalogstruktur
Pass 3: Kontrollerar katalogförbindelser
Pass 4: Kontrollerar referensräknare
Pass 5: Kontrollerar gruppsammanfattningsinformation
Antal fria inoder är fel (1782394, räknade=1782393).
Fixa<j>? ja

/dev/sda5: ***** FILSYSTEMET MODIFIERADES *****
/dev/sda5: 200071/1982464 filer (0.1% ej sammanhängande), 2110951/7909704 block
tester@tester-SATELLITE-PRO-C850-19W:~$
---

Conclusion:

Installing both the first point release and the current daily iso file are affected by this bug. It seems that some but not all previous systems (and their versions of ext4 file systems) are affected. When the previous system is Bionic it is affected, which is bad enough to make this bug relevant.