| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 02 Nov 2011 17:18:57 +0900 From: Akira Fujita <a-fujita@...jp.nec.com> To: Eric Sandeen <sandeen@...hat.com> CC: ext4 development <linux-ext4@...r.kernel.org> Subject: Re: [BUG] e2fsprogs: mke2fs -S and e2fsck cannot recover on ext4 Hi Eric, (2011/10/28 5:02), Eric Sandeen wrote: > On 10/27/11 2:13 AM, Akira Fujita wrote: >> Hi, >> >> If all of the superblock and backup superblocks are corrupted, >> mke2fs -S which reinitializes the superblock and >> group descriptors only is a last resort to recover. >> >> However, on ext4, all of the files are lost with this way. >> Because mke2fs -S for ext4 sets uninit_bg and then later e2fsck regards >> all of block group as uninitialized one so that it can not recover >> with bitmaps. >> >> Of course ext3 can recover all of the files with mke2fsk -S, >> ext4 should be able to recover as well. >> There is a avoidance (see #3 of the reproduce steps) >> but an appropriate fix would be needed for e2fsck. >> >> * Reproduce steps and log are as follows: >> My e2fprogs was e2fsprogs-1.42-WIP >> >> 1. mkfe2s -t ext4 /dev/sdaX >> 2. create some files on ext4 >> 3. mkfe2s -t ext4 -S -b 4096 /dev/sdaX　 >> # This problem does not occur, >> # when we remove uninit_bg feature flag (-O ^uninit_bg). > > It seems to me that the main bug here is that mkfs.ext4 should > never mark blockgroups as uninit, when run with -S. Marking > them uninit goes against the described "not touching the inode > table and the block and inode bitmaps" behavior... Thanks for comment. Yes, I'll add the condition to mkfs.ext4 not to specify -S and uninit_bg feature together. Regards, Akira FUjita > -Eric > >> 4. e2fsck /dev/sdaX >> >> e2fsck 1.42-WIP (16-Oct-2011) >> Backing up journal inode block information. >> >> /dev/sda8 contains a file system with errors, check forced. >> Pass 1: Checking inodes, blocks, and sizes >> Pass 2: Checking directory structure >> Pass 3: Checking directory connectivity >> Root inode not allocated. Allocate<y>? yes >> >> /lost+found not found. Create<y>? yes >> >> Pass 4: Checking reference counts >> Pass 5: Checking group summary information >> Block bitmap differences: -(8483--8486) -(33026--33027) >> Fix<y>? yes >> >> Free blocks count wrong for group #0 (24286, counted=24285). >> Fix<y>? yes >> >> Free blocks count wrong (1030071, counted=1030070). >> Fix<y>? yes >> >> Free inodes count wrong for group #0 (8191, counted=8190). >> Fix<y>? yes >> >> Directories count wrong for group #0 (1, counted=2). >> Fix<y>? yes >> >> Free inodes count wrong (262143, counted=262142). >> Fix<y>? yes >> >> >> /dev/sda8: ***** FILE SYSTEM WAS MODIFIED ***** >> /dev/sda8: 2/262144 files (0.0% non-contiguous), 18506/1048576 blocks >> >> >> As I reported before, e2fsck -b also can not recover with >> backup superblock correctly. >> # http://marc.info/?l=linux-ext4&m=131541543931429&w=2 >> >> Is there any ideas to fix these issues? >> >> Regards, >> Akira Fujita >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in >> the body of a message to majordomo@...r.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Akira Fujita <a-fujita@...jp.nec.com> The First Fundamental Software Development Group, Platform Division, NEC Software Tohoku, Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists