Bug 560191

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>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	harald, jonathan
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-02-01 17:32:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bruno Wolff III 2010-01-30 07:25:18 UTC

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 18:50:56 UTC

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 17:32:40 UTC

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.