I have a feeling that when this is resolved I'll be doing a face palm and saying "of course, you idiot!" but I'm not seeing the answer right now.
I have a local repo that I maintain using rsync from an official Fedora mirror site. This repo is located on one of my "always-on" servers using a systemd automount in /etc/fstab:
worldsys:/install /install nfs rw,x-systemd.automount 0 0
This works great for installing new packages and doing updates, but it does not work for doing dnf system-upgrade. The packages are not copied when the "system-upgrade download" is done because they are already on a locally-available file system, but when the "system-upgrade reboot" is done, the upgrade fails (presumably because the remote file system is not available at the point of the upgrade boot where the upgrade transaction is run, either because the network is not up or the automount is not happening).
Is it impossible to do a system-upgrade from a remote-mounted repo (which would defeat much of the purpose of maintaining such a repo), or is there a way to make the network come up and the automount happen at system-upgrade reboot time?
I suppose I could set up a web server on the system with the repo so that the download would be forced at system-upgrade download time, but that's a big hammer for a small nail that I would prefer to avoid.
Thanks, --Greg
Hi.
On Wed, 29 May 2019 10:58:01 -0600 Greg Woods wrote:
worldsys:/install /install nfs rw,x-systemd.automount 0 0
Is it impossible to do a system-upgrade from a remote-mounted repo (which would defeat much of the purpose of maintaining such a repo), or is there a way to make the network come up and the automount happen at system-upgrade reboot time?
Looking at the man of systemd.offline-updates this should be possible. See for example near the end:
5. It may be desirable to always run an auxiliary unit when booting into offline-updates mode, which itself does not install updates. To do this create a .service file with Wants=system-update-pre.target and Before=system-update-pre.target and add a symlink to that file under /usr/lib/systemd/system-update.target.wants . ## Typo there, it's: ## /usr/lib/systemd/system/system-update.target.wants
I suggest in the following to proceed slightly differently (untested):
[1] system-update.target do not define a Wants=system-update-pre.target only a After=
add a link to ../system-update-pre.target in /usr/lib/systemd/system/system-update.target.wants/
[2] create /usr/lib/systemd/system/system-update-pre.target.wants/
[3] put links in it for:
NetworkManager.service NetworkManager-wait-online.service autofs.service
[4] Override system-update-pre.target for the ordering
create: /usr/lib/systemd/system/system-update-pre.target.d/override.conf
with:
[Unit] After=NetworkManager.service NetworkManager-wait-online.service autofs.service
In addition you may gain adding the nolock option to the NFS mount: that will prevent a requirement to rpcbind and rpc.statd
You can also replace autofs by a static mount defined with a systemd unit install.mount in which you can declare the Before= ordering
PS: I wonder why you said CIFS in the subject :-)
On Thu, 30 May 2019 11:07:50 +0200 Francis.Montagnac@inria.fr wrote:
[3] put links in it for:
...
autofs.service
I was wrong here: you are not using autofs but the automount of systemd.
Make instead a link to /run/systemd/generator/install.mount or write an install.mount unit instead of using /etc/fstab
Adding also a link to rescue.service may help for debugging
On Thu, May 30, 2019 at 7:21 AM Francis.Montagnac@inria.fr wrote:
Make instead a link to /run/systemd/generator/install.mount or write an install.mount unit instead of using /etc/fstab
Thanks, I will try that when I have time for the next upgrade.
And the reason it says CIFS in the subject when it's an NFS mount is: senior moment. I have another systemd automount that *is* via CIFS, and I lost track of which was which.
--Greg