Fixing the delete-root-at-boot script (re: your cohost ask)

[NireBryce]

Hey, you don't have asks enabled and cohost doesn't notify for @-s, so I'm opening an issue.

Your workaround for postDeviceCommands (where you wrote just a script = block) didn't work for me (There was an issue for this, I wrote that it didn't work but then got busy with a move and forgot to follow up)

I found a way that does, from either one of the nixos disk related repos or their issues tab, unfortunately I can't find the source. But this seems to work, without needing to risk things with postDeviceCommands

# delete root at boot
  boot.initrd.postResumeCommands = lib.mkAfter ''
      mkdir -p /mnt
    # We first mount the btrfs root to /mnt
    # so we can manipulate btrfs subvolumes.
      mount -o subvol=/ /dev/mapper/enc /mnt

    # While we\'re tempted to just delete /root and create
    # a new snapshot from /root-blank, /root is already
    # populated at this point with a number of subvolumes,
    # which makes `btrfs subvolume delete` fail.
    # So, we remove them first.
    #
    # /root contains subvolumes:
    # - /root/var/lib/portables
    # - /root/var/lib/machines
    #
    # I suspect these are related to systemd-nspawn, but
    # since I don\'t use it I\'m not 100% sure.
    # Anyhow, deleting these subvolumes hasn\'t resulted
    # in any issues so far, except for fairly
    # benign-looking errors from systemd-tmpfiles.
      btrfs subvolume list -o /mnt/root |
      cut -f9 -d' ' |
      while read subvolume; do
        echo "deleting /$subvolume subvolume..."
        btrfs subvolume delete "/mnt/$subvolume"
      done &&
      echo "deleting /root subvolume..." &&
      btrfs subvolume delete /mnt/root

      echo "restoring blank /root subvolume..."
      btrfs subvolume snapshot /mnt/root-blank /mnt/root

    # Once we\'re done rolling back to a blank snapshot,
    # we can unmount /mnt and continue on the boot process.
        umount /mnt
  '';

Technically I think this should make it trigger on resume, but I've never had that happen. Which is, perhaps, it's own problem. Currently looking for where I found it.

[NireBryce]

so I think it's just used to just make sure it's coming after running the resume checks for some reason in system.boot.stage-1-init.sh and not anything to do with resumes itself.

It's hard to muddle through the two of these, and postResumeCommands' description string in nixpkgs is exceptionally misleading if it just determines where in the script to put things.

https://github.com/NixOS/nixpkgs/blob/45cbf8d42fff56fcac72bbd31292eb381134be93/nixos/modules/system/boot/stage-1.nix#L526

    boot.initrd.postResumeCommands = mkOption {
      default = "";
      type = types.lines;
      description = ''
        Shell commands to be executed immediately after attempting to resume.
      '';
    };

https://github.com/NixOS/nixpkgs/blob/45cbf8d42fff56fcac72bbd31292eb381134be93/nixos/modules/system/boot/stage-1-init.sh#L503

[NireBryce]

nevermind, found it: NixOS/nixpkgs#240651

I think I got here from trying to figure out why postDeviceCommands wasn't executing even when I tried that instead of your script.

Adds a postResumeCommands option to the initramfs to allow inserting code to execute after the device has attempted to resume, and before filesystems are mounted.

This allows to inject code for operations like wiping the rootfs on boot; if those were instead put in postDeviceCommands, on a hibernated device, they would execute before the device resumes from hibernation. The next currently available spot is postMountCommands which is too late.

[Guekka]

Thank you for your help! I appreciate you investigating the issue
I'm going to change the blog post, but I will keep the issue open until I can rebase the git history