Bug 2037233 - generated sysroot.mount in nfsroot case (initramfs) is wrong
Summary: generated sysroot.mount in nfsroot case (initramfs) is wrong
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-05 10:10 UTC by Tomasz Torcz
Modified: 2022-01-15 01:21 UTC (History)
11 users (show)

Fixed In Version: systemd-250-3.fc36 systemd-249.9-1.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-10 21:43:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1989119 1 unspecified NEW Nfsroot system fails to boot when using systemd-networkd 2023-02-07 14:52:22 UTC

Description Tomasz Torcz 2022-01-05 10:10:37 UTC
Description of problem:
NFS root with dracut-generated initramfs no longer works in Fedora. /sysroot cannot be mounted, as generated sysroot.mount unit is bad:

(in initrd recovery shell)
# systemctl status sysroot.mount
o sysroot.mount - /sysroot
     Loaded: loaded (/proc/cmdline: generated)
     Active: inactive (dead)
      Where: /sysroot
       What: nfs:192.168.137.2:/home/poligon/daresbalat-rootfs:vers=3,tcp,local_lock=none,soft
       Docs: man:fstab(5)
             man:systemd-fstab-generator(8)
(no logs)

Issuing "systemctl start sysroot.mount" hangs.

The "What" is formatted completely wrong and "mount" cannot parse it:
- "nfs:" prefix is superfluous
- mount options are appended to remote path

My full ipxe kernel command line is:

kernel https://pipebreaker.pl/vmlinuz initrd=initramfs ip=dhcp root=nfs:192.168.137.2:/home/poligon/daresbalat-rootfs:vers=3,tcp,local_lock=none,soft selinux=0 rw systemd.log_target=console systemd.debug_shell log_buf_len=1M rd.retry=15



Version-Release number of selected component (if applicable):
systemd-250-3.fc36.x86_64
dracut-055-8.fc36.x86_64
but probably appeared long ago. My last working initramfs is initramfs-5.12.0-198.fc35.x86_64.img, built around April 2021.


How reproducible:
Always

Steps to Reproduce:
1. Have root-nfs setup
2. Try to boot over the network
3.

Actual results:
After the timeout waiting for nfs root hook, dracut drops to the shell.

Expected results:
Boot should continue.

Additional info:
1) fstab-generator has some code for handling nfsroot:
https://github.com/systemd/systemd/blob/v250/src/fstab-generator/fstab-generator.c#L711

but it checks for "/dev/nfs" which is deprecated in dracut:

 root=/dev/nfs nfsroot=[<server-ip>:]<root-dir>[:<nfs-options>]
           Deprecated!  kernel Documentation_/filesystems/nfsroot.txt_
           defines this method. This is supported by dracut, but not
           recommended.
https://man7.org/linux/man-pages/man7/dracut.cmdline.7.html

I've tried with this deprecated setting, but it did not help.


2) my dracut configuration:

 dracut.conf.d# bat *
───────┬─────────────────────────────────────────────────────────────────────────────────────────────
       │ File: networkd-config.conf
───────┼─────────────────────────────────────────────────────────────────────────────────────────────
   1   │  # manually install files needed for systemd-networkd
   2   │ install_items+=" /etc/systemd/network/* "
   3   │ 
   4   │ add_dracutmodules+=" systemd-networkd systemd-resolved systemd-sysusers "
───────┴─────────────────────────────────────────────────────────────────────────────────────────────
───────┬─────────────────────────────────────────────────────────────────────────────────────────────
       │ File: no_hostonly.conf
───────┼─────────────────────────────────────────────────────────────────────────────────────────────
   1   │ hostonly="no"
───────┴─────────────────────────────────────────────────────────────────────────────────────────────
───────┬─────────────────────────────────────────────────────────────────────────────────────────────
       │ File: trim-modules.conf
───────┼─────────────────────────────────────────────────────────────────────────────────────────────
   1   │ 
   2   │ # lvm is needed by Ceph OSD on LVM
   3   │ # rootfs-block is required by lvm
   4   │ # dm is required by lvm
   5   │ omit_dracutmodules+=" rdma crypt mdraid multipath qemu qemu-net iscsi lunmask nbd resume "
───────┴─────────────────────────────────────────────────────────────────────────────────────────────



3) I need to use IP address for server, because since dracut switched to systemd-networkd, DNS resolution in initramfs no longer works (systemd-resolved is required, but it cannot start in initramfs due to missing USER); but that's another bug.

Comment 1 Yu Watanabe 2022-01-05 10:27:27 UTC
Fix is waiting in https://github.com/systemd/systemd/pull/22013. But I have not tested it yet. Could you test the PR?

Comment 2 Tomasz Torcz 2022-01-06 18:43:11 UTC
Hey, I've tested the PR. It is half-success:
- incorrect sysroot.mount is no longer generated
but
- nothing else generates sysroot.mount, so boot fails.

I guess dracut for some reason fails its duty of generating the unit.
I'll check dracut modules to see what could be wrong.

Comment 3 Tomasz Torcz 2022-01-08 15:39:44 UTC
PR was merged upstream; rest of my problems are already reported in #1989119

Comment 4 Zbigniew Jędrzejewski-Szmek 2022-01-10 21:43:19 UTC
With the new systemd, fstab-generator now ignores root-on-nfs/cifs/iscsi and live.
Let's track the remaining issues in #1989119.

Comment 5 Fedora Update System 2022-01-11 21:43:00 UTC
FEDORA-2022-f38f479b8f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

Comment 6 Fedora Update System 2022-01-12 01:49:38 UTC
FEDORA-2022-f38f479b8f has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-f38f479b8f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Fedora Update System 2022-01-12 22:17:48 UTC
FEDORA-2022-f38f479b8f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

Comment 8 Fedora Update System 2022-01-13 01:10:48 UTC
FEDORA-2022-f38f479b8f has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-f38f479b8f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2022-01-15 01:21:25 UTC
FEDORA-2022-f38f479b8f has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.