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
dd if=/dev/zero bs=1k count=10000 of=/home/journal.dat
ls -i /home/journal.dat
chmod 400 /home/journal.dat
chattr +i /home/journal.dat
LABEL=/1 / ext3 noatime,nodiratime 1 1
/dev/sdb8 /home ext3 defaults 1 2
mount -t ext3 /dev/sdb8 /home -o journal=3451
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
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?
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
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
fsck.ext3: Filesystem has unsupported feature(s) while checking ext3 journal for
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
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
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
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.