[Bug 1857914] Re: resize2fs destroy the content of the partition

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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1857914

Title:
  resize2fs destroy the content of the partition

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1857914/+subscriptions