Bug 508644

Summary: preupgrade does not work
Product: [Fedora] Fedora Reporter: Mariano Suárez-Alvarez <mariano.suarezalvarez+bugzilla>
Component: preupgradeAssignee: Seth Vidal <skvidal>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-01 10:45:49 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Mariano Suárez-Alvarez 2009-06-29 05:59:09 EDT
Description of problem:

Packagekitd bugged me a couple of times telling me there was a distro upgrade, 
and at last I decided "well, they much have certainly tried this thing for otherwise it would be sheer madness to have it offered by default to all users out there, so what the hell..." So I clicked "Yes, upgrade the beast".

1.7GiB later, I get a dialog informing me that I need to reboot, so obediently I reboot. After the usual booting line-noise, and the blue screen of anaconda, I get a little dialog telling me that informing me something I cannot read, for it goes away too fast (making me wonder how important it was to show it...) and then a second little dialog, and then a third one on top of the second one telling me that it is trying to download something (a repo list) "Didn't it do that already?" After a couple of minutes it tells me it did not succeed. I go out of gramma-mode, and jump to a virtual console. 
ifconfig tells me the network is not set up, so it is no wonder it is not being able to connect. The documentation on the whole procedure is nowhere to be found, so go to IRC; no one knows anything. Play around for a while. Now preupgrade-cli tells me there is no need to set up the network when doing the preupgrade. If only it kept its word! Google shows up little more than rather old bugs about similar issues, and an ominous claim that wireless, along with such madness as passwords and what not, is not going to work, ever. Ok. Find a wired connection. Reboot into anaconda. Nothing changes. No network, still wants to download something. 

Ah! More digging around shows that for some reason /mnt/sysimage does not contain the partition anaconda should be upgrading, but another Fedora partition. Since preupgrade presents no options, and preupgrade-cli has nothing that seems relevant, google, IRC, wondering why it is not a requirement on all apps to have a man page before getting into the Desktop, bugzilla. 

Ah! Bugzilla tells me that aparently anaconda scans for possible roots, and decides to upgrade the first one it finds, ignoring the '--root-device' option on the 'upgrade' line in /boot/upgrade/ks.cfg that apparently preupgrade put there. Notice that by now I am very much out of gramma-mode, so I guess the year of the Linux desktop for rescheduled for next year? Notice also the advanced UI used in the algorithm: just upgrade whatever might be first on the list of upgradable partitions. At least it did not work, for otherwise my poor partition would have been trashed. How to have anaconda obey the --root-device option? Google, everyone is sleeping on #anaconda, bugzilla. Hmm. Oh well, this is not TYOTLD, so google for the source. git-clone. A speed-code-reading would not have been useless.

Ah! It appears one just cannot tell anaconda to use the partition one wants: it will simply use the first one, despite the fact that according to bugzilla it doesn't. Oh well. Maybe the preupgrade guys could have looked at the code, too. Look for the code which decides whether a partition is a candidate to be the root of an upgradable install.

Ah! Temporarily rename things in that partition, reboot, now anaconda does *not* think that partition is a candidate for upgrading. Good. Actually, now it thinks that *none* of my partitions is upgradable. Not even the one I want to upgrade. Ok. Google, IRC, no man page, lovely icons on the packagekit site. Nothing. So... go back to the source. Thank $DEITY for Guido and his language: if this were C this could be worse. Worse! Having gramma read *C* would be unacceptable---python is much friendlier.

Ah! «can't upgrade the part holding hd: media so why look at it?», quoth the source, so my partition is being ignored, and that is how the list of upgradable partitions ends up being empty. Someone is awake on #anaconda. Ask; aparently anaconda does not upgrade a partition which contains the downloaded repo: one might want to reformat it, and that would probably not work. Ok.
But I do not want to upgrade it. Well. But preupgrade could have told me before downloading 1.7GiB that the whole exercise was just hopeless. By design.

Hmph.



Version-Release number of selected component (if applicable):

This is on an uptodate F10 install.



How reproducible:

The scientist in me made me do everything twices, just to be sure.
So it happens 2 out of 2 times.


Steps to Reproduce:

1. When package kit offers to update F10, accept
2. Wait, wait, wait. Reboot when told to.
3. etc
  

Actual results:

F11 was not installed.


Expected results:

F11 should have been installed.


Additional info:

How can possibly be that _by_default_ users are being offered to upgrade their installed F10s in this conditions? 

At least, the whole procedure is harmless in that nothing is destructed.
Comment 1 Will Woods 2009-06-29 10:49:02 EDT
I think you're running the wrong preupgrade version. You failed to mention which version of preupgrade you're filing a bug against, but:

a) preupgrade 1.1.x uses the the kickstart 'upgrade --root-device=XXX' command to specify which device to use. 1.0 does not.
b) preupgrade-1.0.x tries to specify the root device in the repo name, e.g. 'repo=hd:UUID....:...'. Which would get you into the branch of code involving the "can't upgrade the part holding hd: media so why look at it" comment. Preupgrade 1.1.x doesn't do that.

Please check with:
rpm -q preupgrade

I'm guessing you'll have 1.0.x. If so, please upgrade to 1.1.x and try again.

You may wish to run 'preupgrade --clean' first just to be sure that the old config files don't interfere.
Comment 2 Mariano Suárez-Alvarez 2009-07-01 01:42:45 EDT
It was 1.1.something. The F10 box had all packages updated. Someone handed me a F11 DVD so now I cannot test, sadly.

--clean did not seem to do anything when I tried. I was able to start over the second time I tried because the README at /usr/share/doc lists the places where the state is kept, so I removed everything manually.
Comment 3 Will Woods 2009-07-01 10:45:49 EDT
Given that:

a) all the symptoms described should not be possible unless you are running preupgrade 1.0.x (or have leftover files from a previous 1.0.x run),
b) I cannot reproduce the problem, and
c) you can't reproduce the problem anymore either

I'm afraid there's nothing more that can be done here.

Thanks for the report though, and I'm glad you got your system upgraded.
Comment 4 Mariano Suárez-Alvarez 2009-07-01 15:48:17 EDT
I honestly cannot believe this passed through any kind of QA...