You are not logged in.
My first post, so bear with me. I am trying to dual-boot Arch Linux onto my Intel Macbook Pro 2017. I made a partition for the Arch Linux installation while still running macos. I have followed the Installation guide and Mac specific steps as best I could.
From the USB boot session, running `fdisk -l` shows that on my /dev/nvme0n1 disk I have three partitions: nvme0n1p1 (EFI System), nvme0n1p2 (Apple APFS), nvme0n1p3 (Microsoft basic data). The first was formatted as exFAT from macos beforehand, the latter was formatted to ext4 during the installation process.
I mounted /dev/nvme0n1p3 to /mnt and I mounted /dev/nvme0n1p1 to /mnt/boot.
Then I ran the `pacstrap` and `genfstab` command as indicated in the guide.
My `/mnt/etc/fstab` shows:
# /dev/nvme0n1p3
UUID=e60a99a0-97cf-4bb5-9804-022019432b3a / ext4 rw,relatime 0 1
# /dev/nvme0n1p1 LABEL-EFI
UUID=5F66-17ED /boot vfat rw,relatime, fmask=0022,dmask=0022, codepage=437, locharset-ascii,shortname=mixed,utf8,errors-remount-ro 0 2I then entered the live session with `arch-chroot -S /mnt`. The `-S` because I couldn’t change the EFI variables, so `bootctl install` would fail iirc.
For the boot loader, I used systemd-boot, and ran `bootctl install`. I can verify that the relevant .efi file exists in the right location `/boot/EFI/systemd/systemd-bootx64.efi`.
I used `kernel-install add-all` to configure things for systemd-boot, where the ‘install.conf’ included only `layout=bls`, otherwise only defaults.
When rebooting, pressing down Alt, I could see the EFI boot loader I had created, and when chosen an Arch Linux boot process seemed to start until I quickly ran into the following:
[ *** ] A start job is running for /dev/gpt-auto-root (4s / 1min 38s)
[OK] Stopped Virtual Console Setup.
Stopping Virtual Console Setup...
Starting Virtual Console Setup...
[OK] Finished Virtual Console Setup.
[ TIME ] Timed out waiting for device /dev/gpt-auto-root.
[DEPEND]Dependency failed for File System Check on /dev/gpt-auto-root.
[DEPEND]Dependency failed for Root Partition.
[DEPEND]Dependency failed for Validate File System Mount Constraints of /sysroot.
[DEPEND]Dependency failed for Initrd Root File System.
[DEPEND]Dependency failed for Mount points Configured in the Real Root.
[DEPEND]Dependency failed for Initrd Root Device.
[OK] Stopped target Basic System.
[OK] Reached target Initrd File Systems.
[OK]Stopped target System Initialization.
[OK] Started Emergency Shell.
[OK] Reached target Emergency Mode.
You are in emergency mode. After logging in, type “journalctl -xb” to view
system logs. “Systemctl reboot” to reboot, or “exit”
to continue bootup.
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.I can’t figure out why the boot process cannot find the relevant root/filesystem to boot. I tried manually adding `root=UUID=<my_uuid>` to the /etc/kernel/cmdline configuration, which resulted in slightly different error but also hung on finding the root/filesystem there.
Last edited by Lambertarc (Today 14:30:20)
Offline
That is likely caused by the systemd-gpt-auto-generator that tries to detect your partitions very early in the boot process.
It does not use the settings in your /etc/fstab .
Try adding systemd.gpt_auto=0 as kernel boot parameter to disable the generator .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Hey Lone_Wolf, thanks for the swift and clear reply.
After adding said parameter to /etc/kernel/cmdline, running ‘kernel-install add-all’, and then rebooting, I ran into a new issue:
[FAILED] Failed to start Switch Root.
See 'systemctl status initrd-switch-root.service' for details.
You are in emergency mode. After logging in, type mode.
"journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit" to continue bootup.
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.I came across this thread that encountered the same issue, for which the solution was to re-add what I had previously tried namely the ‘root=UUID=<uuid_of_partition>’. For completeness sake, I also added ‘initrd=initramfs-linux.img’. In any case, this configuration worked.
For completeness sake, my /etc/kernel/cmdline file:
reboot=pci
systemd.gpt_auto=0
root=UUID=<fill_in_your_uuid>
initrd=\initramfs-linux.imgThanks again.
Offline
p3 formatted as exFAT
i doubt linux works on any non posix FS like fat
if it really is exFAT start over by format as ext4/btrfs/xfs
Offline
Oh thanks for catching that cryptearth! In fact it is a mistake on my part in writing up the message.
Nvme0n1p1 was exFAT, whereas nvme0n1p3 was formatted to ext4.
Offline
exFAT for ESP won't work either as uefi spec demands FAT32
Offline