No problem with the / procedure to convert it to ext3 But for upgrading my /home filesystem to ext3: fsck: Warning... fsck.ext3 for device /dev/sdb8 exited with signal 11. rc.sysinit: Checking filesystems failed fsck: : Filesystem has unsupported feature(s) /dev/sdb8: journal has incompatible features dd if=/dev/zero bs=1k count=10000 of=/home/journal.dat ls -i /home/journal.dat 3451 /home/journal.dat chmod 400 /home/journal.dat chattr +i /home/journal.dat umount /home cat /etc/fstab LABEL=/1 / ext3 noatime,nodiratime 1 1 /dev/sdb8 /home ext3 defaults 1 2 mount -t ext3 /dev/sdb8 /home -o journal=3451 no problem reboot and after the error message for /home mount like an ext3 partition funniest is that when i attempt to mount /home manually like this mount -t ext3 /dev/sdb8 /home there is no problem any idea ? in spite of it nuisance I have the impression that that goes more quickly with ext3. i will do some bonnie benchmark quickly. just want to tell you that recovery of my / was a true happiness after a deliberated reset: EXT3-fs: WARNING: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. EXT3-fs: recovery complete EXT3-fs: mounted filesystem with ordered data mode. ouah, less than one second. the first tests seem promising. to be continued ;-)
Which version of e2fsprogs were you running? Did you get a core dump from it?
e2fsprogs-1.20.WIP.sct-20001207.i386.rpm like precise in README no core dump from it if i can give you some other information, tell me.
e2fsck from that release really should know about all of the new feature bits. Can you run debugfs on /dev/sdb8 and see what the "features" command says is set? Do you get the problem if you just run e2fsck manually on the partition after unmounting it?
debugfs 1.20-WIP, 16-Nov-2000 for EXT2 FS 0.5b, 95/08/09 debugfs: features Filesystem features: has_journal filetype sparse_super ------------------------------------------------------------------ e2fsck result after umount /dev/sdb8: Parallelizing fsck version 1.20-WIP (16-Nov-2000) e2fsck 1.20-WIP, 16-Nov-2000 for EXT2 FS 0.5b, 95/08/09 fsck.ext3: Filesystem has unsupported feature(s) /dev/sdb8: journal has incompatible features fsck.ext3: Filesystem has unsupported feature(s) while checking ext3 journal for /dev/sdb8 Warning... fsck.ext3 for device /dev/sdb8 exited with signal 11. ------------------------------------------------------------------ to be continued
OK, the SEGV needs to be fixed, but I can't see why you would be getting this error in the first place. Could you send me the header of both the journal (dd bs=1k count=1 < /mnt/.../journal.dat > /tmp/ext3.header) and the filesystem (debugfs /dev/sdb8)? You can mail me directly or attach them to the bugzilla report if you want.
Created attachment 6416 [details] dd bs=1k count=1 </home/journal.dat >/tmp/ext3.header : result
what sort of command do i pass to debugfs for ouput header of /dev/sdb8 partition?
Sorry, try "dumpe2fs" instead.
Created attachment 6417 [details] dumpe2fs /dev/sdb8 >/tmp/sdb8.header : result
ext3-0.0.5d with 2.2.18 now. same problem with fsck.
set out again from scratch. same problem with the upgrade of my /home partition appears to be a problem with superblock of these partition. fortunately, no problem to retrogress to ext2. Currently, this is the only problem which I have with ext3-0.0.5d. Have you indices with header's files given to you.
take another partition to convert to ext3 same problem with fsck is there similary reporting problem (than mine)for upgrading existing ext2 partition?
Created attachment 6521 [details] Fix journal superblock initialisation
OK, there was a fairly obvious hole in the initialisation of the journal: I was zeroing the whole of the journal except for the first block. The attached patch should fix it, as well as adding a couple of minor cleanups to the journal init code. This will be in ext3-0.0.5e.
sorry but this patch don' resolve the problem. is not this a problem of e2fsprogs-1.20.WIP.sct-20001207.i386.rpm ?
The journal header you provided has an uninitialised features field. e2fsprogs is (correctly) refusing to touch it because of the unexpected features flags. The SEGV in e2fsprogs is definitely a bug, but it doesn't appear to be the same one that is causing you trouble: a correctly-initialised journal would not cause e2fsck to get confused in the first place! There is another bug in the kernel which was that the compatibility flags were not being correctly tested at mount time. That bug was the only reason you were ever able to mount the filesystem: e2fsprogs was actually doing the right thing by refusing to fsck the device. I'll look into the e2fsck SEGV as a separate bug, but the compatibility bug here definitely looks like a kernel bug at source.