Bug 429758 - Cannot upgrade F7 system with F9 alpha
Summary: Cannot upgrade F7 system with F9 alpha
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F9Blocker F9Beta
TreeView+ depends on / blocked
Reported: 2008-01-22 21:39 UTC by Orion Poplawski
Modified: 2008-03-12 23:24 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-03-12 22:07:00 UTC

Attachments (Terms of Use)

Description Orion Poplawski 2008-01-22 21:39:39 UTC
Description of problem:

Trying to use the F9 alpha rescue iso image to upgrade a F7 system.  It finds
the install on /dev/sda3, but fails when I select it.  Non-grammatical error
message follows:

Error finding / entry.

This is most likely means that your fstab is incorrect.


On VT3 I see things like:

WARNING : fstab file has LABEL=/1, but this label could not be found on any file

Comment 1 Orion Poplawski 2008-01-22 21:59:29 UTC
rescue mode also cannot mount the F-7 partitions.

Comment 2 Orion Poplawski 2008-01-29 16:58:14 UTC
Tried upgrade with current rawhide and got a traceback in
upgradeMountFilesystems mountRootPartition().

Comment 3 Ray Todd Stevens 2008-02-18 16:24:36 UTC
Also experiencing this error.   Also with /dev/sda3.

I am running a URl based install.

The version I am trying to upgrade is a fc5.   Now this is a pretty minimal
system.   It was pulled running, but pull because we needed to add additional
processes, and there was no real available resources (but CPU cycles and memory)
to run them.

here is my fstab

LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot1            /boot                   ext3    defaults        1 2
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
LABEL=SWAP-hde2         swap                    swap    defaults        0 0

Comment 4 Ray Todd Stevens 2008-02-18 23:41:14 UTC
OK interestingly enough I just tried a machine running fc8 that was upgraded
from fc7 and could not get the upgrade to take for this same reason.

definitely seems to be a problem here.

Comment 5 Ray Todd Stevens 2008-02-18 23:50:22 UTC
I have now tried the boot to rescue mode things on three other simi-production
servers.   This includes one which is a natively loaded fc8 machine.   No luck.

One possible hint.  

we generally override the default drive configuration to allow for a bigger swap
drive.   We also generally do not use lvm.

Comment 6 Ray Todd Stevens 2008-02-19 03:12:13 UTC
OK took one of my hanger deck lilly fc5 systems which would not take the
upgrade, and did a fresh install.   That worked.   So it is in the upgrade
process, and not that the hardware will not work with fc9

Comment 7 Ray Todd Stevens 2008-02-20 18:04:38 UTC
I am wondering if this is related to bug  322421 which I reported back in fc7
days, and which was never fixed.

Certainly the drive structure which is causing this is the same.

Comment 8 Ray Todd Stevens 2008-02-20 18:11:06 UTC
I am also wondering if this is someone related to or caused by the line

LABEL=/                 /                       ext3    defaults        1 1

in fstab.

Looking back on my systems that I have done upgrades on in the past which worked
and which ones didn't I seem to see a pattern here is this label not allowing an
upgrade, while specifying the actual volume for the root partition seems to
allow the upgrade to go forward.

Comment 9 Ray Todd Stevens 2008-02-26 03:56:32 UTC
Wonder if anyone is actually paying attention to this one.

Comment 10 Ray Todd Stevens 2008-03-02 21:20:23 UTC
OK we have movement.   What can those of us experiencing this error do to help here?

Comment 11 Jeremy Katz 2008-03-02 21:38:21 UTC
(In reply to comment #10)
> OK we have movement.   What can those of us experiencing this error do to help

If you'd like to debug and get a patch, that'd be great.  Including testing and
debugging.  But just "doesn't work today, doesn't work today, doesn't work
today" notes in bugzilla _don't_ help unless there's something which explicitly
leads you to believe that there's a change from one day to the next.  In fact,
it hurts because we end up having to spend more time on reading and dealing with
bugzilla spam as opposed to actually working on fixing things.

Beyond that, patience is a virtue.  The general cycle of development is "work on
lots of stuff", "fix up the things that break installs", "fix up the things that
break upgrades", "fix lingering bits".  Mostly due to the fact that doing things
in that order is the most efficient and there aren't that many of us working on

Comment 12 Ray Todd Stevens 2008-03-02 22:16:17 UTC
I just feel a little more comfortable now that I see a @redhat, or a comment
that says "my team is working on this" or a question from someone who seems to
be on the team.   The question 9 may be been a bit badly worded and I apologize
for that.   I am a bit your really "normal" nerd. I don't do diplomacy well.  
In retrospect maybe what I should have said was,

"I wonder if this is getting into the in box of the right people to get this
looked at, or if by chance we have accidentally chosen an option that causes it
to get lost."

Part of the reason for this is that I just found out that I filed a bugzilla
report over six months ago with a completely different organization for some
software we used, and unfortunately the person in charge of that particular
component had moved on and nobody had been appointed to take the place.   So
literally nobody was paying attention to these.   I was beginning to wonder
about this one.    Had there been some kind of an acknowledgment of this even
saying "we have to wait on this" comment 9 would not have been here.

Now I have taken some of my still open bugs and tried them on this alpha and
added the results.   I figured that a new release it would be good to know if
the problem still exists and in the same form.   Incidentally of the bugs I have
open about a third seem to be ones that have been fixed and nobody has closed,
and another third seem to be probably the same bug, but with a completely new

As far as debugging.   I certainly will do what I can.   As I have mentioned in
a different bug,  I have time allocated from my company to work specifically on
testing and debugging issues that we will be experiencing on an upgrade.  I
really am not in a position to do much c programming as that is not something
that I cam experienced in. but if there is something that I could do in the way
of debugging this or other issues I certainly am game.  I have a number of
hanger deck lilly machines, to build specific cases on.  As you can see I do try
and add as much information as I can.   I am not sure what is useful and what is
not.  But I don't want to spend a lot of time going down an path you have
already eliminated.

At this point do you need more information?  Specifically do you need us/me to
build up a machine to be upgraded and get it to fail in the manner of this bug,
and then try different volume structures to see if I can get a similar structure
to the failed cases that does work?    I am willing to spend the time on this if
it would help, but don't want to waste my time.   As I said I can do this on the
company dime. 

Comment 13 Orion Poplawski 2008-03-12 22:07:00 UTC
This appears to work for me with current rawhide and anaconda

Comment 14 Jon Stanley 2008-03-12 23:24:55 UTC

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