Cannot mount labelled filesystems without specifying the disk about disko HOT 12 CLOSED

ah you can just mkForce the definition with the label. that should resolve that error at least.

from disko.

so, the new gpt type now uses labels for all partitions, so I guess this is fixed now?

from disko.

well labels are not unique necessarily and we have no code to handle them in any way. You can create partitions with labels but disko will work only in partnumbers and the device you specified. Since labels are also optional it would be cumbersome to add additional code for label handling. Also disks don't need a partition table so partition labels are not really there. I guess having that workaround, as you already did, is really the preferred way to use labels if you really want to.

Just out of curiosity. why do you prefer labels? you can set the device of the disk to something like /dev/disk/by-id or use udev to have unique device names, although I have not tested that yet.

from disko.

It just makes NixOS configuration simpler and more reusable. Specifying the disk by ID ties the configuration to specific hardware, making it more cumbersome to use the same NixOS configuration for multiple machines. Of course there is some hardware specific configuration in NixOS anyway that cannot be avoided, but in this case labels solve that problem pretty well in my opinion. Of course there is the compromise of them being non unique, but then /dev/sdX (which is supported by Disko) is not without compromises either.

I was surprised this is not handled in Disko as I am using it to handle RAID storage on my NAS in a similar way using labels. The difference there is that mounting is done through mdadm option and the disk option is entirely omitted when not formatting (though I did have to add an empty "dummy" disk to make Disko types happy). This way I can format and partition the RAID by specifying the disks, and mount the RAID without specifying anything.

Is it the implementation that is the concern in this case? Because in my opinion from the user's point of view simply omitting disk.*.device or setting it to null to use labels would be a pretty clear API (and seemingly consistent with the rest of the types).

P.S. I edited the workaround after testing today, as Disko labelled partitions are found in /dev/disk/by-partlabel/, where as fileSystems.*.label looks for partitions in /dev/disk/by-label/, so fileSystems.*.device has to be used instead.

from disko.

well the biggest problem with labels is, there are no disk labels, so there would be a disconnect in the code between the disk devices and the partitions with labels, we could try to inject it at the right place though if a label is specified. But I'm still unsure on how to handle duplicate labels. yeah /dev/sdX has it's own problems, but at least we can easily calculate the disk layout beforehand so there are no surprises half way through and /dev/disk/by-id or similar can also be used for a more "stable" disk layout.
But I will take a look into overriding the device in the partition if a label is specified. But I'm a bit afraid, that it will lead to conflicts if people use the same labels for different disks (as did I in /examples/mdadm.nix) and if we use them now by default people will have conflicts for sure

from disko.

Fair points, what about adding a device option to the partition type, which would be used instead of the dev argument in functions if present? It could f.e. be null, absolute-pathname or enum [ "by-partlabel" ], and in case of by-partlabel it would be substituted by /dev/disk/by-partlabel/${config.name}. Of course disk.*.device would have to be nullable for this to work and I don't know if that would present more problems, but I think it should work for basic setups like this. And if it is a problem an error could probably be thrown when both dev argument and device option are null.

from disko.

hmm, what about we add device to partition type which is nullable, but if it is defined it overrides the device of the parent disk/mdadm/etc.? not sure about nullable device on disk. that would turn the disk scripts into noop sometimes (since there is no device to operate on) which would in turn would cause a bunch of other problems I guess

from disko.

Sorry I'm not sure if I understand what you mean by that. What would happen in this case?

{disk ? null, ...}: {
  disk.nixos = {
    device = disk;
    type = "disk";
    content = {
      type = "table";
      format = "gpt";
      partitions = [
        {
          name = "ESP";
          type = "partition";
          device = "by-partlabel"; # /dev/disk/by-partlabel/ESP
          start = "1MiB";
          end = "100MiB";
          bootable = true;
          content = {
            type = "filesystem";
            format = "vfat";
            mountpoint = "/boot";
          };
        }
        {
          name = "root";
          type = "partition";
          device = "by-partlabel"; # /dev/disk/by-partlabel/root
          start = "100MiB";
          end = "100%";
          part-type = "primary";
          content = {
            type = "filesystem";
            format = "ext4";
            mountpoint = "/";
          };
        }
      ];
    };
  };
}

What would disk.nixos.device have to be set to here in order to work as you suggest? I can't see how it can be overridden by the child partitions, as there's multiple different values and they wouldn't point to the actual disk, but to the specific partitions. At least that's what I meant in my previous suggestion.

Just to be clear, the point of this issue is that it would be great to not need to provide a hard-coded disk.*.device when using the configuration for the Disko NixOS module that mounts the partitions. Would that be possible without disk.*.device being nullable? And for cases where the configuration ends up being noop, couldn't an error be thrown during Nix evaluation to solve that issue?

from disko.

ah, that won't work, but we can't create the partitions if we don't know on which disk we should create the partition? For mounting we can use the labels if they are provided. so if you would set device = "by-partlabel"; on the partitions. it would be mounted via "/dev/disk/by-partlabel" where possible. (which should be possible for all partitions if you create a table)

since we need the disk.*.device still for creating, I'm unsure if we want it to be nullable? I kinda dislike the idea of having different disko configs for creating and for the rest.

from disko.

Well it wouldn't really be a different config, it would just be generated using different arguments (see the {disk ? null, ...} part). Maybe if I explain my use case it will be clearer where I'm going with this. I'm creating a Nix Flake with NixOS configurations and an installer ISO. The installer ISO includes things to make the installation of NixOS simple, including this Disko wrapper that uses a configuration similar to the one provided in this issue (+ a swap partition):

{inputs, pkgs, ...}: {
  environment.systemPackages = [(pkgs.writeShellApplication {
    name = "disko";
    runtimeInputs = [inputs.disko.packages.${pkgs.system}.disko];
    text = ''disko "$@" ${./.}/config.nix'';
  })];
}

With this, when I boot into the installer ISO, I can simply run lsblk to check which drive I want to format (f.e. /dev/sda), and run sudo disko --mode zap_create_mount --argstr disk /dev/sda. Then, I install a NixOS configuration which would have the following module (currently using the provided workaround instead):

{inputs, ...}: {
  imports = [inputs.disko.nixosModules.disko];
  disko.devices = import ./config.nix {};
}

So, as you see, the Disko configuration is the same, but it's used differently when creating vs the rest. Without disk.*.device being nullable, this setup doesn't work. It also makes mounting by label pointless as it's obviously unnecessary in case the device is hard-coded to begin with.

from disko.

@Tomaszal initial post is similar to the setup I am trying to implement, specifically mounting filesystems via /dev/disk/by-partlabel/* as it greatly helps me to unify partitioning across devices.

The example code ** though is failing evaluation on commit 591b53f with the following error

error: The option `fileSystems."/".device' has conflicting definition values:
        - In `/nix/store/rq6yk3v7i2fhb3iw39fkn0zjjsbc22m6-source/infra/nixos/modules/zfs-filesystems.nix': "/dev/disk/by-partlabel/root"
        - In `/nix/store/gcnn6jn8g0q5jppzxngxsghkpgxvp6yf-source/eval.nix': "/dev/sda2"

** minus the deprecated type = "partition"; lines

Not sure if this is directly related to this issue, but reading through past issue around partlabel this seems to be the most recent undertaking towards support the feature.

from disko.

Looks promising! I'll have to try it out once I have some spare time, but I think that yes, the issue can be closed.

from disko.