You are not logged in.
Afer yesterday's kernel upgrade, my computer cannot boot into archlinux anymore.
It prints out:
:: running hook [resume]
ERROR: resume: no device specified for hiberation
ERROR: device ' ' not found. Skipping fsck.
:: mounting ' ' on real root
mount: /new_root: no filesystem type specified.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
I use UEFI to boot system directly. This is my config in loader entries:
title Arch Linux
linux /vmlinuz-linux
initrd \intel-ucode.img
initrd \initramfs-linux.img
options initrd=\EFI root=/dev/sda3 resume=/dev/sda2 initrd=\intel-ucode.img initrd=\initramfs-linux.img i915.modeset=1 i915.enable_guc_loading=1 i915.enable_guc_submission=1
Shall I change the "root=" and "resume=" to uuid?
Thank you.
Last edited by Novite (2020-06-29 10:19:37)
Offline
You should've done it during installation. Now you see from your own unique lived experience™ why using 'dev/*whatever' paths in configuration files is a bad idea. https://wiki.archlinux.org/index.php/Pe … ice_naming
EDIT. Don't forget to change paths in /etc/fstab as well.
Last edited by finoderi (2020-06-28 09:13:40)
Offline
You should've done it during installation. Now you see from your own unique lived experience™ why using 'dev/*whatever' paths in configuration files is a bad idea. https://wiki.archlinux.org/index.php/Pe … ice_naming
EDIT. Don't forget to change paths in /etc/fstab as well.
I’ve tried it, but the problem remains.
Offline
Please show your /etc/fstab and output of
# fdisk -l
and
# blkid
Offline
/etc/fstab
# /dev/sda3
UUID=4273cf35-a5b7-a41d-4aa6a09cd530 / ext4 rw,relatime,data=ordered,discard 0 1
# /dev/sda1
UUID=4EEC-BC55 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2
# /dev/sda2
UUID=f4ceb5b4-0156-4bf0-ba0a-36a90bbed5b4 none swap defaults,pri=-2 0 0
frisk -l result:
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 17825791 16775168 8G Linux swap
/dev/sda3 17825792 468860927 451035136 215.1G Linux filesystem
blkid result:
/dev/sda1: UUID=“4EEC-BC55” BLOCK_SIZE=“512” TYPE=“vfat”. PARTUUID=“640033e2-123e-44db-a6f9-fc07d1b6f668”
/dev/sda2: UUID=“f4ceb5b4-0156-4bf0-ba0a-36a90bbed5b4” TYPE=“swap” PARTUUID=“1bbf5ba9-fede-46cd-8ebe-6d87a0a08b74”
/dev/sda3: UUID=“4273cf35-a5b7-495f-a41d-4aa6a09cd530” BLOCK_SIZE=“4096” TYPE=“ext4” PARTUUID=“af33eafb-bf39-4a86-8e2a-68a81189a637”
/dev/loop0: TYPE=“squashes”
Thank you very much.
Last edited by Novite (2020-06-28 13:15:27)
Offline
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.
Last edited by Head_on_a_Stick (2020-06-28 13:23:25)
Offline
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
Last edited by Novite (2020-06-28 13:45:36)
Offline
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/fstab
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.
Offline
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*.
Online
Wow, didn't know that. It's very strange.
Offline
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.
Offline
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
Offline
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.
Last edited by Novite (2020-06-28 15:54:42)
Offline
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.
Last edited by Head_on_a_Stick (2020-06-28 16:03:07)
Offline
/dev/sdBZ? There's no way that ever worked.
Online
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.
Offline
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
Offline
I create new boot entry with PARTUUID, and change entries in /etc/fstab to PARTUUID. This fixes the problem. I haven’t tried both UUID.
Offline
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.
Offline
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.
Offline
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.
Offline