OK, asking in general, not just specific to s6 init artix. Has anyone using artix experienced that when executing "lsblk -f" the lvm stuff doesn't show uuids? To me:
% lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 vfat FAT32 efi 87C5-3983 510.9M 0% /uefi
├─sda2 crypto_LUKS 2 8c3e2ece-e51a-47f7-b6dc-6a5a9797c7ca
│ └─cryp-lm-4
│ └─lm--4-root 130.9G 35% /
└─sda3 ext4 1.0 boot 43eec14d-1f21-4be0-b63c-34e56f543e90 256.7M 40% /boot
On an arch similar box I get instead the uuids for the lvm stuff:
% lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sdb
├─sdb1 vfat FAT32 lm-3-uefi F066-62B1 510.9M 0% /uefi
├─sdb2 crypto_LUKS 2 16b8246a-0dda-456c-ac9b-687e962652d7
│ └─cryp-lm-3 LVM2_member LVM2 001 6RVcZc-teDE-6KzG-Wmce-Lalx-XQ78-KoRDWN
│ └─lm--3-root ext4 1.0 lm-3 ed95dae7-2300-4884-a22c-7b7691ee452c 87G 55% /
└─sdb3 ext4 1.0 lm-3-boot 50ca5fdc-39dd-4046-b4be-c9f7108c0fa0 347.1M 22% /boot
A weird thing is that running blkid on artix does show the uuids:
% blkid
/dev/sda1: LABEL_FATBOOT="efi" LABEL="efi" UUID="87C5-3983" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5be1314c-c9e8-0540-8861-8d0d0f549559"
/dev/sda2: UUID="8c3e2ece-e51a-47f7-b6dc-6a5a9797c7ca" TYPE="crypto_LUKS" PARTUUID="ff6d0fe0-4a6b-4225-95bf-d69590af2736"
/dev/sda3: LABEL="boot" UUID="43eec14d-1f21-4be0-b63c-34e56f543e90" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2f02aa05-7bb6-9e45-8283-c5670104383d"
/dev/mapper/cryp-lm-4: UUID="5gVrRQ-x2Ae-Q78w-VxKZ-5rl9-28fp-Dg0h8e" TYPE="LVM2_member"
/dev/mapper/lm--4-root: LABEL="lm-4-roo" UUID="8441a31c-c147-4a1c-8bd8-025af76d0b53" BLOCK_SIZE="4096" TYPE="ext4"
Notice it doesn't matter "lsblk -f" is executed as regular user or as root.
Also, when adding full debug on artix:
2390: lsblk: DEV: [0x55a1a1948ec0]: dm-0: found udev properties
2390: lsblk: DEV: [0x55a1a1948ec0]: from udev
2390: lsblk: DEV: [0x55a1a1948ec0]: refer data[1]="(null)"
2390: lsblk: DEV: [0x55a1a1948ec0]: /dev/mapper/cryp-lm-4: properties requested
2390: lsblk: DEV: [0x55a1a1948ec0]: refer data[2]="(null)"
2390: lsblk: DEV: [0x55a1a1948ec0]: /dev/mapper/cryp-lm-4: properties requested
2390: lsblk: DEV: [0x55a1a1948ec0]: refer data[3]="(null)"
2390: lsblk: DEV: [0x55a1a1948ec0]: /dev/mapper/cryp-lm-4: properties requested
2390: lsblk: DEV: [0x55a1a1948ec0]: refer data[4]="(null)"
2390: lsblk: DEV: [0x55a1a1948ec0]: refer data[5]="(null)"
2390: lsblk: DEV: [0x55a1a1948ec0]: refer data[6]="(null)"
2390: lsblk: DEV: [0x55a1a1948ec0]: refer data[7]="(null)"
2390: lsblk: DEV: [0x55a1a1948ec0]: refer data[8]="254:0 "
2390: lsblk: DEV: [0x55a1a1948ec0]: dm-0 -> continue to child
2390: lsblk: DEV: [0x55a1a1948440]: add 'dm-1' to scols
2390: lsblk: DEV: [0x55a1a1948440]: refer data[0]="lm--4-root"
2390: lsblk: DEV: [0x55a1a1948440]: /dev/mapper/lm--4-root: properties requested
2390: lsblk: DEV: [0x55a1a1948440]: dm-1: found udev properties
2390: lsblk: DEV: [0x55a1a1948440]: from udev
2390: lsblk: DEV: [0x55a1a1948440]: refer data[1]="(null)"
2390: lsblk: DEV: [0x55a1a1948440]: /dev/mapper/lm--4-root: properties requested
2390: lsblk: DEV: [0x55a1a1948440]: refer data[2]="(null)"
2390: lsblk: DEV: [0x55a1a1948440]: /dev/mapper/lm--4-root: properties requested
2390: lsblk: DEV: [0x55a1a1948440]: refer data[3]="(null)"
2390: lsblk: DEV: [0x55a1a1948440]: /dev/mapper/lm--4-root: properties requested
2390: lsblk: DEV: [0x55a1a1948440]: refer data[4]="(null)"
2390: lsblk: DEV: [0x55a1a1948440]: mountpoint: /
2390: lsblk: DEV: [0x55a1a1948440]: refer data[5]="131.2G"
2390: lsblk: DEV: [0x55a1a1948440]: refer data[6]="35%"
2390: lsblk: DEV: [0x55a1a1948440]: refer data[7]="/"
2390: lsblk: DEV: [0x55a1a1948440]: refer data[8]="254:1 "
Whereas on the arch box:
177260: lsblk: DEV: [0x563d42f91ec0]: dm-0: found udev properties
177260: lsblk: DEV: [0x563d42f91ec0]: from udev
177260: lsblk: DEV: [0x563d42f91ec0]: refer data[1]="LVM2_member"
177260: lsblk: DEV: [0x563d42f91ec0]: /dev/mapper/cryp-m1: properties requested
177260: lsblk: DEV: [0x563d42f91ec0]: refer data[2]="LVM2 001"
177260: lsblk: DEV: [0x563d42f91ec0]: /dev/mapper/cryp-m1: properties requested
177260: lsblk: DEV: [0x563d42f91ec0]: refer data[3]="(null)"
177260: lsblk: DEV: [0x563d42f91ec0]: /dev/mapper/cryp-m1: properties requested
177260: lsblk: DEV: [0x563d42f91ec0]: refer data[4]="58XT06-y8YP-jJbJ-cUgd-Xd6i-lYHz-Iofkqk"
177260: lsblk: DEV: [0x563d42f91ec0]: refer data[5]="(null)"
177260: lsblk: DEV: [0x563d42f91ec0]: refer data[6]="(null)"
177260: lsblk: DEV: [0x563d42f91ec0]: refer data[7]="(null)"
177260: lsblk: DEV: [0x563d42f91ec0]: refer data[8]="254:0 "
177260: lsblk: DEV: [0x563d42f91ec0]: dm-0 -> continue to child
177260: lsblk: DEV: [0x563d42f91440]: add 'dm-1' to scols
177260: lsblk: DEV: [0x563d42f91440]: refer data[0]="m1-root"
177260: lsblk: DEV: [0x563d42f91440]: /dev/mapper/m1-root: properties requested
177260: lsblk: DEV: [0x563d42f91440]: dm-1: found udev properties
177260: lsblk: DEV: [0x563d42f91440]: from udev
177260: lsblk: DEV: [0x563d42f91440]: refer data[1]="ext4"
177260: lsblk: DEV: [0x563d42f91440]: /dev/mapper/m1-root: properties requested
177260: lsblk: DEV: [0x563d42f91440]: refer data[2]="1.0"
177260: lsblk: DEV: [0x563d42f91440]: /dev/mapper/m1-root: properties requested
177260: lsblk: DEV: [0x563d42f91440]: refer data[3]="m1-all"
177260: lsblk: DEV: [0x563d42f91440]: /dev/mapper/m1-root: properties requested
177260: lsblk: DEV: [0x563d42f91440]: refer data[4]="4faf705a-d425-4255-a98c-e07d57e78398"
177260: lsblk: DEV: [0x563d42f91440]: mountpoint: /
177260: lsblk: DEV: [0x563d42f91440]: refer data[5]="20.2G"
177260: lsblk: DEV: [0x563d42f91440]: refer data[6]="86%"
177260: lsblk: DEV: [0x563d42f91440]: refer data[7]="/"
177260: lsblk: DEV: [0x563d42f91440]: refer data[8]="254:1 "
On arch, udev finds data[4] to be the uuid for both the group and volume, whereas on artix udev finds them to be "(null)".
As you might have noticed I have lvm on luks encryption...
Is this a general issue on artix? Or rather a thing for the s6 init? If a general artix issue, is this due to eudev? Is this a bug? Can it be worked around, how? Whatever causes this, might it have side effects on other functionality rather than the "lsblk -f" output (meaning is this something to be concerned about)?
Thanks !
--
Javier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.artixlinux.org/archives/artix-general/attachments/20200405/0859efa8/attachment.sig>
More information about the artix-general
mailing list