Systemd-boot ready setup with encryption is unbootable (without /boot/efi)

[ultinous-kszegi]

I wanted to install a systemd-boot based system. The installer doesn't have currently an option for that, that is okay.

systemd-boot cannot load initramfs from different partitions, so the old layout of /boot and /boot/efi is not a good match now. If I let the agama manage the boot, it creates a /boot/efi.

Slightly off-topic: BTW this layout is very opinionated even with GRUB: GRUB's ancient crypto is order of magnitude slower than the one that would be in initramfs. If the boot (where initramfs gets generated) is part of the encrypted root, GRUB has to do the decrypt, and it's slow AF. It's a price of encrypted kernel and initramfs. IMO (or should I say Lennart Poettering's opinion, which I share) secure boot should be the responsible to prevent initramfs/kernel tinkering. The partition mounted as /boot should be left out of encryption, and bootloader shouldn't reimplement crypto libraries (and FS drivers, etc.; all of these reimplementations comes with less maintenance and subpar performance as the example illustrates)

Now, I disabled the managed boot option, created a single FAT, mounted to /boot. I note the warning, as I though I know what I am doing. I also enabled encryption. Now, agama was a bit more clever than it should have been - it encrypted both the /boot FAT and the / BTRFS partition. Encryption is a global option in config not per volume, so I should've expected this.

Maybe it is not a good bug report, more of a conversation starter. I get the agama aims to be less customizable (or aims to be simpler, which results is less customization). And most of the time when you want encryption, you want as much as feasible. But I'd very much like if systemd-boot would be selectable, OR you could install a system that can be easily migrated to it. Even the latter is hard now (let agama create /boot/efi partition, but make it bigger through conf editing, after install move /boot's contents to this partition too (and the original contents to efi subfolder, change fstab, install systemd-boot, something like this, quite a dance)

[ancorgs]

We may add support for systemd-boot in the short future. But despite that happening or not, the inhability to customize your own /boot partition without encryption is certainly a problem. And we are aware of that.

In fact, the storage configuration page has certainly A LOT of room for improvement. And we are planning a big revamp of the whole thing (currently under discussion).

So it's indeed unfortunate that encryption cannot be disabled for a particular filesystem. But that's only one of the many small details we want to change in upcoming versions.

Give us three months ;-)

[ultinous-kszegi]

Thank you for the reply. I was not accurate, in places.

However I managed to import autoinst.xml (autoyast generated from a system), only using its storage part. Now, it had two partitions, a single 4GB /boot VFAT, and the rest for / (encrypted BTRFS), together filling the available space. The agama config show did print the two partitions correctly. However the installer created a separate /boot/efi nevertheless (shrinking the wanted partitions of course) I tried again adding "storage": {"boot": {"configure": false}} besides the imported legacyAutoyaststorage but that resulted in the same unwanted partition

[ancorgs]

"storage" and "legacyAutoyastStorage" are exclusive sections. You cannot use parameters of the former to influence the latter. You are either using the classical AutoYaST algorithm and specifications or using the new one. And is not that easy to convince AutoYaST to stop proposing the missing (to the YaST criteria) partitions needed for booting.

If you paste your AutoYaST definition I can try two things:

• Massaging the legacyAutoyastStorage section to try to ensure AutoYaST gives up on proposing a /boot/efi
• Create the equivalent profile for the storage section (new syntax and algorithm), in which {"boot": {"configure": false}} would work as you need.

[ultinous-kszegi]

I presumed that the two storage configs were mutually exclusive, however, I could try mixing the two in no time :smile:

The sotrage config is nothing special (besides being leaner than the "standard" suggestion for systemd-boot, and some encryption with good settings) Also, the size of the second partition shouldn't be fixed, but all the remaining of course. If I export an auto proposed agama config with agama config show the config cannot be validated, party due to auto size not in json schema, but AFAIR agama loads it nevertheless...

{
    "legacyAutoyastStorage": [
      {
        "device": "/dev/nvme0n1",
        "disklabel": "gpt",
        "enable_snapshots": true,
        "partitions": [
          {
            "create": true,
            "filesystem": "vfat",
            "format": true,
            "fstopt": "rw,nosuid,nodev,noexec,relatime,nosymfollow,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro",
            "label": "efi",
            "mount": "/boot",
            "mountby": "device",
            "partition_id": 259,
            "partition_nr": 1,
            "resize": false,
            "size": "4294967296"
          },
          {
            "create": true,
            "create_subvolumes": true,
            "crypt_cipher": "aes-xts-plain64",
            "crypt_key": "randompassword",
            "crypt_key_size": 512,
            "crypt_label": "root_encrypted",
            "crypt_method": "luks2",
            "crypt_pbkdf": "argon2id",
            "filesystem": "btrfs",
            "format": true,
            "fstopt": "compress=lzo,noatime",
            "label": "root",
            "loop_fs": true,
            "mount": "/",
            "mountby": "device",
            "partition_id": 272,
            "partition_nr": 2,
            "quotas": true,
            "resize": false,
            "size": "512109837824",
            "subvolumes": [
              {
                "copy_on_write": false,
                "path": "var"
              },
              {
                "copy_on_write": true,
                "path": "usr/local"
              },
              {
                "copy_on_write": true,
                "path": "srv"
              },
              {
                "copy_on_write": true,
                "path": "root"
              },
              {
                "copy_on_write": true,
                "path": "opt"
              },
              {
                "copy_on_write": true,
                "path": "home"
              },
            ],
            "subvolumes_prefix": "@"
          }
        ],
        "type": "CT_DISK",
        "use": "all"
      }
    ],
}

BTW, I wasn't hell bent on autoyast storage config, OTOH, I tried the new syntax first, but schema-wise correct config was loaded, but starting the the installer failed due to invalid config

It was more or less this:

{
  "storage": {
    "boot": {
      "device": "/dev/nvme0n1",
      "configure": false
    },
    "drives": [
      {
        "search": "/dev/nvme0n1",
        "ptableType": "gpt",
        "partitions": [
          {
            "filesystem": {
              "type": "vfat",
              "mountBy": "uuid",
              "path": "/boot"
            },
            "size": "4 GiB",
            "id": "esp"
          },
          {
            "filesystem": {
              "type":"btrfs",
              "mountOptions": [
                "compress=lzo",
                "noatime"
              ],
              "mountBy": "uuid",
              "path": "/"
            },
            "encryption": {
              "luks2": {
                "pbkdFunction": "argon2id",
                "password": "randompassword"
              }
            },
            "size": "507797380608 B",
            "id": "linux"
          } 
        ]
      }
    ]
  }
}

[ultinous-kszegi]

@ancorgs thanks for your time again. Were you be able to create a valid config with the new syntax, based on my provided snippet? I just happen to have a system I could reinstall this week...

[ancorgs]

Your attempt looks basically correct to me if /dev/nvme0n1 is empty.

If there are existing partitions you need to delete first, then I miss an entry at "partitions" entry to do so. Something like this:

  { "search": { "ifNotFound": "skip" }, "delete": true }

On the other hand, I find it kind of risky to specify the sizes up to the last byte. It's very hard to do that right, since there are a lot of roundings and similar stuff due to arcane things like the extra copy of the GPT table at the end of the disk, etc. Not to mention how some tools interpret GiB vs GB and so on.

So it's safer to rely on Agama to do the calculations. For that, you only have to change one thing. The size of the root partition.

< "size": "507797380608 B",
---
> "size": {"min": "5 GiB"},

That should work. Since there is a min but not a max, the partition will extend to use the rest of the disk.

For completeness, this a simplified version of your profile I used for my testing. That includes my two suggestions above and also shows how you can actually omit many things and Agama will figure things out:

{
  "storage": {
    "boot": { "configure": false },
    "drives": [
      {
        "search": "/dev/nvme0n1",
        "partitions": [
          { "search": { "ifNotFound": "skip" }, "delete": true },
          {
            "filesystem": {
              "type": "vfat",
              "path": "/boot"
            },
            "size": "4 GiB",
            "id": "esp" 
          },
          {
            "filesystem": { "path": "/" },
            "encryption": {
              "luks2": {
                "pbkdFunction": "argon2id",
                "password": "randompassword"
              }
            },
            "size": {"min": "5 GiB"}
          }
        ]
      }
    ]
  }
}

Tell me if you find any problem with it.

[ultinous-kszegi]

That's a big help, I most probably missed to delete the previous partitions when the install failed to start. I specified sizes because even though the agama config show outputs auto, that isn't approved by validation. I should've used min size, yes. I'll try soon, I'd say tonight, but life's quite hectic right now...

[ancorgs]

If something on that config does not work, please make sure to be using a recent-enough version of the installer. The latest development version is always available at https://agama-project.github.io/download