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

[Colin Guthrie]

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/