touch-packages team mailing list archive

[Jani Uusitalo <jani@xxxxxxxxxxx>]

Public bug reported:

The setup for unlocking an encrypted volume during boot using (only) a
keyfile (on a detachable USB drive) usually calls for a keyscript to be
specified as one of the encrypted volume's options. But with systemd,
such encrypted volumes can only be unlocked during boot by typing in a
passphrase.

Steps to reproduce:
1. Have a LUKS encrypted volume.
2. Have said volume specified in /etc/crypttab, with keyscript= option pointing to your script for outputting the unlocking key.
3. Boot.

What I expect to happen:
To have the volume unlocked by the script at boot time without manual intervention.

What happens instead:
Plymouth shows a prompt to enter a valid passphrase for the volume.

Workarounds:
Apparently the options for unlocking encrypted drives, including keyscript, can also be specified at the kernel command-line, without crypttab, and according to yaantc at Hacker News [1] this can be used to work around the issue. I haven't personally tried this.

* [1] https://news.ycombinator.com/item?id=8477913

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-7ubuntu4
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Sat May  2 15:39:07 2015
InstallationDate: Installed on 2014-10-18 (196 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140923)
MachineType: ASUSTeK COMPUTER INC. UX32A
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic.efi.signed root=UUID=2185885c-b860-49a8-973f-fa3b52d3eecf ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: Upgraded to vivid on 2015-04-23 (8 days ago)
dmi.bios.date: 01/29/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX32A.214
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX32A
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX32A.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32A:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32A:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: UX32A
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

** Affects: systemd (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: systemd (Debian)
     Importance: Unknown
         Status: Confirmed


** Tags: amd64 apport-bug vivid

** Bug watch added: Debian Bug tracker #618862
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862

** Also affects: systemd (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862
   Importance: Unknown
       Status: Unknown

** Description changed:

- The setup for unlocking an encrypted volume using (only) a keyfile (on a
- detachable USB drive) usually calls for a keyscript to be specified as
- one of the encrypted volume's options. But with systemd, such encrypted
- volumes can only be unlocked during boot by typing in a passphrase.
+ The setup for unlocking an encrypted volume during boot using (only) a
+ keyfile (on a detachable USB drive) usually calls for a keyscript to be
+ specified as one of the encrypted volume's options. But with systemd,
+ such encrypted volumes can only be unlocked during boot by typing in a
+ passphrase.
  
  Steps to reproduce:
  1. Have a LUKS encrypted volume.
  2. Have said volume specified in /etc/crypttab, with keyscript= option pointing to your script for outputting the unlocking key.
  3. Boot.
  
  What I expect to happen:
  To have the volume unlocked by the script at boot time without manual intervention.
  
  What happens instead:
  Plymouth shows a prompt to enter a valid passphrase for the volume.
  
  Workarounds:
  Apparently the options for unlocking encrypted drives, including keyscript, can also be specified at the kernel command-line, without crypttab, and according to yaantc at Hacker News [1] this can be used to work around the issue. I haven't personally tried this.
  
  * [1] https://news.ycombinator.com/item?id=8477913
  
  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu4
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sat May  2 15:39:07 2015
  InstallationDate: Installed on 2014-10-18 (196 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140923)
  MachineType: ASUSTeK COMPUTER INC. UX32A
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic.efi.signed root=UUID=2185885c-b860-49a8-973f-fa3b52d3eecf ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to vivid on 2015-04-23 (8 days ago)
  dmi.bios.date: 01/29/2013
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX32A.214
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX32A
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX32A.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32A:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32A:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.name: UX32A
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

-- 
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/1451032

Title:
  keyscript option in crypttab ignored

Status in systemd package in Ubuntu:
  New
Status in systemd package in Debian:
  Confirmed

Bug description:
  The setup for unlocking an encrypted volume during boot using (only) a
  keyfile (on a detachable USB drive) usually calls for a keyscript to
  be specified as one of the encrypted volume's options. But with
  systemd, such encrypted volumes can only be unlocked during boot by
  typing in a passphrase.

  Steps to reproduce:
  1. Have a LUKS encrypted volume.
  2. Have said volume specified in /etc/crypttab, with keyscript= option pointing to your script for outputting the unlocking key.
  3. Boot.

  What I expect to happen:
  To have the volume unlocked by the script at boot time without manual intervention.

  What happens instead:
  Plymouth shows a prompt to enter a valid passphrase for the volume.

  Workarounds:
  Apparently the options for unlocking encrypted drives, including keyscript, can also be specified at the kernel command-line, without crypttab, and according to yaantc at Hacker News [1] this can be used to work around the issue. I haven't personally tried this.

  * [1] https://news.ycombinator.com/item?id=8477913

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu4
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sat May  2 15:39:07 2015
  InstallationDate: Installed on 2014-10-18 (196 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140923)
  MachineType: ASUSTeK COMPUTER INC. UX32A
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic.efi.signed root=UUID=2185885c-b860-49a8-973f-fa3b52d3eecf ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: Upgraded to vivid on 2015-04-23 (8 days ago)
  dmi.bios.date: 01/29/2013
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: UX32A.214
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: UX32A
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX32A.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32A:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32A:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.name: UX32A
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

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