what is the rationale behind the following in the _create of types/gpt.nix

        if ! blkid "${config.device}" >&2; then
          sgdisk --clear "${config.device}"
        fi

I say this because when working on the more advanced bcachefs, I have mostly everything working, except the reformat test, as wipefs and all of the disk deactivation doesn't fully clear bcachefs superblocks and such. blkid still returns a value. Thus when trying to re-partition, there are alignment errors since it never gets cleared.

Ultimately: what is the use case of this check? Would we not want to always clear before attempting a partitioning?

what is the rationale behind the following in the _create of types/gpt.nix

        if ! blkid "${config.device}" >&2; then
          sgdisk --clear "${config.device}"
        fi

I say this because when working on the more advanced bcachefs implementation, I have mostly everything working, except the reformat test, as wipefs and all of the disk deactivation doesn't fully clear bcachefs superblocks and such. blkid still returns a value. Thus when trying to re-partition, there are alignment errors since it never gets cleared.

Ultimately: what is the use case of this check? Would we not want to always clear before attempting a partitioning?e

what is the rationale behind the following in the _create of types/gpt.nix

        if ! blkid "${config.device}" >&2; then
          sgdisk --clear "${config.device}"
        fi

I say this because when working on the more advanced bcachefs implementation, I have mostly everything working, except the reformat test, as wipefs and all of the disk deactivation doesn't fully clear bcachefs superblocks and such. blkid still returns a value. Thus when trying to re-partition, there are alignment errors since it never gets cleared.

Ultimately: what is the use case of this check? Would we not want to always clear before attempting a partitioning?

For filesystems that use their own FS definitions like btrfs and bcachefs, what is the recommended way of grabbing the list of devices for the _config attrSet, specifically for defining the fileSystems attrSet.

I can't pull the Bcachefs UUID at eval time as bcachefs Filesystem UUID gets generated during format and there is no way to pre-seed one. The only other option for mounting is via ":" delimited device path list. I am trying to figure out a way to get the list of dependent devices at eval time, as they should be available.

In reply to @projectinitiative:matrix.org
I add an example in the examples folder in a local copy of the disko repo. Then I add that example to the flake.nix file under the testmachine config. Then I load the flake with nix repl and play around with values and functions

postCreateHook = ''
  zfs snapshot zroot/ds1/home@blank';

postCreateHook = ''
  zfs snapshot zroot/ds1/home@blank
'';