[Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi

Sun Mar 24 13:08:51 CET 2013

Hi,
+
+
+Thanks for detailing your  tests :)
+
+'Twas brillig, and Luca Olivetti at 23/03/13 20:00 did gyre and gimble:
+> Al 18/11/12 17:37, En/na Colin Guthrie ha escrit:
+> 
+>>
+>> Happy testing. Let me know if it kills any kittens. Please keep a backup
+>> etc. etc.
+> 
+> I prepared a virtual machine with the same set of packages I have in the
+> real one with mageia 2 to test the upgrade.
+> Once installed the mageia-prepare-upgrade package, I rebooted using the
+> "Mageia 3 Upgrade Preparation" entry. Since the instructions don't say
+> anything, I used that same entry to perform the upgrade (should I have
+> rebooted in the original, plain, mageia 2).
+> 
+> Anyway, these are the issues I found:
+> 
+> 0) In the "Mageia 3 Upgrade Preparation"  NetworkManager stopped
+> working, in its place the network applet was used (after the upgrade
+> both worked).
+
+
+Yeah, this is due to various folders disappearing... I guess I should
+probably do something clever in that package. Perhaps I could look at
+the folders in /var/run and their respective owners etc., then write a
+file in /etc/tmpfiles.d with them detailed.
+
+Then when the package is removed again later (automatically as part of
+the upgrade) this file would be removed. This should mask most of the
+errors. It's not fool proof but it'll probably be enough to avoid
+problems in this case. Will add to my TODO :)
+
+> 1) every other transaction complained with this message:
+> 
+> p11-kit: invalid config filename, will be ignored in the future:
+> /etc/pkcs11/modules/gnome-keyring-module
+> 
+> 2) with less frequency there were these messages (usually 13 in a row,
+> with different 'xxx').
+> 
+> warning: Schema 'xxx' has path 'xxx'. Paths starting with '/apps/',
+> '/desktop/' or '/system/' are deprecated.
+
+Not really sure about these ones.
+
+
+> 3) a handful of packages complained that they couldn't remove files in
+> /var/run (I suppose that's to be expected)
+
+Yes to be expected, but if my generated tmpfiles config approach is
+taken above then these errors will likely be reduced somewhat.
+
+> 4) some packages took a long time to execute the %post script
+> 
+> /bin/systemctl --quiet --try-restart (package)
+> 
+> which eventually failed
+
+Yeah I'm not sure how to address this better :s
+
+> 5) rtkit hung on the %post script
+> dbus-send --system --type=method_call --dest=org.freedesktop.DBus /
+> org.freedesktop.DBus.ReloadConfig
+> 
+> Eventually I had to kill dbus-send to go on with the upgrade
+
+I guess I'll have to find a way to time this out... perhaps adding
+--reply-timeout would work. It would be nice if your VM was in a state
+to be able to test if this has any effect?
+
+I'm also not 100% sure if this is absolutely needed either... will ask
+upstream.
+
+> 6) some packages (e.g., cups, rpcbind, networkmanager and others) gave
+> this message
+> 
+> Migrating sysvinit service 'xxx' to systemd native unit 'xxx.service'
+> via systemd install rules.
+> Failed to issue method call: File exists
+
+Yeah possibly "safe" but I can maybe fix this better via different
+arguments to systemctl enable  in rpm-helper (i.e. passing --force).
+
+> 7) there was a file conflict between kipi-plugins and
+> kipi-plugins-htmlexport, I urpmed the latter.
+
+Needs to be fixed by KDE people to add a conflict I guess. Possibly
+worth a bug report or just ping neoclust or mikala
+
+> 8) I had some problem rebooting (I was using a konsole in kde), the kde
+> menu bar didn't work, trying to do an acpi shutdown didn't work, text
+> console didn't work. Eventually I just pulled the virtual plug.
+
+Yeah one of the many problems related to online updates really :) the
+"reboot" command should work, but.... :)
+
+> 9) plymouthd complained but I hadn't time to write down the message, it
+> eventually booted fine (but with no graphical menu, probably because the
+> initrd was generated running the "Mageia 3 Upgrade Preparation" entry).
+
+It shouldn't really matter too much to be honest. The upgrade prep
+option should be almost identical to a regular boot other than an
+additional check will be done on each boot thereafter. But as
+rpm-mageia-setup package is removed on upgrade and with it the menu
+entry, it shouldn't get in the way too much.
+
+> Apart from these problems, it seems the upgrade went well, though I
+> didn't do any extensive testing (just booted it).
+
+Thanks again for the tests :)
+
+
+Col
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited http://www.tribalogic.net/
+Open Source:
+  Mageia Contributor http://www.mageia.org/
+  PulseAudio Hacker http://www.pulseaudio.org/
+  Trac Hacker http://trac.edgewall.org/
+