[Bug 2073594] Re: Autoinstall fails when using recovery_keyfile workflow

[Chris Peterson]

Hi James, thanks for the report and the logs and data. I was able to
reproduce this today using the autoinstall you provided. I see that we
setup the dm_crypt device correctly but it looks like we're missing a
step saving off the key data:

2024-07-19 23:19:10,856 DEBUG subiquity.models.filesystem:2345 Copying
recovery key for DM_Crypt(volume=partition-3, key=<REDACTED>,
recovery_key=RecoveryKeyHandler(live_location=PosixPath('/root/luks_recovery_key'),
backup_location=PosixPath('/var/log/installer/luks_recovery_key')),
path='/dev/mapper/dm_crypt-0', id='dm_crypt-0', type='dm_crypt') to
target: /target


** Package changed: subiquity (Ubuntu) => subiquity

** Changed in: subiquity
       Status: New => Triaged

** Changed in: subiquity
   Importance: Undecided => Medium

** Tags added: reproducible

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to subiquity in Ubuntu.
https://bugs.launchpad.net/bugs/2073594

Title:
  Autoinstall fails when using recovery_keyfile workflow

Status in subiquity:
  Triaged

Bug description:
  With the Ubuntu 24.04 Desktop ISO, and the latest stable ubuntu-
  desktop-bootstrap snap (0+git.9b015d0d6), autoinstall is failing when
  attempting to add a recovery key.

  I have attached the relevant installer logs and autoinstall user-data.
  I've inspected them myself and can see a python traceback which shows
  that _expose_key function in
  `subiquity/subiquity/models/filesystem.py` is failing when copying the
  recovery_key to the target system.

  The key itself appears to be undefined for some reason.

  I'm using /etc/machine-id as the recovery_keyfile for testing because
  it's a single-line string and world readable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/2073594/+subscriptions