Ubuntu
ubiquity package

encrypted zfs partition not mountable from live session using recovery key

  1. Mantic (23.10)
  2. Bug #2037574
Bug #2037574 reported by Tim Andersson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Status tracked in Mantic
Mantic
New
High
Unassigned

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)

Revision history for this message
Tim Andersson (andersson123) wrote :
Steve Langasek (vorlon)
Changed in ubiquity (Ubuntu Mantic):
importance: Undecided → High
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Reading the code, it seems like after one has completed ubiquity install.
Without shutting down the machine.
One should be able to unmount /target in full, and luksClose all the things.
And then straight away test if one can luksOpen again using main password, recovery password, or recovery key-file. And there at least appears UI to set either recovery password or recovery keyfile.
The final null-byte/new-line is not quite obvious, i.e. if there is one byte missing potentially off the recovery password or not.

Revision history for this message
Tim Andersson (andersson123) wrote (last edit ):

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 :)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.