Universal Blue•15mo ago

GitHub - graybush/testFromContainer

i am having some nfs trouble and i think i have narrowed it down to a difference in the images: quay.io/fedora-ostree-desktops/silverblue:37 ghcr.io/cgwalters/fedora-silverblue:37 to test I created a repository https://github.com/graybush/testFromContainer and generated two images. ghcr.io/graybush/cgwalters:37-20230311 ghcr.io/graybush/fedora-ostree-desktops:37-20230311 each image has the same containerfile with the exception of the FROM statement. to start i have a fully updated, yet stock silverblue:37 install with an nfs mount defined in /etc/fstab that is mounted upon boot. when i rebase from a fully updated fedora/silverblue:37 base to the cgwalters image my nfs mount mounts on boot as expected. but when i rebase from the same fully updated fedora/silverblue:37 base to the fedora-ostree-desktops image my nfs mount does not automatically mount on boot. what am i missing?

GitHub

Contribute to graybush/testFromContainer development by creating an account on GitHub.

87 Replies

bsherman•15mo ago

i feel like these troubleshooting things are well suited to threads so, to be clear, the nfs mount works fine on both images... only on the one, it won't AUTO-mount at boot, right? i've got a VM i don't mind rebasing to your images

100uF•15mo ago

right. from the fedora-ostree-desktop image the mount does not automount, but if i do a sudo mount -a it mounts just fine

bsherman•15mo ago

no messages in journal about this?

100uF•15mo ago

not sure, i've been looking at this all day and might of forgotten some things, sorry!

bsherman•15mo ago

i just spent hours debugging a problem which was a combination of a missing path in /var/log, and then when i attempted to create it, there was a systemd race condition ( my ordering wasn't right) and then finally an incorrect selinux context... so I'm sure it could be super tricky, but there's probably SOME clue,

100uF•15mo ago

i am going to put my vm back on the fedora-ostree image and i'll look at the journal at this point i am pretty confident that if you have an nfs mount defined in the stock silverblue then rebase between those images in one you'll see the mount auto mount just fine and in the other nothing, that is pretty much as far as i've gotten. it's been a journey thus far, lol

100uF•15mo ago

when looking thru the journal journalctl -p 3 -xb the only errors i see are:

100uF•15mo ago

when i look through the journal for the cgwalters image i can search for the mount point /mnt/nas and i can clearly see it mounting. but when i search the journal for the fedora-ostree-desktops image there is nothing, i dont see an attempt or error, just nothing.

bsherman•15mo ago

sorry i disappeared... one child kicked another one off the couch, causing the one kicked to cut open her elbow sigh accidental kicking, thankfully 🙂

100uF•15mo ago

ahh no worries, mine go to bed at 10, now I have free time!

bsherman•15mo ago

yeah, they were up too late but that was nearly a 45 minute ordeal LOL

100uF•15mo ago

nice

bsherman•15mo ago

ok, so... seeing /mnt/nas work in one journal and NOTHING in the other... that seems of interest

100uF•15mo ago

ok! so i am not crazy

bsherman•15mo ago

like... if the same set of packages are installed, then maybe one is configured differently. what's the fstab nfs mount look like?

100uF•15mo ago

pretty basic at this point

bsherman•15mo ago

cool, i just want to try with same options

100uF•15mo ago

no, i really appreciate the second set of eyes. i've been on this all day, it took me a while to narrow it down to something about these to base images

bsherman•15mo ago

yeah, this is definitely part of the 'experimental' nature of things... it's hard to know where the bug is or if it's just part of the "new way"

j0rge•15mo ago

does walter's image have some automounting package or some other convenience thing perhaps?

bsherman•15mo ago

trying to fix a networking issue on my desktop so i can test this the way i want

100uF•15mo ago

left and right, you can see on the left systemd var-lib-nfs-rpc_pipefs.mount and var-mnt-nas.mount , then nothing on the right. that is basically what i've observed until this point on the cgwalters container things automounting, on the fedora-ostree-desktops container nothing...

100uF•15mo ago

i am coming up blank as to what to look for, i dont see errors in the journal or audit.log...

bsherman•15mo ago

ok, finally got my network bridge setup properly... never should have tried to use the GUI 🙂 it just caused problems rebasing to you cgwalters-based image

100uF•15mo ago

yeah i feel like i need stand up another vm, i keep rolling back and rebasing back and forth between images

bsherman•15mo ago

what is systemd-boot-unsigned?

100uF•15mo ago

i do not know the Container files I used to generate the images are exactly the same with the exception of the FROM statement

bsherman•15mo ago

ok, i just noticed that this was added as something i didn't already have random: any reason you aren't using ublue-os/main for your base? or is it exactly this issue since its' based on the image which doesn't automount nfs

100uF•15mo ago

ublue-os/main ultimately comes from fedora-ostree-desktop i would like to use ublue-os/main the contianer i would like to use is graybush/simsulator, it is for my daughter and it uses ublue-os/main but i keep the home dirs and some data on an nfs server so today when attempting to switch her computer over, i ran into this problem my main workstation has been using silverblue ublue since december

bsherman•15mo ago

yep makes sense happy to be another set of eyes, this is the kind of thing i want to work too

100uF•15mo ago

yeah so in debug i traced the problem down to when the base for ublue-base switched, so i created these images to get right to the problem which was about jan 24th i believe

bsherman•15mo ago

ok, i have an nfs mount in my fstab... and mounted manually. 192.168.129.10:/data/files/music /mnt/music nfs4 defaults 0 0 and.. i'm on ostree-unverified-registry:ghcr.io/graybush/cgwalters:37-20230311 and... i'll reboot and see what happens

100uF•15mo ago

i switched my main workstation over to silverblue in dec, since that time i have had 3 problems, a freeipa problem, this nfs automount issue, and another systemctl --user issue

bsherman•15mo ago

mounted, auto-mounted, which you expect

100uF•15mo ago

other than that, silverblue has been a game changer for me yeah cgwlaters mounts everytime

bsherman•15mo ago

yep

100uF•15mo ago

now if all you do is rebase to the fedora-ostree-desktop image it will not automount

bsherman•15mo ago

100uF•15mo ago

which may or may not be a big deal, unless you want to keep home dirs on nfs well, i should say i would typically rollback then rebase

bsherman•15mo ago

i'm just pinning and rebasing

100uF•15mo ago

is there a fundamental difference between pinning and rebasing vs rollback and rebasing? i would think they are the same,but to make sure i rolledback

bsherman•15mo ago

well, pinning just lets you ensure that older builds don't get replaced as you upgrade/layer/rebase i'm not sure what you mean by rollback exactly rolling back a VM?

100uF•15mo ago

after rebasing and confirming that the mount didnt work i would rpm-ostree rollback then reboot, then rebase

bsherman•15mo ago

100uF•15mo ago

i do use the pining feature, just wasnt sure if there was a difference

bsherman•15mo ago

i don't think rollback is needed

100uF•15mo ago

gotcha

bsherman•15mo ago

not for this anyway it's more like "oops, i layered something i don't actually want and rollback is fastest way to revert" maybe? i've never used it 😄 i'm guessing here ok, rebooted into fedora-ostree-desktops... comparing rpm package lists and journal logs

100uF•15mo ago

i would think pining would be fine, but just to make sure i would rollback to the stable fedora:37 ver then rebase

bsherman•15mo ago

as you say, only bolt differs in the package list

100uF•15mo ago

yes for me journal logs didnt show any errors, just an absence of mounting the nas

bsherman•15mo ago

ok, yeah, i'm going to clone the /etc dirs on the respective images and check that next... it looks like something has to be different in the config

100uF•15mo ago

clone the /etc dirs, I do not follow, what do you mean? how?

bsherman•15mo ago

well, /var and /etc are the mutable bits in this setup but... /etc is layered ... so your mutable /etc has default stuff underneath so i'm just storing data between reboots i'm actually ssh-ing into my VM as root and doing thigns since it's easier but i ran these commands so far

    journalctl -b > journal-cgwalters.log
    rpm -qa > rpmqa-cgwalters.log
    journalctl -b > journal-fedora-ostree-desktops.log
    rpm -qa > rpms-fedora-ostree-desktops.log

    journalctl -b > journal-cgwalters.log
    rpm -qa > rpmqa-cgwalters.log
    journalctl -b > journal-fedora-ostree-desktops.log
    rpm -qa > rpms-fedora-ostree-desktops.log

and that's stored in my home-dir for easy searching and for etc

100uF•15mo ago

yup, that makes sense

bsherman•15mo ago

cp -a /etc etc-fedora-ostree-desktops and cp -a /etc etc-cgwalters but then i have snapshots to compare conceptually, not literally 🙂

100uF•15mo ago

yup I follow, makes sense to me, thanks for explaining

bsherman•15mo ago

# du -sc etc*
48156    etc-cgwalters
48096    etc-fedora-ostree-desktops
96252    total

# du -sc etc*
48156    etc-cgwalters
48096    etc-fedora-ostree-desktops
96252    total

definitely different contents in /etc whoa, i'm shocked, but... i dont' see a difference

100uF•15mo ago

how did you compare the two etc's?

bsherman•15mo ago

cd etc-cgwalters
find . -type f -exec diff -uw "{}" "../etc-fedora-ostree-desktops/{}" \;

cd etc-cgwalters
find . -type f -exec diff -uw "{}" "../etc-fedora-ostree-desktops/{}" \;

i mean there are a couple diffs, but nothing obvious

[root@ublue-vm etc-cgwalters]# find . -type f -exec diff -uw "{}" "../etc-fedora-ostree-desktops/{}" \;
--- ./brlapi.key    2023-03-10 22:54:28.209334824 -0600
+++ ../etc-fedora-ostree-desktops/./brlapi.key    2023-03-10 23:06:34.319477177 -0600
@@ -1 +1 @@
-f67322ac924bf9232833ce20648bd462
+c61dc9a0e679b78565b07261a2d9c736
diff: ../etc-fedora-ostree-desktops/./alsa/state-daemon.conf: No such file or directory
--- ./crypto-policies/config    2023-03-10 22:54:28.278334156 -0600
+++ ../etc-fedora-ostree-desktops/./crypto-policies/config    2023-03-10 23:06:34.387476354 -0600
@@ -1 +1,18 @@
+# This file should contain a single keyword, the crypto policy to
+# be applied by default to applications. The available policies are 
+# restricted to the following profiles.
+#
+# * LEGACY: Ensures maximum compatibility with legacy systems (64-bit
+#   security).
+#
+# * DEFAULT: A reasonable default for today's standards (112-bit security).
+#
+# * FUTURE: A policy to provide security on a conservative level that is
+#   believed to withstand any near-term future attacks (128-bit security).
+#
+# * FIPS: Policy that enables only FIPS 140-2 approved or allowed algorithms.
+#
+# After modifying this file, you need to run update-crypto-policies
+# for the changes to propagate.
+#
 DEFAULT
--- ./cups/subscriptions.conf    2023-03-10 23:14:46.368929735 -0600
+++ ../etc-fedora-ostree-desktops/./cups/subscriptions.conf    2023-03-10 23:08:54.411591077 -0600
@@ -34,6 +34,6 @@
 Recipient dbus://
 LeaseDuration 3600
 Interval 0
-ExpirationTime 1678515255
+ExpirationTime 1678514903
 NextEventId 1
 </Subscription>
Binary files ./dconf/db/local and ../etc-fedora-ostree-desktops/./dconf/db/local differ
Binary files ./pki/ca-trust/extracted/java/cacerts and ../etc-fedora-ostree-desktops/./pki/ca-trust/extracted/java/cacerts differ
Binary files ./selinux/targeted/active/commit_num and ../etc-fedora-ostree-desktops/./selinux/targeted/active/commit_num differ

[root@ublue-vm etc-cgwalters]# find . -type f -exec diff -uw "{}" "../etc-fedora-ostree-desktops/{}" \;
--- ./brlapi.key    2023-03-10 22:54:28.209334824 -0600
+++ ../etc-fedora-ostree-desktops/./brlapi.key    2023-03-10 23:06:34.319477177 -0600
@@ -1 +1 @@
-f67322ac924bf9232833ce20648bd462
+c61dc9a0e679b78565b07261a2d9c736
diff: ../etc-fedora-ostree-desktops/./alsa/state-daemon.conf: No such file or directory
--- ./crypto-policies/config    2023-03-10 22:54:28.278334156 -0600
+++ ../etc-fedora-ostree-desktops/./crypto-policies/config    2023-03-10 23:06:34.387476354 -0600
@@ -1 +1,18 @@
+# This file should contain a single keyword, the crypto policy to
+# be applied by default to applications. The available policies are 
+# restricted to the following profiles.
+#
+# * LEGACY: Ensures maximum compatibility with legacy systems (64-bit
+#   security).
+#
+# * DEFAULT: A reasonable default for today's standards (112-bit security).
+#
+# * FUTURE: A policy to provide security on a conservative level that is
+#   believed to withstand any near-term future attacks (128-bit security).
+#
+# * FIPS: Policy that enables only FIPS 140-2 approved or allowed algorithms.
+#
+# After modifying this file, you need to run update-crypto-policies
+# for the changes to propagate.
+#
 DEFAULT
--- ./cups/subscriptions.conf    2023-03-10 23:14:46.368929735 -0600
+++ ../etc-fedora-ostree-desktops/./cups/subscriptions.conf    2023-03-10 23:08:54.411591077 -0600
@@ -34,6 +34,6 @@
 Recipient dbus://
 LeaseDuration 3600
 Interval 0
-ExpirationTime 1678515255
+ExpirationTime 1678514903
 NextEventId 1
 </Subscription>
Binary files ./dconf/db/local and ../etc-fedora-ostree-desktops/./dconf/db/local differ
Binary files ./pki/ca-trust/extracted/java/cacerts and ../etc-fedora-ostree-desktops/./pki/ca-trust/extracted/java/cacerts differ
Binary files ./selinux/targeted/active/commit_num and ../etc-fedora-ostree-desktops/./selinux/targeted/active/commit_num differ

so, back to journal on cgwalters, this is something

Mar 10 23:03:36 ublue-vm systemd[1]: Mounting var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System...
... snip ...
Mar 10 23:03:36 ublue-vm kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Mar 10 23:03:36 ublue-vm systemd[1]: Mounted var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System.

Mar 10 23:03:36 ublue-vm systemd[1]: Mounting var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System...
... snip ...
Mar 10 23:03:36 ublue-vm kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Mar 10 23:03:36 ublue-vm systemd[1]: Mounted var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System.

that happens separately from nfs-client mount of the actual mount point

[root@ublue-vm ~]# systemctl status nfs-client.target
● nfs-client.target - NFS client services
     Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; enabled; preset: disabled)
     Active: active since Fri 2023-03-10 23:14:13 CST; 11min ago

Mar 10 23:14:13 ublue-vm systemd[1]: Reached target nfs-client.target - NFS client services.
[root@ublue-vm ~]# systemctl status var-lib-nfs-rpc_pipefs.mount 
● var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System
     Loaded: loaded (/usr/lib/systemd/system/var-lib-nfs-rpc_pipefs.mount; static)
     Active: active (mounted) since Fri 2023-03-10 23:14:13 CST; 11min ago
      Where: /var/lib/nfs/rpc_pipefs
       What: sunrpc
      Tasks: 0 (limit: 9429)
     Memory: 16.0K
        CPU: 1ms
     CGroup: /system.slice/var-lib-nfs-rpc_pipefs.mount

Mar 10 23:14:13 ublue-vm systemd[1]: Mounting var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System...
Mar 10 23:14:13 ublue-vm systemd[1]: Mounted var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System.

[root@ublue-vm ~]# systemctl status nfs-client.target
● nfs-client.target - NFS client services
     Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; enabled; preset: disabled)
     Active: active since Fri 2023-03-10 23:14:13 CST; 11min ago

Mar 10 23:14:13 ublue-vm systemd[1]: Reached target nfs-client.target - NFS client services.
[root@ublue-vm ~]# systemctl status var-lib-nfs-rpc_pipefs.mount 
● var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System
     Loaded: loaded (/usr/lib/systemd/system/var-lib-nfs-rpc_pipefs.mount; static)
     Active: active (mounted) since Fri 2023-03-10 23:14:13 CST; 11min ago
      Where: /var/lib/nfs/rpc_pipefs
       What: sunrpc
      Tasks: 0 (limit: 9429)
     Memory: 16.0K
        CPU: 1ms
     CGroup: /system.slice/var-lib-nfs-rpc_pipefs.mount

Mar 10 23:14:13 ublue-vm systemd[1]: Mounting var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System...
Mar 10 23:14:13 ublue-vm systemd[1]: Mounted var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System.

rebooting to check those out on the other oh 🙂 yeah, that's simple

[root@ublue-vm ~]# systemctl status nfs-client.target 
○ nfs-client.target - NFS client services
     Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled; preset: disabled)
     Active: inactive (dead)
[root@ublue-vm ~]# systemctl status var-lib-nfs-rpc_pipefs.mount 
○ var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System
     Loaded: loaded (/usr/lib/systemd/system/var-lib-nfs-rpc_pipefs.mount; static)
     Active: inactive (dead)
      Where: /var/lib/nfs/rpc_pipefs
       What: sunrpc

[root@ublue-vm ~]# systemctl status nfs-client.target 
○ nfs-client.target - NFS client services
     Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled; preset: disabled)
     Active: inactive (dead)
[root@ublue-vm ~]# systemctl status var-lib-nfs-rpc_pipefs.mount 
○ var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System
     Loaded: loaded (/usr/lib/systemd/system/var-lib-nfs-rpc_pipefs.mount; static)
     Active: inactive (dead)
      Where: /var/lib/nfs/rpc_pipefs
       What: sunrpc

nfs-client is not enabled

[root@ublue-vm ~]# systemctl enable --now nfs-client
Failed to enable unit: Unit file nfs-client.service does not exist.

[root@ublue-vm ~]# systemctl enable --now nfs-client
Failed to enable unit: Unit file nfs-client.service does not exist.

oops, i missed the .target

100uF•15mo ago

you are too fast for me, are you saying all i needed to do is enable the nfs-client service?

bsherman•15mo ago

[root@ublue-vm ~]# systemctl enable --now nfs-client.target
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /usr/lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /usr/lib/systemd/system/nfs-client.target.

[root@ublue-vm ~]# systemctl enable --now nfs-client.target
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /usr/lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /usr/lib/systemd/system/nfs-client.target.

i did that and rebooted, still no automount, but i think we must be closer partially yes what we are discovering here is for some reason cgwalters' image has services enabled which are disabled on fedora-ostree-desktops

100uF•15mo ago

got it i did notice that var-lib-nfs-rpc_pipefs.mount does not run in the fedora-ostree-desktops image, but i wasnt sure of the root cause

bsherman•15mo ago

[root@ublue-vm ~]# systemctl status remote-fs.target 
○ remote-fs.target - Remote File Systems
     Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; disabled; preset: enabled)
     Active: inactive (dead) since Fri 2023-03-10 23:29:04 CST; 2min 56s ago
       Docs: man:systemd.special(7)

Mar 10 23:29:03 fedora systemd[1]: Reached target remote-fs.target - Remote File Systems.
Mar 10 23:29:04 fedora systemd[1]: Stopped target remote-fs.target - Remote File Systems.

[root@ublue-vm ~]# systemctl status remote-fs.target 
○ remote-fs.target - Remote File Systems
     Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; disabled; preset: enabled)
     Active: inactive (dead) since Fri 2023-03-10 23:29:04 CST; 2min 56s ago
       Docs: man:systemd.special(7)

Mar 10 23:29:03 fedora systemd[1]: Reached target remote-fs.target - Remote File Systems.
Mar 10 23:29:04 fedora systemd[1]: Stopped target remote-fs.target - Remote File Systems.

this seems wrong

systemctl enable --now remote-fs.target
Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target → /usr/lib/systemd/system/remote-fs.target.

systemctl enable --now remote-fs.target
Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target → /usr/lib/systemd/system/remote-fs.target.

ok, yeah... that's the 2 targets you need:

systemctl enable --now remote-fs.target
systemctl enable --now nfs-client.target

systemctl enable --now remote-fs.target
systemctl enable --now nfs-client.target

then your mount should occur, and reoccur on reboot just verified with a reboot here, too

100uF•15mo ago

i concur thank you!

bsherman•15mo ago

you're welcome! it's super weird to me how these "identical" images have different defaults... clearly they are being built differently

100uF•15mo ago

can i download this thread?

bsherman•15mo ago

i'm not copyrighting it if that's what you mean 😉

100uF•15mo ago

i am going to have to go thru this again just to make sure that i appreciate your debug efforts i just want to fully understand how you got from here to there

bsherman•15mo ago

it's just gray beard stuff

100uF•15mo ago

yeah this is great i honestly just thought those two images were the same when the switch over happened

bsherman•15mo ago

like literally, i have a gray beard, LOL i'm old (not too old) but i've been doing it a while...

100uF•15mo ago

i've been doing this a few years, dont have a beard yet though, probably cant grow a full one though!

bsherman•15mo ago

so, i'm old school enough that i didn't really "know" how systemd does nfs exactly, i know it would control it, but i didn't recallhow exactly so, I started with the easy to check stuff... which you helped with initially by noticing the difference in journal logs then confirming those rpm package lists then comparing /etc files now that ruled out differences in files like /etc/nfsmount.conf ... but... it may have also been a bit misleading since it didn't check for missing or dangling symlinks... and systemd uses those a fair bit for "enabled" or not, and service/target relationships anyway, then i decided to study the good journal in more detail and then inspect the status of the nfs related services where were running in it so a key thing i paid attention too on the cgwalters side Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; enabled; preset: disabled it's nfs-client was enabled but that's not default... as the preset is disabled but when enabling nfs-client was not enough to automount, i just happened to remember that remote-fs is a thing

100uF•15mo ago

yeah those are excellent points, i am wondering if i would of looked closer at the systemd units that load the nfs mounts if i might of caught this i def know about nfs-client, im not so sure about remote-fs

bsherman•15mo ago

yeah, the most direct path would hav ebeen seeing "oh, nfs-client is not running" then doing status on it... but more than just running status

# systemctl cat nfs-client.target
# /usr/lib/systemd/system/nfs-client.target
[Unit]
Description=NFS client services
Before=remote-fs-pre.target
Wants=remote-fs-pre.target

# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.
Wants=rpc-statd-notify.service

# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service rpc-svcgssd.service gssproxy.service

[Install]
WantedBy=multi-user.target
WantedBy=remote-fs.target

# systemctl cat nfs-client.target
# /usr/lib/systemd/system/nfs-client.target
[Unit]
Description=NFS client services
Before=remote-fs-pre.target
Wants=remote-fs-pre.target

# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.
Wants=rpc-statd-notify.service

# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service rpc-svcgssd.service gssproxy.service

[Install]
WantedBy=multi-user.target
WantedBy=remote-fs.target

that clearly shows you that the nfs-client.target interacts with remote-fs.target

100uF•15mo ago

yes it does

bsherman•15mo ago

more specifically, enabling-remotefs.target may be all we need? i will test, now i'm curious

100uF•15mo ago

thanks so much for looking at this i've been looking at this all day and was only able to narrow it down to something with these two images i am not sure i could of taken it to its completion like you did thank you

bsherman•15mo ago

you're welcome! just share the knowledge as you can

100uF•15mo ago

will do!

bsherman•15mo ago

btw answered the question... all that seems to be needed is systemctl enable remote-fs.target it seems to force nfs-client auto-mounts on reboot even if nfs-client.target is disabled regardless, having both enabled won't hurt

100uF•15mo ago

sounds like I could add that line to my git's Containerfile and it should resolve this issue ... good to know

bsherman•15mo ago

yeah, that would do it, you'll see a number of systemctl enable FOO lines in the ublue-os Containerfiles (or the scripts they call, like https://github.com/ublue-os/main/blob/main/post-install.sh

100uF•15mo ago

yup, make sense. i just forked https://github.com/ublue-os/startingpoint so I will probably add it there

GitHub

GitHub - ublue-os/startingpoint: Starting point for making your own...

Starting point for making your own OS image (WIP). Contribute to ublue-os/startingpoint development by creating an account on GitHub.

bsherman•15mo ago

👍

Gaming

Programming

GitHub - graybush/testFromContainer