archlinux efi netboot kernel "ip" does not work?; systemd "Failed to start Switch Root."

I am attempting to set up a diskless [node/workstation](https://en.wikipedia.org/wiki/Diskless_node)/[system](https://wiki.archlinux.org/index.php/Diskless_system) , using the instructions provided in the guide [Diskless system](https://wiki.archlinux.org/index.php/Diskless_system) for [archlinux](https://www.archlinux.org) (4.13.12-1-ARCH). #the problem The client successfully connects to TFTP ([atftp](http://github.com/seveas/atftp)) , transfers all files and presents the GRUB selection menu (relevant excerpt from grub.cfg): load_video set gfxpayload=keep insmod gzip insmod ext3 insmod net insmod tftp insmod efinet set root=(tftp,192.168.0.101) set prefix=(tftp,192.168.0.101)/netboot/grub linux /netboot/vmlinuz-linux add_efi_memmap root=/dev/nfs rootfstype=nfs nfsroot=192.168.0.101:/srv/[CLIENT OS] nfsrootdebug rw ip=dhcp initrd /netboot/initramfs-linux.img I have tried various assignments of ip (https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt) ip=:::::efinet0:dhcp ip=:::::eno1s0:dhcp ip=:::::eth0:dhcp ip=[CLIENT IP]:[SERVER IP]:[GATEWAY IP]:[NETMASK]:[HOSTNAME]:[DEVICE]:dhcp While both linux and initrd are loaded, continuing results in [FAILED] "Failed to start Switch Root." See 'systemctl status initrd-switch-root.service' for details. You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reobot, "systemctl default or ^D to enter into default mode. Press Enter for maintenance (or press Control-D to continue): # troubleshooting ## removing add_efi_mmap Instead of Failed to start Switch Root., the kernel panics: [ 1.114386] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255) [ 1.114458] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.13.12-1-ARCH #1 [ 1.114509] Hardware name: ASUSTeK COMPUTER INC. UX51V2A/UX51VZA, BIOS UX51VZA.204 12/03/2012 [ 1.114573] Call Trace: [ 1.114604] dump_stack+0x63/0x8b [ 1.114637] panic+0xe4/0x23d [ 1.114667] mount_block_root+0x1f4/0x2ab [ 1.114703] ? set_debug_rodata+0x17/0x17 [ 1.114737] mount_root+0x6a/0x6d [ 1.114767] prepare_namespace+0x134/0x16c [ 1.114802] kernel_init_freeable+0x1ec/0x205 [ 1.114840] ? rest_init+0xe0/0xe0 [ 1.114872] kernel_init+0xc/0xfc [ 1.114904] ret_from_fork+0x25/0x30 [ 1.114957] Kernel Offset: 0x3000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 1.115040] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255) ## [systemd debugging](https://freedesktop.org/wiki/Software/systemd/Debugging/) I cannot access the journalctl. Either the keyboard is not detected or the system freezes because I can neither press Enter nor ^D to continue. Attempting to directly boot into emergency mode by adding systemd.unit=emergency.target or emergency to the kernel CLI does not seem to work. +(UPDATE 2) The mkinitcpio argument break=premount does not change the systemd startup. ## network Using Wireshark, there is no network activity after the initial PXE boot, that is, when linux and initrd are loaded, there is no more communication between the client and server. SERVER IP: 192.168.2.101/24 CLIENT IP: 192.168.2.102/24 ### GRUB The GRUB net_* [commands](https://www.gnu.org/software/grub/manual/grub/html_node/Networking-commands.html#Networking-commands) and [environment variables](https://www.gnu.org/software/grub/manual/grub/html_node/Network.html) seem to indicate that everything is in order; tftp works. net_ls_cards efinet0 [CLIENT NETWORK DEVICE MAC] net_ls_addr efinet0 [CLIENT NETWORK DEVICE MAC] 192.168.2.102 net_ls_routes efinet0:local 192.168.2.0/24 efinet0 efinet0:default 0.0.0.0/0 gw 192.168.2.101 echo $net_default_ip 192.168.2.102 echo $net_default_mac [CLIENT NETWORK DEVICE MAC] echo $net_default_server 192.168.2.101 echo $net_efinet0_ip 192.168.2.102 echo $net_efinet0_mac [CLIENT NETWORK DEVICE MAC] echo $net_efinet0_hostname (empty) echo $net_efinet0_domain (empty) echo $net_efinet0_dhcp_server_name (empty echo $net_efinet0_next_server 192.168.0.101 echo $net_efinet0_root_path 102.168.0.101:/srv/[CLIENT OS] echo $net_efinet0_extensionpath (empty) ### Kernel support for nfsroot and ip Given that there is no network activity, I presume that the ip or nfsroot are not being executed. In fact, the problem I am having is described in the question [Built the kernel with NFS support but not getting /dev/nfs](https://unix.stackexchange.com/questions/140176/built-the-kernel-with-nfs-support-but-not-getting-dev-nfs) . The answer to that question states (Andreas Wiese Jul 1 '14 at 14:58) > ... make sure to have NFS support built into your kernel binary and not as a module (or have an initramfs, which takes care of this). Same goes for network drivers: you'll most probably want to have the driver for you ethernet NIC built into your kernel image, otherwise you'll have to load it from an initramfs.

In short, there are several possibilities:

1. Do as above link tells you: have root=/dev/nfs set, give the correct nfsroot parameter and tell your kernel your network configuration via the ip parameter (this would be the best way to make sure it's working at all, i.e. to rule out a misconfigured DHCP server).

2. Have CONFIG_IP_PNP and CONFIG_IP_PNP_DHCP enabled and set up a DHCP daemon to tell your client which IP address to use and where to find its NFS-root.

3. Build an initramfs which does the correct configuration and NFS-mounting. Investigating the archlinux kernel zgrep CONFIG_NFS_FS= /proc/config.gz -> CONFIG_NFS_FS=m zgrep DHCP /proc/config.gz -> (nothing) zgrep _IP_PNP_ /proc/config.gz -> CONFIG_IP_PNP is not set indicates that archlinux does not have support for the ip compiled with the kernel. In comment from a bug report (2006) [FS#5056 - Default kernel has NFS root mouting disabled](https://bugs.archlinux.org/task/5056?opened=243&status%5B0%5D=) > mkinitcpio supports netbooting already without changing the kernel Which can be compared to the comment to the accepted answer in the referred question. > Since around 10 years the kernel doesn't boot nfs directly, but it mounts an initial ramdisk, which re-interprets the kernel command line and boots from where you want. – peterh Jun 17 '16 at 13:54 ### mkinitcpio From the lsinitcpio -a ... Created with mkinitcpio 24 Kernel: 4.13.12-1-ARCH Size: 55,63 MiB Compressed with: gzip ... Included modules: ... nfs ... nfsv3 nfsv4 [explicit] ... Included binaries: ... ipconfig ... mount.nsf4 ... nfsmount ... Early hook run order: udev Hook run order: udev net net_nsf4 nbd Cleanup hook order: udev ### mkinitcpio support for network device (update #1) Although the drivers for the network card should be loaded, I wanted to make sure after reading [[SOLVED] Diskless - ipconfig: no devices to configure](https://bbs.archlinux.org/viewtopic.php?id=169335) . > put network module drive in /etc/mkinitcpio.conf. MODULES=(atl1c nbd nfsv4) Neither explicitly declaring the module nor building the entire initramfs.img on the client made no change. > Don't use autodetect if the image should run on different machines. autodetect removes all drivers which are not necessary for booting on the currently running system. Removing autodetect from hooks resulted in an interesting outcome; the earlier observed kernel panic when removing add_efi_mmap occurred. Removing add_efi_mmap when loading the no-autodetect initramfs had no further effect. ### mkinitcpio support for nfs Archlinux may or may not have support for nsf4. * [mkinitcpio Runtime customization Using net](https://wiki.archlinux.org/index.php/mkinitcpio#Using_net) * [FS#28287 - [mkinitpio-nfs-utils] NFS4 Support](https://bugs.archlinux.org/task/28287) As far as I can tell, this is a secondary issue; the network must work before an attempt to mount nfs can be made. ### mkinitcpio support for ip I have just found out that * [mkinitcpio-nfs-utils (0.3-5)](https://www.archlinux.org/packages/core/x86_64/mkinitcpio-nfs-utils/) includes a "ipconfig", * there is a [mkinitcpio-netconf 0.0.4-2](https://aur.archlinux.org/packages/mkinitcpio-netconf/) . # additional information This may or may not be relevant. The reason for using "UEFI PXE boot" instead of "BIOS PXE boot" is because GRUB i386-pc fails to load the grub.cfg. The computer either restarts, freezes on "Welcome to GRUB!" and may clutter the screen with colorized pixels; the outcome seems random. The Wireshark logs reveal that tftp sometimes loads all grub modules, sometimes not. The last log entry is often the client asking for the server network device; ARP 60 Who has [SERVER IP]? Tell [CLIENT IP]?