I'm lost. Are you using systemd-boot or not? If not, how anything in arch.conf could affect the boot process? If you are using systemd-boot, why on Earth you're editing EFI variables with efibootmgr? Choose only one way to boot your system and stick to it.
I have no idea either. Because it has been years since the installation of archlinux on my laptop.
Thank you for yor help.
]]>Are you using systemd-boot or not?
The OP is using pure EFI_STUB booting. All else is a mystery because they won't share the exact efibootmgr command used to create the NVRAM entry or tell us what exactly happens during the failed boot with the new entry. FWIW the last posted efibootmgr output appears to show a working entry at number 0004.
]]>BTW.
Recently, kernel upgrade had crashed the boot process once. So I changed those initrd path backslashes in loader config to slashes, then it fixed.
That's because EFISTUB needs backslashes in paths according to EFI standards. But may be before using EFISTUB it would be a good idea to read about it. https://wiki.archlinux.org/index.php/EFISTUB
]]>Novite wrote:efibootmgr -v gives out:
Boot0001* Arch Linux HD(1,GPT,640033e2-123e-44db-a6f9-fc07d1b6f668,0x800,0x100000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.B.Z. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
https://bbs.archlinux.org/viewtopic.php?id=57855
Novite wrote:I created new boot entry
https://bbs.archlinux.org/viewtopic.php?id=57855
EDIT: just to clarify, you're using direct EFI_STUB booting so configuration files are not relevant here. The posted NVRAM entry is incorrect but also appears cropped so I can't really comment further at this stage.
This is the whole output:
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0004,0001,0002,0003
Boot0000* arch iso PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(2,0)/HD(1,MBR,0x46ba7513,0xa4,0x20000)/File(\EFI\Shell_x64.efi)
Boot0001* Arch Linux HD(1, GPT,640033e2-123e-44db-a6f9-fc07d1b6f668,0x800,0x100000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.B.Z. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
Boot0002* UEFI: TEAML5Lite3D240G PciRoot(0x0)/Pci(0x1f,0x2)/Sata(2,32768,0)/HD(1,GPT,640033e2-123e-44db-a6f9-fc07d1b6f668,0x800,0x100000)AMBO
Boot0003* UEFI: SanDisk PciRoot(0x0)/Pci(0x1d,0x0)/USB(3,0)/HD(1,MBR,0x6ecd5127,0x800,0x1ca3800)/HD(1,MBR,0x46ba7513,0xa4,0x20000)AMBO
Boot0004* Arch Linux HD(1,GPT,640033e2-123e-44db-a6f9-fc07d1b6f668,0x800,0x100000)/File(\vmlinuz-linux)r.o.o.t.=.P.A.R.T.U.U.I.D.=.a.f.3.3.e.a.b.f.-.b.f.3.9.-.4.a.8.6.-.8.e.2.a.-.6.8.a.8.1.1.8.9.a.6.3.7. .r.e.s.u.m.e.=.P.A.R.T.U.U.I.D.=.1.b.b.f.5.b.a.9.-.f.e.c.e.-.4.6.c.d.-.8.e.b.e.-.6.d.8.7.a.0.a.0.8.b.7.4. .r.w. .i.n.i.t.r.d.=.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
Boot0008* arch iso PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(3.0)/HD(1,MBR,0x46ba7513,0xa4,0x20000)/File(\EFI\Shell_x64.efi)
Boot0009* arch iso PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(2.0)/HD(1,MBR,0x46ba7513,0xa4,0x20000)/File(\intel-ucode.img)
Boot000A* Ubuntu Server PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(2.0)/HD(1,MBR,0x36b64baf,0x523c,0x1f00)/File(\EFI\BOOT\GRUBX64.efi)
Boot000B* Ubuntu Server PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(2.0)/HD(1,MBR,0x36b64baf,0x523c,0x1f00)/File(\EFI\BOOT\BOOTX64.efi)
Boot000C* Ubuntu PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(2.0)/HD(1,MBR,0x36b64baf,0x523c,0x1f00)/File(\EFI\BOOT\BOOTX64.efi)
The “Boot0004*” should be the new entry created following wiki.
BTW.
Recently, kernel upgrade had crashed the boot process once. So I changed those initrd path backslashes in loader config to slashes, then it fixed.
efiboormgr -v gives out:
Boot0001* Arch Linux HD(1,GPT,640033e2-123e-44db-a6f9-fc07d1b6f668,0x800,0x100000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.B.Z. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
https://bbs.archlinux.org/viewtopic.php?id=57855
I created new boot entry
https://bbs.archlinux.org/viewtopic.php?id=57855
EDIT: just to clarify, you're using direct EFI_STUB booting so configuration files are not relevant here. The posted NVRAM entry is incorrect but also appears cropped so I can't really comment further at this stage.
]]>Novite wrote:I tried to rebuild initramfs with
mkinitcpio -P
It reports
ERROR: ‘/lib/modules/4.14.15-1-ARCH’ is not a valid kernel directory
The kernel version can be specified so that the correct modules are used but the kernel image is copied over by the mkinitcpio package[0] so it shouldn't be possible to have a miss-matched kernel & initramfs.
I've just noticed this from your OP:
Novite wrote:options initrd=\EFI
Is that a typo? Does removing that nonsense option get your system booting again? Note that the initrd options don't have to be specified again in the kernel command line if you're using systemd-boot.
And in the OP you claim to be using "UEFI to boot system directly" but loader.conf is for system-boot rather than direct EFI_STUB booting (which does not use a configuration file) — which method are you using?
This will show us for sure:
efibootmgr -v
Without the option
initrd=\EFI
It has no change.
efiboormgr -v gives out:
Boot0001* Arch Linux HD(1,GPT,640033e2-123e-44db-a6f9-fc07d1b6f668,0x800,0x100000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.B.Z. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
I created new boot entry following the guide https://wiki.archlinux.org/index.php/EFISTUB#efibootmgr
The problem remains.
I tried to rebuild initramfs with
mkinitcpio -P
It reports
ERROR: ‘/lib/modules/4.14.15-1-ARCH’ is not a valid kernel directory
The kernel version can be specified so that the correct modules are used but the kernel image is copied over by the mkinitcpio package[0] so it shouldn't be possible to have a miss-matched kernel & initramfs.
I've just noticed this from your OP:
options initrd=\EFI
Is that a typo? Does removing that nonsense option get your system booting again? Note that the initrd options don't have to be specified again in the kernel command line if you're using systemd-boot.
And in the OP you claim to be using "UEFI to boot system directly" but loader.conf is for system-boot rather than direct EFI_STUB booting (which does not use a configuration file) — which method are you using?
This will show us for sure:
efibootmgr -v
OK. First.
In /etc/fstab UUID of your root partition is 4273cf35-a5b7-a41d-4aa6a09cd530
But blkid shows UUID=4273cf35-a5b7-495f-a41d-4aa6a09cd530
Fix that line in /etc/fstabSecond. Your arch.conf should look like this.
title Arch Linux linux /vmlinuz-linux initrd /intel-ucode.img initrd /initramfs-linux.img options root=UUID=4273cf35-a5b7-495f-a41d-4aa6a09cd530 resume=UUID=f4ceb5b4-0156-4bf0-ba0a-36a90bbed5b4 enable_guc
Slashes like this \ - marks the escape on linux, don't use them in paths. They are used in paths only on Windows, because on Windows everything is backwards.
Sorry. I typed it on cellphone. The unmatched part of UUID is a typo.
]]>Slashes like this \ - marks the escape on linux, don't use them in paths. They are used in paths only on Windows, because on Windows everything is backwards.
You're wrong about this. It will take either, but the 5.7 kernel had a bug in it until 5.7.6 which made backslashes *required*.
]]>Second. Your arch.conf should look like this.
title Arch Linux
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options root=UUID=4273cf35-a5b7-495f-a41d-4aa6a09cd530 resume=UUID=f4ceb5b4-0156-4bf0-ba0a-36a90bbed5b4 enable_guc
Slashes like this \ - marks the escape on linux, don't use them in paths. They are used in paths only on Windows, because on Windows everything is backwards.
]]>Check the kernel version on the EFI system partition:
# mount /dev/sda1 /mnt file /mnt/vmlinuz-linux
Does that match the version listed in /usr/lib/modules/?
If not then your /boot partition wasn't mounted correctly during a kernel upgrade so you need to (arch-)chroot into your system, make sure that the ESP is mounted correctly and reinstall the linux package. Then find out why it wasn't mounted correctly so this doesn't happen again.
The two do match, both are:
5.7.6-arch1-1
EDITED
I tried to rebuild initramfs with
mkinitcpio -P
It reports
ERROR: ‘/lib/modules/4.14.15-1-ARCH’ is not a valid kernel directory