Discussion:
Proposed F19 Feature: Fedora Upgrade - using yum
(too old to reply)
Jaroslav Reznik
2013-01-23 18:04:03 UTC
Permalink
= Features/FedoraUpgrade =
https://fedoraproject.org/wiki/Features/FedoraUpgrade

Feature owner(s): Miroslav SuchÜ <msuchy at redhat.com>

Upgrade Fedora to next version using yum upgrade.

== Detailed description ==
In past (until Fedora 17) we could upgrade Fedora using Anaconda Upgrade and
PreUpgrade.

Now (in Fedora 18) we have only FedUp and previous methods are obsoleted.

I propose to have FedUp and FedoraUpgrade in Fedora 19.

FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line
upgrade). Some devels say that offline upgrade is only way. But on-line upgrade
is possible. E.g in Debian world it is even prefered method. In Fedora exist
upgrade using yum as unofficial method for long time.

A lot of people are using upgrade using yum for long time and the "problem
ratio" was at least on pair with Anaconda upgrade. In fact most problems comes
from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade
user get file conflict. Once these problems are reported and fixed the upgrade is
without problem.

And since FedUp is just different approach to yum-upgrade, FedUp will benefit
from fixes on FedoraUpgrade (and vice versa).

I propose to support both FedUp and FedoraUpgrade and give user option.

If this method will be tested by FedoraQA, then I believe this upgrade method
can be safely recommended to user.
Lennart Poettering
2013-01-23 18:50:07 UTC
Permalink
Post by Jaroslav Reznik
FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line
upgrade). Some devels say that offline upgrade is only way. But on-line upgrade
is possible. E.g in Debian world it is even prefered method. In Fedora exist
upgrade using yum as unofficial method for long time.
A lot of people are using upgrade using yum for long time and the "problem
ratio" was at least on pair with Anaconda upgrade. In fact most problems comes
from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade
user get file conflict. Once these problems are reported and fixed the upgrade is
without problem.
I'd strongly say "NO" to this. Not because I would have a problem with
people doing non-fedup upgrades (I tend to upgrade my machines with yum
myself, too). However, making this officially supported, and advertising
this as a feature appears to be the wrong move to me.

The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
tried to update the Firefox RPM while it is running knows that this
doesn't end well, and you frequently have to manually kill firefox to
get it back into a usual state.

Doing manual on-line upgrades with "yum distro-sync" is a fine
thing to do, but this requires people to understand that things might go
wrong, and requires a certain skill set from people so that they know
what to do if things go wrong (like for example knowing how to kill
firefox from the command line). But by making this an officially
supported feature fedora would suggest this as something that would work
for anybody, without any additional knowledge, and Fedora would have to
deal with the additional support work/bug burden this creates.

It's OK if an RPM for this enters the archive, it's OK if people who
know how to fix their machines use this, it's OK if people suggest this
as hidden functionality. But I think it would be a big mistake for
Fedora to advertise this as official feature, and to accept the support
burden this creates.

Fedora doesn't have unlimited resources, we have more than enough bugs
to fix anyway, making online updates an officially supported feature
would amplify this disparity.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Kay Sievers
2013-01-23 19:12:45 UTC
Permalink
On Wed, Jan 23, 2013 at 7:50 PM, Lennart Poettering
Post by Lennart Poettering
Post by Jaroslav Reznik
FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line
upgrade). Some devels say that offline upgrade is only way. But on-line upgrade
is possible. E.g in Debian world it is even prefered method. In Fedora exist
upgrade using yum as unofficial method for long time.
A lot of people are using upgrade using yum for long time and the "problem
ratio" was at least on pair with Anaconda upgrade. In fact most problems comes
from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade
user get file conflict. Once these problems are reported and fixed the upgrade is
without problem.
I'd strongly say "NO" to this. Not because I would have a problem with
people doing non-fedup upgrades (I tend to upgrade my machines with yum
myself, too). However, making this officially supported, and advertising
this as a feature appears to be the wrong move to me.
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
tried to update the Firefox RPM while it is running knows that this
doesn't end well, and you frequently have to manually kill firefox to
get it back into a usual state.
Doing manual on-line upgrades with "yum distro-sync" is a fine
thing to do, but this requires people to understand that things might go
wrong, and requires a certain skill set from people so that they know
what to do if things go wrong (like for example knowing how to kill
firefox from the command line). But by making this an officially
supported feature fedora would suggest this as something that would work
for anybody, without any additional knowledge, and Fedora would have to
deal with the additional support work/bug burden this creates.
It's OK if an RPM for this enters the archive, it's OK if people who
know how to fix their machines use this, it's OK if people suggest this
as hidden functionality. But I think it would be a big mistake for
Fedora to advertise this as official feature, and to accept the support
burden this creates.
Fedora doesn't have unlimited resources, we have more than enough bugs
to fix anyway, making online updates an officially supported feature
would amplify this disparity.
I, speaking for the stuff I'm involved and maintain, will certainly
not work on things to make online upgrades work correctly, if they
don't for whatever reason.

It's a huge lie to pretend we can reliably do this, and just a
I-hope-it-will-work-out thing not based on the technical reality.
Anybody who claims this can and will always work flawlessly as a
general model, seems not to understand the problems well enough.

We all do these kind of updates ourselves, sure, and we surely don't
want to make that impossible in the future; but it's nothing I
personally would *ever* want to *support* on other people's systems.

There is a reason we partly switched to offline updates now, it can at
least work in the theory behind it, unlike the online updates. Please
never try to *support* that officially, it cannot and will not work
out.

Thanks,
Kay
Michael Scherer
2013-01-23 22:23:00 UTC
Permalink
Post by Lennart Poettering
Post by Jaroslav Reznik
FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line
upgrade). Some devels say that offline upgrade is only way. But on-line upgrade
is possible. E.g in Debian world it is even prefered method. In Fedora exist
upgrade using yum as unofficial method for long time.
A lot of people are using upgrade using yum for long time and the "problem
ratio" was at least on pair with Anaconda upgrade. In fact most problems comes
from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade
user get file conflict. Once these problems are reported and fixed the upgrade is
without problem.
[...]
It's OK if an RPM for this enters the archive, it's OK if people who
know how to fix their machines use this, it's OK if people suggest this
as hidden functionality. But I think it would be a big mistake for
Fedora to advertise this as official feature, and to accept the support
burden this creates.
Yet, there is enough people ( like you, like me ) using it. While I
agree that pushing this as fully supported in all cases do not seems a
wise move, maybe we could restrict to some use cases, like "upgrading a
lxc container with a minimal downtime", or sometimes like that, and see
how it goes.

And the more I think about, the more I think we should rather have a SIG
than a feature ( like the move of arm to PA ) :

- this need to have a specific set of ressources for QA, etc. We cannot
increase QA by magic and should not increase the workload of the current
team, but we cannot forbid to people to test what they want. So as long
as the interested people organize themselves, this would not be a issue

- this is a effort that must be sustained in time. So we need a team of
people to do it. IE, a SIG, not a Feature.

And if this permit to find bugs sooner, this is good because AFAIK fedup
use distro-sync as well.

And having a SIG permit also to direct people who want to do it to see
with the SIG, who can explain the caveats better than "this is not
supported" as it currently is.

If this work for Rawhide (since Kevin is IMHO on a good track for that),
it can work for that too.
--
Michael Scherer
Miroslav Suchý
2013-01-24 14:28:34 UTC
Permalink
Post by Lennart Poettering
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
What could not be restarted? And what we can do to fix that?

If this work for Debian/Ubuntu, why it could not work for Fedora?
Post by Lennart Poettering
tried to update the Firefox RPM while it is running knows that this
doesn't end well, and you frequently have to manually kill firefox to
get it back into a usual state.
Interesting. Although I'm doing yum upgrade quite frequently I do not
have such experience.
--
Miroslav Suchy
Red Hat Systems Management Engineering
Bill Nottingham
2013-01-24 16:22:12 UTC
Permalink
Post by Miroslav Suchý
Post by Lennart Poettering
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
What could not be restarted? And what we can do to fix that?
If this work for Debian/Ubuntu, why it could not work for Fedora?
Essentially, the idea of a major release is to do the sorts of upgrades
that don't work cleanly on a running system. Examples would be:

- mysql database version upgrade (or similar upgrades that require
a format conversion)
- switching out the system python interpreter version
- switching from a static /dev to udev
- switching init systems
- switching a script from being sysv to being a systemd service
- refactoring of a systemd service if necessary
- /usr move
- introduction of changes that require a new kernel subsystem mount
point, or the move of one (/selinux to /sys/fs/selinux, for example)

None of these things are things that will work perfectly reliably in an
on-line upgrade mechanism.

Bill
Lennart Poettering
2013-01-24 23:12:48 UTC
Permalink
Post by Miroslav Suchý
Post by Lennart Poettering
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
What could not be restarted? And what we can do to fix that?
The kernel for starters, dbus too, bash, ssh daemon processes of open
connections, gdm, ...

If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...

Then all code that runs that is not a system service is difficult to
restart from a system script. How do you plan to restart Evolution or
Firefox, or Gimp?

Of course, you can say that it's OK if those processes just stay
running, and then are updated when the user reboots the machine the next
time, or restarts his apps the next time, or logs out and back in the
next time, but until then you have versions of these programs in memory
that might not be able to find their own resources anymore, because
those got replaced, or they might find them in different versions than
they might expect.

But let's pretend for a minute that there was a way how you could
restart the kernel, dbus, and everything else without taking the machine
or user session down, how would you figure out *what* precisely you need
to restart? There are some scripts floating around that try to figure
that out via "ldd", but that's very incomplete, because that assumes the
only kind of dependency that was relevant were shared library deps --
but there are more than that and in times of dlopen() ldd doesn't work
comprehensively for those anyway. Applications have deps on all kinds of
data in /usr/lib, not just shared libraries. Such as locale data, icons,
fonts, artwork, documentation. And much of that might be continously
mapped into memory, and others only temporarily. How are you going to
figure out that?

I mean, here's an example: let's say openssl is updated, which is pulled
in by a ton of other things, for example the libc NSS LDAP module. The
libc NSS is used by at least half of all processes running on your system,
and they all dlopen() the NSS module. So how do you now figure out which
ones that are and how do you then figure out what the heck you need to
do to get them restarted?

So, you can ignore all of that, but then you have to think about what
you actually accomplished by your upgrade? You updated a couple of
libraries, and maybe managed to restart a few processes using them, but
for the rest of them the vulnerable openssl version is still in memory,
still actively used, even though your update script exited successfully
leaving the user under the impression that all was good now and that
after he made this upgrade his machine was not vulnerable anymore.

So you kinda promised the user online updates, but you actually just
updated a number of things, and leaving the biggest chunk of code in
memory still, without a chance to restart it or even figure out what it
is that you left unrestarted.

Of course, you could tell the user as last step of your script to
"please reboot now", but if you do that your update isn't "online"
anymore, but is awfully close to real offline upgrades, except that
during the upgrade period you have a ton of processes around that might
be seriously confused by not being able to find their own resources
anymore or in wrong versions...
Post by Miroslav Suchý
If this work for Debian/Ubuntu, why it could not work for Fedora?
Will, because it doesn't work for them either. It works "well enough"
for the knowledgeable, and that's what they focus on.

I mean, just think about it: every new Fedora release sofar came with a
new kernel version. The only way how to upgrade the kernel probably is
by taking the machine offline for a while and rebooting. If you are
willing to ignore everything I said above, how would your script keep
the machine online during a kernel upgrade?
Post by Miroslav Suchý
Post by Lennart Poettering
tried to update the Firefox RPM while it is running knows that this
doesn't end well, and you frequently have to manually kill firefox to
get it back into a usual state.
Interesting. Although I'm doing yum upgrade quite frequently I do
not have such experience.
Well, sooner or later you'll run into that with Firefox, or with some
other app.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Simo Sorce
2013-01-25 02:15:14 UTC
Permalink
Post by Lennart Poettering
I mean, here's an example: let's say openssl is updated, which is pulled
in by a ton of other things, for example the libc NSS LDAP module. The
libc NSS is used by at least half of all processes running on your system,
and they all dlopen() the NSS module. So how do you now figure out which
ones that are and how do you then figure out what the heck you need to
do to get them restarted?
A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and
is also deprecated on its own in favor of nss_ldapd and others.

B) Luckily we solved this case with SSSD, and this is exactly one of the
use cases we wanted to solve with it. The sssd client side that gets
loaded in processes has been made extremely simple and the protocol
fixed in stone exactly so that you can upgrade SSSD and it's
dependencies and even change sssd's configuration w/o having to restart
applications.

So I would remove the nsswitch problem, for the most part (we still have
some nsswitch things sssd does not handle like hostname resolution, but
we may take that over as well if really necessary.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Lennart Poettering
2013-01-25 03:46:51 UTC
Permalink
Post by Simo Sorce
Post by Lennart Poettering
I mean, here's an example: let's say openssl is updated, which is pulled
in by a ton of other things, for example the libc NSS LDAP module. The
libc NSS is used by at least half of all processes running on your system,
and they all dlopen() the NSS module. So how do you now figure out which
ones that are and how do you then figure out what the heck you need to
do to get them restarted?
A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and
is also deprecated on its own in favor of nss_ldapd and others.
Not part of libc? uh? no, of course not. It's still a module that is
loaded into libc via the libc NSS scheme, which is the point I am making
here...

And anyway you are missing the point here... this is just an
example. It's not particularly hard to come up with a different
example. Just think of some other NSS module, that uses some
library. Because of NSS its's loaded into half of our processes, all
they have to do is invoke gethostbyname() and the module and all
depending libaries are mapped in, and how would ever detect that?
Post by Simo Sorce
B) Luckily we solved this case with SSSD, and this is exactly one of the
use cases we wanted to solve with it. The sssd client side that gets
loaded in processes has been made extremely simple and the protocol
fixed in stone exactly so that you can upgrade SSSD and it's
dependencies and even change sssd's configuration w/o having to restart
applications.
Well you "fixed" a tiny facet of the issue. As it turns out however sssd
is not the only service we ship, is not the only package we ship, it's
not the only NSS module we ship, and update nss_sssd is still not
possible either...
Post by Simo Sorce
So I would remove the nsswitch problem, for the most part (we still have
some nsswitch things sssd does not handle like hostname resolution, but
we may take that over as well if really necessary.
Dude, sssd is not the only NSS module in the world, and NSS not the only
interface that uses dlopen(). Look at PAM, at gstreamer loading codecs,
at iconv loading char maps, gtk loading gtk modules, pulseaudio loading
pa modules, python loading any module, apache loading a module, gvfs
loading gvfs modules, ppp loading some module, ...

There's no way to determine those deps from the outside.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Simo Sorce
2013-01-25 04:46:24 UTC
Permalink
Post by Lennart Poettering
Post by Simo Sorce
Post by Lennart Poettering
I mean, here's an example: let's say openssl is updated, which is pulled
in by a ton of other things, for example the libc NSS LDAP module. The
libc NSS is used by at least half of all processes running on your system,
and they all dlopen() the NSS module. So how do you now figure out which
ones that are and how do you then figure out what the heck you need to
do to get them restarted?
A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and
is also deprecated on its own in favor of nss_ldapd and others.
Not part of libc? uh? no, of course not. It's still a module that is
loaded into libc via the libc NSS scheme, which is the point I am making
here...
And anyway you are missing the point here... this is just an
example. It's not particularly hard to come up with a different
example. Just think of some other NSS module, that uses some
library. Because of NSS its's loaded into half of our processes, all
they have to do is invoke gethostbyname() and the module and all
depending libaries are mapped in, and how would ever detect that?
cat /proc/$pid/maps
Post by Lennart Poettering
Post by Simo Sorce
B) Luckily we solved this case with SSSD, and this is exactly one of the
use cases we wanted to solve with it. The sssd client side that gets
loaded in processes has been made extremely simple and the protocol
fixed in stone exactly so that you can upgrade SSSD and it's
dependencies and even change sssd's configuration w/o having to restart
applications.
Well you "fixed" a tiny facet of the issue. As it turns out however sssd
is not the only service we ship, is not the only package we ship, it's
not the only NSS module we ship, and update nss_sssd is still not
possible either...
And it is not necessary either, as I already explained.
Post by Lennart Poettering
Post by Simo Sorce
So I would remove the nsswitch problem, for the most part (we still have
some nsswitch things sssd does not handle like hostname resolution, but
we may take that over as well if really necessary.
Dude, sssd is not the only NSS module in the world, and NSS not the only
interface that uses dlopen(). Look at PAM, at gstreamer loading codecs,
at iconv loading char maps, gtk loading gtk modules, pulseaudio loading
pa modules, python loading any module, apache loading a module, gvfs
loading gvfs modules, ppp loading some module, ...
Dude, nothing is perfect.
Post by Lennart Poettering
There's no way to determine those deps from the outside.
Of course there is, for the currently running process.

But that is besides the point. yum upgrades, just like apt-get upgrades
work just fine in the very vast majority of times.

For daemons sensible rpms include condrestart statements.

If some user app misbehaves after the upgrade you just restart it. If
you know in advance which ones you *might* want to restart I will be
very glad if you give me a list as part of the final yum output, and I
will decide if I want to do that or not.

We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.

That said I think trying a distro-sync from a graphical session is just
a funny and instructive experience, I wouldn't recommend it as you'll
keep the pieces when your session blows up and brings with it your yum
upgrade, but it is certainly instructive :)

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Matthew Garrett
2013-01-25 05:42:18 UTC
Permalink
Post by Simo Sorce
We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.
Well, that's the problem. Most of our users (including many of the
professional sysadmins) are *not* able to make a fully informed choice
about whether an online upgrade will ensure that they're no longer
running any code with known security issues. That's not a criticism of
them - it's just a much harder problem than almost everyone realises.

Nobody's suggesting making it impossible to use yum, but blessing it as
a first-class distribution upgrade mechanism is a bad idea. There's far
too many corner cases, and we can't justify the effort it'd take to fix
all of them.
--
Matthew Garrett | mjg59 at srcf.ucam.org
Simo Sorce
2013-01-25 13:58:36 UTC
Permalink
Post by Matthew Garrett
Post by Simo Sorce
We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.
Well, that's the problem. Most of our users (including many of the
professional sysadmins) are *not* able to make a fully informed choice
about whether an online upgrade will ensure that they're no longer
running any code with known security issues. That's not a criticism of
them - it's just a much harder problem than almost everyone realises.
Nobody's suggesting making it impossible to use yum, but blessing it as
a first-class distribution upgrade mechanism is a bad idea. There's far
too many corner cases, and we can't justify the effort it'd take to fix
all of them.
Nonsense, for a distribution upgrade you just recommend the admin to
reboot the system when done.
Everybody expects to reboot after a big distro-sync anyway as there is a
new kernel and basically new-everything.

But I said my points, I won't argue anymore.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Lennart Poettering
2013-01-25 18:20:40 UTC
Permalink
Post by Simo Sorce
Post by Matthew Garrett
Post by Simo Sorce
We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.
Well, that's the problem. Most of our users (including many of the
professional sysadmins) are *not* able to make a fully informed choice
about whether an online upgrade will ensure that they're no longer
running any code with known security issues. That's not a criticism of
them - it's just a much harder problem than almost everyone realises.
Nobody's suggesting making it impossible to use yum, but blessing it as
a first-class distribution upgrade mechanism is a bad idea. There's far
too many corner cases, and we can't justify the effort it'd take to fix
all of them.
Nonsense, for a distribution upgrade you just recommend the admin to
reboot the system when done.
Everybody expects to reboot after a big distro-sync anyway as there is a
new kernel and basically new-everything.
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...

Lennart
--
Lennart Poettering - Red Hat, Inc.
Simo Sorce
2013-01-25 19:23:31 UTC
Permalink
Post by Lennart Poettering
Post by Simo Sorce
Post by Matthew Garrett
Post by Simo Sorce
We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.
Well, that's the problem. Most of our users (including many of the
professional sysadmins) are *not* able to make a fully informed choice
about whether an online upgrade will ensure that they're no longer
running any code with known security issues. That's not a criticism of
them - it's just a much harder problem than almost everyone realises.
Nobody's suggesting making it impossible to use yum, but blessing it as
a first-class distribution upgrade mechanism is a bad idea. There's far
too many corner cases, and we can't justify the effort it'd take to fix
all of them.
Nonsense, for a distribution upgrade you just recommend the admin to
reboot the system when done.
Everybody expects to reboot after a big distro-sync anyway as there is a
new kernel and basically new-everything.
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...
A) One single reboot you do after not upfront.

If you are on a server logged in via ssh you can often keep doing some
work while most of the system is being updated and you can more easily
remote updates.

B) I will *not* trust an update system that cuts me out of my remote
server and make me *hope* it will come up later. If yum freaks out for
*whatever* reason I want to be there with an emergency shell open via
ssh to try to recover the system. Not have to call the colocation and
figure out what happened from possibly missing logs *if the system boots
at all*.

I've been saved more than once by a shell open during changes in the
configuration or upgrades, that is non-negotiable to me.

C) Not all updates require immediate reboot.
If I am updating the kernel and some minor package, I can as well decide
to reboot at the end of the day, rarely the update is so critical I have
to reboot NOW!

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Frank Ch. Eigler
2013-01-25 20:51:14 UTC
Permalink
[...] B) I will *not* trust an update system that cuts me out of my
remote server and make me *hope* it will come up later. If yum
freaks out for *whatever* reason I want to be there with an
emergency shell open [...] I've been saved more than once by a
shell open during changes in the configuration or upgrades, that is
non-negotiable to me. [...]
I agree that this capability is very important.

- FChE
Matthew Garrett
2013-01-25 21:57:32 UTC
Permalink
Post by Frank Ch. Eigler
[...] B) I will *not* trust an update system that cuts me out of my
remote server and make me *hope* it will come up later. If yum
freaks out for *whatever* reason I want to be there with an
emergency shell open [...] I've been saved more than once by a
shell open during changes in the configuration or upgrades, that is
non-negotiable to me. [...]
I agree that this capability is very important.
Nobody has suggested removing it. It'll continue to work as well (or as
badly, if you prefer) as it currently does.
--
Matthew Garrett | mjg59 at srcf.ucam.org
Simo Sorce
2013-01-25 22:42:20 UTC
Permalink
Post by Matthew Garrett
Post by Frank Ch. Eigler
[...] B) I will *not* trust an update system that cuts me out of my
remote server and make me *hope* it will come up later. If yum
freaks out for *whatever* reason I want to be there with an
emergency shell open [...] I've been saved more than once by a
shell open during changes in the configuration or upgrades, that is
non-negotiable to me. [...]
I agree that this capability is very important.
Nobody has suggested removing it. It'll continue to work as well (or as
badly, if you prefer) as it currently does.
Unfortunately, lately I have the impression you need to state even
obvious things very clearly lest they are removed 'to improve' the
system.

So, just making it clear.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Mike Pinkerton
2013-01-25 22:27:52 UTC
Permalink
Post by Simo Sorce
Post by Lennart Poettering
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...
A) One single reboot you do after not upfront.
If you are on a server logged in via ssh you can often keep doing some
work while most of the system is being updated and you can more easily
remote updates.
B) I will *not* trust an update system that cuts me out of my remote
server and make me *hope* it will come up later. If yum freaks out for
*whatever* reason I want to be there with an emergency shell open via
ssh to try to recover the system. Not have to call the colocation and
figure out what happened from possibly missing logs *if the system boots
at all*.
I've been saved more than once by a shell open during changes in the
configuration or upgrades, that is non-negotiable to me.
I do the same for the same reasons.
Post by Simo Sorce
C) Not all updates require immediate reboot.
If I am updating the kernel and some minor package, I can as well decide
to reboot at the end of the day, rarely the update is so critical I have
to reboot NOW!
For normal updates, yes. But I would not start an upgrade from one
Fedora release to another at an "inconvenient time" and then wait to
reboot hours later.

In this discussion of whether "yum upgrade" would be enhanced
alongside FedUp, I had assumed that FedUp would only be used for
upgrading from one Fedora release to the next, not for regular
software updates. Is that assumption wrong?
--
Mike
Michael Scherer
2013-01-26 01:16:29 UTC
Permalink
Post by Lennart Poettering
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...
Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I
already did version upgrade taking 6 to 8h due to slow internet or slow
hard drives, that's IMHO a pretty significant downtime.
--
Michael Scherer
Matthew Garrett
2013-01-26 06:21:01 UTC
Permalink
Post by Michael Scherer
Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I
already did version upgrade taking 6 to 8h due to slow internet or slow
hard drives, that's IMHO a pretty significant downtime.
fedup does all network activity before reboot, so presumably you're
talking about some upgrade system other than the currently supported
one?
--
Matthew Garrett | mjg59 at srcf.ucam.org
Michael Scherer
2013-01-26 11:59:56 UTC
Permalink
Post by Matthew Garrett
Post by Michael Scherer
Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I
already did version upgrade taking 6 to 8h due to slow internet or slow
hard drives, that's IMHO a pretty significant downtime.
fedup does all network activity before reboot, so presumably you're
talking about some upgrade system other than the currently supported
one?
You are right, the 6 to 8h is indeed unrelated, this was on a very old
computer, not using fedup, and this was for the download + install part,
just to give a order of magnitude ( heck, i should really refrain from
using evo during the night )

And for the 2 to 3h, I didn't look at the details, it was in the LUG
meeting and the time between I gave the instruction and the time the
person came back to me. While I think the exact time is not important,
let me do a test to have more precise data, so my bad memories do not
muddle the discussion ( as people around me say "depend, maybe 1h, maybe
more" when asked about fedup ).
--
Michael Scherer
Reindl Harald
2013-01-25 18:32:16 UTC
Permalink
Post by Lennart Poettering
Post by Simo Sorce
Nonsense, for a distribution upgrade you just recommend the admin to
reboot the system when done.
Everybody expects to reboot after a big distro-sync anyway as there is a
new kernel and basically new-everything.
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...
i had enough anaconda upgrades which failed to boot after that
by such things like missing initrd, missing rub-entry and so
on to have learend i want a upgrade where i can VERIFY all this
basic stuff, fix things, cleanup configurations, package-cleanup
and AFTER THAT i reboot the machine

guess - since i do it this way i survived calculated more
than 300 dist-upgares with yum and not a single one had
any problem coming up again, said that: from FC7 until F18
und the oldest setups are started with FC8 and now F18

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/95af010d/attachment-0001.sig>
Kevin Kofler
2013-02-04 04:11:13 UTC
Permalink
Post by Lennart Poettering
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...
That yum is tested every day and known to work, whereas FedUp is
experimental and incomplete (no signature checking) code.

Kevin Kofler
Chris Murphy
2013-01-26 17:11:37 UTC
Permalink
Post by Matthew Garrett
Well, that's the problem. Most of our users (including many of the
professional sysadmins) are *not* able to make a fully informed choice
about whether an online upgrade will ensure that they're no longer
running any code with known security issues. That's not a criticism of
them - it's just a much harder problem than almost everyone realises.
My Scottish co-author and dear friend referred to such cases as "giving users razor blades, and telling them to go play on the freeway."

After 1/2 dozen fedup upgrades during testing, on average the downtime portion of the upgrade was between 25 and 40 minutes. On a five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust drive (the new computer with SSD did the fedup upgrade in less than 10 minutes).

Meanwhile, a yum upgrade involves a transition from download to upgrade without notification, concomitant with the potential for arbitrary and untimely implosion that could hose the entire upgrade. And this is on a supposedly important computer that can't be down for 2 hours? Umm? I really don't understand this thread.

Chris Murphy
Mike Pinkerton
2013-01-26 17:45:31 UTC
Permalink
Post by Chris Murphy
After 1/2 dozen fedup upgrades during testing, on average the
downtime portion of the upgrade was between 25 and 40 minutes. On a
five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust
drive (the new computer with SSD did the fedup upgrade in less than
10 minutes).
Meanwhile, a yum upgrade involves a transition from download to
upgrade without notification, concomitant with the potential for
arbitrary and untimely implosion that could hose the entire
upgrade. And this is on a supposedly important computer that can't
be down for 2 hours? Umm? I really don't understand this thread.
Over the years, I have yum upgraded remote boxes from RHL 7.3 to F16.

On a remote yum upgrade, you can follow yum's progress -- see if it
hangs, see any failure warnings, etc., fix what you can after it
finishes -- then hold your breath when you reboot. If the box isn't
back online within 2 minutes, you know you have a major problem and
contact the data center immediately.

If a fedup upgrade can go offline for a lengthy, but uncertain,
amount of time, then the lack of feedback is worrying. You can't
hold your breath for 25 minutes, you don't know when to conclude that
you have a serious problem that will require help from the data
center staff, and you don't have any idea where the process went off-
track.

If you could SSH into fedup during its "offline" period and get real
time feedback about what it is doing and any errors it encounters,
and perhaps the ability to fix any problems when it finishes but
before it attempts to reboot, then it would be less scary for remote
upgrades.
--
Mike
Chris Murphy
2013-01-26 18:09:54 UTC
Permalink
If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off-track.
I think the lack of feedback with fedup is a known weak area that needs improvement. I found that by deleting 'quiet rhgb' and adding one of the debug options to the fedup kenel at reboot time, I can get to a shell during the upgrade, and issue a:

journalcti --follow

And I get live updates throughout the process. I don't recall "hang" without some sort of feedback for more than maybe 5 minutes. I forget off hand if top and/or ps are available, I think at least one of them is.
If you could SSH into fedup during its "offline" period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades.
I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running.

I don't know any company that allows major upgrades without user processes being required to quit. Apple and Microsoft both download and stage their upgrades, no user processes allowed, a partially upgraded system reboots, completes the primary upgrade tasks before user sessions are allowed again (and Windows might have one more reboot, I forget).

Once upon a time, Apple allows user session to stay live during the installation of minor system software updates. They don't even do this anymore. Apparently it was so fraught with peril. So now, the download occurs in the background during the user session, and you have the option to being the install which also requires a restart. If you agree, you're logged out, user processes quit, the update begins, the system reboots.

I just don't see how it's best practices to be doing updates on live processes. This seems sorta like a game to find out just how much one can cheat the upgrade process before the ship will in fact sink.

Chris Murphy
Chris Murphy
2013-01-26 18:32:19 UTC
Permalink
Post by Reindl Harald
Post by Chris Murphy
I just don't see how it's best practices to be doing updates on live processes. This seems sorta like a game to find out just how much one can cheat the upgrade process before the ship will in fact sink.
bullshit
upgraded more than 20 production server from F9 to F18
with yum without any single problem because the upgrade
takes around5 minutes and there are no new processes start
most of the time and the few are nothing critical
I think that's unicorn poop you're talking about. But hey, if you are ninja enough to avoid being cut by machine guns shooting razor blades at you, nice job. But asking other people make you an inflatable raft that can withstand being shot by razor blade shooting machine guns, write documentation for it, test, and support it? I will laugh out loud, and then give you the phone number for my unicorn dealer.


Chris Murphy
Mike Pinkerton
2013-01-26 20:20:10 UTC
Permalink
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton
Post by Mike Pinkerton
If a fedup upgrade can go offline for a lengthy, but uncertain,
amount of time, then the lack of feedback is worrying. You can't
hold your breath for 25 minutes, you don't know when to conclude
that you have a serious problem that will require help from the
data center staff, and you don't have any idea where the process
went off-track.
I think the lack of feedback with fedup is a known weak area that
needs improvement. I found that by deleting 'quiet rhgb' and adding
one of the debug options to the fedup kenel at reboot time, I can
journalcti --follow
And I get live updates throughout the process. I don't recall
"hang" without some sort of feedback for more than maybe 5 minutes.
I forget off hand if top and/or ps are available, I think at least
one of them is.
I can see how this would help when sitting in front of the box, but
when you're hundreds or thousands of miles away, it isn't really an
option.
Post by Mike Pinkerton
If you could SSH into fedup during its "offline" period and get
real time feedback about what it is doing and any errors it
encounters, and perhaps the ability to fix any problems when it
finishes but before it attempts to reboot, then it would be less
scary for remote upgrades.
I haven't tried 'systemctl start sshd' during the upgrade to see
what happens; it's probably not totally benign to do this, since
ssh will be upgraded, but it seems a lot safer, vastly so, than a
live yum update while a server is running.
Would it work for the network and sshd to be run from the initramfs
rather than the file system that is being updated?

It would be nice if one could start fedup with a flag that would tell
it to start the network and sshd upon reboot, and enable feedback to
a remote user. That would make the process a lot less worrisome.
--
Mike
Michael Scherer
2013-01-26 20:28:10 UTC
Permalink
Post by Mike Pinkerton
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton
Post by Mike Pinkerton
If you could SSH into fedup during its "offline" period and get
real time feedback about what it is doing and any errors it
encounters, and perhaps the ability to fix any problems when it
finishes but before it attempts to reboot, then it would be less
scary for remote upgrades.
I haven't tried 'systemctl start sshd' during the upgrade to see
what happens; it's probably not totally benign to do this, since
ssh will be upgraded, but it seems a lot safer, vastly so, than a
live yum update while a server is running.
Would it work for the network and sshd to be run from the initramfs
rather than the file system that is being updated?
Then you need to have the network configuration, etc. This can be done,
but for now, the feature is not in dracut, see this bug for a similar
request for encrypted root :
https://bugzilla.redhat.com/show_bug.cgi?id=524727
--
Michael Scherer
Mike Pinkerton
2013-01-27 09:58:12 UTC
Permalink
Post by Michael Scherer
Post by Mike Pinkerton
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton
Post by Mike Pinkerton
If you could SSH into fedup during its "offline" period and get
real time feedback about what it is doing and any errors it
encounters, and perhaps the ability to fix any problems when it
finishes but before it attempts to reboot, then it would be less
scary for remote upgrades.
I haven't tried 'systemctl start sshd' during the upgrade to see
what happens; it's probably not totally benign to do this, since
ssh will be upgraded, but it seems a lot safer, vastly so, than a
live yum update while a server is running.
Would it work for the network and sshd to be run from the initramfs
rather than the file system that is being updated?
Then you need to have the network configuration, etc. This can be done,
but for now, the feature is not in dracut, see this bug for a similar
https://bugzilla.redhat.com/show_bug.cgi?id=524727
That bug looks like a superset of what would be needed to run the
network and sshd from the initramfs.

As for network configuration, in the past (I haven't tried it with
F18's new Anaconda), one could do a VNC-enabled install by passing a
minimal network configuration (interface and IP address), as well as
a VNC password, on the kernel line. Perhaps for a ssh-enabled fedup,
one could do something similar, passing an interface and IP address
to fedup, possibly as well as a one-time use ssh password and a
"permitted" remote IP address block from which one could connect.
How those persist across the reboot -- whether fedup writes those to
the kernel line in grub.conf as one would do with a remote VNC
install, or they are written into the initramfs -- would be a question.
--
Mike
Gerd Hoffmann
2013-01-28 13:01:54 UTC
Permalink
Hi,
If a fedup upgrade can go offline for a lengthy, but uncertain, amount
of time, then the lack of feedback is worrying. You can't hold your
breath for 25 minutes, you don't know when to conclude that you have a
serious problem that will require help from the data center staff, and
you don't have any idea where the process went off-track.
I actually like fedup, and I guess I'll go stop using yum for upgrades
if I can use fedup instead.

I've seen anaconda upgrades (be it dvd-based or via preupgrade) blow up
multiple times and settled on using yum instead.

But fedup is different. Even though it is still quite young I actually
trust it to get things right. It fetches all packages, then does a
transaction check and if that fails it says so and allows you to fixup
stuff before actually kicking the upgrade. Remove orphaned packages
causing dep issues, cleanup disk so filesystems have enough free space
to run the transaction, whatever is needed.

That is very simliar to how you handle issues when upgrading using yum.

Once everything is settled and fedup says "reboot to upgrade" you can be
pretty sure that it will work fine.

cheers,
Gerd
Adam Williamson
2013-01-28 23:59:43 UTC
Permalink
Post by Gerd Hoffmann
Hi,
If a fedup upgrade can go offline for a lengthy, but uncertain, amount
of time, then the lack of feedback is worrying. You can't hold your
breath for 25 minutes, you don't know when to conclude that you have a
serious problem that will require help from the data center staff, and
you don't have any idea where the process went off-track.
I actually like fedup, and I guess I'll go stop using yum for upgrades
if I can use fedup instead.
I've seen anaconda upgrades (be it dvd-based or via preupgrade) blow up
multiple times and settled on using yum instead.
But fedup is different. Even though it is still quite young I actually
trust it to get things right. It fetches all packages, then does a
transaction check and if that fails it says so and allows you to fixup
stuff before actually kicking the upgrade. Remove orphaned packages
causing dep issues, cleanup disk so filesystems have enough free space
to run the transaction, whatever is needed.
That is very simliar to how you handle issues when upgrading using yum.
Once everything is settled and fedup says "reboot to upgrade" you can be
pretty sure that it will work fine.
Well, the other thing fedup does - and the other reason it's necessary
compared to a simple online yum upgrade - is provide a mechanism for
pretty much any package to hook in pretty much any action to be
performed as part of the upgrade. To be sure of what's going to happen
during a given fedup transaction, you should also check what scripts are
going to get fired as part of the upgrade. In F18 I'm not sure there are
any, but this is the kind of mechanism we would use, fr'instance, to
switch the default bootloader as part of an upgrade in future, if we
decided we wanted to do that again. The kind of stuff that can't be done
in %pre/%post etc.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
Miroslav Suchý
2013-02-04 17:11:15 UTC
Permalink
Post by Adam Williamson
Well, the other thing fedup does - and the other reason it's necessary
compared to a simple online yum upgrade - is provide a mechanism for
pretty much any package to hook in pretty much any action to be
performed as part of the upgrade. To be sure of what's going to happen
during a given fedup transaction, you should also check what scripts are
going to get fired as part of the upgrade. In F18 I'm not sure there are
any, but this is the kind of mechanism we would use, fr'instance, to
switch the default bootloader as part of an upgrade in future, if we
decided we wanted to do that again. The kind of stuff that can't be done
in %pre/%post etc.
Is this documented somewhere? I would like to read more about this feature.
--
Miroslav Suchy
Red Hat Systems Management Engineering
Adam Williamson
2013-02-04 21:29:43 UTC
Permalink
Post by Miroslav Suchý
Post by Adam Williamson
Well, the other thing fedup does - and the other reason it's necessary
compared to a simple online yum upgrade - is provide a mechanism for
pretty much any package to hook in pretty much any action to be
performed as part of the upgrade. To be sure of what's going to happen
during a given fedup transaction, you should also check what scripts are
going to get fired as part of the upgrade. In F18 I'm not sure there are
any, but this is the kind of mechanism we would use, fr'instance, to
switch the default bootloader as part of an upgrade in future, if we
decided we wanted to do that again. The kind of stuff that can't be done
in %pre/%post etc.
Is this documented somewhere? I would like to read more about this feature.
https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... kinda. That's the best that I know of.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
Miroslav Suchý
2013-02-05 07:54:14 UTC
Permalink
https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... kinda. That's the best that I know of.
It lacks in details how I can put hook in upgrade.pre and upgrade.post.
What is the best practise here?

It would be nice if you can enhance:
http://fedoraproject.org/wiki/Packaging:Guidelines
with example snippets and general guidance how packager can create such
hook.
--
Miroslav Suchy
Red Hat Systems Management Engineering
Adam Williamson
2013-02-05 16:24:03 UTC
Permalink
Post by Miroslav Suchý
https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... kinda. That's the best that I know of.
It lacks in details how I can put hook in upgrade.pre and upgrade.post.
What is the best practise here?
http://fedoraproject.org/wiki/Packaging:Guidelines
with example snippets and general guidance how packager can create such
hook.
I agree that would be nice, but I am not actually the author of the
feature or a user of it, so I don't have the expertise on tap. :) Will
is the one currently best-placed to do so. So far as I'm aware these are
simply dracut hooks so dracut docs would apply, but I'm not sure.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
Reindl Harald
2013-01-25 04:58:04 UTC
Permalink
Post by Simo Sorce
That said I think trying a distro-sync from a graphical session is just
a funny and instructive experience, I wouldn't recommend it as you'll
keep the pieces when your session blows up and brings with it your yum
upgrade, but it is certainly instructive :)
even this is no problem
screen is your friend

did it multiple times

well, there are times due the upgrade where things
behave strange, but webbrowsing is fine and even if
firefox gets unstable, just restart it

the point of distro-sync is to give advanced users
a upgrade option where they decide by theirself what
they are doing

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/1dc622dd/attachment-0001.sig>
Nicolas Mailhot
2013-01-25 17:00:06 UTC
Permalink
Post by Lennart Poettering
Applications have deps on all kinds of
data in /usr/lib, not just shared libraries. Such as locale data, icons,
fonts, artwork, documentation.
BTW Firefox seems to be the only application that goes bonkers when fonts
are updated while it's running, so it looks more like a bug in Firefox's
text rendering than a general problem to me
--
Nicolas Mailhot
Reindl Harald
2013-01-25 17:07:38 UTC
Permalink
Post by Nicolas Mailhot
Post by Lennart Poettering
Applications have deps on all kinds of
data in /usr/lib, not just shared libraries. Such as locale data, icons,
fonts, artwork, documentation.
BTW Firefox seems to be the only application that goes bonkers when fonts
are updated while it's running, so it looks more like a bug in Firefox's
text rendering than a general problem to me
and on the other hand i had longer time ago troubles with
my systemdisk suddenly disappear until hard power off and
more than one time i used firefox for half an hour because
it had anything in the memory and freezed only if it should
display a dialog with icons not loaded before

proven by /var/log/ on a different disk with errors in a
"tail -f" while all aplications worked for minutes and
even VMware machines could be CLEAN powered off via SSH
from a notebook as long they were on a different physical
drive

so no - it's not that bad doing updates while things running

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/95956fcd/attachment-0001.sig>
Przemek Klosowski
2013-01-25 18:02:22 UTC
Permalink
Post by Lennart Poettering
If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...
Then all code that runs that is not a system service is difficult to
restart from a system script. How do you plan to restart Evolution or
Firefox, or Gimp?
...
Post by Lennart Poettering
Of course, you could tell the user as last step of your script to
"please reboot now", but if you do that your update isn't "online"
anymore, but is awfully close to real offline upgrades, except that
during the upgrade period you have a ton of processes around that might
be seriously confused by not being able to find their own resources
anymore or in wrong versions...
This is a pessimistic view but I think it's not as intractable.

There are two separate aspects to it: discovery what needs to be
restarted, and the actual process of restarting. The discovery is almost
there: we know the resources (libs, files, etc) that were replaced, so
it's a matter of walking the list of running processes and checking if
they depend on those resources. I can see how transient I/O, including
dlopen() could be tricky, but I don't think it's fundamentally
impossible---at worst, it'd be implementing some sort of
/proc/1234/history-of-opened-fd mechanism.

That leaves the restarting: again it seems to me that is not as hopeless
as you make it sound, either: kernel is hardest but even there people
are working on ksplice. Many services are designed to be restarted, like
DHCPD which doesn't even have an online reload but has to be bounced if
the DHCP data file changes.

Regular process restart is of course application dependent, but e.g.
Firefox actually restarts relatively graciously: I just killed mine and
the new instance reopened all my tabs (a pleasant surprise--I expected
the Restore Session ("Well this is embarrassing") window I was used to).
Maybe there is a couple of classes that the restart falls into:

- no problems restarting anytime

- availability problems but no data loss on restart (easy restart but
maybe needs user confirmation)

- some out-of-process support needed (file rotation/cleanup, etc)

- user intervention required (saving files, etc).


I believe that seamless upgrades are an attractive goal. I am not
arguing for infinite upgrades---only a fresh install can guarantee
getting all new technologies that one wouldn't get through upgrades
because they may not even existed at the original installation. My point
is that the reinstall decision should be in principle driven by the
user, not by the OS release schedule.
Lennart Poettering
2013-01-25 18:27:57 UTC
Permalink
Post by Przemek Klosowski
Post by Lennart Poettering
If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...
Then all code that runs that is not a system service is difficult to
restart from a system script. How do you plan to restart Evolution or
Firefox, or Gimp?
...
Post by Lennart Poettering
Of course, you could tell the user as last step of your script to
"please reboot now", but if you do that your update isn't "online"
anymore, but is awfully close to real offline upgrades, except that
during the upgrade period you have a ton of processes around that might
be seriously confused by not being able to find their own resources
anymore or in wrong versions...
This is a pessimistic view but I think it's not as intractable.
There are two separate aspects to it: discovery what needs to be
restarted, and the actual process of restarting. The discovery is
almost there: we know the resources (libs, files, etc) that were
replaced, so it's a matter of walking the list of running processes
and checking if they depend on those resources. I can see how
transient I/O, including dlopen() could be tricky, but I don't think
it's fundamentally impossible---at worst, it'd be implementing some
sort of /proc/1234/history-of-opened-fd mechanism.
That doesn't work. Let's say my app needs to display a certain icon in
some dialog. The next version of that app doesn't need that icon
anymore, so on upgrade the icon is deleted. At the same time the user is
still running that app, and then enters the dialog. The app now looks
for the icon, and doesn't find it. Bang.

There is no sane way to determine all these dependencies, because many
of them are never explicit, and only temporary in nature. Well written
apps load a lot of resources lazily. That has the side effect that you
can never know those deps, until they are actually needed.

The icon thing is just one example, you can now extrapolate from that...
Post by Przemek Klosowski
That leaves the restarting: again it seems to me that is not as
hopeless as you make it sound, either: kernel is hardest but even
there people are working on ksplice. Many services are designed to
be restarted, like DHCPD which doesn't even have an online reload
but has to be bounced if the DHCP data file changes.
"kernel is hardest"? Yuck. Kernel is not feasible. And much of the rest
isn't either.

I'll wait your patches for the kernel to allow seamless upgrades of the
kernel without reboots.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Bill Nottingham
2013-01-25 18:35:14 UTC
Permalink
Post by Lennart Poettering
I'll wait your patches for the kernel to allow seamless upgrades of the
kernel without reboots.
Sure, just have a ksplice server that generates splices for each new kernel
build relative to the previous one, and your upgrade process downloads all of
the series of splices and applies them. Voila!

The ksplice series from 2.6.18 to 3.7 will be loads of fun.

Bill

(NOTE: THIS IS NOT A SERIOUS IDEA.)
Przemek Klosowski
2013-01-25 19:22:44 UTC
Permalink
My point is that it'd be nice to improve the upgrades. I love
upgrades---I love the shiny new toys and I hate them for the disruption
they always bring, at someone else's schedule. As you say, there are
good reasons why it's what it is now, and maybe you're right that it
can't be significantly changed. I am just trying to think what COULD be
done, because such improvements would benefit regular updates ('yum
update') as well.
Post by Lennart Poettering
There is no sane way to determine all these dependencies, because many
of them are never explicit, and only temporary in nature. Well written
apps load a lot of resources lazily. That has the side effect that you
can never know those deps, until they are actually needed.
You are right, can't be solved with the simplistic approach I
discussed--it would have to be more complex than that. This of course
is true of any upgrade, even the routine 'yum update', so improving this
situation is desirable even if one disagrees about distribution upgrades.

We know what resources we had and what we replaced them with. Perhaps we
could at least tag the running processes that will need restarting and
notify the users/administrators.
Post by Lennart Poettering
"kernel is hardest"? Yuck. Kernel is not feasible. And much of the rest
isn't either.
So kernel is out. DHCP is definitely possible. The others are somewhere
in between. My point again is that I think the upgrades are a sore point
for the users and it'd be nice to improve the process. If indeed this
can't be done properly, then the second best is a fall-back of having
the infrastructure to do it anyway and notify the user about which
pieces need special attention.
Bruno Wolff III
2013-01-25 19:26:07 UTC
Permalink
On Fri, Jan 25, 2013 at 14:22:44 -0500,
Post by Przemek Klosowski
My point is that it'd be nice to improve the upgrades. I love
upgrades---I love the shiny new toys and I hate them for the
disruption they always bring, at someone else's schedule. As you say,
there are good reasons why it's what it is now, and maybe you're
right that it can't be significantly changed. I am just trying to
think what COULD be done, because such improvements would benefit
regular updates ('yum update') as well.
Sure any help getting stuff properly obsoleted and the like is good. I don't
think we really want it to be a feaure though.
Pavel Alexeev
2013-01-27 00:13:00 UTC
Permalink
Post by Lennart Poettering
Post by Przemek Klosowski
Post by Lennart Poettering
If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...
Then all code that runs that is not a system service is difficult to
restart from a system script. How do you plan to restart Evolution or
Firefox, or Gimp?
...
Post by Lennart Poettering
Of course, you could tell the user as last step of your script to
"please reboot now", but if you do that your update isn't "online"
anymore, but is awfully close to real offline upgrades, except that
during the upgrade period you have a ton of processes around that might
be seriously confused by not being able to find their own resources
anymore or in wrong versions...
This is a pessimistic view but I think it's not as intractable.
There are two separate aspects to it: discovery what needs to be
restarted, and the actual process of restarting. The discovery is
almost there: we know the resources (libs, files, etc) that were
replaced, so it's a matter of walking the list of running processes
and checking if they depend on those resources. I can see how
transient I/O, including dlopen() could be tricky, but I don't think
it's fundamentally impossible---at worst, it'd be implementing some
sort of /proc/1234/history-of-opened-fd mechanism.
That doesn't work. Let's say my app needs to display a certain icon in
some dialog. The next version of that app doesn't need that icon
anymore, so on upgrade the icon is deleted. At the same time the user is
still running that app, and then enters the dialog. The app now looks
for the icon, and doesn't find it. Bang.
There is no sane way to determine all these dependencies, because many
of them are never explicit, and only temporary in nature. Well written
apps load a lot of resources lazily. That has the side effect that you
can never know those deps, until they are actually needed.
The icon thing is just one example, you can now extrapolate from that...
Sorry but how such use case different from simple firefox update in
current release when it happened parallel with browsing?? It may also
lead to that unpredictable behavior. Off course you will say it
shouldn't be major release in stable Fedora. And off course it is true.
But anyone can't guaranty what even change or delete 1 file do not lead
to unstable app. So for that cases graphical application similar to
PackageKit suggests user reboot (and may suggest only reload certain
apps) with list of apps, based on maintainers expectation from ("suggest
reboot" in bodhi update system). I hope you do not suggest force reload
such apps for user of force always offline update for that thinks. In
that point of view "online" distro update differs only by amount of
updated packages which "suggest reboot" for user. And I may himself plan
reboot when I want...
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: Hubbitus at jabber.ru
Miroslav Suchý
2013-02-04 17:35:54 UTC
Permalink
Post by Lennart Poettering
So, you can ignore all of that, but then you have to think about what
you actually accomplished by your upgrade? You updated a couple of
libraries, and maybe managed to restart a few processes using them, but
for the rest of them the vulnerable openssl version is still in memory,
still actively used, even though your update script exited successfully
leaving the user under the impression that all was good now and that
after he made this upgrade his machine was not vulnerable anymore.
And how this differ from
yum upgrade
which I'm doing every day/week?

Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade
and not rebooted from day zero.
I have exactly the same problem as during yum upgrade to next Fedora
release.

So we are ignoring this behaviour in middle of release, but it is very
serious problem between releases?
--
Miroslav Suchy
Red Hat Systems Management Engineering
Rahul Sundaram
2013-02-04 17:58:14 UTC
Permalink
Hi
Post by Miroslav Suchý
Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade
and not rebooted from day zero.
I have exactly the same problem as during yum upgrade to next Fedora
release.
So we are ignoring this behaviour in middle of release, but it is very
serious problem between releases?
https://fedoraproject.org/wiki/Features/OfflineSystemUpdates

Rahul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130204/27db3b09/attachment.html>
Reindl Harald
2013-02-04 17:52:02 UTC
Permalink
Post by Miroslav Suchý
Post by Lennart Poettering
So, you can ignore all of that, but then you have to think about what
you actually accomplished by your upgrade? You updated a couple of
libraries, and maybe managed to restart a few processes using them, but
for the rest of them the vulnerable openssl version is still in memory,
still actively used, even though your update script exited successfully
leaving the user under the impression that all was good now and that
after he made this upgrade his machine was not vulnerable anymore.
And how this differ from
yum upgrade
which I'm doing every day/week?
Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade and not rebooted from day zero.
I have exactly the same problem as during yum upgrade to next Fedora release.
So we are ignoring this behaviour in middle of release, but it is very serious problem between releases?
oh even if people like i did some hundret dist-upgrades over the
years it was us told that linux has to go the windows way:

http://fedoraproject.org/wiki/Features/OfflineSystemUpdates

a few years ago you could make a dist-upgrade and even httpd
and fileservers like "netatalk" were running in the old
version until reboot, did it, was there

then fedora introduced the restart-service-snippets in
every SPEC file, after that came Packagekit and after
systemd now all the things worked over decades are
suddenly not possible in a clean way - i do not buy
that the development goes in the right direction at all



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130204/297759e8/attachment.sig>
Kevin Kofler
2013-02-09 08:10:41 UTC
Permalink
Post by Reindl Harald
oh even if people like i did some hundret dist-upgrades over the
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
Yeah, this is a really insane "feature"!

Let me assure you that this "feature" is only currently implemented in
gnome-packagekit. The command-line tools will probably NEVER implement this.
As for Apper, I can assure you that:
* this "feature" is not currently implemented in Apper,
* Apper's upstream author plans to support it in the future, but make it
optional, and
* KDE SIG has strong reservations about the usefulness and desirability of
this "feature" and it will likely end up disabled by default in Fedora if
implemented.

Kevin Kofler
drago01
2013-02-09 14:52:49 UTC
Permalink
Post by Kevin Kofler
Post by Reindl Harald
oh even if people like i did some hundret dist-upgrades over the
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
Yeah, this is a really insane "feature"!
Let me assure you that this "feature" is only currently implemented in
gnome-packagekit. The command-line tools will probably NEVER implement this.
* this "feature" is not currently implemented in Apper,
* Apper's upstream author plans to support it in the future, but make it
optional, and
* KDE SIG has strong reservations about the usefulness and desirability of
this "feature" and it will likely end up disabled by default in Fedora if
implemented.
Yes become ignoring problems by pretending that they do not exist is
the way to go ....
Reindl Harald
2013-02-09 14:58:00 UTC
Permalink
Post by drago01
Post by Kevin Kofler
Post by Reindl Harald
oh even if people like i did some hundret dist-upgrades over the
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
Yeah, this is a really insane "feature"!
Let me assure you that this "feature" is only currently implemented in
gnome-packagekit. The command-line tools will probably NEVER implement this.
* this "feature" is not currently implemented in Apper,
* Apper's upstream author plans to support it in the future, but make it
optional, and
* KDE SIG has strong reservations about the usefulness and desirability of
this "feature" and it will likely end up disabled by default in Fedora if
implemented.
Yes become ignoring problems by pretending that they do not exist is
the way to go ....
why preklink not banned which also touches probably running
binaries, but hey in this case it is OK because it was a
fedora feature years ago and there must be good

which problems?
where were they over decades?
who did introduce them recently?
why this bugs are not fixed?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130209/274c3059/attachment.sig>
Kevin Kofler
2013-02-04 04:08:01 UTC
Permalink
Post by Lennart Poettering
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
tried to update the Firefox RPM while it is running knows that this
doesn't end well, and you frequently have to manually kill firefox to
get it back into a usual state.
Strawman alert!

Who ever said that this feature is about online upgrades? Even the
"Upgrading Fedora using yum" wiki page clearly says that upgrades should be
done in runlevel 3 (multi-user.target), not in runlevel 5
(graphical.target).

The point of using yum to upgrade is not to do it in a running user session,
but to use the same frequently-tested code paths as for normal updates
rather than a special distro-upgrade-only one where half of the
functionality has to be reimplemented differently (see e.g. FedUp not
supporting something as basic as signature checks; why do we even bother
signing our packages if we're happy to deliver an "official" and
"recommended" upgrade method which won't even bother checking them?).

Kevin Kofler
Josh Boyer
2013-01-23 19:29:50 UTC
Permalink
Post by Jaroslav Reznik
= Features/FedoraUpgrade =
https://fedoraproject.org/wiki/Features/FedoraUpgrade
Feature owner(s): Miroslav SuchÜ <msuchy at redhat.com>
Upgrade Fedora to next version using yum upgrade.
I see no reason to make this an officially supported method to upgrade
Fedora. The QA team is already swamped with work just getting the new
install tests done, and now fedup tests. Having a third way of getting
a Fedora release onto a machine is going to expand the testing matrix
even more. This isn't replacing something, it's just creating more
work.

Yum upgrade has always been possible but not supported. Seems it can
stay that way.

josh
Bruno Wolff III
2013-01-23 20:04:31 UTC
Permalink
Post by Jaroslav Reznik
If this method will be tested by FedoraQA, then I believe this upgrade method
can be safely recommended to user.
The feature owners of this need to do the testing and prodding, not QA. The
way this feature is written, it seems to imply that QA is supposed to
implement this feature.

Note that this doesn't fix problems caused by dropped packages, that block
other packages from being updated. One possiblity here would be to create
a special package that obsoletes all of the dropped packages from the
last release (or two depending on how far back you want to yum update from).

There are going to be some releases where you need to do things outside of
yum to upgrade. I don't know that we want to advertise this as a feature
when it can't really be supported from release to release. However, a group
of people who wanted to report bugs for missing obsoletes and the like
would be appreciated.
Vít Ondruch
2013-01-24 12:13:09 UTC
Permalink
One possiblity here would be to create a special package that
obsoletes all of the dropped packages from the last release (or two
depending on how far back you want to yum update from).
Actually, this is cool idea IMO. Why this package does not exist yet?
Rel-engs has to have list of blocked packages already, so it should be
easy to convert it into .spec.

Vít
Michael Schwendt
2013-01-24 13:18:25 UTC
Permalink
Post by Vít Ondruch
One possiblity here would be to create a special package that
obsoletes all of the dropped packages from the last release (or two
depending on how far back you want to yum update from).
Actually, this is cool idea IMO. Why this package does not exist yet?
Rel-engs has to have list of blocked packages already, so it should be
easy to convert it into .spec.
It has been suggested, discussed and rejected many years ago. Here's
one thread from 2007,

https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html

and I remember it has been a topic before for early FESCO, but probably
on IRC or the closed list. As one can see, we referred to it with the
term "garbage collection" for packages. That's why I managed to find this
thread, too.
--
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc4.git1.1.fc19.x86_64
loadavg: 0.03 0.04 0.05
Bruno Wolff III
2013-01-24 13:57:37 UTC
Permalink
On Thu, Jan 24, 2013 at 14:18:25 +0100,
Post by Michael Schwendt
It has been suggested, discussed and rejected many years ago. Here's
one thread from 2007,
https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html
and I remember it has been a topic before for early FESCO, but probably
on IRC or the closed list. As one can see, we referred to it with the
term "garbage collection" for packages. That's why I managed to find this
thread, too.
The above thread was sort of neutral. I think the downsides of making it
harder to keep some dropped packages is out weighed by making yum upgrades
work smoother.
Matthew Miller
2013-01-24 13:58:06 UTC
Permalink
Post by Michael Schwendt
Post by Vít Ondruch
Actually, this is cool idea IMO. Why this package does not exist yet?
Rel-engs has to have list of blocked packages already, so it should be
easy to convert it into .spec.
It has been suggested, discussed and rejected many years ago. Here's
one thread from 2007,
https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html
Nice, because I was just going to say

https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00107.html
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm at fedoraproject.org>
Vít Ondruch
2013-01-24 14:13:59 UTC
Permalink
Post by Michael Schwendt
Post by Vít Ondruch
One possiblity here would be to create a special package that
obsoletes all of the dropped packages from the last release (or two
depending on how far back you want to yum update from).
Actually, this is cool idea IMO. Why this package does not exist yet?
Rel-engs has to have list of blocked packages already, so it should be
easy to convert it into .spec.
It has been suggested, discussed and rejected many years ago. Here's
one thread from 2007,
https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html
and I remember it has been a topic before for early FESCO, but probably
on IRC or the closed list. As one can see, we referred to it with the
term "garbage collection" for packages. That's why I managed to find this
thread, too.
Thank you for pointing it out. Was not aware of it.


Vít
Michael scherer
2013-01-24 15:41:10 UTC
Permalink
Post by Vít Ondruch
One possiblity here would be to create a special package that
obsoletes all of the dropped packages from the last release (or
two depending on how far back you want to yum update from).
Actually, this is cool idea IMO. Why this package does not exist
yet? Rel-engs has to have list of blocked packages already, so it
should be easy to convert it into .spec.
For the record, mageia does it, but not everybody is ok with that.

So you could talk to them to see if they have some interesting feedback on the topic.
--
Michael Scherer
Kevin Kofler
2013-02-04 04:04:03 UTC
Permalink
Post by Bruno Wolff III
Note that this doesn't fix problems caused by dropped packages, that block
other packages from being updated.
That's a problem for all upgrade methods, they might leave your system with
broken dependencies instead of erroring out, but in the end the problem is
always there. It's not solvable as long as we're as happy to drop packages
as we are now, rather than keeping them working by rebuilding them even if
there's no active maintainer.
Post by Bruno Wolff III
One possiblity here would be to create a special package that obsoletes
all of the dropped packages from the last release (or two depending on how
far back you want to yum update from).
Please no! Many of those packages keep working just fine. And where not,
it's better to get a clear error message and to remove the offending
packages manually and explicitly than to have the upgrade silently (well,
with a one-line notice buried under many other lines of text) removing a
package one may be depending on!
Post by Bruno Wolff III
There are going to be some releases where you need to do things outside of
yum to upgrade.
Then that's a problem with the feature which requires you to do that, and
should be a showstopper! (Yes, I think UsrMove should not have been
allowed.)

Kevin Kofler
&quot;Jóhann B. Guðmundsson&quot;
2013-01-23 22:47:18 UTC
Permalink
Post by Josh Boyer
Post by Jaroslav Reznik
= Features/FedoraUpgrade =
https://fedoraproject.org/wiki/Features/FedoraUpgrade
Feature owner(s): Miroslav SuchÜ<msuchy at redhat.com>
Upgrade Fedora to next version using yum upgrade.
I see no reason to make this an officially supported method to upgrade
Fedora. The QA team is already swamped with work just getting the new
install tests done, and now fedup tests. Having a third way of getting
a Fedora release onto a machine is going to expand the testing matrix
even more. This isn't replacing something, it's just creating more
work.
Yum upgrade has always been possible but not supported. Seems it can
stay that way.
a)

QA was never asked when preupgrade got approved as an official upgrade
method in the first place...


b)

We QA have alot of QA community members testing this so this does NOT
require any additional effort or cause additional LOAD on the QA community.

c)

We ( QA ) already have discussed this and it takes minor criteria
changed for us to implement this ( either or ).

yum upgrade is equally broken from my pov as preupgrade or fedup thus to
me we can just as well "support" two failed upgrade mechanism or non et
all.

It does not take a rocket scientist to figure out we cant probably
"support" upgrading until we default to brtrfs and users can rollback
and boot into their old environment just incase heck our own so called
default desktop does not handle upgrades very well.

So I say let's support both or non et all..

JBG
drago01
2013-01-23 22:55:40 UTC
Permalink
On Wed, Jan 23, 2013 at 11:47 PM, "Jóhann B. Guðmundsson"
Post by &quot;Jóhann B. Guðmundsson&quot;
So I say let's support both or non et all..
Supporting "none" is not an option.
And the major issue with yum upgrades is that online upgrades can fail
not only based on what you have installed but also what is currently
running and it cannot handle stuff like usermove without user
intervention.
&quot;Jóhann B. Guðmundsson&quot;
2013-01-23 22:57:59 UTC
Permalink
Post by drago01
Supporting "none" is not an option.
Really suddenly not an option.

We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an option.

Users are better of keeping /home on a separated partition and re-use it
with an fresh install then those poor attempts to "support" upgrades one
way or another which at this point in time we cant do since the bits for
that aren't properly aligned to make that happen...

JBG
Matthew Garrett
2013-01-24 06:03:25 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Users are better of keeping /home on a separated partition and
re-use it with an fresh install then those poor attempts to
"support" upgrades one way or another which at this point in time we
cant do since the bits for that aren't properly aligned to make that
happen...
If you don't like what we produce, you're not obliged to use it.
--
Matthew Garrett | mjg59 at srcf.ucam.org
drago01
2013-01-24 08:21:22 UTC
Permalink
On Wed, Jan 23, 2013 at 11:57 PM, "Jóhann B. Guðmundsson"
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by drago01
Supporting "none" is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an option.
It was supported as long as fedora exists (and back in RHL days).
Post by &quot;Jóhann B. Guðmundsson&quot;
Users are better of keeping /home on a separated partition and re-use it
with an fresh install
And loose all other configuration, having to reinstall every
application etc etc.
Post by &quot;Jóhann B. Guðmundsson&quot;
then those poor attempts to "support" upgrades one way
or another which at this point in time we cant do
We can and always did.
Post by &quot;Jóhann B. Guðmundsson&quot;
since the bits for that
aren't properly aligned to make that happen...
Works for me ... I always upgrade my systems ... if it does not work
for you for whatever reason file bugs and don't claim that it is
inherently impossible because isn't.
Michał Piotrowski
2013-01-25 19:39:43 UTC
Permalink
Hi,
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by drago01
Supporting "none" is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an option.
Users are better of keeping /home on a separated partition and re-use it
with an fresh install then those poor attempts to "support" upgrades one way
or another which at this point in time we cant do since the bits for that
aren't properly aligned to make that happen...
? 8-)

I really can't imagine it.

I use Fedora as a server system for my daily developer work. I use
many services with different configurations. Actually updating it with
preupgrade/fedup is sometimes hard. Reinstalling whole system after
each release will be super painful.
Post by &quot;Jóhann B. Guðmundsson&quot;
JBG
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
&quot;Jóhann B. Guðmundsson&quot;
2013-01-25 20:17:06 UTC
Permalink
Post by Michał Piotrowski
Hi,
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by drago01
Supporting "none" is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an option.
Users are better of keeping /home on a separated partition and re-use it
with an fresh install then those poor attempts to "support" upgrades one way
or another which at this point in time we cant do since the bits for that
aren't properly aligned to make that happen...
? 8-)
I really can't imagine it.
I use Fedora as a server system for my daily developer work. I use
many services with different configurations. Actually updating it with
preupgrade/fedup is sometimes hard. Reinstalling whole system after
each release will be super painful.
?

Keep your server configuration in git and keep the relevant data on
separated partition then reinstall and checkout the config(s)

JBG
Simo Sorce
2013-01-25 20:32:14 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Michał Piotrowski
Hi,
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by drago01
Supporting "none" is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an option.
Users are better of keeping /home on a separated partition and re-use it
with an fresh install then those poor attempts to "support" upgrades one way
or another which at this point in time we cant do since the bits for that
aren't properly aligned to make that happen...
? 8-)
I really can't imagine it.
I use Fedora as a server system for my daily developer work. I use
many services with different configurations. Actually updating it with
preupgrade/fedup is sometimes hard. Reinstalling whole system after
each release will be super painful.
?
Keep your server configuration in git and keep the relevant data on
separated partition then reinstall and checkout the config(s)
Why should I do all this when I can simply apt-get upgrade^W^Wyum
upgrade ?

Simo.
--
Simo Sorce * Red Hat, Inc * New York
&quot;Jóhann B. Guðmundsson&quot;
2013-01-25 20:42:02 UTC
Permalink
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Michał Piotrowski
Hi,
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by drago01
Supporting "none" is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an option.
Users are better of keeping /home on a separated partition and re-use it
with an fresh install then those poor attempts to "support" upgrades one way
or another which at this point in time we cant do since the bits for that
aren't properly aligned to make that happen...
? 8-)
I really can't imagine it.
I use Fedora as a server system for my daily developer work. I use
many services with different configurations. Actually updating it with
preupgrade/fedup is sometimes hard. Reinstalling whole system after
each release will be super painful.
?
Keep your server configuration in git and keep the relevant data on
separated partition then reinstall and checkout the config(s)
Why should I do all this when I can simply apt-get upgrade^W^Wyum
upgrade ?
You do whatever floats your boat I prefer doing fresh installs and keep
relevant data on their own partitions and configuration files in git you
prefer to do it via yum or fedupgrade.

JBG
Reindl Harald
2013-01-25 20:31:14 UTC
Permalink
Post by Michał Piotrowski
I use Fedora as a server system for my daily developer work. I use
many services with different configurations. Actually updating it with
preupgrade/fedup is sometimes hard. Reinstalling whole system after
each release will be super painful.
?
Keep your server configuration in git and keep the relevant data on separated partition then reinstall and checkout
the config(s)
which part of the configuration?
all /etc - well this would be more damage than resolution :-)

sorry but this does not work

i have made some hundret dist-upgrades with yum over the years
nearly zero downtime, normally not more as a kernel update with reboot

well, i keep all my systems 100% clear
but with reinstalls i had wasted so much more time

the big benefit (especially in VM environments) is that the update
goes so fast (as long you not install every bullshit) that the timeframe
is to short to make any troubles for running services

4-7 minutes per instance here since years

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/01fe5752/attachment-0001.sig>
Kevin Kofler
2013-02-04 04:24:10 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Users are better of keeping /home on a separated partition and re-use it
with an fresh install then those poor attempts to "support" upgrades one
way or another which at this point in time we cant do since the bits for
that aren't properly aligned to make that happen...
Reinstalling all the time is a no go.

Kevin Kofler
Kevin Kofler
2013-02-04 04:23:11 UTC
Permalink
Post by drago01
And the major issue with yum upgrades is that online upgrades can fail
not only based on what you have installed but also what is currently
running and it cannot handle stuff like usermove without user
intervention.
1. That's a problem with UsrMove, not with yum!
2. UsrMove CAN be done online, e.g. with a C program (which won't care if
you move ld.so under it after it's already in memory), or – with some
trickery – even in shell. It was an explicit decision to require that
useless dracut step.

Kevin Kofler
Bruno Wolff III
2013-01-24 01:47:03 UTC
Permalink
On Wed, Jan 23, 2013 at 22:47:18 +0000,
Post by &quot;Jóhann B. Guðmundsson&quot;
b)
We QA have alot of QA community members testing this so this does NOT
require any additional effort or cause additional LOAD on the QA community.
Aren't they just testing an upgrade of the default install?

I don't think people are doing any automated testing of proper obsoletes
for dropped packages, though most problems could probably be detected.
And this still doesn't handle dropped packages that are being replaced.
Post by &quot;Jóhann B. Guðmundsson&quot;
yum upgrade is equally broken from my pov as preupgrade or fedup thus
to me we can just as well "support" two failed upgrade mechanism or
non et all.
Anaconda does some tricks that get packages installed even when there
are problems that don't get handled by a normal yum update. (Or at least
used to. (With the move toward not using special stuff in anaconda, maybe
this isn't true any more.)
Adam Williamson
2013-01-24 06:17:22 UTC
Permalink
Post by Bruno Wolff III
On Wed, Jan 23, 2013 at 22:47:18 +0000,
Post by &quot;Jóhann B. Guðmundsson&quot;
b)
We QA have alot of QA community members testing this so this does NOT
require any additional effort or cause additional LOAD on the QA community.
Aren't they just testing an upgrade of the default install?
Correct:
https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop is the only current upgrade test case.

We could plausibly extend the range somewhat to cover common package
loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles
(non-US keyboard layout, encryption, a couple of different partition
schemes), for _one_ upgrade method. Anything beyond that would be a bit
of a stretch, I think.
Post by Bruno Wolff III
I don't think people are doing any automated testing of proper obsoletes
for dropped packages,
Correct.
Post by Bruno Wolff III
though most problems could probably be detected.
And this still doesn't handle dropped packages that are being replaced.
Post by &quot;Jóhann B. Guðmundsson&quot;
yum upgrade is equally broken from my pov as preupgrade or fedup thus
to me we can just as well "support" two failed upgrade mechanism or
non et all.
Anaconda does some tricks that get packages installed even when there
are problems that don't get handled by a normal yum update. (Or at least
used to. (With the move toward not using special stuff in anaconda, maybe
this isn't true any more.)
fedup does not use anaconda in any way. anaconda didn't really do any
'tricks', IIRC, it just ran the upgrade in skip-broken mode. I don't
know if fedup uses skip-broken or not.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
Lennart Poettering
2013-01-24 17:11:19 UTC
Permalink
Post by Adam Williamson
Post by Bruno Wolff III
On Wed, Jan 23, 2013 at 22:47:18 +0000,
Post by &quot;Jóhann B. Guðmundsson&quot;
b)
We QA have alot of QA community members testing this so this does NOT
require any additional effort or cause additional LOAD on the QA community.
Aren't they just testing an upgrade of the default install?
https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop is the only current upgrade test case.
We could plausibly extend the range somewhat to cover common package
loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles
(non-US keyboard layout, encryption, a couple of different partition
schemes), for _one_ upgrade method. Anything beyond that would be a bit
of a stretch, I think.
Wouldn't it make sense to test the "full install"? In contrast to other
distributions it should be possible to install all our RPMs at once
(modulo arch specific ones that is). If that thing upgrades properly,
then you have a pretty good chance it will work for most subsets too?

Lennart
--
Lennart Poettering - Red Hat, Inc.
drago01
2013-01-24 17:25:11 UTC
Permalink
On Thu, Jan 24, 2013 at 6:11 PM, Lennart Poettering
Post by Lennart Poettering
Post by Adam Williamson
Post by Bruno Wolff III
On Wed, Jan 23, 2013 at 22:47:18 +0000,
Post by &quot;Jóhann B. Guðmundsson&quot;
b)
We QA have alot of QA community members testing this so this does NOT
require any additional effort or cause additional LOAD on the QA community.
Aren't they just testing an upgrade of the default install?
https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop is the only current upgrade test case.
We could plausibly extend the range somewhat to cover common package
loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles
(non-US keyboard layout, encryption, a couple of different partition
schemes), for _one_ upgrade method. Anything beyond that would be a bit
of a stretch, I think.
Wouldn't it make sense to test the "full install"?
I doubt that you can install all packages without hitting conflicts.
Stephen John Smoogen
2013-01-24 19:38:00 UTC
Permalink
Post by drago01
On Thu, Jan 24, 2013 at 6:11 PM, Lennart Poettering
Post by Lennart Poettering
Wouldn't it make sense to test the "full install"?
I doubt that you can install all packages without hitting conflicts.
You can not. Lots of things conflict so if you try to do a 'yum
install *' you get a LOT of different conflicts from say stuff
requiring mod_ssl versus nss or gnutls etc.
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
Kevin Kofler
2013-02-04 04:26:02 UTC
Permalink
Post by drago01
I doubt that you can install all packages without hitting conflicts.
That just shows again how Conflicts are evil and how we're way too tolerant
about them. There should be NO conflicting packages in the official
repositories.

Kevin Kofler
Adam Williamson
2013-01-24 23:21:27 UTC
Permalink
Post by Lennart Poettering
Post by Adam Williamson
Post by Bruno Wolff III
On Wed, Jan 23, 2013 at 22:47:18 +0000,
Post by &quot;Jóhann B. Guðmundsson&quot;
b)
We QA have alot of QA community members testing this so this does NOT
require any additional effort or cause additional LOAD on the QA community.
Aren't they just testing an upgrade of the default install?
https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop is the only current upgrade test case.
We could plausibly extend the range somewhat to cover common package
loadouts (GNOME, KDE, minimal perhaps) and common configuration wrinkles
(non-US keyboard layout, encryption, a couple of different partition
schemes), for _one_ upgrade method. Anything beyond that would be a bit
of a stretch, I think.
Wouldn't it make sense to test the "full install"? In contrast to other
distributions it should be possible to install all our RPMs at once
(modulo arch specific ones that is). If that thing upgrades properly,
then you have a pretty good chance it will work for most subsets too?
It's probably a useful test case to add, yeah, but I can think of
several scenarios where it wouldn't cover things (by definition it
probably wouldn't catch cases where a necessary dependency was missing
in an upgraded package, for instance :>). It helps to some degree to
cover against issues in the package set, but it still doesn't innoculate
us against configuration differences - hardware borking between kernel
releases, different partition layouts etc.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
Adam Williamson
2013-01-24 06:14:28 UTC
Permalink
Post by Jaroslav Reznik
If this method will be tested by FedoraQA, then I believe this upgrade method
can be safely recommended to user.
On a practical level, this is not a good thing to rely on. It is
impossible for QA to cover the entire set of possible upgrades, or even
an appreciable fraction of it.

The upgrade testing we do can reliably expose major problems with the
upgrade mechanism itself, and - mostly - major problems in core and
commonly-used package scripts. It can never be relied upon to expose
anything beyond that; and any scenarios in which 'FedoraUpgrade' would
produce a worse result than fedup are likely to fall into this set.
Thus, QA testing of 'FedoraUpgrade' would not be a reasonable foundation
on which to build an assertion that it is a safe upgrade method, worthy
of recommendation to end users.

Several knowledgeable developers have asserted that - while it often
happens to work out okay - online upgrading is an inherently dangerous
operation, I don't see that the limited amount of validation QA is able
to offer can possibly gainsay them.

Personally, I'd agree with several other responders that yum upgrade
should stay in its current status: we document it but discourage it.

(As a side note, I would like to avoid describing fedup as 'officially
supported' and describe it instead as 'officially recommended' - it's an
important semantic difference, I think.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
Matthew Miller
2013-01-24 13:56:20 UTC
Permalink
Post by Adam Williamson
(As a side note, I would like to avoid describing fedup as 'officially
supported' and describe it instead as 'officially recommended' - it's an
important semantic difference, I think.)
Because we don't "officially support" anything, or because it has lesser
status than, say, doing a fresh install and preserving home?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm at fedoraproject.org>
Adam Williamson
2013-01-24 23:19:32 UTC
Permalink
Post by Matthew Miller
Post by Adam Williamson
(As a side note, I would like to avoid describing fedup as 'officially
supported' and describe it instead as 'officially recommended' - it's an
important semantic difference, I think.)
Because we don't "officially support" anything, or because it has lesser
status than, say, doing a fresh install and preserving home?
Because we don't 'officially support' anything, correct. When someone
files a bug on upgrade our usual response is not to fix it immediately
and try to help them recover their borked system, our usual response
tends to be to file it in the same place as Arthur Dent's local council
filed their bypass designs...

being less flippant, it's really just that upgrade is inherently an
operation that a project like Fedora can't really 'support'. It's always
going to be best effort and it's probably going to break for some
people. 'Recommend' just seems like a better verb. I would suggest this,
frankly, whatever the method in question is.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
Chris Adams
2013-01-24 14:27:51 UTC
Permalink
Post by Adam Williamson
Several knowledgeable developers have asserted that - while it often
happens to work out okay - online upgrading is an inherently dangerous
operation, I don't see that the limited amount of validation QA is able
to offer can possibly gainsay them.
The way some other Unix OSes I've used worked for version upgrades was
to require the admin drop to single-user mode first, optionally with
network access. RHL/RHEL/Fedora have never had a "single-user with
network" mode, but that would be nice to have. Then maybe "yum upgrade"
could require (or at least recommend) switching to that mode first.
--
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Björn Persson
2013-01-25 15:58:37 UTC
Permalink
Post by Chris Adams
The way some other Unix OSes I've used worked for version upgrades was
to require the admin drop to single-user mode first, optionally with
network access. RHL/RHEL/Fedora have never had a "single-user with
network" mode, but that would be nice to have. Then maybe "yum upgrade"
could require (or at least recommend) switching to that mode first.
Isn't that essentially what Fedup does?

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/5ea76eb4/attachment-0001.sig>
Björn Persson
2013-01-25 16:03:14 UTC
Permalink
Post by Adam Williamson
(As a side note, I would like to avoid describing fedup as 'officially
supported' and describe it instead as 'officially recommended' - it's an
important semantic difference, I think.)
Good idea. I've often wondered what it means that upgrading by Yum
isn't supported, as Fedora is said to be community-supported and the
community seems to be supporting Yum upgrades about as well as any
other aspect of Fedora.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/7a844e65/attachment-0001.sig>
kaperang07
2013-01-25 18:11:33 UTC
Permalink
Post by Przemek Klosowski
Post by Lennart Poettering
If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...
Then all code that runs that is not a system service is difficult to
restart from a system script. How do you plan to restart Evolution or
Firefox, or Gimp?
...
Post by Lennart Poettering
Of course, you could tell the user as last step of your script to
"please reboot now", but if you do that your update isn't "online"
anymore, but is awfully close to real offline upgrades, except that
during the upgrade period you have a ton of processes around that might
be seriously confused by not being able to find their own resources
anymore or in wrong versions...
This is a pessimistic view but I think it's not as intractable.
There are two separate aspects to it: discovery what needs to be
restarted, and the actual process of restarting. The discovery is almost
there: we know the resources (libs, files, etc) that were replaced, so
it's a matter of walking the list of running processes and checking if
they depend on those resources. I can see how transient I/O, including
dlopen() could be tricky, but I don't think it's fundamentally
impossible---at worst, it'd be implementing some sort of
/proc/1234/history-of-opened-fd mechanism.
That leaves the restarting: again it seems to me that is not as hopeless
as you make it sound, either: kernel is hardest but even there people
are working on ksplice. Many services are designed to be restarted, like
DHCPD which doesn't even have an online reload but has to be bounced if
the DHCP data file changes.
Regular process restart is of course application dependent, but e.g.
Firefox actually restarts relatively graciously: I just killed mine and
the new instance reopened all my tabs (a pleasant surprise--I expected
the Restore Session ("Well this is embarrassing") window I was used to).
- no problems restarting anytime
- availability problems but no data loss on restart (easy restart but
maybe needs user confirmation)
- some out-of-process support needed (file rotation/cleanup, etc)
- user intervention required (saving files, etc).
I believe that seamless upgrades are an attractive goal. I am not
arguing for infinite upgrades---only a fresh install can guarantee
getting all new technologies that one wouldn't get through upgrades
because they may not even existed at the original installation. My point
is that the reinstall decision should be in principle driven by the
user, not by the OS release schedule.
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/2fb91849/attachment-0001.html>
kaperang07
2013-01-25 18:22:44 UTC
Permalink
Post by Lennart Poettering
Post by Simo Sorce
Post by Matthew Garrett
Post by Simo Sorce
We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.
Well, that's the problem. Most of our users (including many of the
professional sysadmins) are *not* able to make a fully informed choice
about whether an online upgrade will ensure that they're no longer
running any code with known security issues. That's not a criticism of
them - it's just a much harder problem than almost everyone realises.
Nobody's suggesting making it impossible to use yum, but blessing it as
a first-class distribution upgrade mechanism is a bad idea. There's far
too many corner cases, and we can't justify the effort it'd take to fix
all of them.
Nonsense, for a distribution upgrade you just recommend the admin to
reboot the system when done.
Everybody expects to reboot after a big distro-sync anyway as there is a
new kernel and basically new-everything.
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/15f43109/attachment-0001.html>
William Brown
2013-01-26 02:44:58 UTC
Permalink
Post by Lennart Poettering
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
In the future, hopefully once btrfs is a bit more mature, perhaps it
could be considered to make a new writable snapshot subvolume of the
system, and the use yum prefix to update the new subvolume. When you
reboot, the new subvolume can become the new root.

a) Currently running system files aren't affected.
b) All upgrades are done online
c) the update would merely be a switching of the root device on next
reboot
d) you could even roll-back by remounting the old root subvolume as the
root fs.

This would be similar to "boot environments" in solaris.

Of course, if btrfs wasn't in use, there could be some fallback?
--
Sincerely,

William Brown

pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 876 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130126/c3c67cf0/attachment-0001.sig>
Sam Varshavchik
2013-01-26 04:20:23 UTC
Permalink
Post by William Brown
In the future, hopefully once btrfs is a bit more mature, perhaps it
could be considered to make a new writable snapshot subvolume of the
system, and the use yum prefix to update the new subvolume. When you
reboot, the new subvolume can become the new root.
a) Currently running system files aren't affected.
b) All upgrades are done online
c) the update would merely be a switching of the root device on next
reboot
d) you could even roll-back by remounting the old root subvolume as the
root fs.
Now, what's not clear to me – what exactly happens if, say, at the same
time I'm browsing the web at the same time, watching videos. That generates
write activity, changes to the disk, so what happens to all other disk
activity while the upgrade takes place.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/d6edac38/attachment-0001.sig>
Chris Murphy
2013-01-26 17:16:33 UTC
Permalink
Post by William Brown
In the future, hopefully once btrfs is a bit more mature, perhaps it
could be considered to make a new writable snapshot subvolume of the
system, and the use yum prefix to update the new subvolume. When you
reboot, the new subvolume can become the new root.
a) Currently running system files aren't affected.
b) All upgrades are done online
c) the update would merely be a switching of the root device on next
reboot
d) you could even roll-back by remounting the old root subvolume as the
root fs.
Now, what's not clear to me – what exactly happens if, say, at the same time I'm browsing the web at the same time, watching videos. That generates write activity, changes to the disk, so what happens to all other disk activity while the upgrade takes place.
Disk contention, and things may be sluggish. Chances are your videos won't stutter, but I guess that depends on the video bit rate, effectiveness of disk and file system read ahead, and application buffering all are.


Chris Murphy
Chris Adams
2013-01-26 05:33:11 UTC
Permalink
Post by William Brown
In the future, hopefully once btrfs is a bit more mature, perhaps it
could be considered to make a new writable snapshot subvolume of the
system, and the use yum prefix to update the new subvolume. When you
reboot, the new subvolume can become the new root.
Even that won't help when there are kernel updates that move kernel
filesystems around (like some things have moved from their own top-level
mountpoints to under /sys).
--
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Kevin Kofler
2013-02-04 04:20:08 UTC
Permalink
Post by Jaroslav Reznik
= Features/FedoraUpgrade =
https://fedoraproject.org/wiki/Features/FedoraUpgrade
Feature owner(s): Miroslav SuchÜ <msuchy at redhat.com>
Upgrade Fedora to next version using yum upgrade.
I propose to have FedUp and FedoraUpgrade in Fedora 19.
not using that FedoraUpgrade script. Sorry, but IMHO, that script causes
more problems than it solves.

For one, it's a one step approach, whereas the IMHO nicest solution, which
is IMHO the best compromise between safety and minimum downtime, and which
also works if you don't have working networking outside of user sessions (NM
user connection), is the following:
yum --releasever=n+1 --downloadonly distro-sync
telinit 3
yum --releasever=n+1 -C distro-sync
which cannot be done in a single script (the telinit would kill the script
if it's run from the graphical session). (And sorry Lennart for using
telinit 3 rather than whatever the native systemd equivalent is. ;-) )

In addition, not all the things the script does are strictly required and
wanted by all users, and finally, I don't think the steps are so tedious as
to deserve automation.

Kevin Kofler
Continue reading on narkive:
Loading...