Bug 560191 - rootfstype=ext3 needed for successful boot
rootfstype=ext3 needed for successful boot
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-01-30 02:25 EST by Bruno Wolff III
Modified: 2010-02-01 12:32 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-02-01 12:32:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bruno Wolff III 2010-01-30 02:25:18 EST
Description of problem:
Recently after applying some updates from updates and updates-testing on f12 one of my machines would no longer boot. When getting to the root pivot step mount would complain about needing the fstype specified a few times and then the boot process would stop.
As a work around I added the rootfstype=ext3 boot parameter and things would work normally.
I am not sure what change caused this. It doesn't seem to be the mount command since util-linux-ng hasn't changed recently. It doesn't seem to be dracut or the kernel since boot images that used to work stopped working. udev did change recently but I didn't have time to test that rolling udev back would fix the problem and I won't have hands on access to the machine again until Monday.
I tried reproducing the problem at home, but it doesn't happen on my F12 machine here. The machine it does happen on has ext3 file systems and is x86_64, while the home machine uses ext4 and is i686. Both use an encrypted root file system on top of software raid.

Version-Release number of selected component (if applicable):

How reproducible:
On the problem machine it happens consistently. But it doesn't affect all f12 installations.

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Bruno Wolff III 2010-01-30 13:50:56 EST
I tried this on another system and things worked normally. This machine also was i686 and had ext3 /. So not all machines with an ext3 based / have the problem.
Comment 2 Bruno Wolff III 2010-02-01 12:32:40 EST
The problem machine is now booting properly. udev is still the same, so it probably wasn't that either. But since things are working again, I don't want to put a lot of effort into figuring out what was really broken and then fixed.

Note You need to log in before you can comment on or make changes to this bug.