Red Hat Bugzilla – Bug 135863
Using reiserfs as / results in failure during init
Last modified: 2013-07-02 22:22:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002
Description of problem:
Upgrading FC2 with FCT3 with a RAID 0 reiserfs root partition (BOOT is
ext2) successfully upgrades but results in a critical error during
init. Root partition is mounted RO and fails quota-check dumping user
into a shell. Also trying to select interative start-up seems
impossible. From the shell the root partition can be remounted RW and
the command init 5 will successuflly start the machine. A more stable
work-around can be effected by editing /etc/rc.d/rc.sysinit changing
line 377 to insert -a "X$ROOTFSTYPE" != "Xreiserfs" before the ]
character. This effectively skips the root partition check for
reiserfs root partitions. This is probably not the best solution. As
far as I can tell the problem is related to the resiserfs file system
not the raid array. I understand resierfs is not the preferred
filesystem for Fedora but I think this glitch could be fixed fairly
easily and it would be nice to at least warn people who are using
resierfs before they upgrade.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Upgrade to FC3T3
3.Boot again as often as you wish
Actual Results: Machine fails to boot
Expected Results: Machine boots sucessfully
Any filesystem used should be able to support fsck being called on it;
if reiserfsck is erroring here, that's a bug in reiserfsck.
Sure, I should probably point out that the error message indicates
that fsck.ext2 is called at this point not fsck.resierfs. Calling
fsck.resierfs when dumped into the shell does not result in an error.
I'm not sure why fsck.ext2 is used by the system, but I suspect a
problem in initscripts, not resierfs-utils.
What actually *is* the error message?
The only fsck called is /sbin/fsck, which parcels it out to the appropriate one
for the FS type. What's your /etc/fstab look like?
Well that is part of what has me confused. The problem occurs right
after line 377 in rc.sysinit which why I made the change I did. You
are correct that the lines in rc.sysinit appear to simply call fsck.
However when init runs and it gets to that point fsck.ext2 complains
and returns a rc >= 2 which results in the dump to the console prompt.
That code is a couple of if statements later. Since I've gotten it
fixed I no longer get the messages so I can't copy them out of dmesg
any longer. Fsck.ext2 makes some complaint about invalid filesystem -
no surprise since it is a reiserfs filesystem - but does not actually
seem to run. If you immedately run fsck.reiserfs it doesn't have any
problem. Normally if you run fsck it calls fsck.reiserfs, /etc/fstab
correctly identifies / as reiserfs. However, if I correctly
understand the boot process at this point / is being checked so the
file system the operating system knows about is loaded from /boot and
initrd. Fsck is looking at /initrd/dev/root. Although when you get
to the console prompt the raid 0 reiserfs is mounted at /. Rc.sysinit
is looking at a lot of files that don't seem to exist (/.autofsck ,
etc.) so I don't really know what is going on. Initrd is created by
the installation process and has not been modified. The kernel is the
kernel distributed with FC3T3, it has not been recompiled or modified.
Now my fix works because the $ROOTFSTYPE variable in rc.sysinit is
correctly set with reiserfs, one of the reasons I made that
modification was to check that. I haven't done anything to force it
to resierfs. I'm not sure that reiserfs really wants to be fsck'ed
when mounted RO because it complains and says it is skipping journal
I should probably also add that the reiserfs for / was not created by
the installation process. I understand you can pass use "linux
reiserfs" when making a new install. What I did at some point with an
earlier FC installation was to do a ext3 partition and then tarball
the whole root partition from a rescue boot, create a new partition
and format it reiserfs and then untar the tarball. It seemed to work
at the time.
UPDATE - FC4
Problem did not occur in upgrade to FC4. Problem may be fixed in FC4.
Also I specified reiserfs with the linux command starting upgrade. That may
be required for correct initscripts.