Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Disk specs as input data for the dynamic partitioning function #894

Open
mechan1sm opened this issue Nov 24, 2024 · 1 comment

Comments

@mechan1sm
Copy link

Problem

Here is an example partition layout:

  • bootloader1
    • size = exactly 31 MiB
    • fs = FAT16
  • root
    • size = rest of space && multiple of 4GiB
    • fs = XFS
  • boot
    • size = multiple of 16MiB && >= 2GiB && < 6GiB
    • fs = ext4
  • bootloader2
    • size = multiple of 1MiB && >= 8 MiB && < 24 MiB
    • fs = FAT16

afaik it is not possible to write a disko config, so that any disk will be partitioned according to the rules above,
mainly because there is no input information about the disk specs

Possible solution

make it possible to define the content as the function:

disk.example = {
  device = "/dev/loop0";
  type = "disk";
  content = disk_specs : {
    ...
  };
};

where disk_specs is the attrset consisting of the following fields:

{
  sector_size: integer; (512 | 4096);
  size_in_sectors: integer;
  size_in_bytes: integer;
}

there might also be the actual physical block size, that disk uses internally, but I'm unsure if it's even possible to get this one

Notes

May be related to #728 and #789

@iFreilicht
Copy link
Contributor

Yes, this might be possible to achieve with #789. We can retrieve information about the sustem and pass it into the module evaluation function. We do have to make sure that it's possible to evaluate the config even without that info, though. As I understand, you only care about values related to partition sizing, so I would suggest we change the options start, size and end to allow for functions instead. This would limit the influence the dynamic values can have.

I'm not sure if we use then to set any NixOS options, but if we are not, we could define default empty values for the function inputs so the evaluation as a module as part of the NixOS configuration doesn't break.


In the meantime, you can should be able to get all these values with lsblk -O (I think physical block size is part of this as well) and then change the start of your config to something like

let
  sector_size = 512;
  size_in_sectors = 10000000;
  size_in_bytes = 5120000000;
in
{

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants