I had some minor and some not so minor issues upgrading from 9.1 to 9.2 on a test machine (my company laptop) using the method outlined by Buchan at
http://www.pclinuxonline.com/modules.php?name=News&file=article&sid=7018
If someone feels I should add this information to some wiki page please tell me where (no, I won't find the location by myself, sorry, I find wikis difficult to use and never find the information I'm looking for).
Since most of the issues are with urpmi I hope this report is useful to correct them (this is why I'm posting this to cooker). Next week I'll try the update on my main machine (and hopefully put the test machine on cooker), so if you find this report missing or incomplete plese tell me what should I do to give more useful details.
I added a couple of steps of my own to Buchan's method: I took a list of all the packages before the update (rpm -qa | sort | > rpms.mdk91) and after (rpm -qa | sort | > rpms.mdk92). Using these lists I could see which packages weren't updated by urpmi --auto-select (comm -1 -2 rpms.mdk91 rpms.mdk92). More on this later.
Also, instead of using ftp/http urpmi sources, I used local sources (a local 9.2 tree dowloaded with rsync, both main and contribs) plus an ftp source for plf. No updates source at the moment (I'll save that for later, I'll see if the updates are included in the 9.2 tree for the new iso and I'll rsync the tree. Either that or download the updates so I can use them for both machines. No lg cdroms here ;-).
I had an "operator error": the hdlist for plf was old, so urpmi couldn't find some packages. Obviously this isn't an urpmi problem but a pebkac one ;-) (but the error message, or the translation, was misleading since it told me that "all packages could be downloaded").
Let's go for a summary of the problems:
* The "urpmi urpmi" step worked well. After that I had to stop the "urpmi --auto-select" because it was scrolling a bazillion of error messages regarding /var/lib/rpm/PubKeys. Had to remove the file and manually "rpm --import" the keys
* There was some conflict with files with some updated packages. Removed the offending packages and urpmi --auto-select worked well.
* It couldn't update libavifile0.7 libaviplayavcodec (and dependent packages) due to dependencies. I think this is a problem caused by urpmi batching, since when I manually issued an "urpmi libavifile0.7 libaviplayavcodec" it could upgrade both flawlessly. Maybe this problem will be more noticeable on the other machine since it has many more packages installed.
* I had to urpmi all kde packages that weren't updated due to the package split. Not an urpmi problem and not a big deal since I really like the split (so I don't have to install things I don't need) but I'm reporting it since the info could be useful to somebody that didn't follow the issue on the various mailing lists. For the curious what I did was:
urpmi kdebase-konsole urpmi kdebase-kate urpmi kdepim-knotes urpmi kdepim-korganizer urpmi kdenetwork-knewsticker
* Had a problem with cyrus-imapd databases. Don't know if it's because I screwed up with this machine (after all it's a test machine) or because during an upgrade a db_upgrade should be done. Since the databases were for duplicate delivery and tls sessions (thank God I used skiplist for the useful ones) I just removed them. I'll see what happens with the other machine where my real mail is (I'll keep my fingers crossed) (note that this problem has nothing to do with urpmi).
* Then I compared packages before and after the upgrade
comm -1 -2 rpms-mdk91 rpms-mdk92 > not_upgraded
(to get a list of packages that weren't upgraded)
( for i in `not_upgraded` ; do urpmq --sources $i ; done ) 2>&1 | grep 'cap paquet' > orphaned
(to exclude packages that remained the same in 9.1 and 9.2, note that 'cap paquet' is the localized string for 'no package' )
looking at the packages in "orphaned" I found mostly obsolete libs that I subsequently removed (in fact this step was useful to perform a kind of "spring cleaning") but there were some packages that "urpmi --auto-select" failed to upgrade:
gettext
kdeutils
screemurpmi gettext, urpmi kdeutils, urpmi screem solved that but I'm puzzled that urpmi --auto-select didn't find the newer versions by itself.
The versions in 9.1 were:
gettext-0.11.5-2mdk, kdeutils-3.1-9mdk, screem-0.6.0-1mdk
in 9.2:
gettext-0.11.5-7mdk, kdeutils-3.1.3-20mdk, screem-0.6.2-4mdk
Add to the list automake, but that's because of the naming (I had automake1.6 while 9.2 has automake1.7).
* The last issue is that by rebooting (I didn't upgrade the kernel) I had a dead machine: it couldn't find the initrd so it couldn't mount the root directory (since it's xfs). Hopefully one of the older kernels I had could boot, ran lilo from it and the machine went back to life. I don't understand what happened here, really. The other machine has a much more convoluted lilo setup, so I fear it won't be as easy to recover.
Well, I'm impressed by how well the procedure worked. Sure, there were some hurdles and the modification in libraries versions wasn't earth shattering (I wonder if everything would work as well with a major glibc update) but still it's much better that what was available before. Oh, btw, I was using the machine (logged in in X) during the whole process. That's incredible. Kudos to mandrake developers and contributors.
Bye
-- - Yo tambi�n quiero una Europa libre de Patentes de Software - - I want a Software Patents Free Europe too! And you? - --------------------------------------------------------------- EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
pgp00000.pgp
Description: PGP signature
