[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/