Bug 474484

Summary:	Preupgrade 9-10: Error finding / entry - anaconda doesn't recognize 'ext4dev' root
Product:	[Fedora] Fedora	Reporter:	Alan Schmidt <bucky>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	10	CC:	anaconda-maint-list, wwoods
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:	2009-02-02 16:31:48 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:
Bug Depends On:
Bug Blocks:	446452

Description Alan Schmidt 2008-12-04 00:30:33 UTC

Description of problem:
I attempted to use preupgrade to upgrade from Fedora 9 to Fedora 10, and got the error: "Error finding / entry"

Version-Release number of selected component (if applicable):
preupgrade-1.0.0-1.fc9.noarch
anaconda 11.4.1.62

Steps to Reproduce:
After rebooting into the anaconda install, X started, and a dialog box appeared, stating:

Error finding / entry.
This is most likely means that your fstab is incorrect.
Press OK to exit the installer.

Pressing OK boots me back into Fedora 9, and all is well (which says to me that my fstab is fine).

Also, I'm not sure how it managed to boot into X without /var/tmp, which it couldn't get to without /.

My fstab:
/dev/VolGroup00/LogVol00 /                       ext4dev defaults        1 1
UUID=31df2e3d-8e2f-42aa-9b56-d137eb35eb83 /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0

Output from /sbin/blkid:
/dev/sdb1: UUID="xjni5E-iQnB-vVtz-Crq1-fk9F-uwKB-NfkSVn" TYPE="lvm2pv"
/dev/sda1: LABEL="/boot" UUID="31df2e3d-8e2f-42aa-9b56-d137eb35eb83" TYPE="ext3" SEC_TYPE="ext2"
/dev/sda2: UUID="v32v0w-dk3L-Wkz0-zWRE-2DJw-N8Bh-1JFdYZ" TYPE="lvm2pv"
/dev/sdc1: UUID="V3sl9N-Hf5a-1ZLI-QOX1-nlN4-VB25-c3wYKY" TYPE="lvm2pv"
/dev/mapper/VolGroup00-LogVol00: UUID="3a42e82c-b4d1-4b5b-adba-f8316c7c4c81" TYPE="ext4"
/dev/mapper/VolGroup00-LogVol01: TYPE="swap" UUID="7689f3b9-796f-4484-8d86-e321baaab652"
/dev/VolGroup00/LogVol00: UUID="3a42e82c-b4d1-4b5b-adba-f8316c7c4c81" TYPE="ext4"
/dev/VolGroup00/LogVol01: TYPE="swap" UUID="7689f3b9-796f-4484-8d86-e321baaab652"
/dev/dm-0: UUID="3a42e82c-b4d1-4b5b-adba-f8316c7c4c81" TYPE="ext4"

Comment 1 Alan Schmidt 2008-12-14 05:25:17 UTC

Is there any further information I could supply?

I was thinking at first it was the ext4dev fstype, but that wasn't changed to simply ext4 until 2.6.28, and I think we're still at 2.6.27, so I guess that's ruled out.

I haven't gotten around to bringing an install DVD to this machine yet, so I'll be able to perform interesting diagnostics for a little while, but I'll probably upgrade it, one way or another, some time this week.

What's protocol? Do I mark this issue as closed if I do my upgrade a different way?

Comment 2 Will Woods 2008-12-15 17:21:24 UTC

If you want to give up trying to trace the problem, you can close the bug as WORKSFORME. But I'd like be sure that it's not 'ext4dev' that's the problem before we give up.

Is that 'blkid' output from inside the installer session, or while the system isrunning F9?

Comment 3 Alan Schmidt 2008-12-15 17:47:12 UTC

That's from F9.

I'm not sure how to get a console from inside the installer. I tried Alt+F? (all of them), but no go.

Comment 4 Will Woods 2008-12-15 20:05:36 UTC

Ctrl-Alt-F2 should give you a shell; F3 is anaconda log, F4 is syslog, F5 command output, and F6 is the GUI.

I reproduced this problem locally; as far as I can tell booting into F9 and changing 'ext4dev' to 'ext4' in /etc/fstab fixes the problem. And it's harmless to F9. 

On the other hand, anaconda *should* handle this more gracefully. I'm going to reassign this bug to anaconda - it's likely that the anaconda team has seen this before.

Comment 5 Alan Schmidt 2008-12-16 03:35:52 UTC

Thanks! That's all it took.

Comment 6 Chris Lumens 2009-02-02 16:31:48 UTC

This will be fixed in the next build of anaconda.  Thanks for the bug report.