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