Looks like I need to file a few bugs, though I’m not sure which are causing the others and don’t have great notes except for a few.
Initially some very minor display problems — text at the top part of the installer saying “F11″ was accompanied by some random text. I should review that as that is probably a known problem.
From there the Anaconda install via preupgrade mostly went fine, but Anaconda gets locked up with “/usr/lib/anaconda/gui.py: 538 ….”, basically an assertion that it was trying to set the progress bar to something that was not 0…100. I assumed it was greater than 100 and had to restart my machine.
Numerous kernel oopses — one involving SELinux and another involving gem_set_tiling. Not sure if it’s the video card’s fault or the monitor but that one is way up in the kerneloops reports.
Numerous F10 RPMs left installed, which I manually removed — and also yum thinks my releasever is still 10 which made installing packages somewhat confusing because the instructions indicate to run cleanup commands, when it really should be saying “whoa, horsie, these packages aren’t for your OS”. Finally figured that out after the cleanup commands didn’t do anything. I would have expected the installer to bump the release version. Perhaps this is stuff that was supposed to happen after the install bar got past 100% and didn’t happen. Attempting to fix this caused some nice RPM PANIC messages… not sure what happened there. Perhaps a result of PackageKit coming in and trying to do updates while I was running yum and had to clobber some locks. I think by default PackageKit should be /off/ and only lock up things if you want it to, but that’s just me. (If Fedora is a developer distribution, people probably use the CLI).
In order to get the laptop to work I had to add “xrandr -s 1440×900″ to the GNOME startup sequence, which mostly does the trick. Perhaps there is a better way to force that, though the X.Org detection seems a little whack. Perhaps it was the gem thing and it was related.
(My home machine which I posted about a long while ago went through a lot cleaner — only hitting the problem of not having a good way to recover from not having enough space — which is a sign the preupgrade space detection was not sufficient prior to jumping into the reboot.)
Yay, desktop and upgrade funness. Given this is almost always a little painful (and always different between machines), perhaps this is a good reason for a longer updates cycle and more testing on upgrades versus clean installs? I don’t know.
Another minor annoyance — if you don’t use GDM, you have to re-enter your password to unlock NetworkManager’s access to your keychain once you do “startx” (which I switched to when testing graphics problems) — how to do you turn that off?
Thankfully no LVM-like errors though, which is good — those are some hard ones to get around.
Haven’t tried anything else yet so far.
[...] Original post: Another F-11 Upgrade And Misc Bugs « michaeldehaan.net [...]
Waitaminute. That anaconda “hang” you saw – that message you quote is harmless and happens on every install.
So what was it doing when it “hung”? You didn’t happen to, say, think it must be hung because the “finishing upgrade process” part was taking a really long time, did you? Because, uh, that just takes a really long time, and I’ve gotten a *lot* of bug reports from people who get impatient and reboot before it finishes.
They end up with a bunch of F10 packages still half-installed, and yum thinking they have Fedora 10…
You’re scaring me off from upgrading to 11 =/
But anyways one thing I can answer is the keychain issue. Basically the keychain has an encrypted file on disk using a passphrase, and gdm via a PAM module tries to decrypt it using your login password if they’re the same.
The fact that there’s a separate keychain password is really confusing and poorly explained. The fact that it’s different between KDE and GNOME kind of sucks too of course.
colin: FWIW, I upgraded this system (vaio P) from f10 to f11 with yum, it worked flawlessly. I just don’t usually post ‘upgrade report’ blogs.
Michael: the second issue (anaconda puking up on a progress bar related thing) is known, IIRC. Do a Bugzilla search for some key phrase from the error, it should find it. I think you’re probably right that the install failing to complete caused most of the other problems.
Check /var/log/Xorg.0.log to see what mode X is starting your monitor up in, and possibly why. Also check if it works right if you disable kernel modesetting (‘nomodeset’ as a kernel parameter). File a bug with the relevant info.
Yeah, Will, the last thing in the logs was the progress bar assertion, so I gave it five minutes (it might have taken longer) but I figured the code was hung because it tripped that error condition. It’s very likely I was trying to be /too/ smart and that wasn’t an error that locked up the installer.
I’ll follow up on the Xorg bits to see if I have log data and file that one for sure. I figure the kerneloopses are enough and that those are known — except for maybe the selinux panic one, which I need to turn back on and see if I can repro.
Colin — yeah, I thought it used to be that way as I have a previous install that used to have different ones (changed one password and I had to login twice) though I was confused a bit by /not/ having to do that when they were the same passsword and using gdm — figuring gdm did not send my password along to another app, I guessed they used the same password info now. If they could, I’d like that
(WRT desktop info, also tried KDE4 seeing some people suggested it… was mainly seeing if the display worked any different to verify it was an X thing … KDE4 was pretty slow but that just might have been KDE, anyway, I like GNOME better anyhow. The detection is somewhat confusing because you sometimes can end up as if you are looking at monitor two, but mostly it’s just that you get half of the screen off the side until you run xrandr… I am really thinking the kernel bug is related and it’s an Intel video problem.)
Thanks all!
Reading Will’s comment again, I would think we could improve the dialog box by trying to say it could take 5-10 minutes (explain what long is)… I had inferred the progress bar message was an error because nothing else was printed in the console, and that could also trip up other people who were wondering why it was taking so long. Just a simple “I’m ok, give me a few minutes” after the progress bar message in the log would have not caused me to abort it.
“5-10 minutes” would be misleading. On a lot of systems (slow disks, lots of packages, etc) it can take upwards of 20-30 minutes. Sometimes up to an hour for really bad cases. I’m not sure of the best way to phrase it: “Yes, this will take a long time, and yes, it’s still running. No, we don’t know exactly how long. Don’t get impatient and reboot your system or you will screw up your upgrade. Go outside for a while. I’ll reboot when I’m finished. Really.”
Anyway, part of the plan for F12 is to get better callback info there, so the progress bar actually tells you “300/1075 packages cleaned up” or similar. See the second item here: http://fedoraproject.org/wiki/Anaconda/Features/YuminstallCleanup
@cwalters — that would most definitely solve it, not the long message, but the x/y info.
err, wwoods I mean.