Red Hat Bugzilla – Full Text Bug Listing
|Summary:||rootfstype=ext3 needed for successful boot|
|Product:||[Fedora] Fedora||Reporter:||Bruno Wolff III <bruno>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-02-01 12:32:40 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): udev-145-15.fc12.x86_64 How reproducible: On the problem machine it happens consistently. But it doesn't affect all f12 installations. Steps to Reproduce: 1. 2. 3. 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.