Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Cannot upgrade F7 system with F9 alpha|
|Product:||[Fedora] Fedora||Reporter:||Orion Poplawski <orion>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||cra, jonstanley, raytodd|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-03-12 18:07:00 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||235706, 430962|
Description Orion Poplawski 2008-01-22 16:39:39 EST
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 system
Comment 1 Orion Poplawski 2008-01-22 16:59:29 EST
rescue mode also cannot mount the F-7 partitions.
Comment 2 Orion Poplawski 2008-01-29 11:58:14 EST
Tried upgrade with current rawhide and got a traceback in upgradeMountFilesystems mountRootPartition().
Comment 3 Ray Todd Stevens 2008-02-18 11:24:36 EST
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 18:41:14 EST
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 18:50:22 EST
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-18 22:12:13 EST
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 13:04:38 EST
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 13:11:06 EST
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-25 22:56:32 EST
Wonder if anyone is actually paying attention to this one.
Comment 10 Ray Todd Stevens 2008-03-02 16:20:23 EST
OK we have movement. What can those of us experiencing this error do to help here?
Comment 11 Jeremy Katz 2008-03-02 16:38:21 EST
(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.
Comment 12 Ray Todd Stevens 2008-03-02 17:16:17 EST
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.
Comment 13 Orion Poplawski 2008-03-12 18:07:00 EDT
This appears to work for me with current rawhide and anaconda 188.8.131.52.
Comment 14 Jon Stanley 2008-03-12 19:24:55 EDT