The client successfully connects to TFTP (atftp), transfers all files and presents the GRUB selection menu (relevant excerpt from
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=:::::efinet0:dhcp ip=:::::eno1s0:dhcp ip=:::::eth0:dhcp ip=[CLIENT IP]:[SERVER IP]:[GATEWAY IP]:[NETMASK]:[HOSTNAME]:[DEVICE]:dhcp
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):
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)
I cannot access the journalctl. Either the keyboard is not detected or the system freezes because I can neither press
^D to continue.
Attempting to directly boot into emergency mode by adding
emergency to the kernel CLI does not seem to work.
+(UPDATE 2) The
break=premount does not change the
Using Wireshark, there is no network activity after the initial PXE boot, that is, when
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
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 188.8.131.52:/srv/[CLIENT OS] echo $net_efinet0_extensionpath (empty)
Kernel support for
Given that there is no network activity, I presume that the
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.
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
In short, there are several possibilities:
1. Do as above link tells you: have
root=/dev/nfsset, give the correct
nfsrootparameter and tell your kernel your network configuration via the
ipparameter (this would be the best way to make sure it's working at all, i.e. to rule out a misconfigured DHCP server).
CONFIG_IP_PNP_DHCPenabled 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
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
... 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.
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.
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-
initramfs had no further effect.
mkinitcpio support for
Archlinux may or may not have support for nsf4.
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
I have just found out that
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]?