主页 / unix / 问题 / 408477
Accepted
user212827
Asked: 2017-12-03 18:26:53 +0800 CST

archlinux efi netboot 内核“ip”不起作用？systemd "启动 Switch Root 失败。"

  • 772

我正在尝试使用指南Diskless system for archlinux (4.13.12-1-ARCH)中提供的说明设置无盘节点/工作站/系统。

问题

客户端成功连接到 TFTP ( atftp )，传输所有文件并显示 GRUB 选择菜单（相关摘录自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

我尝试了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

在同时加载linux和initrd时，继续导致

[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):

故障排除

删除 add_efi_mmap

而不是Failed to start Switch Root.，内核恐慌：

[    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)

系统调试

我无法访问 journalctl。未检测到键盘或系统冻结，因为我既不能按Enter也不能^D继续。

尝试通过向内核 CLI 添加systemd.unit=emergency.target或直接引导进入紧急模式emergency似乎不起作用。

+(UPDATE 2)mkinitcpio参数break=premount不会改变systemd启动。

网络

使用 Wireshark，在初始 PXE 引导后没有网络活动，也就是说，当linux和initrd加载时，客户端和服务器之间不再有通信。

SERVER IP: 192.168.2.101/24
CLIENT IP: 192.168.2.102/24

格鲁布

GRUB net_*命令和环境变量似乎表明一切正常；tftp 工作。

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)

内核支持nfsroot和ip

鉴于没有网络活动，我假设ipornfsroot没有被执行。

事实上，我遇到的问题在Build the kernel with NFS support but not getting /dev/nfs问题中有所描述。

该问题的答案指出（Andreas Wiese 2014 年 7 月 1 日 14:58）

...确保将 NFS 支持内置到您的内核二进制文件中，而不是作为一个模块（或有一个initramfs，它负责这个）。网络驱动程序也是如此：您很可能希望将以太网 NIC 的驱动程序内置到内核映像中，否则您必须从initramfs.

简而言之，有几种可能性：

1. 按照上面的链接告诉您：已root=/dev/nfs设置，提供正确的nfsroot参数并通过参数告诉您的内核您的网络配置ip（这将是确保它完全正常工作的最佳方法，即以排除配置错误的 DHCP 服务器）。

2.拥有CONFIG_IP_PNP和CONFIG_IP_PNP_DHCP启用并设置一个 DHCP 守护程序来告诉您的客户端使用哪个 IP 地址以及在哪里可以找到它的 NFS-root。

3. 构建一个 initramfs，它可以进行正确的配置和 NFS 挂载。

研究archlinux内核

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

表示archlinux不支持ip用内核编译。

在错误报告 (2006) FS#5056 的评论中 - 默认内核已禁用 NFS 根安装

mkinitcpio 已经支持 netbooting 而无需更改内核

可以将其与对所引用问题中已接受答案的评论进行比较。

大约 10 年以来，内核并没有直接引导 nfs，而是安装了一个初始 ramdisk，它重新解释了内核命令行并从您想要的位置引导。– 彼得 2016 年 6 月 17 日在 13:54

mkinitcpio

来自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 支持（更新 #1）

虽然应该加载网卡的驱动程序，但我想在阅读[SOLVED] Diskless - ipconfig: no devices to configure后确定。

将网络模块驱动器放在 /etc/mkinitcpio.conf 中。

MODULES=(atl1c nbd nfsv4)

无论是明确声明模块还是在客户端上构建整个模块都initramfs.img没有改变。

如果图像应该在不同的机器上运行，不要使用自动检测。自动检测会删除在当前运行的系统上启动不需要的所有驱动程序。

从钩子中移除autodetect会产生一个有趣的结果；之前观察到的删除add_efi_mmap时发生的内核恐慌。add_efi_mmap加载 no- 时删除autodetect initramfs没有进一步的影响。

mkinitcpio 支持nfs

Archlinux 可能支持也可能不支持 nsf4。

据我所知，这是次要问题；在尝试挂载 nfs 之前，网络必须工作。

mkinitcpio 支持ip

我刚刚发现

附加信息

这可能相关也可能不相关。

使用“UEFI PXE 引导”而不是“BIOS PXE 引导”的原因是因为 GRUB i386-pc 无法加载 grub.cfg。计算机要么重新启动，要么冻结在“欢迎使用 GRUB！”。并且可能会用彩色像素使屏幕混乱；结果似乎是随机的。Wireshark 日志显示tftp有时会加载所有 grub 模块，有时则不会。最后一个日志条目通常是客户端请求服务器网络设备；ARP 60 Who has [SERVER IP]? Tell [CLIENT IP]?

arch-linux linux-kernel

1 个回答

  1. Best Answer

    根据 Arch Linux wiki 中关于无盘系统的说明

    对于客户端安装

    在服务器的子目录中创建完整的 Arch Linux 安装。

    然后

    编辑 $root/etc/mkinitcpio.conf 并将 nfsv4 添加到 MODULES，将 net_nfs4 添加到 HOOKS，并将 /usr/bin/mount.nfs4 添加到 BINARIES

    据我了解，只需添加net_nfs4到mkinitcpio.conf. 在寻找答案时，我想不起任何关于必要的钩子的事情，相反，我最终net在阅读其他可能用于 nfs3 的指南的混乱中添加了钩子。

    最后我遇到了我们处理在网络 Roshalsky 22 марта 2015 в 16:14上加载 ArchLinux 。

    这篇文章有一个名为We prepare initramfs的部分，一开始是 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

    但它在一些关键点上有所不同。

    首先，编辑 net_nfs4 文件，在 Arch Linux 中是

    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
}

    第二，

    我们通过更正 mkinitcpio.conf 文件中的行将处理器添加到 initramfs：

    nano $root/etc/mkinitcpio.conf

HOOKS="base udev net_nfs4"

    更新 +(20171210)

    试图解决另一个问题，我在/usr/lib/initcpio/hooks/net_nfs4定义的函数nfs_mount_handler中注意到以下行：

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

    根据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.
   ...

    因此，我已将该行更改为：

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

相关问题