| |||||||||||||
Various notes on /usr unificationVarious notes on /usr unificationPosted Feb 28, 2012 3:21 UTC (Tue) by pj (subscriber, #4506)Parent article: Various notes on /usr unification
A bit offtopic, but:
> Fedora policy has always said that using the yum tool to update an installation to a newer release of the distribution is not supported; one is supposed to use a CD or the preupgrade tool for that purpose.
...is why I've run debian continuously since 1995 or thereabouts. And when I say continuously, I mean that one system image has survived that long (module restores from backup after failed hardware). And been upgraded (remotely, via ssh or (back in the day) rsh, in most cases!) for that long.
I can't believe the haberdashy distros don't consider this a feature.
(Log in to post comments)
Various notes on /usr unification Posted Feb 28, 2012 8:32 UTC (Tue) by michich (subscriber, #17902) [Link]
In practice yum upgrades work in Fedora. There are users who upgraded all the way through from Fedora Core 1. One just has to read http://fedoraproject.org/wiki/YumUpgradeFaq to learn about the few version-specific gotchas that may have to be handled manually. In Debian you should read upgrade instructions as well (http://www.debian.org/releases/squeeze/amd64/release-note...).
Various notes on /usr unification Posted Feb 28, 2012 17:53 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
Indeed,
With enough care and attentiveness most if not all gotchas for any distribution can be worked around. Based on the information in Chapter 4 and Chapter 5 in that Debian document you reference I wouldn't really call the live Debian upgrade a fire and forget automated process either. You really do need to be aware of that document before you attempt it.
-jef
Various notes on /usr unification Posted Feb 28, 2012 23:36 UTC (Tue) by juliank (subscriber, #45896) [Link]
That's just official release notes. In practice you change your sources.list to point to the new distro, run apt-get update, apt-get upgrade, apt-get dist-upgrade, and reboot. Or at least my upgrade from lenny to squeeze worked like this IIRC.
And if you're running unstable, things are much more easier. You just upgrade once in a while and be happy.
Various notes on /usr unification Posted Feb 28, 2012 23:57 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
Wow.
Uhm okay. I guess reports like this are just fantasy right?
The discussion for this bug:
And I particularly like this upgrade bug
I will standby my previous statements as to anyone who thinks that live upgrading is a fire and forget process on any linux distribution. It is not..especially as the use case in question looks more and more like a median end-user usage case(with median end-users as admins) and less like a production server (with knowledgable admins at the helm making sure they do the necessary pre-upgrade prep)
-jef
Various notes on /usr unification Posted Feb 29, 2012 3:28 UTC (Wed) by foom (subscriber, #14868) [Link]
Shrug, sure, there are edge cases and bugs you could run into. But everyone I know who runs debian does do live upgrades, and it works. The parent comment's "in practice" is, in practice, what you actually do. (And speaking for myself, I don't bother to read the release notes before doing so.)
Now, I don't actually know how things work out in practice for Fedora, but the upgrade page says "Version updates without using anaconda - such as the yum method described here - is unsupported and not recommended!" and "Although upgrades with yum do work, they are not explicitly tested as part of the release process by the Fedora QA and are not documented in the Fedora installation guide."
Maybe that warning is wrong, but it really makes it *sound* like running yum upgrade is something that is not recommended and that is untested. While, in contrast, apt-get on a running system *is* the tested, documented, and supported upgrade mechanism for Debian. They really try to make sure it works properly for most users.
Various notes on /usr unification Posted Mar 5, 2012 22:41 UTC (Mon) by man_ls (subscriber, #15091) [Link] Sounds like a smokescreen to me. All we are saying is that live upgrading a Debian system is supported, while on Fedora it is not. Not that it is flawless.
Various notes on /usr unification Posted Mar 8, 2012 9:28 UTC (Thu) by kragil (subscriber, #34373) [Link]
Stupid Debian-bashing (from a person who probably does not use it)
In place upgrades generally work just great and are supported on Debian. Sure they are not 100% perfect for everyone, but they have been for me.
Your Canonical-bashing is a lot better than this.
Various notes on /usr unification Posted Feb 29, 2012 11:57 UTC (Wed) by etiennez (guest, #53056) [Link]
Seriously, read the release notes before attempting upgrades of your Debian system. I never broke an upgrade because I always do, and a lot of my friends broke their system (not behind repair but still) because they didn't and it seems everybody on the Internet repeat that edit sources.list + apt-get update && apt-get dist-upgrade just works (except when it doesn't).
Important informations I can remember reading in release notes for example: apt-get/aptitude incompatibility that could cause half your system to be uninstalled, recommended upgrade tool (aptitude vs apt-get) for best result, renaming of hard drive device (hd* => sd*), + lots of useful advices to avoid breaking things (packages you should probably upgrade first, etc).
The squeeze upgrade was quite trouble free IIRC, but it is not always the case.
Various notes on /usr unification Posted Feb 29, 2012 4:47 UTC (Wed) by jmalcolm (guest, #8876) [Link]
I have a system that has been upgraded from Red Hat Linux 9 to Scientific Linux 6.2.
Red Hat Linux 9 -> Fedora Core 1 -> FC2 -> FC3 -> FC4 -> FC5 -> Centos 5 -> Scientific Linux 6.2
I must confess though that there are some old 'mailman' mailing lists on that thing that I am afraid to mess with. The way 'mailman' is configured changed somewhere along the way.
Various notes on /usr unification Posted Feb 28, 2012 8:52 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
pj wrote:
> A bit offtopic, but: >> Fedora policy has always said that using the yum tool to update an installation to a newer release of the distribution is not supported; one is supposed to use a CD or the preupgrade tool for that purpose.
> ...is why I've run debian continuously since 1995 or thereabouts.
Upgrading Posted Feb 28, 2012 14:20 UTC (Tue) by corbet (editor, #1) [Link] Note that you don't have to reinstall to get to a new release. Well, I guess RHEL doesn't support major release upgrades, but it's the exception. Fedora does upgrades just fine (modulo the occasional difficulty), but you're supposed to running anaconda from a separate root to do it in the supported way.
Upgrading Posted Feb 28, 2012 21:55 UTC (Tue) by rvfh (subscriber, #31018) [Link]
And it's not like upgrading [K]Ubuntu was always a breeze... Almost every time I have to fix something - though I am probably no typical [Ubuntu] user either.
Various notes on /usr unification Posted Feb 29, 2012 5:01 UTC (Wed) by jmalcolm (guest, #8876) [Link]
I have run RPM systems including Fedora for many years and have never used the install disk to upgrade. I have always used RPM (via Yum, up2date, URPMI, Red Carpet, SMART, or others). It has always gone well.
Well, I have run into package incompatibilities here and there. I would say that knowing how to 'temporarily' break the RPM database has probably been required a couple times along the way. For example, you might have to force the installation or removal of a package that is blocking other change. Or, a newer package might want to overwrite a file that still falls under the dominion of an older package.
My memory of when these have been required is a bit cloudy as I have also done dumb stuff like go from Fedora to RHEL or vice versa. I even went from Mandrake to Fedora once.
Other than a few Scientific Linux and CentOS machines I am mostly off RPM based systems these days though. Having to source from multiple (inevitably incompatible) RPM repositories has always caused more trouble for me than moving from version to version of the OS. I have found it necessary far less often to source foreign packages (or install unmanaged applications) when using Ubuntu or Debian.
I have run into similar issues converting an Ubuntu machine to Debian or back as well. The machine I am typing on was originally an Ubuntu machine, was migrated to Linux Mint, and is now Debian Unstable. The whole migration was nothing more than overwriting sources.list and using 'apt-get' each time.
Various notes on /usr unification Posted Feb 28, 2012 9:07 UTC (Tue) by niner (subscriber, #26151) [Link]
Please note that using a CD or preupgrade tool does not mean a complete reinstallation. It just means that the upgrade should not be done from a running system but by booting a known stable and non-changing system to do the upgrade. It's not as convenient, but still not that bad a situation. At least it allows major changes to the system without endangering the update system itself. For example it's kinda bad if the update removes an obsolete compression library before installing its replacement leaving the system unable to read the package containing said replacement.
It's certainly not impossible to avoid such problems in an on the fly upgrade, but it takes quite some effort. Effort which may be seen as better invested in other features like a solid unattended installation or upgrade process.
Same was true for openSUSE btw. On the fly upgrades tended to work but have only been recommended for the last couple of versions.
Various notes on /usr unification Posted Feb 28, 2012 12:20 UTC (Tue) by Sho (subscriber, #8956) [Link]
Actually I consider preupgrade a much better way to go. To recap, preupgrade works by downloading a bootable installer image, performing a dry-run and then adding the installer as the default option to the bootloader configuration. Then it reboots into the installer, performs the upgrade and reboots again.
The reason this is better is that the system that is being upgraded is offline during the upgrade. A lot of software doesn't support being upgraded while it's running Things can go subtly wrong when files get swapped out underneath running instances, or config files get rewritten by upgrade processes to fit the new version and then the old version overwrites the changes when it's flushing state to disk while quitting. "Being replaced while running" is a scenario very few projects test for.
Various notes on /usr unification Posted Feb 28, 2012 13:06 UTC (Tue) by khim (subscriber, #9252) [Link] "Being replaced while running" is a scenario very few projects test for. Every rule has an exception. Google Chrome (and Chromium) are quite explicitly developed for such usage. Of course "silent upgrades" are their core design decision thus they have to support them. Other projects... are less forgiving. Our Linux support team likes to push upgrades every time you connect [loaned] laptop to a corp network. Firefox often becomes unusable as a result :-( Usually restart fixes it, but once or twice (in last five years) it corrupted profile beyond repair.
Various notes on /usr unification Posted Feb 28, 2012 13:25 UTC (Tue) by Sho (subscriber, #8956) [Link]
One large contingent of software that potentially has problems with in-place upgrades is any KDE application. This is only very, very rarely a real problem in practice, though, so there's no reason to panic. Still, it's good to be aware of it:
Basically, when code evolves, the format of its configuration file will sometimes change. One way to handle existing user config files using the old format is to retain support for reading the old format, and then write out the new format later, and that's indeed what apps often do. However, the KDE platform also contains an alternate mechanism called "kconf_update". With kconf_update, the application developer supplies scripts that will be run to transform a config file from one format into another (either in a simple DSL or something free-form specifying the interpreter), and a section in the config file is used to keep track of what scripts have already been run.
The problem lies in the "will be run" part. KDE sessions run a process called kded, the KDE daemon, which plays host to lightweight plugins that perform a variety of tasks, from holding binary caches of things like the app db to disk space warnings, etc. One of those plugins also watches directories for newly-installed kconf_update scripts and runs them immediately as it discovers them.
However, KDE apps also tend to flush their config out to disk while quitting.
You can see where this goes:
The reason this is very rarely a problem in practice is because config file format changes are rare to begin with, and the changes that do happen often include changing of the config key names, so the number of actual conflicts that occur is very low. But it's a possibility.
And yes, this is definitely a case of bad design.
Various notes on /usr unification Posted Feb 29, 2012 11:53 UTC (Wed) by Lennie (subscriber, #49641) [Link]
I would change the path of the config file and only look at the new path first in the newer version of the program.
Because otherwise things will just go wrong.
Especially if you have several machines with /home on NFS or whatever which don't get upgraded at the exact same time.
Various notes on /usr unification Posted Feb 28, 2012 13:08 UTC (Tue) by drago01 (subscriber, #50715) [Link]
Yeah I don't see preupgrade as worse but actually as a better solution.
Updating the whole OS while it is running sounds to error prone to me (it can work but it is kinda fragile).
Various notes on /usr unification Posted Feb 28, 2012 15:17 UTC (Tue) by sorpigal (subscriber, #36106) [Link]
It may sound error prone but in practice I've had incredibly few issues, not with servers or workstations. I do make sure I shut down outside access for servers to prevent user access during an upgrade. Sometimes you get warnings like "You should shut down X first," which I ignore unless a video driver is involved, and even doing this have had no more than a small handful of issues in the last decade.
It seems like we accidentally managed to make this work nearly without flaw.
Various notes on /usr unification Posted Feb 28, 2012 15:21 UTC (Tue) by Sho (subscriber, #8956) [Link]
Thing is, though, you're power user who is equipped to deal with the breakage in the event that it does arise, so it's a calculated risk for you. A distro may legitimately decide to care about serving users who aren't equipped for it. And in the face of the possibility of breakage, an upgrade process that tries to avoid it sounds like a good idea.
Various notes on /usr unification Posted Feb 28, 2012 23:37 UTC (Tue) by cmccabe (guest, #60281) [Link]
If things get broken by the upgrade, users would simply reboot. And if the issue was the version skew you're worried about, that would fix it.
Does knowing how to press the power button make you a "power user"? If so, I weep for the future of computing.
Various notes on /usr unification Posted Feb 29, 2012 0:57 UTC (Wed) by mgedmin (subscriber, #34497) [Link]
If the upgrade crashes halfway through, there is a chance the machine won't boot.
A power user might fix it (dpkg --configure -a; apt-get install -f; apt-get dist-upgrade).
Various notes on /usr unification Posted Mar 4, 2012 6:25 UTC (Sun) by cmccabe (guest, #60281) [Link]
And if a Boeing 747 crash-lands on top of the computer, that would probably be bad too. But how is it related to what we were talking about?
Just to be clear, the issue we were talking about was version skew in libraries causing applications to misbehave during the upgrade.
Various notes on /usr unification Posted Feb 29, 2012 13:21 UTC (Wed) by sorpigal (subscriber, #36106) [Link] You're not wrong, but I find myself wondering whether, if we've come this far without really trying, it might not be worthwhile to test for this usage and make the "unequipped" users able to do it in relative safety.
Various notes on /usr unification Posted Mar 4, 2012 17:45 UTC (Sun) by dirtyepic (subscriber, #30178) [Link]
> A lot of software doesn't support being upgraded while it's running
I'm going to have to call bullshit on that one. See every rolling distro ever.
> or config files get rewritten by upgrade processes to fit the new version
Well, first of all, don't overwrite config files. Store the new config somewhere else and give the user an interactive diff tool. Second, any service that writes state to a file that would get overwritten on a reinstall is broken. Any service that can't recognize state information from its previous version is broken.
> "Being replaced while running" is a scenario very few projects test for.
Because it rarely causes problems. The majority of Gentoo systems are upgraded continually while in use. The biggest problem I had after upgrading and recompiling every package installed on a system that hadn't been updated in six months, which included major gcc and glibc updates, was Firefox wouldn't open links sent to it from external programs until I restarted it.
|
|||||||||||||