Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
Al 24/03/13 17:02, En/na Luca Olivetti ha escrit: Maybe it's just enough to put it in the wiki, so that one knows what to expect. One small detail I forgot to mention: initially I assigned 1GB of memory to the virtual machine (https://www.mageia.org/en/support/ says 512MB minimum, 2GB recommended), no swap, and eventually urpmi started giving strange errors. Next time I gave 3GB, just to be on the safe side. I suppose that 2GB should be enough. Bye -- Luca
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
Em 25-03-2013 08:54, Luca Olivetti escreveu: One small detail I forgot to mention: initially I assigned 1GB of memory to the virtual machine (https://www.mageia.org/en/support/ says 512MB minimum, 2GB recommended), no swap, and eventually urpmi started giving strange errors. Next time I gave 3GB, just to be on the safe side. I suppose that 2GB should be enough. Of course minimum memory is with swap enabled!
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
Al 24/03/13 13:08, En/na Colin Guthrie ha escrit: 0) In the Mageia 3 Upgrade Preparation NetworkManager stopped working, in its place the network applet was used (after the upgrade both worked). Yeah, this is due to various folders disappearing... I guess I should probably do something clever in that package. Perhaps I could look at the folders in /var/run and their respective owners etc., then write a file in /etc/tmpfiles.d with them detailed. Then when the package is removed again later (automatically as part of the upgrade) this file would be removed. This should mask most of the errors. It's not fool proof but it'll probably be enough to avoid problems in this case. Will add to my TODO :) Maybe it's just enough to put it in the wiki, so that one knows what to expect. Eventually I had to kill dbus-send to go on with the upgrade I guess I'll have to find a way to time this out... perhaps adding --reply-timeout would work. It would be nice if your VM was in a state to be able to test if this has any effect? Sure, I have a snapshot before the update just for that (i.e., I want to be absolutely sure that the upgrade to the final mageia 3 works smoothly before even attempting to upgrade the real machine). The only problem is that the update takes roughly 3 hours. Ping me when you want me to test again. 8) I had some problem rebooting (I was using a konsole in kde), the kde menu bar didn't work, trying to do an acpi shutdown didn't work, text console didn't work. Eventually I just pulled the virtual plug. Yeah one of the many problems related to online updates really :) the reboot command should work, but :) The problem is I already closed the working konsole (silly me) and at that point I couldn't do anything but pull the plug 9) plymouthd complained but I hadn't time to write down the message, it eventually booted fine (but with no graphical menu, probably because the initrd was generated running the Mageia 3 Upgrade Preparation entry). It shouldn't really matter too much to be honest. The upgrade prep option should be almost identical to a regular boot other than an additional check will be done on each boot thereafter. But as rpm-mageia-setup package is removed on upgrade and with it the menu entry, it shouldn't get in the way too much. I performed the update under the Mageia 3 Upgrade Preparation and, since that had no graphical boot, the resulting new kernel also has no graphical boot. To restore it I had to manually run dracut once booted in mageia 3. Maybe I should have performed the update rebooting into the regular mageia 2? The wiki isn't clear about it. Bye -- Luca
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Luca Olivetti at 24/03/13 16:02 did gyre and gimble: I performed the update under the Mageia 3 Upgrade Preparation and, since that had no graphical boot, the resulting new kernel also has no graphical boot. To restore it I had to manually run dracut once booted in mageia 3. Maybe I should have performed the update rebooting into the regular mageia 2? The wiki isn't clear about it. Yeah this is technically a bug! It just doens't copy across the vga= bit for some reason... another item on my TODO list methinks! 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
Al 18/11/12 17:37, En/na Colin Guthrie ha escrit: Happy testing. Let me know if it kills any kittens. Please keep a backup etc. etc. I prepared a virtual machine with the same set of packages I have in the real one with mageia 2 to test the upgrade. Once installed the mageia-prepare-upgrade package, I rebooted using the Mageia 3 Upgrade Preparation entry. Since the instructions don't say anything, I used that same entry to perform the upgrade (should I have rebooted in the original, plain, mageia 2). Anyway, these are the issues I found: 0) In the Mageia 3 Upgrade Preparation NetworkManager stopped working, in its place the network applet was used (after the upgrade both worked). 1) every other transaction complained with this message: p11-kit: invalid config filename, will be ignored in the future: /etc/pkcs11/modules/gnome-keyring-module 2) with less frequency there were these messages (usually 13 in a row, with different 'xxx'). warning: Schema 'xxx' has path 'xxx'. Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated. 3) a handful of packages complained that they couldn't remove files in /var/run (I suppose that's to be expected) 4) some packages took a long time to execute the %post script /bin/systemctl --quiet --try-restart (package) which eventually failed 5) rtkit hung on the %post script dbus-send --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig Eventually I had to kill dbus-send to go on with the upgrade 6) some packages (e.g., cups, rpcbind, networkmanager and others) gave this message Migrating sysvinit service 'xxx' to systemd native unit 'xxx.service' via systemd install rules. Failed to issue method call: File exists 7) there was a file conflict between kipi-plugins and kipi-plugins-htmlexport, I urpmed the latter. 8) I had some problem rebooting (I was using a konsole in kde), the kde menu bar didn't work, trying to do an acpi shutdown didn't work, text console didn't work. Eventually I just pulled the virtual plug. 9) plymouthd complained but I hadn't time to write down the message, it eventually booted fine (but with no graphical menu, probably because the initrd was generated running the Mageia 3 Upgrade Preparation entry). Apart from these problems, it seems the upgrade went well, though I didn't do any extensive testing (just booted it). Bye -- Luca
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Mika Laitio at 16/12/12 17:00 did gyre and gimble: On 12/16/2012 01:55 PM, Thierry Vignaud wrote: On 16 December 2012 12:38, Mika Laitio lam...@pilppa.org wrote: Install started fine and offered that I have about 2200 rpm's to update. During the install some package seemed to hang (I don't remember anymore which one) and I canceled install with ctrl-c and saw message about error in postinst section. I run urpmi.update again and then urpmi auto-select and somehow ended up to situation where all my network interfaces are down maybe b/c kernel-firmware was upgraded first and your network card needs a firmware that is not compatible between different kernels and about 900 rpm's fail to install as some of their dependencies are missing. I tried to download and copy the missing rpm's with another computer to usb stick, but usb fails to mount... (I can not see /dev/sdb, etc... only /dev/sda which is my harddisk) Strange... Probably related to your network issue. You could run modprobe usb_storage (you may also have to load the USB controller modules (see output of lspcidrake -v)) Yes, this indeed helped. modprobe usb_serial and then /dev/sdb* showed up and I was able to mount manually. May be related to fact that udev failed to start. Didn't you reboot to a new kernel which you aborted the installation? What if you boot to an older kernel (eg mga2 one)? Forget to say that I can get to console only from the mageia 3 safe mode grup option which goes directly to console. With normal mageia 3 or older mageia 2 kernel options I will eventually reach the login screen, but login itself always fails with all desktop envs I have and resets itself back to login screen again. (kde4, gnome, lxde, openbox, icewm) Now that I can mount the usb stick and manually copy the missing rpm's to harddrive, can I install these 900 rpm packages from this mga3 safe mode login, or should I create a new Mageia 3 upgrade preparation safe mode option to grup which has this rd.convertfs boot option and boot there for upgrading the rest of the rpm's from mga2 version to mga3? Once the conversion has been done once, it doesn't need to run again (it's safe enough to do so, but it's a no-op and does nothing) The timeout you possibly saw was waiting for a service to restart or similar. Chances are it would have timed out eventually (but that timeout may be up to five minutes). It would be interesting to know which %postinst failed if you still have that info so I can try reproducing the situation and work on a more graceful solution. 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
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. Hi, tested this on yesterday with the up to date mga 2 by installing upgrade prepare rpm and rebooting and selecting the upgrade to mga3 option from grup and then adding the cauldron repositories. Then I started the install with urpmi.update -a urpmi --download-all --auto-select Install started fine and offered that I have about 2200 rpm's to update. During the install some package seemed to hang (I don't remember anymore which one) and I canceled install with ctrl-c and saw message about error in postinst section. I run urpmi.update again and then urpmi auto-select and somehow ended up to situation where all my network interfaces are down and about 900 rpm's fail to install as some of their dependencies are missing. I tried to download and copy the missing rpm's with another computer to usb stick, but usb fails to mount... (I can not see /dev/sdb, etc... only /dev/sda which is my harddisk) Questions: 1) If I copy them missing rpm's to device by using the rescuq disc, do I need to select again the upgrade to mga3 option when booting to mandriva or is it one time operation that has been done in first boot. 2) Is there some trick for getting network up? Now ifconfig command shows only the lo interface. Mika
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On 16 December 2012 12:38, Mika Laitio lam...@pilppa.org wrote: Install started fine and offered that I have about 2200 rpm's to update. During the install some package seemed to hang (I don't remember anymore which one) and I canceled install with ctrl-c and saw message about error in postinst section. I run urpmi.update again and then urpmi auto-select and somehow ended up to situation where all my network interfaces are down maybe b/c kernel-firmware was upgraded first and your network card needs a firmware that is not compatible between different kernels and about 900 rpm's fail to install as some of their dependencies are missing. I tried to download and copy the missing rpm's with another computer to usb stick, but usb fails to mount... (I can not see /dev/sdb, etc... only /dev/sda which is my harddisk) Strange... Probably related to your network issue. You could run modprobe usb_storage (you may also have to load the USB controller modules (see output of lspcidrake -v)) Didn't you reboot to a new kernel which you aborted the installation? What if you boot to an older kernel (eg mga2 one)? Questions: 1) If I copy them missing rpm's to device by using the rescuq disc, do I need to select again the upgrade to mga3 option when booting to mandriva or is it one time operation that has been done in first boot. 2) Is there some trick for getting network up? Now ifconfig command shows only the lo interface.
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On 12/16/2012 01:55 PM, Thierry Vignaud wrote: On 16 December 2012 12:38, Mika Laitio lam...@pilppa.org wrote: Install started fine and offered that I have about 2200 rpm's to update. During the install some package seemed to hang (I don't remember anymore which one) and I canceled install with ctrl-c and saw message about error in postinst section. I run urpmi.update again and then urpmi auto-select and somehow ended up to situation where all my network interfaces are down maybe b/c kernel-firmware was upgraded first and your network card needs a firmware that is not compatible between different kernels and about 900 rpm's fail to install as some of their dependencies are missing. I tried to download and copy the missing rpm's with another computer to usb stick, but usb fails to mount... (I can not see /dev/sdb, etc... only /dev/sda which is my harddisk) Strange... Probably related to your network issue. You could run modprobe usb_storage (you may also have to load the USB controller modules (see output of lspcidrake -v)) Yes, this indeed helped. modprobe usb_serial and then /dev/sdb* showed up and I was able to mount manually. May be related to fact that udev failed to start. Didn't you reboot to a new kernel which you aborted the installation? What if you boot to an older kernel (eg mga2 one)? Forget to say that I can get to console only from the mageia 3 safe mode grup option which goes directly to console. With normal mageia 3 or older mageia 2 kernel options I will eventually reach the login screen, but login itself always fails with all desktop envs I have and resets itself back to login screen again. (kde4, gnome, lxde, openbox, icewm) Now that I can mount the usb stick and manually copy the missing rpm's to harddrive, can I install these 900 rpm packages from this mga3 safe mode login, or should I create a new Mageia 3 upgrade preparation safe mode option to grup which has this rd.convertfs boot option and boot there for upgrading the rest of the rpm's from mga2 version to mga3? Mika
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and AL13N at 11/12/12 19:56 did gyre and gimble: Op dinsdag 11 december 2012 20:27:23 schreef Remy CLOUARD: [...] I presume your setup is such that /var is indeed on a separate partition? Yeah, I don’t see the point of having a separate usr so that one went smoothly. However, having a separate /var is useful even on a desktop for me, because of /var/cache/urpmi (I had aptitude fill my / on a safe-upgrade that ended up not being that safe once so I kinda became paranoid :p) [...] this reminds me... what should we do with /var/cache ? /var/cache/urpmi-proxy could potentially take quite some space... how should i handle that? What do you mean specifically? We don't touch /var/cache with the usrmove, only /var/run and /var/lock. Personally, most of my free space is on /home so my urpmi-proxy is configured to use /home/urpmi-proxy/ instead... 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Thomas Spuhler at 12/12/12 04:34 did gyre and gimble: On Tuesday, December 11, 2012 03:56:30 AM Colin Guthrie wrote: 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 Ahh so that's where the timeout problems occur. OK, that makes sense indeed. Just need to work out when /var/run symlink when missing. Sadly, I need to get systems where this keeps reoccuring, sadly by completing the upgrade fully it now means we can't debug the causes. Hopefully someone will be able to reproduce it on a snapshotted VM so we can reply various scenarios :) 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. Yeah completely understandable. I'm sure we'll find a way to reproduce it in laboratory settings :) 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 Yeah, the mandriva-clean-var-run-lock.service is no longer shipped in cauldron/mga3's initscripts package (with the move to /run it's no longer needed). I'm still confused as to what's causing the problem tho'. I don't suppose you happen to have a left over broken symlink to mandriva-clean-var-run-lock.service somewhere in your /etc/systemd/system/ tree? If so what's the exact path? (you can safely remove it now if it exists). 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Remy CLOUARD at 11/12/12 19:27 did gyre and gimble: If the symlinks disappear and are replaced again by folders, then also make sure you disable mandriva-clean-var-run-lock.service as it helpfully nukes the symlinks (the update does this but perhaps it's somehow been run/re-enabled?) Can’t answer for that, most of the time I never shutdown my laptop, only pm-suspend. I should also mention that each try at installing filesystem resulted in a temporary symlink being created like: lock;50b68005. I assume these symlinks can safely be removed, just thought I would point that out. Yeah those are just temporary names extracted from the package before being mv'ed into place (or rm'ed if a comparison shows they are identical to files/folders already present). They can be safely rm'ed now. 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'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 mag...@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
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On Sun, Dec 09, 2012 at 06:49:03PM +, Colin Guthrie wrote: 'Twas brillig, and Colin Guthrie at 09/12/12 12:14 did gyre and gimble: 'Twas brillig, and Remy CLOUARD at 08/12/12 12:25 did gyre and gimble: ... I’ve followed the procedure and could upgrade my system from 2 to cauldron, but I still have an issue with the filesystem package. Somehow it seems like it fails to move /var/run to /run and /var/lock to /run/lock. I would be glad if there could be a workaround for this. ... The only way out I think would be to manually do the symlink from another install. Could you confirm that ? Actually yes, there is still a problem at present with /var on a separate partition... I need to look into that. So the latest package should mount /var in the initrd in much the same way it does with /usr (not exactly the same but I want to make the changes as unobtrusive as possible and ideally separate from the main dracut package for convenience of updating). I presume your setup is such that /var is indeed on a separate partition? Yeah, I don’t see the point of having a separate usr so that one went smoothly. However, having a separate /var is useful even on a desktop for me, because of /var/cache/urpmi (I had aptitude fill my / on a safe-upgrade that ended up not being that safe once so I kinda became paranoid :p) In order to fix this, simply mv the folders out the way and just do the symlinks manually - it'll mess up the current boot, but a reboot should fix it. That’s what I did indeed, then I could upgrade filesystem, thanks for the answer ;) If the symlinks disappear and are replaced again by folders, then also make sure you disable mandriva-clean-var-run-lock.service as it helpfully nukes the symlinks (the update does this but perhaps it's somehow been run/re-enabled?) Can’t answer for that, most of the time I never shutdown my laptop, only pm-suspend. I should also mention that each try at installing filesystem resulted in a temporary symlink being created like: lock;50b68005. I assume these symlinks can safely be removed, just thought I would point that out. Thanks for your help ! Regards, Cheers Col -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
Op dinsdag 11 december 2012 20:27:23 schreef Remy CLOUARD: [...] I presume your setup is such that /var is indeed on a separate partition? Yeah, I don’t see the point of having a separate usr so that one went smoothly. However, having a separate /var is useful even on a desktop for me, because of /var/cache/urpmi (I had aptitude fill my / on a safe-upgrade that ended up not being that safe once so I kinda became paranoid :p) [...] this reminds me... what should we do with /var/cache ? /var/cache/urpmi-proxy could potentially take quite some space... how should i handle that?
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
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 mag...@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
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
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 mag...@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 install mageia-prepare-upgrade change sources to cauldron reboot with mageia-prepare-ugrade eat pizza and drink beer, it takes a lot of time to pass all the time-outs (it will boot into a none graphic shell) login as root ans then startx create /var/run and then start the network after network runs, remove the /var/run (otherwise filesystem will not install) 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) This got me a full up-to-date cauldron -- Best regards Thomas Spuhler
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Thomas Spuhler at 08/12/12 22:51 did gyre and gimble: On Sunday, November 18, 2012 09:37:43 AM Colin Guthrie wrote: Hi, As many of you know, upgrading from Mageia 2 is somewhat tricky due to the usr move. With Alpha3 comes the ability for the installer to upgrade the filesystem layout, but many of you (myself included) prefer upgrading via urpmi rather than the installer. While this is possible with some manual commands, it's not as trivial a task as it should be - until now!! 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. Cheers for the report 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Colin Guthrie at 09/12/12 12:18 did gyre and gimble: What is needed is to add some directories and then the network will start /var/run/netreport Hmm, even on my mga2 system, I have the following in /etc/tmpfiles.d/initscripts.conf: d /var/run/netreport 0775 root root - This should mean that on a fresh boot, the folder should be created for you on boot by systemd-tmpfiles-setup.service. /var/lock/subsystem/network Actually, re the latter one in the list there, are you sure about it? I have no such folder on my Mga2 systems nor my Mga3 one. Are you perhaps referring to a /var/lock/subsys/network file? So I'm a little confused as to why you needed to create these by hand :s 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On 9 December 2012 13:18, Colin Guthrie mag...@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
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Colin Guthrie at 09/12/12 12:14 did gyre and gimble: 'Twas brillig, and Remy CLOUARD at 08/12/12 12:25 did gyre and gimble: On Sun, Nov 18, 2012 at 04:37:43PM +, Colin Guthrie wrote: Hi, [...] So I've just pushed the package mageia-prepare-upgrade to mga2 core/updates_testing. [...] Happy testing. Let me know if it kills any kittens. Please keep a backup etc. etc. Col Hi Colin, I’ve followed the procedure and could upgrade my system from 2 to cauldron, but I still have an issue with the filesystem package. Somehow it seems like it fails to move /var/run to /run and /var/lock to /run/lock. I would be glad if there could be a workaround for this. Here is a debug output of urpmi: # export LC_ALL=C # export LANG=C # urpmi --debug filesystem error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory error: filesystem-2.1.9-18.mga3.x86_64: install failed error: filesystem-2.1.9-17.mga2.x86_64: erase skipped unlocking urpmi database unlocking rpm database EXITING (pid=11661) The only way out I think would be to manually do the symlink from another install. Could you confirm that ? Actually yes, there is still a problem at present with /var on a separate partition... I need to look into that. So the latest package should mount /var in the initrd in much the same way it does with /usr (not exactly the same but I want to make the changes as unobtrusive as possible and ideally separate from the main dracut package for convenience of updating). I presume your setup is such that /var is indeed on a separate partition? In order to fix this, simply mv the folders out the way and just do the symlinks manually - it'll mess up the current boot, but a reboot should fix it. If the symlinks disappear and are replaced again by folders, then also make sure you disable mandriva-clean-var-run-lock.service as it helpfully nukes the symlinks (the update does this but perhaps it's somehow been run/re-enabled?) Cheers 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Thierry Vignaud at 09/12/12 18:48 did gyre and gimble: On 9 December 2012 13:18, Colin Guthrie mag...@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 -- 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On Sun, Nov 18, 2012 at 04:37:43PM +, Colin Guthrie wrote: Hi, [...] So I've just pushed the package mageia-prepare-upgrade to mga2 core/updates_testing. [...] Happy testing. Let me know if it kills any kittens. Please keep a backup etc. etc. Col Hi Colin, I’ve followed the procedure and could upgrade my system from 2 to cauldron, but I still have an issue with the filesystem package. Somehow it seems like it fails to move /var/run to /run and /var/lock to /run/lock. I would be glad if there could be a workaround for this. Here is a debug output of urpmi: # export LC_ALL=C # export LANG=C # urpmi --debug filesystem error: unpacking of archive failed on file /var/lock: cpio: rename failed - Is a directory error: filesystem-2.1.9-18.mga3.x86_64: install failed error: filesystem-2.1.9-17.mga2.x86_64: erase skipped unlocking urpmi database unlocking rpm database EXITING (pid=11661) The only way out I think would be to manually do the symlink from another install. Could you confirm that ? Thanks in advance, Regards, -- 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/ -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On Sunday, November 18, 2012 09:37:43 AM Colin Guthrie wrote: Hi, As many of you know, upgrading from Mageia 2 is somewhat tricky due to the usr move. With Alpha3 comes the ability for the installer to upgrade the filesystem layout, but many of you (myself included) prefer upgrading via urpmi rather than the installer. While this is possible with some manual commands, it's not as trivial a task as it should be - until now!! 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 -- Best regards Thomas Spuhler
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On 18 November 2012 17:37, Colin Guthrie mag...@colin.guthr.ie wrote: 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. Cannot you just made dracut/mkinitrd always include it and just rebuild initrds so that any kernel with work 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. Cannot you just automatically remount / rw?
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On Sunday, November 18, 2012 09:40:21 AM Thierry Vignaud wrote: On 18 November 2012 17:37, Colin Guthrie mag...@colin.guthr.ie wrote: 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. Cannot you just made dracut/mkinitrd always include it and just rebuild initrds so that any kernel with work 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. Cannot you just automatically remount / rw? This is great, but if you are running it on a Virtualbox, it will not work (at least it didn't work 2 weeks ago). The problem is I (you) lose the network connection at the initial 100+ packages upgrade and you cannot finish it. I may try it again after the holidays, but we may need to put a warning out. The other option would be to download everything before the actaul upgrade. -- Best regards Thomas Spuhler
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On 18 November 2012 18:59, Thomas Spuhler tho...@btspuhler.com wrote: 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. Cannot you just automatically remount / rw? This is great, but if you are running it on a Virtualbox, it will not work (at least it didn't work 2 weeks ago). The problem is I (you) lose the network connection at the initial 100+ packages upgrade and you cannot finish it. That's not related to virtualbox. I may try it again after the holidays, but we may need to put a warning out. The other option would be to download everything before the actaul upgrade. urpmi --download-all
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Thierry Vignaud at 18/11/12 16:40 did gyre and gimble: On 18 November 2012 17:37, Colin Guthrie mag...@colin.guthr.ie wrote: 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. Cannot you just made dracut/mkinitrd always include it and just rebuild initrds so that any kernel with work Well yes, this package installs a dracut config snippet that does always include the module. The rebuilding of the initrd is just that - a rebuild under the same name as is always used for the normal kernel - just with the extra convertfs module added. However, it requires special kernel command line to trigger the change and thus the bootloader entry adds the needed params for you. I'm not sure it would be a good idea to make any boot silently do the conversion. 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. Cannot you just automatically remount / rw? Yup it would of course be possible, however I'm not sure it's a good idea. I mean users who have chosen to have both a separate /usr and to mount it ro by default are undoubtebly in the minority. They likely do so for very specific reasons. To this end asking them to acknowledge the change very specifically seems to me like the prudent option, rather than silently remounting rw for them. However, if your first point is conceded, you could argue that the user is very specifically requesting a rw setup anyway and that, to me, is likely confirmation enough. So I would likely propose keeping the special menu item, but also changing the convertfs script such that it can be used with a ro /usr silently without any manual intervention. 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Thomas Spuhler at 18/11/12 17:59 did gyre and gimble: This is great, but if you are running it on a Virtualbox, it will not work (at least it didn't work 2 weeks ago). I presume you just mean urpmi upgrading generally rather than anything usr move specific which is the main point in this thread? The problem is I (you) lose the network connection at the initial 100+ packages upgrade and you cannot finish it. I may try it again after the holidays, but we may need to put a warning out. The other option would be to download everything before the actaul upgrade. I've had to deal with similar problems for many years. Either nfs mounts are lost and the path to the install mirror is lost, or named restarts and DNS fails. There are no doubt other paths too, but this is a fairly common issue all the same. Obviously it would be nice to handle it (in all it's causes) more gracefully, but it's not strictly speaking why I started this thread (although I cannot deny it firs the subject :p) 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/
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
Em 18-11-2012 19:12, Thierry Vignaud escreveu: 2 weeks ago). The problem is I (you) lose the network connection at the initial 100+ packages upgrade and you cannot finish it. I may try it again after the holidays, but we may need to put a warning out. The other option would be to download everything before the actaul upgrade. urpmi --download-all The important to not get broken upgrades is the GUI that will invite to upgrade. Maybe we should modify it to default check the box download all before upgrade?
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
On 18 Nov 2012 22:13, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Thierry Vignaud at 18/11/12 16:40 did gyre and gimble: On 18 November 2012 17:37, Colin Guthrie mag...@colin.guthr.ie wrote: 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. Cannot you just made dracut/mkinitrd always include it and just rebuild initrds so that any kernel with work Well yes, this package installs a dracut config snippet that does always include the module. The rebuilding of the initrd is just that - a rebuild under the same name as is always used for the normal kernel - just with the extra convertfs module added. However, it requires special kernel command line to trigger the change and thus the bootloader entry adds the needed params for you. I'm not sure it would be a good idea to make any boot silently do the conversion. But you can have the new entry pointing to the non versionned symlinks
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Pascal Terjan at 18/11/12 23:52 did gyre and gimble: On 18 Nov 2012 22:13, Colin Guthrie mag...@colin.guthr.ie mailto:mag...@colin.guthr.ie wrote: 'Twas brillig, and Thierry Vignaud at 18/11/12 16:40 did gyre and gimble: On 18 November 2012 17:37, Colin Guthrie mag...@colin.guthr.ie mailto:mag...@colin.guthr.ie wrote: 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. Cannot you just made dracut/mkinitrd always include it and just rebuild initrds so that any kernel with work Well yes, this package installs a dracut config snippet that does always include the module. The rebuilding of the initrd is just that - a rebuild under the same name as is always used for the normal kernel - just with the extra convertfs module added. However, it requires special kernel command line to trigger the change and thus the bootloader entry adds the needed params for you. I'm not sure it would be a good idea to make any boot silently do the conversion. But you can have the new entry pointing to the non versionned symlinks Yup, that would work I guess. Dunno why I didn't think of that :p 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/
