Bug 429758

rescue mode also cannot mount the F-7 partitions.

Tried upgrade with current rawhide and got a traceback in
upgradeMountFilesystems mountRootPartition().

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

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.

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.

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

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.

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.

Wonder if anyone is actually paying attention to this one.

OK we have movement.   What can those of us experiencing this error do to help here?

(In reply to comment #10)
> OK we have movement.   What can those of us experiencing this error do to help
here?

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
things.

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
presentation.

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. 

This appears to work for me with current rawhide and anaconda 11.4.0.50.

confirmed