fedup for F23 and beyond

[Stephen John Smoogen]

On 8 June 2015 at 06:37, Neal Gompa <ngompa13 at gmail.com> wrote:
> On Sun, Jun 7, 2015 at 3:30 PM, Will Woods <wwoods at redhat.com> wrote:
>> On Sun, 2015-06-07 at 07:41 -0400, Neal Gompa wrote:
>>> Uhh, this might be a stupid question, but what actually prevents us
>>> from integrating the FedUp process into install media (that is, not
>>> live images)? I mean, yeah, it's nice that we can do upgrades online,
>>> but what about when the system we need to upgrade doesn't necessarily
>>> have online access? I'd like to be able to trigger the upgrade
>>> environment from install media (like with a Fedora Server ISO).
>>
>> Nothing, really - it's *better* if you have access to the updates repos
>> during the upgrade, but it's technically feasible to do the upgrade
>> from local media/repos.
>>
>> To make that work, you'd need:
>>
>> a) a way to easily enable the media as a repo, and then
>> b) run DNF in offline mode (so it's OK with the unreachable network
>> repos), and then
>> c) ensure that the media will be mounted in the same place after reboot
>> (e.g. by adding it to /etc/fstab) so the upgrade can proceed.
>>
>> (this workflow might even work with the current dnf-plugin-fedup, but I
>> haven't tried it...)
>>
>> So, yeah, the last one is the trickiest part. It's very hard to be
>> certain about whether a given filesystem path will be there when you
>> reboot. So we either need to just leave that up to the user, or write
>> mount units for *everything* on the system and hope that systemd
>> figures it out after we reboot.
>>
>> (It's on my TODO list, since the fedup supported this with --device,
>> but.. I just don't have spare time right now.)
>>
>> -w
>> --
>> devel mailing list
>> devel at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
> From my view, if you're booting from an ISO already, wouldn't you be
> able to consider that in a state in which you could just do the
> upgrade? Couldn't Anaconda just drive DNF through the upgrade process?
> When you're booting from the ISO, you've already mounted the local
> filesystem and package repositories, so you could use it from there. I
> would figure that DNF is already configured for offline mode during
> anaconda installs as it is (unless, of course, you tell it to grab
> updates from the Internet). Unless I'm missing something really big, I
> don't see why you need to reboot when you're already offline and using
> the Fedora install media boot environment to do an upgrade.

The problem that has plagued updates since RHL-4 in 1997 has been that
updates on the system may and can be of a newer NEVR than what is on
the ISO. This then requires you to be able to have the system online
to download updates and then have space for those updates which at
that point usually ends up meaning you are not gaining much from the
iso.

The usual problem usually ends up being something like: Fedora X and
X+1 have 2 libraries (let us say with the same major.minor numbers at
release time. Then there was a security update which got applied to
the system which means that the ISO has an older major.minor version
than the system. [This is usually something like gzip, gpg or some
other tool] You then either  have to abort the upgrade or do an rpm
-Uvh --force  type of upgrade. Or you have to tell the user that they
need a network connection and space on the system to download various
upgrades to sort out what was needed. However the reason most people
are wanting to upgrade from an ISO is because the system doesn't have
a good network connection and they were hoping to not have to pay for
a multi gigabyte download. Let us just say that a lot of users
complained about this and have done so for the time frame of ISO
updates until it was finally dropped by the anaconda team because they
were sick and tired of trying to deal with it.


>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
Stephen J Smoogen.