Storage dm_crypt + preserve Always Fails

Bug #2005131 reported by Mark Lopez
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
curtin
In Progress
Undecided
Dan Bungert

Bug Description

Running via Subiquity

In this case, I'm trying to install Ubuntu Server onto a luks btrfs root.

Given the autoinstall storage config:

```
    config:

      - id: sda-disk
        type: disk
        ptable: gpt
        preserve: true
        path: /dev/sda

      - id: efi-partition
        type: partition
        size: 1072693248
        device: sda-disk
        flag: boot
        partition_type: EF00
        preserve: true
        grub_device: true
      - id: boot-partition
        type: partition
        size: 1G
        device: sda-disk
        preserve: true
      - id: root-partition
        type: partition
        size: 134216679424
        device: sda-disk
        preserve: true

      - id: root-crypt
        type: dm_crypt
        dm_name: crypto_root
        volume: root-partition
        key: password
        preserve: true

      - id: root-format
        type: format
        fstype: btrfs
        preserve: true
        volume: root-crypt
      - id: boot-format
        type: format
        fstype: btrfs
        preserve: true
        volume: boot-partition
      - id: efi-format
        type: format
        fstype: fat32
        preserve: true
        volume: efi-partition

      - id: boot-mount
        type: mount
        path: /boot
        device: boot-format
      - id: efi-mount
        type: mount
        path: /boot/efi
        device: efi-format
      - id: root-mount
        type: mount
        path: /
        device: root-format
```

Curtin fails with the following error:

```
Verifying /dev/mapper/crypto_root exists
Running command ['dmsetup', 'info', '/dev/mapper/crypto_root', '-C', '-o', 'name,uuid,blkdevname,blkdevs_used,subsystem', '--noheading', '--separator', '='] with allowed return codes [0] (capture=True)
Verifying /dev/mapper/crypto_root volume, expecting /dev/sda3 , found sda3
An error occured handling 'root-crypt': RuntimeError - Verifying /dev/mapper/crypto_root volume, expecting /dev/sda3 , found sda3
finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: configuring dm_crypt: root-crypt
TIMED BLOCK_META: 1.230
finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: curtin command block-meta
Traceback (most recent call last):
  File "/snap/subiquity/4229/lib/python3.8/site-packages/curtin/commands/main.py", line 202, in main
    ret = args.func(args)
  File "/snap/subiquity/4229/lib/python3.8/site-packages/curtin/log.py", line 97, in wrapper
    return log_time("TIMED %s: " % msg, func, *args, **kwargs)
  File "/snap/subiquity/4229/lib/python3.8/site-packages/curtin/log.py", line 79, in log_time
    return func(*args, **kwargs)
  File "/snap/subiquity/4229/lib/python3.8/site-packages/curtin/commands/block_meta.py", line 118, in block_meta
    return meta_custom(args)
  File "/snap/subiquity/4229/lib/python3.8/site-packages/curtin/commands/block_meta.py", line 2097, in meta_custom
    handler(command, storage_config_dict, context)
  File "/snap/subiquity/4229/lib/python3.8/site-packages/curtin/commands/block_meta.py", line 1514, in dm_crypt_handler
    dm_crypt_verify(dmcrypt_dev, volume_path)
  File "/snap/subiquity/4229/lib/python3.8/site-packages/curtin/commands/block_meta.py", line 1476, in dm_crypt_verify
    verify_blkdev_used(dmcrypt_dev, volume_path)
  File "/snap/subiquity/4229/lib/python3.8/site-packages/curtin/commands/block_meta.py", line 1471, in verify_blkdev_used
    raise RuntimeError(msg)
RuntimeError: Verifying /dev/mapper/crypto_root volume, expecting /dev/sda3 , found sda3
Verifying /dev/mapper/crypto_root volume, expecting /dev/sda3 , found sda3
```

Note that the command in the logs returns:

```
# dmsetup info /dev/mapper/crypto_root -C -o name,uuid,blkdevname,blkdevs_used,subsystem --noheading --separator =
crypto_root=CRYPT-LUKS2-b2f76b46a21e4cb9b35676a4849c47c0-crypto_root=dm-0=sda3=CRYPT
```

I'm not sure when this code would succeed given the code: https://github.com/canonical/curtin/blob/8c5f87ed567b2a4cdddeb4a49ad607011b34aa49/curtin/commands/block_meta.py#L565-L575

Which makes me think this is likely a bug.

Dan Bungert (dbungert)
Changed in curtin:
status: New → Confirmed
Revision history for this message
Dan Bungert (dbungert) wrote :

I've got a branch in progress that I think will resolve this.

Mark, are you interested in helping to test? I will strongly recommend backing up your data first though.

Changed in curtin:
status: Confirmed → In Progress
assignee: nobody → Dan Bungert (dbungert)
Revision history for this message
Mark Lopez (silvenga) wrote :

Of course! I have VM's I can test with.

That said, I might need some pointers in how to switch over to your branch - my current local environment is around autoinstall right now.

Revision history for this message
Josef Wolf (jw-raven) wrote :

I am also affected by this bug (using 22.04 LTS server with cloud-init autoinstall).

Problem seems to be that dmsetup reports only file name of the device file (e.g. nvme0n1p3 without the /dev/ prefix) but curtin expects the full path of the device file (e.g. /dev/nvme0n1p3 including /dev/ prefix)

I don't see how to tell dmsetup to include full path when reporting the blkdevs_used field. Thus, I'd assume curtin should drop the directory part from its expectation or at least make it optional.

Problem seems to still exist in current subiquity, at least it still fails when

   refresh-installer:
    update: yes

updates to snap-version 23.10.1

BTW: I'd be happy to test. Where can I find the patch (and possibly instruction of how to install the patch on 22.04 LTS iso?)

Revision history for this message
Josef Wolf (jw-raven) wrote :

Oh, and there is one problem with cm_crypt and preserve:true (hitting even earlier in the installation process)

curtin fails to luksOpen the device. To work around this, one needs to create/populate an /etc/crypttab and invoke cryptdisk_start form early-commands. But still, the /dev/ prefix problem hits after this.

Revision history for this message
Josef Wolf (jw-raven) wrote :

Please find patch in attachment. This patch fixes the issue for me.

Probably some rework needs to be done to this patch, since I am not an python expert and am not familiar with curtin internals.

Please feel free to use this patch as a starting point.

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

Other bug subscribers

Remote bug watches

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