system-upgrade from CIFS-mounted repo?

[Greg Woods]

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 [e-mail] 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

[Greg Woods]

On Thu, May 30, 2019 at 7:21 AM  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