Random boot failues due to partition confusion because disko now relies on `by-partlabel` about disko HOT 8 OPEN

hmm, you would need to override the device of each partition. you can set it to /dev/disk/by-id/$my_id-part$x. Another alternative would be to override the disk name. so something like:

disko.devices.disk.root.name = builtins.substring 0 10 (builtins.hashString "sha256" config.disko.devices.disk.root.device);

that should ensure a unique id according to the device? not sure if that's good enough for you. otherwise overriding each partition is exactly what you want, although a bit tedious if you have a lot of them

from disko.

you can set it to /dev/disk/by-id/$my_id-part$x

That's what I did yesterday to work around the issue for the time being, but I was hoping there would be a better approach. The current partition numbers obviously only correspond to the order with legacy tables from before and if I were to resetup now, then the partitions would be in a different order because of alphabetical sorting and it would break again. Adding a partition would also break it if it isn't ordered last. Previously we could choose where to place the partitions so this would not happen.

I then tried to use the canonical device name via name = "nvme-Samsung_SSD_980_PRO_2TB_SXXENFXXWXXXXX" but noticed that this causes the partition labels to become very long because of the disk-<diskname>-<partname> format. And unfortunately those long labels seem to be unsupported somewhere (in the kernel ?).

disko.devices.disk.root.name = builtins.substring 0 10 (builtins.hashString "sha256" config.disko.devices.disk.root.device);

that should ensure a unique id according to the device?

This only solves part of the problem. I'd like to use the unique device identifier for the name anyway, but that results in huge partlabels. Hashing it here would make it shorter, but if you also have a longer name for the partition it will still exceed the limit. So that would need to be hashed too. It's a bit awkward having to set a hashed name for each device and partition from now on.

Please excuse my ignorance, but can you explain to me why the legacy tables are deprecated now? I searched the git history but failed to find any explanation or rationale for why they are deprecated.

From my (limited) point of view we previously had stable and predictable disk names, which were humanly readable at runtime, no issues with long names, no possibility for duplicates and thus confusion and we also had predictable partition order. Anyone who would intentionally want to create a name clash with a USB stick would have had to emulate a whole disk with one of my disk ids, now it just requires to trivially set a partition label to make my system boot something else.

What am I missing that makes the new approach preferable?

from disko.

you can set it to /dev/disk/by-id/$my_id-part$x

That's what I did yesterday to work around the issue for the time being, but I was hoping there would be a better approach. The current partition numbers obviously only correspond to the order with legacy tables from before and if I were to resetup now, then the partitions would be in a different order because of alphabetical sorting and it would break again. Adding a partition would also break it if it isn't ordered last. Previously we could choose where to place the partitions so this would not happen.

you can add a priority to each partition to ensure a stable partition order. just think of them as an index in that case.

I then tried to use the canonical device name via name = "nvme-Samsung_SSD_980_PRO_2TB_SXXENFXXWXXXXX" but noticed that this causes the partition labels to become very long because of the disk-<diskname>-<partname> format. And unfortunately those long labels seem to be unsupported somewhere (in the kernel ?).

This only solves part of the problem. I'd like to use the unique device identifier for the name anyway, but that results in huge partlabels. Hashing it here would make it shorter, but if you also have a longer name for the partition it will still exceed the limit. So that would need to be hashed too. It's a bit awkward having to set a hashed name for each device and partition from now on.

yeah I haven't figured out the limit yet, maybe its 64 characters? we could automatically hash them if they exceed the limit so you wouldn't have to override them on each device.

Please excuse my ignorance, but can you explain to me why the legacy tables are deprecated now? I searched the git history but failed to find any explanation or rationale for why they are deprecated.

From my (limited) point of view we previously had stable and predictable disk names, which were humanly readable at runtime, no issues with long names, no possibility for duplicates and thus confusion and we also had predictable partition order. Anyone who would intentionally want to create a name clash with a USB stick would have had to emulate a whole disk with one of my disk ids, now it just requires to trivially set a partition label to make my system boot something else.

What am I missing that makes the new approach preferable?

the old legacy tables used lists, which are hard to override or reference in nixos modules. also the device numbering was cumbersome and not portable (meaning, that if you changed your device from something like /dev/sda to /dev/disk/by-id/... the whole logic for device numbering changed) and this made testing the code harder. With the old tables the vm tests or image generation doesn't work because we can't really override all the device names in every partition. With the new attrset based tables we now have the possibility to set the device to an environment variable and have portable install scripts that way. the old tables also broke easily if people set it to devices like /dev/sda and /dev/sdb and they sometimes flipped.

Also the old device nubmering code https://github.com/nix-community/disko/blob/master/lib/default.nix#L76 was brittle and incomplete.

from disko.

Also another feature this enables is the non destructive updates I'm working on right now. Since you can add partitions later and they won't mess up the old partitions for mounting.

from disko.

yeah I haven't figured out the limit yet, maybe its 64 characters? we could automatically hash them if they exceed the limit so you wouldn't have to override them on each device.

Yeah that'd definitely be a lot easier.

the old legacy tables used lists, which are hard to override or reference in nixos modules. also the device numbering was cumbersome and not portable (meaning, that if you changed your device from something like /dev/sda to /dev/disk/by-id/... the whole logic for device numbering changed) and this made testing the code harder. With the old tables the vm tests or image generation doesn't work because we can't really override all the device names in every partition. With the new attrset based tables we now have the possibility to set the device to an environment variable and have portable install scripts that way. the old tables also broke easily if people set it to devices like /dev/sda and /dev/sdb and they sometimes flipped.

Also the old device nubmering code https://github.com/nix-community/disko/blob/master/lib/default.nix#L76 was brittle and incomplete.

I see, thanks for the explanation. I'll test the partlabel hashing approach.

from disko.

FWIW I ran into this too, the approach I've taken is to add a config.fileSystems block back into the machine configs, and just override the device attributes. It's a temporary workaround which I'll remove if/when the machines are reinstalled. You can see the commit here:

jnsgruk/nixos-config@186ba38

from disko.

Well, I'm not getting random boot failures since in my case it's not random at all.
It fails a 100% of the times because it's looking for the wrong disk.

Errors before unlocking because it wants disk-vbd-cryptvol0 instead of cryptvol0 which is the name that appears when running ls /dev/disk/by-partlabel.

I have no clue on what to do.

from disko.

Probably open a new issue with more insight into your config would help. Since disko is not run automatically to you probably have to either xhange the label in your config or change the partition labels with gdisk/parted or something like that

from disko.