You are not logged in.

#1 2019-10-05 09:46:56

Vizitor
Member
Registered: 2015-01-05
Posts: 81

[Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#2 2019-10-05 10:02:36

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

The output of `efibootmgr -v`  shows efistub entry and no other unexpected bootloaders?

Offline

#3 2019-10-05 10:12:29

Vizitor
Member
Registered: 2015-01-05
Posts: 81

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#4 2019-10-05 10:45:07

Vizitor
Member
Registered: 2015-01-05
Posts: 81

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#5 2019-10-05 12:30:13

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#6 2019-10-05 13:30:15

Vizitor
Member
Registered: 2015-01-05
Posts: 81

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#7 2019-10-07 06:41:27

Vizitor
Member
Registered: 2015-01-05
Posts: 81

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#8 2019-10-07 07:01:41

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

Vizitor wrote:

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

#9 2019-10-07 07:15:02

Vizitor
Member
Registered: 2015-01-05
Posts: 81

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#10 2019-10-07 07:25:16

nl6720
The Evil Wiki Admin
Registered: 2016-07-02
Posts: 592

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#11 2019-10-07 07:30:27

Vizitor
Member
Registered: 2015-01-05
Posts: 81

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

Thanks, I will try to learn and see what can I do further about it.

Offline

#12 2019-10-07 11:34:15

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

/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

#13 2019-10-07 20:30:02

Vizitor
Member
Registered: 2015-01-05
Posts: 81

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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.

loqs wrote:

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

#14 2019-10-07 20:37:40

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,427

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

#15 2019-10-07 20:50:28

Vizitor
Member
Registered: 2015-01-05
Posts: 81

Re: [Solved] sda<>sdb random swapping, kernel 5.3, luks and efistub

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

Board footer

Powered by FluxBB