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

Wed Dec 12 05:34:04 CET 2012

On Tuesday, December 11, 2012 03:56:30 AM Colin Guthrie wrote:
+> '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?
+no, same patition. I have / swap and /home
+>  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.
+I only know its not there and that is why the network doesn't start. Also about for other services 
+need to timeout during boot because of the missing /var/run
+> 
+> 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.servic
+> e
+> 
+> I fear it is somehow still running for you and killing of /var/run.
+Could be but I don't know what. I know need the system to do some packaging.
+> 
+> > 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?
+not anymore. Teh problem went away after about 1,000packges have been upgraded or maybe before.
+I still have
+mandriva-boot-links        
+mandriva-save-dmesg
+> 
+> > 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
+
+-- 
+Best regards
+Thomas Spuhler
+