On 8 June 2015 at 06:37, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > On Sun, Jun 7, 2015 at 3:30 PM, Will Woods <wwoods@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
