The output of `efibootmgr -v` shows efistub entry and no other unexpected bootloaders?
So You know about such efibootmgr entries that exist only on booted system, and not in uefi bios:
Boot0002* UEFI:CD/DVD Drive
Boot0003* UEFI:Removable Device
Boot0004* UEFI:Network Device
Do You know how to fix that, because I can't find on google anything similar, and it confuses me that those entries are not shown when I boot Arch installed on (same computer) nvme?
]]> if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then
if cryptsetup isLuks ${resolved} >/dev/null 2>&1; then
[ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
dopassphrase=1
# If keyfile exists, try to use that
if [ -f ${ckeyfile} ]; then
if eval cryptsetup --key-file ${ckeyfile} open --type luks ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}; then
dopassphrase=0
else
echo "Invalid keyfile. Reverting to passphrase."
fi
fi
# Ask for a passphrase
if [ ${dopassphrase} -gt 0 ]; then
echo ""
echo "A password is required to access the ${cryptname} volume:"
#loop until we get a real password
while ! eval cryptsetup open --type luks ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}; do
sleep 2;
done
fi
Unfortunately I have no advice, I'm just pointing you to the place where the /dev/sd* vs /dev/disk/by-uuid/* decision is made.
]]>#!/usr/bin/ash
run_hook() {
modprobe -a -q dm-crypt >/dev/null 2>&1
[ "${quiet}" = "y" ] && CSQUIET=">/dev/null"
# Get keyfile if specified
ckeyfile="/crypto_keyfile.bin"
if [ -n "$cryptkey" ]; then
IFS=: read ckdev ckarg1 ckarg2 <<EOF
$cryptkey
EOF
if [ "$ckdev" = "rootfs" ]; then
ckeyfile=$ckarg1
elif resolved=$(resolve_device "${ckdev}" ${rootdelay}); then
case ${ckarg1} in
*[!0-9]*)
# Use a file on the device
# ckarg1 is not numeric: ckarg1=filesystem, ckarg2=path
mkdir /ckey
mount -r -t "$ckarg1" "$resolved" /ckey
dd if="/ckey/$ckarg2" of="$ckeyfile" >/dev/null 2>&1
umount /ckey
;;
*)
# Read raw data from the block device
# ckarg1 is numeric: ckarg1=offset, ckarg2=length
dd if="$resolved" of="$ckeyfile" bs=1 skip="$ckarg1" count="$ckarg2" >/dev/null 2>&1
;;
esac
fi
[ ! -f ${ckeyfile} ] && echo "Keyfile could not be opened. Reverting to passphrase."
fi
if [ -n "${cryptdevice}" ]; then
DEPRECATED_CRYPT=0
IFS=: read cryptdev cryptname cryptoptions <<EOF
$cryptdevice
EOF
else
DEPRECATED_CRYPT=1
cryptdev="${root}"
cryptname="root"
fi
# This may happen if third party hooks do the crypt setup
if [ -b "/dev/mapper/${cryptname}" ]; then
echo "Device ${cryptname} already exists, not doing any crypt setup."
return 0
fi
warn_deprecated() {
echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"
echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."
}
for cryptopt in ${cryptoptions//,/ }; do
case ${cryptopt} in
allow-discards)
cryptargs="${cryptargs} --allow-discards"
;;
*)
echo "Encryption option '${cryptopt}' not known, ignoring." >&2
;;
esac
done
if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then
if cryptsetup isLuks ${resolved} >/dev/null 2>&1; then
[ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
dopassphrase=1
# If keyfile exists, try to use that
if [ -f ${ckeyfile} ]; then
if eval cryptsetup --key-file ${ckeyfile} open --type luks ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}; then
dopassphrase=0
else
echo "Invalid keyfile. Reverting to passphrase."
fi
fi
# Ask for a passphrase
if [ ${dopassphrase} -gt 0 ]; then
echo ""
echo "A password is required to access the ${cryptname} volume:"
#loop until we get a real password
while ! eval cryptsetup open --type luks ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}; do
sleep 2;
done
fi
if [ -e "/dev/mapper/${cryptname}" ]; then
if [ ${DEPRECATED_CRYPT} -eq 1 ]; then
export root="/dev/mapper/root"
fi
else
err "Password succeeded, but ${cryptname} creation failed, aborting..."
return 1
fi
elif [ -n "${crypto}" ]; then
[ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
msg "Non-LUKS encrypted device found..."
if echo "$crypto" | awk -F: '{ exit(NF == 5) }'; then
err "Verify parameter format: crypto=hash:cipher:keysize:offset:skip"
err "Non-LUKS decryption not attempted..."
return 1
fi
exe="cryptsetup open --type plain $resolved $cryptname $cryptargs"
IFS=: read c_hash c_cipher c_keysize c_offset c_skip <<EOF
$crypto
EOF
[ -n "$c_hash" ] && exe="$exe --hash '$c_hash'"
[ -n "$c_cipher" ] && exe="$exe --cipher '$c_cipher'"
[ -n "$c_keysize" ] && exe="$exe --key-size '$c_keysize'"
[ -n "$c_offset" ] && exe="$exe --offset '$c_offset'"
[ -n "$c_skip" ] && exe="$exe --skip '$c_skip'"
if [ -f "$ckeyfile" ]; then
exe="$exe --key-file $ckeyfile"
else
echo ""
echo "A password is required to access the ${cryptname} volume:"
fi
eval "$exe $CSQUIET"
if [ $? -ne 0 ]; then
err "Non-LUKS device decryption failed. verify format: "
err " crypto=hash:cipher:keysize:offset:skip"
return 1
fi
if [ -e "/dev/mapper/${cryptname}" ]; then
if [ ${DEPRECATED_CRYPT} -eq 1 ]; then
export root="/dev/mapper/root"
fi
else
err "Password succeeded, but ${cryptname} creation failed, aborting..."
return 1
fi
else
err "Failed to open encryption mapping: The device ${cryptdev} is not a LUKS volume and the crypto= paramater was not specified."
fi
fi
rm -f ${ckeyfile}
}
# vim: set ft=sh ts=4 sw=4 et:
Please, I am not an expert, what can I do, copy-paste that section into /usr/lib/initcpio/hooks/encrypt or what?
Edit: Well, I found that You were talking about file /usr/lib/initcpio/init_functions, and everything else is beyond my knowledge.
]]>I am wondering what is "decision maker" in efistub command which decide about using designation disk-by-uuid or by using sda,b,c and so on?
The decision is made by resolve_device() that is used by /usr/lib/initcpio/hooks/encrypt.
]]>This computer have Asus Prime B450-plus motherboard, and it shows first thing on booting:
A password is required to access the cryptroot volume:
Enter passphrase for /dev/sda2
Older computer with motherboard Asus 970 Pro Gaming/Aura (and almost identical settings of Arch Linux), shows first thing on booting:
A password is required to access the cryptroot volume:
Enter passphrase for /dev/disk/by-uuid/11111111-1111-1111-1111-1111111102
I am wondering what is "decision maker" in efistub command which decide about using designation disk-by-uuid or by using sda,b,c and so on?
Obviously it have something to do with hardware and I can't do anything about it, but I can't remember this random sda<>sdb swapping, and phantom efibootmgr entries before Kernel 5.3 (?)
If there wasn't that game crashing, I would never noticed sda/sdb swapping issue.
So now only issue remains that sda/sdb swapping described before, and those
Boot0002* UEFI:CD/DVD Drive
Boot0003* UEFI:Removable Device
Boot0004* UEFI:Network Device
misterious efibootmgr phantom entries.
I'll wait for future kernel upgrades to see if there will be any changes, because I do not consider this swapping behaviour normal.
Oh, I almost forgot, what about my question "Is it somehow possible to replace first part of efibootmgr command ..." ?
Thank You
blkid -lt UUID=11111111-1111-1111-1111-111111111102
which it resoves to /dev/sda2 or /dev/sdb2 depending on the kernels device assignment.
I do not think this is related to other symptoms you have encountered under linux 5.3.
Have you checked the kernel messages when the game froze?
efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003,0004
Boot0000* ArchMush HD(1,GPT,4db7ca05-7e29-4a2f-a198-ee9d1243258c,0x800,0x43000)/File(\vmlinuz-linux)c.r.y.p.t.d.e.v.i.c.e.=.U.U.I.D.=.1.1.1.1.1.1.1.1.-.1.1.1.1.-.1.1.1.1.-.1.1.1.1.-.1.1.1.1.1.1.1.1.1.1.0.2.:.c.r.y.p.t.r.o.o.t.:.a.l.l.o.w.-.d.i.s.c.a.r.d.s. .r.o.o.t.=.U.U.I.D.=.1.1.1.1.1.1.1.1.-.1.1.1.1.-.1.1.1.1.-.1.1.1.1.-.1.1.1.1.1.1.1.1.1.1.1.2. .r.w. .i.n.i.t.r.d.=./.a.m.d.-.u.c.o.d.e...i.m.g. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.
Boot0001* Arch Zer0 HD(1,GPT,6a4afab9-028e-42eb-95e1-0b1db3b037ae,0x800,0xf0800)/File(\vmlinuz-linux)c.r.y.p.t.d.e.v.i.c.e.=.U.U.I.D.=.0.0.0.0.0.0.0.0.-.0.0.0.0.-.0.0.0.0.-.0.0.0.0.-.2.2.2.2.2.2.2.2.2.2.0.2.:.c.r.y.p.t.r.o.o.t.:.a.l.l.o.w.-.d.i.s.c.a.r.d.s. .r.o.o.t.=.U.U.I.D.=.0.0.0.0.0.0.0.0.-.0.0.0.0.-.0.0.0.0.-.0.0.0.0.-.2.2.2.2.2.2.2.2.2.2.2.2. .r.w. .i.n.i.t.r.d.=./.a.m.d.-.u.c.o.d.e...i.m.g. .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:CD/DVD Drive BBS(129,,0x0)
Boot0003* UEFI:Removable Device BBS(130,,0x0)
Boot0004* UEFI:Network Device BBS(131,,0x0)
or
efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003,0004
Boot0000* ArchMush
Boot0001* Arch Zer0
Boot0002* UEFI:CD/DVD Drive
Boot0003* UEFI:Removable Device
Boot0004* UEFI:Network Device
First two entries are the only valid one!
I don't have CD/DVD drive on this computer.
My disks:
nvme - with 'serious' Arch Linux installation
ssd - with gaming (multilib) Arch Linux installed - (attached to mobo on sata0, aka sda)
hdd - gamefiles and multimedia - (attached to sata1 on mobo, aka sdb)
All my fstab entries are with UUID.
So, after upgrade nvme has no problems, but ssd started to act strange, freezing game (I can't explain why - if everything is done by UUID).
System is configured to boot via efistub, so no GRUB here.
After I discovered this swapping, I rebooted with Arch installation USB (it is few month OLD installer 5.1.5, so NO KERNEL 5.3 ! ), mounted ssd, chrooted, and executed script which is sitting on the root of Arch Linux OS (prepared for emergencies like this).
Script is:
#!/bin/bash
efibootmgr -d /dev/sda -p 1 -c -L "ArchMush" -l /vmlinuz-linux -u "cryptdevice=UUID=11111111-1111-1111-1111-111111111102:cryptroot:allow-discards root=UUID=11111111-1111-1111-1111-111111111112 rw initrd=/amd-ucode.img initrd=/initramfs-linux.img"
But that not helped, because, my reboot has 50:50 chance to :
A password is required to access the cryptroot volume:
Enter passphrase for /dev/sda2
or
A password is required to access the cryptroot volume:
Enter passphrase for /dev/sdb2
So, my question is:
Is it somehow possible to replace first part of efibootmgr command:
efibootmgr -d /dev/sda -p 1 ... ...
with somewhat (I'm not expert):
efibootmgr --disk-by-UUID <uuid-here> -c -L "ArchMush" ... ...
so that sdA, B or C is completely removed from the picture, and first boot thing would be:
A password is required to access the cryptroot volume:
Enter passphrase for /dev/disk-by-uuid ... ...