我在 Macbook Pro 上安装了 Arch，但无法启动。我quiet从 grub.cfg 中删除了该标志以弄清楚发生了什么，但我找不到任何模式。以下是三只不成功的靴子的最后几行：
...
[ OK ] Reached target Sound Card.
[ OK ] Created slice system-systemd\x2drfkill.slice.
Starting Load/Save RF Kill Switch Status of rfkill0...
[ OK ] Reached target Bluetooth.
[ OK ] Found device Hitachi_HTS[...blah blah blah...] EFI.
Mounting /boot...
[ OK ] Started Load/Save Screen Backlight Brightness of leds:smc::kbd_backlight.
[ OK ] Found device Hitachi_HTS[...blah blah blah...] home.
Starting File System Check on /dev/disk/bu-uuid/44[...valid UUID of my /home partition...]
[ 7.420848] sd 6:0:0:0: [sdc] No caching mode page found
[ 7.42... ] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 7.42... ] sd 6:0:0:0: [sdc] No caching mode page found
[ 7.42... ] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 7.43... ] sd 6:0:0:0: [sdc] No caching mode page found
[ 7.43... ] sd 6:0:0:0: [sdc] Assuming drive cache: write through
^ 挂在这里。
[ OK ] Started udev Coldplug all Devices.
[ OK ] Started Remount Root and Kernel File Systems
Starting Load/Save Random Seed...
[ OK ] Started Create Static Device Nodes in /dev.
Starting udev Kernel Device Manager...
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Started udev Kernel Device Manager.
[ OK ] Started Load/Save Random Seed.
[ OK ] Reached target Sound Card.
^ 挂在这里。
[ OK ] Found device Hitachi_HTS[...blah blah blah...] EFI.
Mounting /boot...
[ OK ] Found device Hitachi_HTS[...blah blah blah...] home.
Starting File System Check on /dev/disk/bu-uuid/44[...valid UUID of my /home partition...]
[ OK ] Created slice system-systemd\x2backlight.slice.
Starting Load/Save Screen Backlight Brightness of leds:smc::kbd_backlight...
[ OK ] Started Load/Save Screen Backlight Brightness of leds:smc::kbd_backlight.
[ OK ] Created slice system-systemd\x2drfkill.slice.
Starting Load/Save RF Kill Switch Status of rfkill0...
[ OK ] Reached target Bluetooth.
[ OK ] Started Load/Save RF Kill Switch Status of rfkill0.
^ 挂在这里。
我在 MacbookPro8,2 上安装了 Arch，并带有 rEFInd 和 GRUB v2。
答案1
问题大概是systemd。它不是很健壮 - 它的依赖关系有时会锁定并阻止启动过程的继续，即使一切实际上都很好。它非常重视依赖关系——过于重视以至于不可靠。
我曾经有过以下经历：由于外部未挂载，本地文件系统（fstab）的依赖关系不满足，引导从未到达入口[email protected]。最糟糕的是 - 它甚至没有到达紧急控制台，因为它只是无限期地等待。
请注意，事情是异步发生的，因此它可能不会传递到声卡，而是传递到其他地方。当您设法登录时，journalctl -b以 root 身份检查（上次启动）并查找超时、失败和依赖性错误。
rfkill 和蓝牙的东西非常不稳定且不可预测。它永远不会以同样的方式发生。
如果您找出是谁的错，您可以复制该.service文件/etc/systemd/system/并对其进行修改以使其不那么严格。如果是这种情况，我们可以提供帮助。