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

Tue Dec 11 11:56:30 CET 2012

'Twas brillig, and Thomas Spuhler at 11/12/12 04:51 did gyre and gimble:
+> On Sunday, December 09, 2012 11:55:13 AM Colin Guthrie wrote:
+>> 'Twas brillig, and Thierry Vignaud at 09/12/12 18:48 did gyre and gimble:
+>>> On 9 December 2012 13:18, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>>>>>> So I've just pushed the package mageia-prepare-upgrade to mga2
+>>>>>> core/updates_testing.
+>>>>>>
+>>>>>> This package, when installed will add a new menu option to your
+>>>>>> bootloader. Simply install this package, reboot, select the "Mageia 3
+>>>>>> Upgrade Preparation" entry boot, wait while your FS is converted and
+>>>>>> then perform a urpmi upgrade as you would normally.
+>>>>>>
+>>>>>> I've not specifically tested the upgrade part, only the installation
+>>>>>> and creation of the initrd and bootloader entries in grub. I've also
+>>>>>> not done this on an mga2 machine yet but will do soon enough.
+>>>>>>
+>>>>>> I just wanted to get this package "out there" for anyone wanting to
+>>>>>> update their mga2 machines to mga3 a3 but not wanting to use the
+>>>>>> installer.
+>>>>>>
+>>>>>> At present there are a few limitations:
+>>>>>>
+>>>>>> 1. It requires kernel 3.3.8-2.mga2 to be installed (any flavour should
+>>>>>> work). A specific kernel version is not really 100% necessary but it
+>>>>>> does mean I can add hard requires to the package. This is only
+>>>>>> desirable to prevent the situation where users install this upgrade
+>>>>>> package but do not run it and later remove the kernel used to
+>>>>>> generate the initrd for the bootloader menu item, thus breaking it.
+>>>>>> Any smarter ideas on how to manage this welcome.
+>>>>>>
+>>>>>> 2. If you have /usr in a separate partition and have it mounted ro in
+>>>>>> your fstab, you will have to manually change the fstab to rw for the
+>>>>>> upgrade boot.
+>>>>>>
+>>>>>>
+>>>>>> Happy testing. Let me know if it kills any kittens. Please keep a
+>>>>>> backup etc. etc.
+>>>>>>
+>>>>>> Col
+>>>>>
+>>>>> Thanks Colin.
+>>>>> The conversion works. But then the problem shows, we have no network.
+>>>>> doing a urpmi --download-all --auto-update only downloads the fist 120+
+>>>>> rpms (the ones needed before restart-urpmi
+>>>>>
+>>>>> What is needed is to add some directories and then the network will
+>>>>> start /var/run/netreport
+>>>>> /var/lock/subsystem/network
+>>>>>
+>>>>> I will check after the upgrade if they can be deleted
+>>>>
+>>>> Hmm, yes, I guess after doing the upgrade the various /var/run and
+>>>> /var/lock folders would be nuked. In mga3 they will be created by
+>>>> tmpfiles but not with a simple reboot on mga2...
+>>>>
+>>>> Hmm, I wonder how best to do this... perhaps we could ship updated
+>>>> packages for each of the packages which absolutely *need* this to do the
+>>>> download... or perhaps we could just ship some essential config tweaks
+>>>> in the this mageia-prepare-upgrade file. It shouldn't do any harm to do
+>>>> the latter and it's a bit easier on the QA folk.
+>>>
+>>> Humm we could just package mageia-prepare-upgrade in mga3 and add
+>>> it to urpmi priority list.
+>>> Thus it would also work for people who never apply updates...
+>>> My 2 cents
+>>
+>> Not sure it would help. I mean users have to install it, reboot and then
+>> install the rest...
+>>
+>> Also how does the urpmi priority list work? Does that not require that
+>> we install urpmi first? If so that likely won't work as there is a
+>> chicken and egg scenario that prevents the rpm+urpmi from mga3 being
+>> installed until the fs is updated.
+>>
+>>
+>> Basically, a fully up-to-date mga2 (including rpm package and the
+>> mageia-prepare-upgrade package) + reboot for preparation is needed for a
+>> urpmi-based upgrades to work.
+>>
+>> Col
+> 
+> OK, I started all over again from a completed mga 2 with all updates.
+
+> The requires are: Pizza and beer
+
+:D
+
+> install mageia-prepare-upgrade
+> change sources to cauldron
+
+No need to change sources yet, but no harm in it either.
+
+> reboot with mageia-prepare-ugrade
+> 
+> eat pizza and drink beer, it takes a lot of time to pass all the time-outs
+
+Hmm, this shouldn't take long... Especially if /usr is on the same
+partition as / (it should take < 30s then really as it's "copying" using
+hardlinks which are very quick). What kind of timeouts are you seeing here?
+
+Perhaps remove "silent" and "splash" here to get more verbose output.
+
+> (it will boot into a none graphic shell)
+
+Hmm, interesting. It seems the kernel entry added does not honour the
+vga= argument. Need to work out why that is not propagated from the
+other kernel entries.
+
+> login as root ans then startx
+>  create /var/run and then start the network
+
+Hmm, you need to *create* /var/run? This definitely should not be
+needed. Are you saying you have no /var/run symlink?
+
+This should have been added as part of the conversion process.
+
+Can I ask:
+ 1. Do you have /var on a separate partition?
+ 2. If so, did my updated package allow you to mount it OK in the initrd
+(you can pass rd.break=mount and then check the /sysroot/var dir to see
+if it's mounted - you will have to type "exit" once to actually do the
+mount IIRC).
+ 3. If the conversion is done with rd.break=prepivot, does the
+/sysroot/var/run symlink exist (again you may need to do "exit" once to
+actually trigger the conversion).
+
+If so, then something is later on *removing* the /var/run symlink again.
+
+In my earlier tests it was mandriva-clean-var-run-lock.service that
+killed the symlinks. I made sure to disable it by rm'ing the symlink:
+/lib/systemd/system/sysinit.target.wants/mandriva-clean-var-run-lock.service
+
+I fear it is somehow still running for you and killing of /var/run.
+
+> after network runs, remove the /var/run (otherwise filesystem will not install)
+
+No, /var/run should just be a symlink to /run then filesystem installs
+fine - this is how it's meant to be, but something somewhere is going wrong!
+
+> then use urpmi --auto-update
+> 
+> ( got the message "/"  is mount read-only a few times and had to re-boot and go throught the 
+> /var/run cycle as desribed above)
+
+Something has to be nuking the /var/run symlink on your system.
+
+Does "systemctl status mandriva-clean-var-run-lock.service" indicate
+it's been run? Does
+[/usr]/lib/systemd/system/sysinit.target.wants/mandriva-clean-var-run-lock.service
+still exist somehow?
+
+
+> This got me a full up-to-date cauldron
+
+Glad you made it! Certainly still a few rough edges to get filed down
+tho' :)
+
+
+Thank you very much for testing this!!
+
+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/
+