Red Hat Bugzilla – Bug 499963
reinstall over existing system fails on Apple hardware
Last modified: 2013-07-02 23:22:06 EDT
Created attachment 343218 [details]
traceback for failure to reinstall
Description of problem:
Installing rawhide into free space on a Powerbook G3 laptop works, but reinstalling over that
Version-Release number of selected component (if applicable):
100% I think (didn't try more than once)
Steps to Reproduce:
1. Select "replace existing system" option during text-mode install
fails with traceback (attached)
should replace old installation
continuation of bug #492154
Does using updates=http://clumens.fedorapeople.org/499963.img fix your problem?
Pardon my ignorance, but I don't understand exactly what I'm supposed to do with this file?
If you have a network connection, at the CD bootloader screen, you just need to append updates= to the boot arguments. Otherwise, you need to copy the updates image onto a USB key and add "updates" to the boot arguments. Doing it via the network really is easiest.
NAK: exact same traceback with this update applied.
what happens if you first delete the previously created partition then recreate them from free space?
Looks like /boot is the culprit either the partition is missing or got some how corrupted during the initial creation?
Well, this is a text-mode install, so it is not offering me the option to fool with the partition table by hand.
Since the previous installation had been working just fine, I kinda doubt the theory that there was something wrong with its /boot partition.
Are you sure the updates image is being used? I don't see how it could be the same traceback given that the code is totally changed around now and you can't get to the startswith() call without at least having an empty string instead of None.
You can verify the updates image is being used if there's /tmp/updates/*.pyc, and there should be some mention of it in your /tmp/anaconda.log file.
Hmmm, I was wondering about the line numbers being the same.
What I see is that it asks me which disk to get updates from, I select /dev/sda, then it says "Reading anaconda updates" for a few seconds and then proceeds with no hint of an error, so at the very least you've got a user interface deficiency here...
After it's crashed, I look into /tmp/updates/ and see 499963.img (as well as a couple of other files that were on my USB stick); but nothing *.pyc. /tmp/anaconda.log has a line "UPDATES device is /dev/sda" but nothing further that seems related.
I think you are probably right that the update wasn't used, but how do I find out why not?
(PS: I'm using the USB stick method because, as usual, NetworkManager is utterly useless in a DHCP-free environment.)
Works for me using 499963.img and current rawhide anaconda (220.127.116.11). I'm installing a new copy of rawhide over itself right now.
After turning on a DHCP server I can confirm that 499963.img seems to fix the problem. I'm still wondering why the non-network approach to installing the update doesn't work.
Also, I notice that the update enables a "use VNC" prompt, which is nice, but if you back up from that the plain text mode is all wonky --- the text box boundary lines are replaced by LATIN1 letters ...
Original problem confirmed fixed in today's rawhide (anaconda .52). Is it useful filing bugs about the other two issues mentioned in comment #10? I do not see the VNC option offered by .52, so I'm unsure if that was just experimental code or something that should work.
Doesn't hurt to file the bugs. I'll close this one since you've confirmed it.