touch-packages team mailing list archive

[Hadmut Danisch <hadmut@xxxxxxxxxx>]

OK,

I have debugged this down and got big steps further in identifying the
problem.


An important step for debugging was to learn how to debug systemd. 

    http://freedesktop.org/wiki/Software/systemd/Debugging/

was quite helpful, that

   systemctl enable debug-shell.service

helps a lot. After that, one can get a root shell when the systemd boot
process is hanging.


I have identified *two*  problems, both in 
/lib/systemd/systemd-cryptsetup



First problem:

The system boot procedure hangs because the process

    /lib/systemd/systemd-cryptsetup attach sda2_crypt /dev/disk/by-id
/ata-SanDisk_SDSSDHII480G_**********-part2 none  luks,swap,discard

hangs. It waits for password input, but for some reason it's prompt and
input don't make it their way to the boot console or boot splash prompt.
There's a problem with the procedure for requesting a password.

Killing that process from the debug console makes the boot process
continue immediately (of course without working swap).


Once knowing that this is the process causing trouble, debugging get's much easier, since it is not required anymore to try this within a boot process. You can use a running machine with any test partition for easy debugging. 

BTW: systemd does not use /etc/crypttab directly, but converts the
contents of /etc/crypttab to dynamically created units first, which can
be found under /run/systemd. It shows


ExecStart=/lib/systemd/systemd-cryptsetup attach 'sda2_crypt' '/dev/disk/by-id/ata-SanDisk_SDSSDHII480G_**********-part2' 'none' 'luks,swap,discard'
ExecStop=/lib/systemd/systemd-cryptsetup detach 'sda2_crypt'
ExecStartPost=/sbin/mkswap '/dev/mapper/sda2_crypt'


So one knows what happens right here. 


You can easily call the given command from anywhere as root with any partition, without the need to edit /etc/crypttab, because it's all command line parameters here. Makes testing pretty easy now. 



Second problem: 


That damned systemd-cryptsetup ignores luks (or is unable to cope with modern luks settings). 

That's what the dmsetup looks like for my root partition setup in the
initramfs:

0 903712768 crypt aes-xts-plain64
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0 8:3 4096 1 allow_discards


This looks good, because it's the same crypt-parameters (aes-xts) as I used when creating the luks partition, and it uses an offset of 4096, allowing the luks header to remain untouched. 


But after running that systemd-cryptsetup for the sda2 partition (even
after freshly partitioning it with cryptsetup), dmtable shows that:


0 32616448 crypt aes-cbc-essiv:sha256 0000000000000000000000000000000000000000000000000000000000000000 0 8:2 0 1 allow_discards


which contains *two* wrong settings:

- it's the wrong cipher

- it's an offset of 0, which overwrites the luks header. That's why I am
seeing garbage again and again.




So it turns out that systemd-cryptsetup is tripple-buggy:

- Password dialog not working in boot process, neither in splash or non-
splash mode (that's why boot process hangs)

- wrong cipher

- no offset, thus overwriting the luks header.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1506139

Title:
  15.10beta crashes encrypted swap partition

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Hi,

  I'm usually using a setup with three partitions on a disk

  Partition 1:  plain ext4 boot partition mounted on  /boot
  Partition 2:  luks-encrypted swap
  Partition 3: luks-encrypted btrfs for /  /home ...

  both mentioned in /etc/crypttab like

  sda2_crypt UUID=a7976d5c-6191-436d-9cf9-2cedf17d0893 none luks,swap,discard
  sda3_crypt UUID=339b9a90-8292-422d-a3cf-eeb0317e9f84 none luks,discard

  
  With several machines I have installed 15.10 beta on and in several cases I experienced the problem that the swap is not activated at boot time and that /dev/disks/by-uuid does not contain a link to the swap partition, and the previously created luks-encrypted swap is destroyed after boot: It is not a luks partition anymore and filled with random (presumably encrypted) bytes without structure. 

  I first thought that this is a problem of the setup process, and
  repaired the swap manually. But then I found the partition destroyed
  again. This happend several times on several machines.

  I am not sure yet what exactly would destroy the partition.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: cryptsetup 2:1.6.6-5ubuntu2
  ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
  Uname: Linux 4.2.0-16-generic x86_64
  ApportVersion: 2.19.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Wed Oct 14 18:12:58 2015
  InstallationDate: Installed on 2015-10-08 (5 days ago)
  InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150924)
  SourcePackage: cryptsetup
  UpgradeStatus: No upgrade log present (probably fresh install)
  crypttab:
   sda2_crypt UUID=a7976d5c-6191-436d-9cf9-2cedf17d0893 none luks,swap,discard
   sda3_crypt UUID=339b9a90-8292-422d-a3cf-eeb0317e9f84 none luks,discard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1506139/+subscriptions