Bug 560191

Summary: rootfstype=ext3 needed for successful boot
Product: [Fedora] Fedora Reporter: Bruno Wolff III <bruno>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: harald, jonathan
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-02-01 12:32:40 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.