You are not logged in.
Today after upgrade to kernel 5.3 i had some issue similar as described here.
And as user loqs pointed to bug here.
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 ... ...
Last edited by Vizitor (2019-10-07 22:49:58)
Offline
The output of `efibootmgr -v` shows efistub entry and no other unexpected bootloaders?
Offline
HOLLY SHhhhh!
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.
Offline
I manually deleted Boot002, 3, and 4; but after rebooting (still 50/50 chance to boot as sda/sdb) those entries are back.
I know that there was almost no chance to fix that, but that was first on my mind.
Offline
The encrypt hook is resolving the UUID using:
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?
Offline
Since wine was updated at same time, I believe it has something to do with wine, because everything other works fine.
Game started to exit due to problem with memory alocation size, and sometime without even displaying any message.
And - this is important - game crashes when OS is booted from proper (sda2) prompt.
Also, there are no suspicious kernel messages.
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
Offline
Further investigation:
Phantom entries showed by efibootmgr are not showing on boot menu (when pressing F8 - my "show boot menu" key) on computer booting.
Phantom entries showed by efibootmgr are not showing on Arch OS installed on nvme.
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 (?)
Offline
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.
Offline
Arch Linux /usr/lib/initcpio/hooks/encrypt does not have this section:
#!/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.
Last edited by Vizitor (2019-10-07 07:28:33)
Offline
resolve_device is defined /usr/lib/initcpio/init_functions, it gets called by /usr/lib/initcpio/hooks/encrypt:
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.
Offline
Thanks, I will try to learn and see what can I do further about it.
Offline
/dev/disk/by-uuid/11111111-1111-1111-1111-1111111102 will be a symlink /dev/sda2 or /dev/sdb2
If you want for cosmetic reasons to see "Enter passphrase for /dev/disk/by-uuid/11111111-1111-1111-1111-1111111102"
change cryptdevice=UUID=11111111-1111-1111-1111-111111111102 to cryptdevice=/dev/disk/by-uuid/11111111-1111-1111-1111-1111111102
Offline
loqs, You are a pure genius!
How was I suppose to know that "cryptdevice=UUID=..." is not the same as "cryptdevice=/dev/disk/by-uuid/..."?
Well, this part is solved.
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?
Offline
Those are compatibility entries for accessing devices/EFI partitions that are not actually part of the system (they are part of your UEFI bios, how else would you start the live USB in EFI mode?)
Offline
OK, I now understand, especially because system is workig fast and without problems.
But why Arch installed on same computer, on nvme, does not show that? Only difference is that one on nvme is not multilib-ed.
Offline