Hi all
This is probably a stupid question, but anyway... If I understood correctly, an upgrade from one distro to the next (say, FC1 to FC2) will never be as good with apt or yum as it is with anaconda. Anaconda knows much more about the process, which packages need to be removed, which packages need to be installed, and what needs to be done to the system (ie all the SELinux labelling stuff)
But online upgrade is really extremely useful, especially for a distro with a 6 months release cycle (I've recently heard Debian users boast --again-- about that) Well, if anaconda can handle the process when it is run from the CDRom, would it be possible to make it do its job from a running system ? I suppose it is not possible right now, but would it be possible to just download the isos, mount them on a loopback device, and launch anaconda from there ? If needed, it could require a reboot at the end of the process, etc... Are there operations which need to be done on an unmounted filesystem ? If yes, they could be done by a "very-first-start" program after anaconda's work, or even something loaded in RAM.
I have no idea whether this is possible or not, because I don't know anaconda's design. If this is the most stupid proposition you've ever heard, please ignore this. If it is technically impossible, please tell me. If there are better solutions to upgrade an online system, please tell me too. But if it is possible (for FC4 or even FC3), this would really rock. Thanks for your attention.
Aurélien
Well, if anaconda can handle the process when it is run from the CDRom, would it be possible to make it do its job from a running system ?
the really hard nut to crack is that from the cdrom, anaconda runs the *new* kernel, while in a live upgrade by definition you run the *old* kernel. Debian can do this because they still ship a 2.2 kernel :)
Am Do, den 29.04.2004 schrieb Arjan van de Ven um 12:34:
Well, if anaconda can handle the process when it is run from the CDRom, would it be possible to make it do its job from a running system ?
the really hard nut to crack is that from the cdrom, anaconda runs the *new* kernel, while in a live upgrade by definition you run the *old* kernel. Debian can do this because they still ship a 2.2 kernel :)
Just a stupid thought, but couldn't that be solved by using a 2.6 kernel running in user-space?
Overall I too would like to update my system to the newest, by simply doing an apt-get dist-upgrade (or something similar). But I see that the work involved in coding that simply isn't worth it. Especially, because you would still need to reboot anyway.-Of course, if you could get things to update without rebooting you would have a serious argument against every other distro and of course winxxxx. But imho that should be impossible (Changing the kernel in a running system that is.)
-Thomas-
On Thu, 2004-04-29 at 21:45 +0000, Thomas Hille wrote:
Am Do, den 29.04.2004 schrieb Arjan van de Ven um 12:34:
Well, if anaconda can handle the process when it is run from the CDRom, would it be possible to make it do its job from a running system ?
the really hard nut to crack is that from the cdrom, anaconda runs the *new* kernel, while in a live upgrade by definition you run the *old* kernel. Debian can do this because they still ship a 2.2 kernel :)
Just a stupid thought, but couldn't that be solved by using a 2.6 kernel running in user-space?
What about the supporting packages you need to have to run 2.6? If you're using LVM, you need updated LVM tools. And newer mkinitrd, modutils, etc. The cascade effect is fairly non-trivial. To the point that it's easier to really just have people upgrade as we currently do.
Jeremy
On Thu, 2004-04-29 at 05:22, Aurelien Bompard wrote:
(I've recently heard Debian users boast --again-- about that)
* debian rant *
Debian users may boast about - but last time I installed Sarge from CD - it would hang the installer at the place where it creates the apt config file because it could not establish a network connection, apparently PPPoE is something they don't want to offer even from CD.
So no problem - I have a dialup modem as well. It couldn't find it - so I told it where it was at - /dev/ttyS4 Still couldn't. I looked in /dev - and they only had stopped at ttyS3
MAKEDEV fixed that. But then it couldn't mount my cdroms to read the packages. Looked - their installer neglected to add an entry in fstab for my cdrom. I fixed that - and now it could mount CD's.
Then partway through the installer - it crapped out on me. It had installed a package that told apt to require the .debs to be signed - but they didn't sign any any of their packages.
Removed that package - and THEN it installed.
I posted these concerns on some debian lists and got flamed to hell about how I must be stupid because everything works for them, all seeming to completely miss the point that I could not network install like they did, because PPPoE wasn't something that worked for that.
Fine - let debian work for them. Let them boast. Debian IMHO use to be a very very good distribution (slink days) - now they seem to be more concerned about filling 12 CD's with software packages than anything else. Like they've lost their focus or something.
Oh well - hopefully the new installer they are talking about will resolve their issues, and users won't have to switch to virtual consoles to create a modem device - or edit their fstab to install from CD. I like the distro when it is installed, I really do. It was one of my first distro's. It's getting there they need to seriously work on.
On Thu, 2004-04-29 at 14:22 +0200, Aurelien Bompard wrote:
This is probably a stupid question, but anyway... If I understood correctly, an upgrade from one distro to the next (say, FC1 to FC2) will never be as good with apt or yum as it is with anaconda. Anaconda knows much more about the process, which packages need to be removed, which packages need to be installed, and what needs to be done to the system (ie all the SELinux labelling stuff)
Actually, SELinux doesn't get set up on an upgrade (intentionally). The main upgrade logic that doesn't appear elsewhere that's in anaconda is some trickiness to get newer packages at times.
Are there operations which need to be done on an unmounted filesystem ? If yes, they could be done by a "very-first-start" program after anaconda's work, or even something loaded in RAM.
There are some operations that require newer libraries and newer kernels, etc. eg, there are a few things now that are 2.6 specific and count on the fact that you're running a 2.6 kernel so that you can be correctly set up to run the 2.6 kernel post-upgrade. Having to do those from within 2.4 is extremely difficult. And you need to use newer rpmlib for some features which then depends on new glibc which depends on ..., etc
Unfortunately, while rolling upgrades can work fine if executed on a regular basis (ie, I run the devel tree and actually update at least once a week and regularly daily), they don't work nearly as well when they're more of a flag day event (eg, from FC1 -> FC2).
Jeremy
On Thu, Apr 29, 2004 at 11:12:01AM -0400, Jeremy Katz wrote:
Actually, SELinux doesn't get set up on an upgrade (intentionally). The main upgrade logic that doesn't appear elsewhere that's in anaconda is some trickiness to get newer packages at times.
BTW, in case anyone's interested, here is my attempt to describe the "trickiness" in English (as of Fedora Core 1): http://www.redhat.com/archives/fedora-devel-list/2004-January/msg00004.html
-Barry K. Nathan barryn@pobox.com
Am Do, den 29.04.2004 schrieb Jeremy Katz um 17:12:
On Thu, 2004-04-29 at 14:22 +0200, Aurelien Bompard wrote:
This is probably a stupid question, but anyway...
Maybe, but with ~3 releases/year and a short "lifetime" of fedora every update cost a lot of time (especially if you have a lot of machines...). I really would like it if it would be possible to update while you can still work with the system.
[...]
Are there operations which need to be done on an unmounted filesystem ? If yes, they could be done by a "very-first-start" program after anaconda's work, or even something loaded in RAM.
There are some operations that require newer libraries and newer kernels, etc. eg, there are a few things now that are 2.6 specific and count on the fact that you're running a 2.6 kernel so that you can be correctly set up to run the 2.6 kernel post-upgrade. Having to do those from within 2.4 is extremely difficult. And you need to use newer rpmlib for some features which then depends on new glibc which depends on ..., etc
Then my stupid question: How hard would it be to update these core packages with on short boot from cd/dvd (~5 min) and install/update all the other packages at the next start parallel to a normal (or restricted) login session?
CU thl
Then my stupid question: How hard would it be to update these core packages with on short boot from cd/dvd (~5 min) and install/update all the other packages at the next start parallel to a normal (or restricted) login session?
+1. If it's too much trouble to support a real online update, then could we reduce the downtime to a minimum ?
Thanks for your explanations.
Aurélien
There were many discussions on this subject when FC1 came out, and back then, people were under the belief that it would work on those flag days. When did things change?
Elliott Wilcoxon
Jeremy Katz wrote:
Unfortunately, while rolling upgrades can work fine if executed on a regular basis (ie, I run the devel tree and actually update at least once a week and regularly daily), they don't work nearly as well when they're more of a flag day event (eg, from FC1 -> FC2).
Jeremy
On Thu, 29 Apr 2004, Elliott Wilcoxon wrote:
There were many discussions on this subject when FC1 came out, and back then, people were under the belief that it would work on those flag days. When did things change?
It's not that it *cannot* be done, it's just a whole lot more difficult to do and support. Speaking as someone who has supported online upgrades (for customized RHL based encrypted systems where anaconda wont work) from RHL7 to RHL9 .. it's been "interesting" at times.
- Panu -
-
Arjan van de Ven -
Aurelien Bompard -
Barry K. Nathan -
Elliott Wilcoxon -
Jeremy Katz -
Michael A. Peters -
Panu Matilainen -
Thomas Hille -
Thorsten Leemhuis