[Bug 2037574] Re: encrypted zfs partition not mountable from live session using recovery key

[Tim Andersson]

I understand that perhaps this would work, but is that really the point
of the recovery key? If we're using the recovery key post-install on the
same installed system, manually unmounting /target etc, is that
reflective of the situations the recovery key is supposed to be used in?

I don't have a problem with the process you suggest but in terms of
tests for the isotracker, they should be reflective of user experience.
It's my assumption, and I may be wrong, but would a user not use the
recovery key to recover a drive they no longer have access too by usual
methods (on the originally installed system)? Is there a use case in
which a user would have access to the original system, but not to the
encrypted zfs data?

We can also include both steps in the isotracker tests - unmount and
remount from the installed system, then boot into it with an iso and
mount the data in a live session.

If I'm wrong in my assumptions, please do tell me :)

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

Title:
  encrypted zfs partition not mountable from live session using recovery
  key

Status in ubiquity package in Ubuntu:
  New
Status in ubiquity source package in Mantic:
  New

Bug description:
  I did an install in a VM with zfs+encryption, and I enabled the
  recovery key option in the install process.

  I then booted into a live session using the same storage and attempted to mount the storage using steps from the following:
  https://radagast.ca/linux/mounting-ubuntu-encrypted-zfs.html

  It works just fine (the cryptsetup command specifically) using the
  passphrase from the install process. However, the cryptsetup command
  does NOT work when using the recovery key chosen in the install
  process.

  I copied the recovery key down at install time, and wrote the key to a
  file in the live session. I then passed it to the cryptsetup command
  using --key-file and --master-key-file command line options (with
  /path/to/recovery.key). Neither options worked. The disk is only
  mountable using the passphrase.

  I may be using the recovery key incorrectly, but if that is the case,
  there is a lack of documentation surrounding this part of the install
  process.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: ubiquity (not installed)
  ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0
  Uname: Linux 6.5.0-5-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Sep 27 17:44:13 2023
  InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---
  InstallationDate: Installed on 2023-09-27 (0 days ago)
  InstallationMedia: Ubuntu Legacy 23.10 "Mantic Minotaur" - Beta amd64 (20230925)
  SourcePackage: ubiquity
  UpgradeStatus: No upgrade log present (probably fresh install)

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