Encrypted partitions not decrypted at boot time when using key-file.

colin@xxxxxxxxxx (Colin Guthrie) · Tue, 27 Mar 2018 16:36:20 +0100

Hi,

Yeah, unfortunately that log line is very misleading (and has actually
been removed in more recent versions of systemd for this reason!)

Ultimately this is something which you should debug via your distro
support channels as disk encryption is ultimately implemented quite
differently in various distros.

Someone here might know the answer and be able to help out but I suspect
you may get more progress going via an Ubuntu specific support channel
of some kind - especially of folk there know what to look out for
specifically).

Col

Arbiel (gmx) wrote on 27/03/18 15:41:
> Hi
> 
> I am not quite sure to post at the right place. I do so because I got
> the following lines when running "journalctl -xb" in a Ubuntu xenial
> system, and more precisely
> 
> "Support:http://lists.freedesktop.org/mailman/listinfo/systemd-devel";.
> 
> I added lines on # to border output from command lines and lines of +
> to help locate relevant information.
> 
> Here are the lines:
> #######################################################
> mars 26 15:00:56 remi-Vostro-3550 systemd[1]:
> dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.ckf-victor\x2droot:1.device:
> Job
> dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.ckf-victor\x2droot:1.device/start
> timed out.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> mars 26 15:00:56 remi-Vostro-3550 systemd[1]: Timed out waiting for
> device
> dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.ckf-victor\x2droot:1.device.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> -- Subject: L'unitÃ?Â© (unit)
> dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.ckf-victor\x2droot:1.device
> a Ã?Â©chouÃ?Â©
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> ####################################################
> 
> "L'unitÃ?Â© (unit)
> dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.ckf-victor\x2droot:1.device
> a Ã?Â©chouÃ?Â©"
> means
> "Unit
> dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.ckf-victor\x2droot:1.device
> failed"
> 
> The corresponding device, a USB key, was perfectly connected. No doubt
> about that because it also holds grub, and booting a GNU system requires
> it to be connected,  as shown in the following lines taken from
> bootinfoscript output:
> 
> #####################################################
> ============================= Boot Info Summary:
> ===============================
> ++++++++++++++++++++++++++++++++++++++++++++
>  => Windows 7/8/2012 is installed in the MBR of /dev/sda.
>  => Grub2 (v2.00) is installed in the MBR of /dev/sdb and looks at
> +++++++++++++++++++++++++++++++++++++++++++++
> sector 1 of
>     the same hard drive for core.img. core.img is at this location and
> looks
>     for (,msdos1)/grub.
> 
> and, further down
> 
> "blkid" output:
> ________________________________________________________________
> 
> Device           UUID                                   TYPE       LABEL
> 
> /dev/mapper/victor-archos 0b1a0ad3-a97d-43c9-adbb-cd4b86474670   ext2
> /dev/mapper/victor-boot 728d4e9f-3015-4571-b226-73a7155164af
> ext2       victor-boot
> /dev/mapper/victor-boot_alt 70c6be90-0e8d-4bae-85c2-e4493abfce8e
> ext2       victor-boot_alt
> /dev/mapper/victor-gumnon 473aaf37-8b79-4bd5-8b04-1ede572a8481
> ext2       victor-gumnon
> /dev/mapper/victor-home 767bbb95-4b40-4321-8394-2636e06b87a0
> ext4       victor-home_alt
> /dev/mapper/victor-home_alt c5faba25-bb99-4afd-84cc-575657c03fa5
> ext4       victor-home
> /dev/mapper/victor-home_jetable_l 37447a61-f946-4d38-a398-5a886c4e3f22
> crypto_LUKS
> /dev/mapper/victor-home_l 3d6502a4-ee71-4291-a17e-304e3027ca59
> crypto_LUKS
> /dev/mapper/victor-odos 763ceb54-0166-4266-a684-bbc7545f9861   ext4
> /dev/mapper/victor-odos_l fd6afe40-b9c5-40af-a48f-d397bb57382f
> crypto_LUKS
> /dev/mapper/victor-oikia 5b96a110-0c7d-4ffa-acd8-7665bc84e18a   ext4
> /dev/mapper/victor-oikia_l 97aca676-26ee-4745-8d9f-336257426db3
> crypto_LUKS
> /dev/mapper/victor-ouranos 2f32f2a6-d8d5-485f-8a68-769ca1671bbe
> ext2       victor-ouranos
> /dev/mapper/victor-psilos 6d247bdb-0bad-4562-b8bb-0a69c06e85fd
> ext4       victor-psilos
> /dev/mapper/victor-root 4e0b8f16-2c9a-491f-8e13-d780893f65a4
> ext4       victor-root
> /dev/mapper/victor-root_alt_l bcc1027f-6078-449f-a26c-99706b5b59b4
> crypto_LUKS
> /dev/mapper/victor-root_l 78576555-f0c2-4c80-af4f-d763cc7ae71d
> crypto_LUKS
> /dev/mapper/victor-trophe 6412a23a-703e-4eea-bb34-2d9b973e4943   ext4
> /dev/mapper/victor-usr c438ab5d-636a-4e87-bdbc-25700b1ebdad   ext2
> victor-usr
> /dev/mapper/victor-usr_alt 07a8dd93-820b-40c1-a73b-2e71f6914167
> ext2       victor-usr_alt
> /dev/mapper/victor-xenial f0091524-8a6e-4980-9664-7863a2d8ce78   ext4
> /dev/sda1        367C9BBD7C9B75F9                       ntfs
> multi_amorces
> /dev/sda2        5A549F42549F1FB5                       ntfs       win7pro
> /dev/sda3        6FA7-9CC9                              vfat       TRANSIT
> /dev/sda4        mLCqaA-7Su3-x2BK-RMJZ-4Qzi-xfY1-IEnZv9 LVM2_member
> /dev/sdb1        40FD37A875ADF030                       ntfs       Ibead
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> /dev/sdb2        4146dfad-26f0-4aec-99c3-8ab00c3e4297   ext2       .ibead
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> /dev/sdb3        7a9556f8-fdac-484d-8263-804bec042cf1   ext2       ..ibead
> #########################################################
> 
> 
> The fstab and crypttab of the running system were as follows :
> 
> ########################################################
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> /dev/mapper/victor-xenial /               ext4    errors=remount-ro
> 0       1
> 
> 
> victor-root UUID=78576555-f0c2-4c80-af4f-d763cc7ae71d
> /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/victor-root:1
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> luks,keyscript=/lib/cryptsetup/scripts/passdev
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> victor-home UUID=3d6502a4-ee71-4291-a17e-304e3027ca59
> /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/victor-home:1
> luks,noauto,keyscript=/lib/cryptsetup/scripts/passdev
> victor-odos UUID=fd6afe40-b9c5-40af-a48f-d397bb57382f
> /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/victor-odos:1
> luks,noauto,keyscript=/lib/cryptsetup/scripts/m_passdev
> victor-oikia UUID=97aca676-26ee-4745-8d9f-336257426db3
> /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/victor-oikia:1
> luks,noauto,keyscript=/lib/cryptsetup/scripts/m_passdev
> xavier-root UUID=2e167b67-6ac7-4ede-94bd-bafebcb3491c
> /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/xavier-root:5
> luks,noauto,keyscript=/lib/cryptsetup/scripts/passdev
> xavier-home UUID=46889e2d-aac8-4869-8f6b-1d4f4deda420
> /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/xavier-home:5
> luks,noauto,keyscript=/lib/cryptsetup/scripts/passdev
> soter-logisthen UUID=e400e0fa-e232-450c-97df-8625a93cc669
> /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/soter-logisthen
> luks,noauto,keyscript=/lib/cryptsetup/scripts/passdev
> #########################################################
> 
> 
> As can be deduced from these files, victor-xenial is a clear partition.
> The system booted correctly. And the error message concerning
> victor-root to time out stems for the fact that the "noauto" is absent
> for the victor-root list of options.
> 
> As can also be seen in the crypttab file, I used a m_passdev module,
> only to output messages as proof of the invocation on not invocation of
> the module in charge of outputing the key
> 
> ##############################################################
> remi at remi-Vostro-3550:~$ sudo cryptdisks_start victor-odos
>  * Starting crypto
> disk...                                                       *
> victor-odos (starting)..
> declare --
> param="/dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/victor-odos:1"
> declare -x CRYPTTAB_NAME="victor-odos"
> declare -x
> CRYPTTAB_SOURCE="/dev/disk/by-uuid/fd6afe40-b9c5-40af-a48f-d397bb57382f"
> declare -x
> CRYPTTAB_KEY="/dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/victor-odos:1"
> declare -x CRYPTTAB_TRIED="0"
> declare -x CRYPTTAB_OPTIONS=" luks keyscript"
> declare -- src="/dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297"
> declare -- fic_cle="/.ckf/victor-odos"
> declare -- delai="1"
> declare -- dev="/dev/sdb2"
>  * victor-odos (started)...
> [ OK ]
> ##########################################################
> 
> However, Ubuntu xenial fails at booting when victor-odos is root and
> victor-oikia is /home, as specified in the following fstab, that is when
> the crypted partitions are to be used to boot the system.
> 
> #######################################################
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> /dev/mapper/victor-odos /               ext4    errors=remount-ro 0       1
> /dev/mapper/victor-archos /boot           ext2    defaults        0       2
> /dev/mapper/victor-oikia /home           ext4    defaults        0       2
> /dev/mapper/victor-trophe /usr            ext4    defaults        0       2
> ##########################################################
> 
> In that case, I obviously rub out the "noauto" option from the option
> list. No messages are produced. m_passdev is not invoqued.
> 
> This bug does not occur with kernel 3.13.0-106-generic (Ubuntu Trusty)
> xenial kernel is 4.13.0-36-generic.
> 
> Arbiel
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/