You are not logged in.
Pages: 1
Hello forum,
these days I moved my installation to a new machine.
On the way to get the system back as before, I stumble to some problem. Trying to get the way it was, I prepare the same set up, but the boot loader behaves strangely.
$ bootctl status
System:
Firmware: UEFI 2.70 (Acer Inc. 5.12)
Secure Boot: disabled
Setup Mode: user
Current Boot Loader:
Product: systemd-boot 245.6-8-arch
Features: ✓ Boot counting
✓ Menu timeout control
✓ One-shot menu timeout control
✓ Default entry control
✓ One-shot entry control
✓ Support for XBOOTLDR partition
✓ Support for passing random seed to OS
✓ Boot loader sets ESP partition information
ESP: /dev/disk/by-partuuid/6177b945-cc2d-4a95-9593-4d009cf6edda
File: └─/EFI/systemd/systemd-bootx64.efi
Random Seed:
Passed to OS: yes
System Token: set
Exists: yes
Available Boot Loaders on ESP:
ESP: /boot (/dev/disk/by-partuuid/6177b945-cc2d-4a95-9593-4d009cf6edda)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 245.6-8-arch)
File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 245.6-8-arch)
Boot Loaders Listed in EFI Variables:
Title: Linux Boot Manager
ID: 0x0000
Status: active, boot-order
Partition: /dev/disk/by-partuuid/6177b945-cc2d-4a95-9593-4d009cf6edda
File: └─/EFI/systemd/systemd-bootx64.efi
Title: Windows Boot Manager
ID: 0x0001
Status: inactive, boot-order
Partition: /dev/disk/by-partuuid/6177b945-cc2d-4a95-9593-4d009cf6edda
File: └─/EFI/Microsoft/Boot/bootmgfw.efi
Boot Loader Entries:
$BOOT: /boot (/dev/disk/by-partuuid/6177b945-cc2d-4a95-9593-4d009cf6edda)
Default Boot Loader Entry:
title: UEFI Shell x86_64 v2
id: ShellV2.conf
source: /boot/loader/entries/ShellV2.conf
$ sudo blkid
/dev/nvme0n1p1: LABEL_FATBOOT="BOOT" LABEL="BOOT" UUID="F312-1401" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="6177b945-cc2d-4a95-9593-4d009cf6edda"
/dev/nvme0n1p2: LABEL="Linux" UUID="386aa18f-b93a-43f8-b71f-6ab05ebe7ac8" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Root" PARTUUID="e370476e-1a6b-438d-a204-36d5bb7f703b"
/dev/nvme0n1p3: LABEL="HomeNew" UUID="97b773c6-5a56-4483-9c1e-ce1fa437786e" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="hm" PARTUUID="0e423ef9-51b6-4387-a001-96a641613116"
/dev/sda1: LABEL="Data" BLOCK_SIZE="512" UUID="8C16883716882474" TYPE="ntfs" PARTUUID="6d1c789d-01"
$ cat /boot/loader/
entries/ loader.conf random-seed
myself@AcerXC886-~> cat /boot/loader/loader.conf
timeout 1
default arch
$ tree /boot
/boot
├── boot.scr
├── EFI
│ ├── BOOT
│ │ └── BOOTX64.EFI
│ └── systemd
│ └── systemd-bootx64.efi
├── initramfs-linux.img
├── intel-ucode.img
├── loader
│ ├── entries
│ │ ├── arch.conf
│ │ ├── archOld.conf
│ │ └── ShellV2.conf
│ ├── loader.conf
│ └── random-seed
├── shellx64_v2.efi
├── syslinux
│ └── syslinux.cfg
└── vmlinuz-linux
As you may see, everything is expected to boot on the arch option, but then it falls on the EFI shell, bothering every time to care to switch the correct one.
EDIT
I made the mistake that the loader.conf must specify the entire file name, suffix included.
Last edited by TheSaint (2020-07-23 04:58:08)
do it good first, it will be faster than do it twice the saint
Offline
IIRC, there was a change, that now requires the user to set the default entry including the .conf extension:
default arch.conf
Okay, strike that. I just tested it and the behaviour is definitely weird:
$ cat /boot/loader/loader.conf
timeout 3
default digital-signage
$ bootctl list
Boot Loader Entries:
title: Digital Signage
id: digital-signage.conf
source: /boot/loader/entries/digital-signage.conf
linux: /vmlinuz-linux-lts
initrd: /amd-ucode.img
/intel-ucode.img
/initramfs-linux-lts.img
options: init=/usr/lib/systemd/systemd root=LABEL=root rw
title: Configuration Mode
id: hidsl-cfg.conf
source: /boot/loader/entries/hidsl-cfg.conf
linux: /vmlinuz-linux-lts
initrd: /amd-ucode.img
/intel-ucode.img
/initramfs-linux-lts.img
options: init=/usr/lib/systemd/systemd root=LABEL=root rw systemd.unit=hidslcfg.target
title: Maintenance (default)
id: maintenance.conf
source: /boot/loader/entries/maintenance.conf
linux: /vmlinuz-linux-lts
initrd: /amd-ucode.img
/intel-ucode.img
/initramfs-linux-lts.img
options: init=/usr/lib/systemd/systemd root=LABEL=root rw systemd.unit=multi-user.target
→ Boots into digital-signage per default, whereas
$ cat /boot/loader/loader.conf
timeout 3
default digital-signage.conf
$ bootctl list
Boot Loader Entries:
title: Digital Signage (default)
id: digital-signage.conf
source: /boot/loader/entries/digital-signage.conf
linux: /vmlinuz-linux-lts
initrd: /amd-ucode.img
/intel-ucode.img
/initramfs-linux-lts.img
options: init=/usr/lib/systemd/systemd root=LABEL=root rw
title: Configuration Mode
id: hidsl-cfg.conf
source: /boot/loader/entries/hidsl-cfg.conf
linux: /vmlinuz-linux-lts
initrd: /amd-ucode.img
/intel-ucode.img
/initramfs-linux-lts.img
options: init=/usr/lib/systemd/systemd root=LABEL=root rw systemd.unit=hidslcfg.target
title: Maintenance
id: maintenance.conf
source: /boot/loader/entries/maintenance.conf
linux: /vmlinuz-linux-lts
initrd: /amd-ucode.img
/intel-ucode.img
/initramfs-linux-lts.img
options: init=/usr/lib/systemd/systemd root=LABEL=root rw systemd.unit=multi-user.target
→ Boots into maintenance.
I am confused.
See also: https://bbs.archlinux.org/viewtopic.php?id=244611
Aaaand... It's a bug: https://github.com/systemd/systemd/issues/7727
See below.
Last edited by schard (2020-07-23 09:33:29)
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
Aaaand... It's a bug: https://github.com/systemd/systemd/issues/7727
Looks quiet old, strange they haven't fixed yet.
Should I rather opt to a EFIstub?
do it good first, it will be faster than do it twice the saint
Offline
I think that it might be a regression. That's why I necro bumped the thread. For the time being I just ignore the faulty output of bootctl.
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
As you may see, everything is expected to boot on the arch option
What do you mean? The status output shows the EFI shell as Default Boot Loader Entry.
@schard: any chance your installed (to ESP) bootloader is outdated? Did you run `bootctl update`?
Offline
@Raynman: Problem is, that bootctl status show EFI shell as default. Arch.conf should be default as requested in loader.conf
I remember, that I was solving this problem some time ago by playing with efibootmgr...
Offline
I specifically quoted "everything is expected to boot on the arch option", because the output shows that bootctl expects systemd-boot to use ShellV2.conf as the default (and OP confirms that bootctl's expectation is correct). If TheSaint also saw this, then "everything" actually refers only to a single thing (the line with "default" in loader.conf), which seems a little strange.
Anyway, I'll repeat that it should be "arch.conf" and not "arch".
In schard's case, bootctl's expectation turns out to be wrong. That indicates that bootctl and systemd-boot interpret things differently. This could be a bug or a version mismatch.
Offline
Anyway, I'll repeat that it should be "arch.conf" and not "arch".
Raynman, Thank you.
I checked it out, that I made such mistake assuming that was not necessary the suffix.
At the least I obviated by using the Efistub. After all I'm willing to boot quickly on the GUI. Occasionally I might enter the BIOS and change the boot order, in case of particular maintenance.
Last edited by TheSaint (2020-07-23 04:59:18)
do it good first, it will be faster than do it twice the saint
Offline
@Raynman: Thank you. The cause was indeed, that I never ran
bootctl update
*facepalm*
Last edited by schard (2020-07-23 09:34:31)
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
@schard
I did such command but I couldn't have the result. Perhaps the wrong setting took the precedence.
do it good first, it will be faster than do it twice the saint
Offline
Pages: 1