'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 <[email protected]> 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/
