resize2fs destroy the content of the partition

[geole0]

Hello
The used version of ubuntu is 19.10
So the used version of ubuntu is GParted 0.32.0
    and the used of resize2fs is 1.45.3 (14-Jul-2019)

I wanted to shrink by 20 GB the size of an old partition created with ubuntu 18.04 and stored on an external hard drive connected by USB3.

The process says it works perfectly well see attachment file
But the partition can no longer be mounted. The message is:
mount: /mnt/sdb2 : wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error.

if I do the stupidity to launch the fsk command to repair, I find all the files and directory in the special directory called Lost + found

Being able to remake the original content, I have seen four times that it gives this unpleasant result.

It also allows me to change the scenario.
- If I use an internal disk partition instead of the external disk, you're fine.
- If I use version 18.04, everything is fine even if I use the external disk
- If I make a new partition on the external disk in version 19.10, I can shrink also without any problem.

So I think there is a software regression for a very specific context.

Thanks.

[Theodore Ts'o (tytso)]

Can you provide a detailed reproduction instructions --- preferably one that I can run myself, so I can see exactly is going on?

One thing that would be helpful is whether this can me reproduced without gpart being part of the mix. That is, can you do something like this:

mke2fs -t ext4 /path/to/fs.img 20G
mount -o loop /path/to/fs.img /mnt
<create files, or not, if it's not needed for the repro>
umount /mnt
e2fsck -fy /path/to/fs.img
resize2fs /path/to/fs.img 30G

If it does require gpart being in the mix, this could very much be a gpart bug, in which case I'll be happy to hand this off to the gpart maintainer.

[Theodore Ts'o (tytso)]

Oh, also please send me the dumpe2fs -h of the partition before you try to resize it, and please send the output of your reproduction with the locale set to POSIX, so I can read the output of e2fsprogs in English, please?

[geole0 (geole0)]

Hello
 I cannot reproduce the incident with this method

export LC_ALL=POSIX
sudo mke2fs -t ext4 /USB1910bis/fs.img 30G
mke2fs 1.45.3 (14-Jul-2019)
Creating regular file /mnt/USB1910bis/fs.img
Creating filesystem with 7864320 4k blocks and 1966080 inodes
Filesystem UUID: 2cf9eafb-628c-45d3-b452-6bdf785ae24d
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
 4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

sudo mount -v -o loop /USB1910bis/fs.img /mnt
mount: /dev/loop12 mounted on /mnt.

#### It is necessary to copy files because when the partition does not contain any, it can shrink without difficulty

sudo ls -ls /mnt
total 20
 4 drwx------ 20 root root 4096 Jan 2 13:20 P2
16 drwx------ 2 root root 16384 Jan 2 12:56 lost+found

sudo umount -v /mnt
umount: /mnt unmounted

sudo e2fsck -fy /USB1910bis/fs.img
e2fsck 1.45.3 (14-Jul-2019)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/USB1910bis/fs.img: 3929/1966080 files (0.4% non-contiguous), 3978206/7864320 blocks

sudo resize2fs /USB1910bis/fs.img 20G
resize2fs 1.45.3 (14-Jul-2019)
Resizing the filesystem on /USB1910bis/fs.img to 5242880 (4k) blocks.
The filesystem on /USB1910bis/fs.img is now 5242880 (4k) blocks long.

sudo e2fsck -fy /USB1910bis/fs.img
e2fsck 1.45.3 (14-Jul-2019)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/USB1910bis/fs.img: 3929/1310720 files (0.4% non-contiguous), 3937075/5242880 blocks

sudo mount -v -o loop /USB1910bis/fs.img /mnt
mount: /dev/loop12 mounted on /mnt.

[Theodore Ts'o (tytso)]

So if the same procedure (with exactly the same files) reproduces reliably when using a partition and gpart --- and it does not reproduce at all, even with multiple attmepts, without gpart, then it is clearly a gpart bug.

[geole0 (geole0)]

Hello
You suggested that I use a file to simulate a partition. I could not highlight the incident.

However, the commands you offer can also be used with a partition. So I no longer need to use gparted.
This highlights that it is the resize command that destroys the partition. Here is the trace below and also in attached file

______________

UNDER UBUNTU1910
.
sudo -i
export LC_ALL=POSIX
mount /dev/sda1 /mnt
ls -ls /mnt
       total 28
        4 drwx------ 20 root root 4096 Jan 5 12:54 P2
        4 drwx------ 20 root root 4096 Jan 5 12:59 P3
        4 drwx------ 20 root root 4096 Jan 5 13:04 P4
       16 drwx------ 2 root root 16384 Jan 5 12:38 lost+found
umount /dev/sda1
e2fsck -f /dev/sda1
          Pass 1: Checking inodes, blocks, and sizes
          Pass 2: Checking directory structure
          Pass 3: Checking directory connectivity
          Pass 4: Checking reference counts
          Pass 5: Checking group summary information
          bug_1857914: 11765/3932160 files (0.4% non-contiguous), 11842526/15728640 blocks
resize2fs -p /dev/sda1 50G
          resize2fs 1.45.3 (14-Jul-2019)
          Resizing the filesystem on /dev/sda1 to 13107200 (4k) blocks.
          Begin pass 2 (max = 2580320)
          Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
          Begin pass 3 (max = 480)
          Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
          Begin pass 4 (max = 5606)
          Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
          The filesystem on /dev/sda1 is now 13107200 (4k) blocks long.
e2fsck /dev/sda1
          e2fsck 1.45.3 (14-Jul-2019)
          Superblock has an invalid journal (inode 8).
          Clear<y>? cancelled!
          e2fsck: The journal superblock is corrupt while checking journal for bug_1857914
          e2fsck: Cannot proceed with file system check
dumpe2fs -h /dev/sda1
          dumpe2fs 1.45.3 (14-Jul-2019)
          Filesystem volume name: bug 1857914
          ....................
          dumpe2fs: Inode checksum does not match inode while reading journal inode
mount /dev/sda1 /mnt
          mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.
dmesg | tail -2
      [ 2319.145382] EXT4-fs error (device sda1): ext4_get_journal_inode:4751: inode #8: comm mount: iget: checksum invalid
      [ 2319.176425] EXT4-fs (sda1): no journal found

[Theodore Ts'o (tytso)]

Can you provide an exact set of commands to create the file system, populate the file system, that *anyone* (but especially, the developers that you are asking to looking at the bug) to replicate this failure? In particular, how is the file system is created (the exact mke2fs command) and the set of files that were used to populate the file system. Is it sensitive to the set of files?

Also, can you replicate it on some other storage device? If the exact sequence on a normal file doesn't reproduce, but it does on a hardware device, the first question that comes to mind is whether there is something wrong with the storage device --- since it really shouldn't make the difference whether you are using a file system image versus an external storage device.

[geole0 (geole0)]

Hello
It took me a little while to reproduce the incident.
I only wanted to put what seemed to me the minimum necessary.
But I couldn't reproduce the incident.
So I replayed the initial scenario. I also couldn't rebuild.
So I destroyed the inaccessible partition to make a new one now called SDB1

You will find attached a file containing all the commands executed as well as some returns and three trace files for returns of certain commands.

You will find that I did at the same time for another partition which has no errors.

At the beginning the order of the partitions was 1 2 3 4. The error was on the partitions 2 and 3 but the partition 1 had not been treated.
I deleted partition 1 to put it at the end of the disk. I was never able to cause the incident.
So I deleted partitions 1 and 3. I just recreated them.

My opinion is that the bug is triggered for partitions stored at the beginning of the disc !!!

Good research.

[geole0 (geole0)]

Hello.

The problem is more complicated or simpler than I thought.

I tried again.
A) With version 18.04.3
  Formatting SDB1, SDB2 and SDB3
Creation of the P1, P2, P3 and P4 directories in the 3 partitions.
B) Reboot with version 19.10.
Deletion of the P1 directories in the three partitions.
Shrinking of the 3 partitions.
The partition SDB1 is destroyed but SDB2 and SDB3 are correct.
C) Reboot with version 19.10
Deletion of P2 directories in the two operational partitions.
Shrinking of the 2 partitions.
The partition SDB2 is destroyed but SDB3 is correct.
D) Reboot with version 19.10.
Shrinking of the SDB3 partition.
The SDB3 partition is correct.
E) Reboot with version 19.10
Creation of a P5 directory in SDB3
Copy files from the remaining SDB3 directory.
Delete old directory.
Shrinking of the SDB3 partition.
The SDB3 partition is now destroyed.

[geole0 (geole0)]

Hello
I progressed in the reproduction of the incident which I know how to do systematically.
It seems to me that resize2fs is part of the incident by forgetting to control something.

I can raise with a debugging option.
Which advise me you?

In attachment you will find the script of the four commands executed

Thank you for your support.

[geole0 (geole0)]

Something strange in journalctl
janv. 24 09:02:03 a sudo[2658]: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/sbin/e2fsck -f -y -v /dev/sdb4
janv. 24 09:02:04 a sudo[2667]: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/sbin/resize2fs -P /dev/sdb4
janv. 24 09:02:04 a sudo[2672]: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/sbin/resize2fs -p /dev/sdb4 36496384k
janv. 24 09:06:21 a kernel: sd 6:0:0:0: [sdb] tag#11 uas_eh_abort_handler 0 uas-tag 2 inflight: OUT
janv. 24 09:06:21 a kernel: sd 6:0:0:0: [sdb] tag#11 CDB: Write(10) 2a 00 1e 00 0c 08 00 04 00 00
janv. 24 09:06:23 a sudo[2893]: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/sbin/e2fsck -f -n -v /dev/sdb4

[geole0 (geole0)]

maybe a link with this option that i never used
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.autosuspend=-1"

[geole0 (geole0)]

Hello

I discovered that if I gradually decrease the partition size by 250 MiB at a time (not tested with 500 MiB), I can shrink the file system to the minimum value indicated without it being broken.

But the end result is very surprising: The partition cannot be reduced. There is a message that advises to enlarge again to the original size !!!

I also opened this exchange : https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1860917

[geole0 (geole0)]

Screen of gparted refuse to reduce https://doc.ubuntu-fr.org/_media/captures/gparted/gpartedtreduce.png