···
···
262
+
assertions = lib.mkOption {
263
+
type = options.assertions.type;
268
+
Assertions only evaluated by the repart image, not by the system toplevel.
272
+
warnings = lib.mkOption {
273
+
type = options.warnings.type;
278
+
Warnings only evaluated by the repart image, not by the system toplevel.
264
-
assertions = lib.mapAttrsToList (
265
-
fileName: partitionConfig:
267
-
inherit (partitionConfig) repartConfig;
268
-
labelLength = builtins.stringLength repartConfig.Label;
271
-
assertion = repartConfig ? Label -> GPTMaxLabelLength >= labelLength;
273
-
The partition label '${repartConfig.Label}'
274
-
defined for '${fileName}' is ${toString labelLength} characters long,
275
-
but the maximum label length supported by UEFI is ${toString GPTMaxLabelLength}.
280
-
warnings = lib.filter (v: v != null) (
281
-
lib.mapAttrsToList (
282
-
fileName: partitionConfig:
284
-
inherit (partitionConfig) repartConfig;
285
-
suggestedMaxLabelLength = GPTMaxLabelLength - 2;
286
-
labelLength = builtins.stringLength repartConfig.Label;
288
-
if (repartConfig ? Label && labelLength >= suggestedMaxLabelLength) then
290
-
The partition label '${repartConfig.Label}'
291
-
defined for '${fileName}' is ${toString labelLength} characters long.
292
-
The suggested maximum label length is ${toString suggestedMaxLabelLength}.
294
-
If you use sytemd-sysupdate style A/B updates, this might
295
-
not leave enough space to increment the version number included in
296
-
the label in a future release. For example, if your label is
297
-
${toString GPTMaxLabelLength} characters long (the maximum enforced by UEFI) and
298
-
you're at version 9, you cannot increment this to 10.
version = config.image.repart.version;
···
finalPartitions = lib.mapAttrs addClosure cfg.partitions;
336
+
assertions = lib.mapAttrsToList (
337
+
fileName: partitionConfig:
339
+
inherit (partitionConfig) repartConfig;
340
+
labelLength = builtins.stringLength repartConfig.Label;
343
+
assertion = repartConfig ? Label -> GPTMaxLabelLength >= labelLength;
345
+
The partition label '${repartConfig.Label}'
346
+
defined for '${fileName}' is ${toString labelLength} characters long,
347
+
but the maximum label length supported by UEFI is ${toString GPTMaxLabelLength}.
352
+
warnings = lib.filter (v: v != null) (
353
+
lib.mapAttrsToList (
354
+
fileName: partitionConfig:
356
+
inherit (partitionConfig) repartConfig;
357
+
suggestedMaxLabelLength = GPTMaxLabelLength - 2;
358
+
labelLength = builtins.stringLength repartConfig.Label;
360
+
if (repartConfig ? Label && labelLength >= suggestedMaxLabelLength) then
362
+
The partition label '${repartConfig.Label}'
363
+
defined for '${fileName}' is ${toString labelLength} characters long.
364
+
The suggested maximum label length is ${toString suggestedMaxLabelLength}.
366
+
If you use sytemd-sysupdate style A/B updates, this might
367
+
not leave enough space to increment the version number included in
368
+
the label in a future release. For example, if your label is
369
+
${toString GPTMaxLabelLength} characters long (the maximum enforced by UEFI) and
370
+
you're at version 9, you cannot increment this to 10.
···
mkfsEnv = mkfsOptionsToEnv cfg.mkfsOptions;
391
+
val = pkgs.callPackage ./repart-image.nix {
392
+
systemd = cfg.package;
393
+
imageFileBasename = config.image.baseName;
403
+
inherit fileSystems definitionsDirectory mkfsEnv;
371
-
pkgs.callPackage ./repart-image.nix {
372
-
systemd = cfg.package;
373
-
imageFileBasename = config.image.baseName;
383
-
inherit fileSystems definitionsDirectory mkfsEnv;
406
+
lib.asserts.checkAssertWarn cfg.assertions cfg.warnings val;
meta.maintainers = with lib.maintainers; [