2

I am attempting to set up a diskless node/workstation/system, using the instructions provided in the guide Diskless system for archlinux (4.13.12-1-ARCH).

the problem

The client successfully connects to TFTP (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

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 and environment variables 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.

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

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.

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.

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

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]?

asked Dec 3, 2017 at 2:26
1

1 Answer 1

1

According to the instructions in the Arch Linux wiki for diskless systems

For the client installation

create a full Arch Linux installation in a subdirectory on the server.

then

Edit $root/etc/mkinitcpio.conf and add nfsv4 to MODULES, net_nfs4 to HOOKS, and /usr/bin/mount.nfs4 to BINARIES

As I understood it, simply add net_nfs4 to the default hooks in mkinitcpio.conf. Searching for an answer, I cannot recall anything about necessary hooks, rather, I ended up instead adding the net hook in the confusion of reading other guides that were presumingly intended for nfs3.

Finally I came across We deal with loading of ArchLinux on network Roshalsky 22 марта 2015 в 16:14.

The article has a section named We prepare initramfs that is in the beginning familiar to the Arch Linux wiki,

# sed s/nfsmount/mount.nfs4/ "$root/usr/lib/initcpio/hooks/net" > "$root/etc/initcpio/hooks/net_nfs4"
# cp $root/usr/lib/initcpio/install/net $root/etc/initcpio/install/net_nfs4

but it differs on some crucial points.

Firstly, edit the net_nfs4 file, which in Arch Linux is 

nano $root/usr/lib/initcpio/install/net_nfs4
build() {
 add_checked_modules '/drivers/net/'
 add_module nfsv4?
 add_binary "/usr/lib/initcpio/ipconfig" "/bin/ipconfig"
 # Not sure if it is an Arch Linux specific, but nfsmount is correct;
 # mount.nsf4 causes mkinitcpio during build to throw an error like "file not found".
 # add_binary "/usr/bin/mount.nfs4" "/bin/mount.nfs4"
 add_binary "/usr/bin/nfsmount" "/bin/mount.nfs4"
 add_runscript
}

Secondly,

We add the processor to initramfs by correction of line in the mkinitcpio.conf file:

nano $root/etc/mkinitcpio.conf
HOOKS="base udev net_nfs4"

UPDATE +(20171210)

Trying to solve another problem I noticed in the /usr/lib/initcpio/hooks/net_nfs4 defined function nfs_mount_handler the following line:

mount.nfs4 ${nfs_option:+-o ${nfs_option}} "${nfs_server}:${nfs_path}" "1ドル"

According to the man mount.nfs4:

SYNOPSIS
 mount.nfs remotetarget dir [-rvVwfnsh ] [-o options]
DESCRIPTION
 ...
 remotetarget is a server share usually in the form of servername:/path/to/share. dir is the directory on which the file system is to be mounted.
 ...

therefore, I have changed that line to:

mount.nfs4 "${nfs_server}:${nfs_path}" "1ドル" ${nfs_option:+-o ${nfs_option}}
answered Dec 3, 2017 at 10:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.