Bug 474484 - Preupgrade 9-10: Error finding / entry - anaconda doesn't recognize 'ext4dev' root
Preupgrade 9-10: Error finding / entry - anaconda doesn't recognize 'ext4dev'...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
 
Reported: 2008-12-03 19:30 EST by Alan Schmidt
Modified: 2014-01-21 18:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-02 11:31:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alan Schmidt 2008-12-03 19:30:33 EST
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 00:25:17 EST
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 12:21:24 EST
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 12:47:12 EST
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 15:05:36 EST
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-15 22:35:52 EST
Thanks! That's all it took.
Comment 6 Chris Lumens 2009-02-02 11:31:48 EST
This will be fixed in the next build of anaconda.  Thanks for the bug report.

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