[SOLVED] Bug in mke2fs or e2fsck man page?

business_kid · 02-18-2019, 11:59 AM

I tried something here and came unstuck. What has the bug? This is in the e2fsck man page

Quote:

-b superblock
Instead of using the normal superblock, use an alternative superblock specified by superblock. This option is normally used
when the primary superblock has been corrupted. The location of backup superblocks is dependent on the filesystem's block‐
size, the number of blocks per group, and features such as sparse_super.

Additional backup superblocks can be determined by using the mke2fs program using the -n option to print out where the
superblocks exist, supposing mke2fs is supplied with arguments that are consistent with the filesystem's layout (e.g. block‐
size, blocks per group, sparse_super, etc.).

If an alternative superblock is specified and the filesystem is not opened read-only, e2fsck will make sure that the primary
superblock is updated appropriately upon completion of the filesystem check.

So I ran 'mke2fs -n' on a partition as root to find out where the superblocks were, and overwrote it with a new filesystem, destroying all the data. The data loss is of no consequence at all to me, because it is a data partition, I am well backed up, and I am currently restoring it. But it may upset others!!

Which is wrong? mke2fs -n overwriting a filesystem? The e2fsck man page? I'd better report the bug.

crts · 02-18-2019, 12:53 PM

Quote:

Originally Posted by business_kid

I tried something here and came unstuck. What has the bug? This is in the e2fsck man page

So I ran 'mke2fs -n' on a partition as root to find out where the superblocks were, and overwrote it with a new filesystem, destroying all the data. The data loss is of no consequence at all to me, because it is a data partition, I am well backed up, and I am currently restoring it. But it may upset others!!

Which is wrong? mke2fs -n overwriting a filesystem? The e2fsck man page? I'd better report the bug.

From the manpage of mke2fs:

Code:

-n     Causes  mke2fs  to not actually create a filesystem, but display
       what it would do if it were to create a filesystem.  This can be
       used  to  determine the location of the backup superblocks for a
       particular filesystem, so long as  the  mke2fs  parameters  that
       were  passed when the filesystem was originally created are used
       again.  (With the -n option added, of course!)

using the -n option should definitely not damage the filesystem, at least that is how I understand it. Which version of mke2fs are you using? I would like to try and reproduce the bug.

business_kid · 02-18-2019, 02:06 PM

That's where I thought the bug was, but the manpage was a bit woolly, so I wasn't 100% positive.

Code:

bash-4.4$ mke2fs -V
mke2fs 1.44.4 (18-Aug-2018)
	Using EXT2FS Library version 1.44.4

Installed from Slackware64's current iso of December last. My mileage has varied (a lot!) with current, so I have not updated since.

The exact line was

Code:

mke2fs 1.44.4 (18-Aug-2018)
/dev/sda7 contains a ext2 file system


	last mounted on /mnt/virtual on Mon Feb 18 17:43:57 2019
Proceed anyway? (y,N)

If I say 'n' it exits. If I say 'y' it overwrites. I don't think I should be getting that question at all.

EDIT: I can attach the exact package if you need it.

syg00 · 02-18-2019, 04:11 PM

FWIW I have regularly used "-n" successfully to find the backup superblocks for fsck. Never had a problem - open a bug.

crts · 02-18-2019, 04:42 PM

I have tested with 'mke2fs 1.43.1' since I do not use 'current' but just "regular" Slackware64 14.2. I used an image file to test, so not an actual device. There were no damages. After I ran the command I could loop-mount the image and the testfile I had created was still intact. I checked with 'stat' and it had the same modification times, size, inode etc. The content was also intact. I repeated the this procedure several times.

I also get the 'Proceed' question with the '-n' option, the only difference is:

Code:

Proceed anyway? (y,n)

I get a lower-case 'n' for the 'no' option. Not sure if this is of any importance. I would also suggest that you file a bug report. It would be nice if you could provide a link to it afterwards.

business_kid · 02-19-2019, 05:35 AM

OK. First, a warning.

First of all, if anyone is using Slackware's e2fsprogs-1.44.4, compiled Aug 19 2018, and perhaps later versions watch out!

Code:

bash-4.4$ md5sum e2fsprogs-1.44.4-x86_64-1.txz
f7835ebe9bbf51517d1392772dae9fbe  e2fsprogs-1.44.4-x86_64-1.txz

2nd there's a download of e2fsprogs-1.44.4-x86_64-1.txz HERE if anyone wants to play with it.

I would imagine the (y,n) or (y,N) thing was a hint not to proceed, as it had just pointed out the thing had just been mounted (ergo, there was a functional filesystem on it). In my case, no was the default. Pressing return would have selected 'N'

Here's the bug report. Please confirm if you replicate

Paulo2 · 02-19-2019, 07:28 AM

It seems that the 1.44.5 version

Code:

Mon Dec 17 23:02:56 UTC 2018
a/e2fsprogs-1.44.5-x86_64-1.txz:  Upgraded.

doesn't erase the partition, I tested in a VirtualBox vm.

But if you read the messages, it looks like mke2fs really
would erase the partition.

Code:

# mke2fs -n /dev/sda1
mke2fs 1.44.5 (15-Dec-2018)
/dev/sda1 contains a ext4 file system
        last mounted on / on Tue Feb 19 13:12:26 2019
Proceed anyway? (y,N) y
/dev/sda1 is mounted; will not make a filesystem here!

business_kid · 02-19-2019, 01:20 PM

Yep, it sure looks as if it would erase that partition, except you had yours mounted. Lucky you.

Paulo2 · 02-19-2019, 07:01 PM

Quote:

Originally Posted by business_kid

Yep, it sure looks as if it would erase that partition, except you had yours mounted. Lucky you.

Excuse me, I forgot to post the unmounted test.
With unmounted partition it doesn't erase the file system,
despite what the message says.

I think even in a mounted partition it should give a different message.

Output from a test with a Debian partition.

Code:

mke2fs -n /dev/sda3
mke2fs 1.44.5 (15-Dec-2018)
/dev/sda3 contains a ext4 file system labelled 'Debian'
        last mounted on /mnt/Debian on Sat Feb 16 20:02:32 2019
Proceed anyway? (y,N) y
Creating filesystem with 8160768 4k blocks and 2044000 inodes
Filesystem UUID: cf5ad65e-d4ee-40e7-a92b-0004a6445f8d
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624

# mount /dev/sda3 /mnt/Debian/
# ls /mnt/Debian/
bin                           home            lost+found  root  tmp
boot                          initrd.img      media       run   usr
debian-9.4.0-amd64-DVD-1.iso  initrd.img.old  mnt         sbin  var
dev                           lib             opt         srv   vmlinuz
etc                           lib64           proc        sys   vmlinuz.old

tytso · 02-21-2019, 10:14 AM

Hi, e2fsprogs maintainer here.

I'm not able to reproduce it either.

We should change mke2fs so it doesn't ask for confirmation for mounted file systems and the messages printed by it to be clear that it didn't actually create a file system, so it's less confusing. But I see no problem here.

business_kid · 02-22-2019, 04:09 AM

So I'm left wondering why, but I accept that it's not a bug.