(RHEL-13193) fix(url-lib.sh): nfs_already_mounted() with trailing slash in nfs path

[pvalena]

nfs_already_mounted() doesn't work when the installation ISO and kickstart file on a same NFS share are specified with inst.repo and inst.ks boot parameter as below.

inst.repo=nfs:192.168.1.1:/home/data/rhel9.iso inst.ks=nfs:192.168.1.1:/home/data/ks.cfg

NOTE: /home/data is configured for nfs share on 192.168.1.1

One problem is a file (not a directory) was passed into nfs_already_mounted().
nfs_already_mounted() is the function to judge if the given directory is already mounted.
So, filepath should be passed in nfs_fetch_url().

The other problem is about the trailing slash in the nfs path in /proc/mounts.

The /proc/mounts has an entry after nfs mount of inst.repo.

192.168.1.1:/data/ /run/install/isodir nfs ro,relatime,

In this case, nfs_already_mounted() returns "/run/install/isodir//home/data/ks.cfg" wrongly. The following is from the log.

[ 14.556279] localhost.localdomain dracut-initqueue[1282]: ///lib/url-lib.sh@156(nfs_fetch_url): nfs_already_mounted 192.168.122.1 /home/data/ks.cfg
[ 14.556279] localhost.localdomain dracut-initqueue[1282]: ///lib/url-lib.sh@137(nfs_already_mounted): local server=192.168.122.1 path=/home/data/ks.cfg s= p=
...
[ 14.654966] localhost.localdomain dracut-initqueue[1282]: ///lib/url-lib.sh@140(nfs_already_mounted): '[' 192.168.122.1 = 192.168.122.1 ']'
[ 14.654966] localhost.localdomain dracut-initqueue[1282]: ///lib/url-lib.sh@141(nfs_already_mounted): '[' /home/data/ks.cfg = /home/data/ ']'
[ 14.654966] localhost.localdomain dracut-initqueue[1282]: ///lib/url-lib.sh@143(nfs_already_mounted): str_starts /home/data/ks.cfg /home/data/
[ 14.654966] localhost.localdomain dracut-initqueue[1282]: ///lib/dracut-lib.sh@51(str_starts): '[' ks.cfg '!=' /home/data/ks.cfg ']'
[ 14.654966] localhost.localdomain dracut-initqueue[1282]: ///lib/url-lib.sh@144(nfs_already_mounted): echo /run/install/isodir//home/data/ks.cfg
...
[ 14.658069] localhost.localdomain dracut-initqueue[934]: //lib/url-lib.sh@156(nfs_fetch_url): mntdir=/run/install/isodir//home/data/ks.cfg

This function doesn't expect the trailiing slash of the nfs path in /proc/mounts, so it should be removed before processing it.

feat(test): nfs_fetch_url test into nfs test

This is to check the behavior of nfs_fetch_url() in nfs-lib.sh.
nfs_fetch_url() calls nfs_already_mounted() internally.
A file /nfs/client/root/fetchfile is on NFS server, which is fetched
from clients for testing with nfs_fetch_url().

(Cherry-picked commits:
b731369c5fe7f9247337fe08017638a38f36cfca
3cf092dbd8754a31595b0d8447827c6358fc3a88)

Resolves: RHEL-13193

[github-actions]

Commit validation

Tracker - RHEL-13193

The following commits need an inspection

commit	note
b105492 - fix(url-lib.sh): nfs_already_mounted() with trailing slash in nfs path…	Missing upstream reference ‼️

---

Tracker validation

Success

🟢 Tracker RHEL-13193 has set desired product: rhel-9.0.0
🟢 Tracker RHEL-13193 has set desired component: dracut
🟢 Tracker RHEL-13193 has been approved

---

Pull Request validation

Failed

🔴 Failed or pending checks - triage[failure],testing-farm:centos-stream-9-x86_64[failure]
🔴 Review - Missing review from a member

[pvalena]

@jamacku I'm afraid I can't add reviews.

Also; do I need to do something to re-validate the commit / tracker? I've added the missing FixVersion.

[pvalena]

And the testing farm issue ,.... I'm not sure why it's looking for epel-9-x86_64 buildroot :/. But I suppose we can simply drop the install test....

[mrc0mmand]

And the testing farm issue ,.... I'm not sure why it's looking for epel-9-x86_64 buildroot :/. But I suppose we can simply drop the install test....

I saw this a couple of months back as well and it was a bug on OSCI side. Let's just ignore the failing job there, I'll look into that in the meantime.

[jamacku]

@jamacku I'm afraid I can't add reviews.

Also; do I need to do something to re-validate the commit / tracker? I've added the missing FixVersion.

The automation runs periodically; there is no need to start it manually. However, you can run it manually using the Run workflow dropdown button.

A review is currently required, and unfortunately, there is no option to configure it. However, I believe that even without automatic merging, you will find some value in this automation (JIRA validation, follow-up detection, etc.).

[mrc0mmand]

And the testing farm issue ,.... I'm not sure why it's looking for epel-9-x86_64 buildroot :/. But I suppose we can simply drop the install test....

I saw this a couple of months back as well and it was a bug on OSCI side. Let's just ignore the failing job there, I'll look into that in the meantime.

Ah, I thought I had a weird sense of deja vu - the last time I saw it was also in this repo (#82 (comment)) and the respective Testing Farm issue is still open: https://gitlab.com/testing-farm/general/-/issues/78 sigh

[pvalena]

LGTM.