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

[Thomas Spuhler]

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