functional.cafe is one of the many independent Mastodon servers you can use to participate in the fediverse.
functional.cafe is an instance for people interested in functional programming and languages.

Server stats:

217
active users

We could probably remove the initrd completely from the AWS NixOS images. It only needs virtio,nvme,ext4 and ena . Could easily just build that into the kernel directly.

Public

The other option is the opposite: _only_ ship an initrd and allow people to reconfigure the rootfs dynamically on first boot

Public

@arianvp Thinking about initrd-only images a lot lately, I favor that approach. Downside being that it might mess with people’s assumptions, e.g. about attaching a volume to a VM and being able to use it directly

Public

@moritz apparently there also need to be some changes in systemd-initrd for this to work when I was talking about this idea with @daandemeyer . There needs to be an additional transaction in the initrd so we can determine what to boot into after setting up the disk to boot into. E.g. refire the gpt-auto discovery logic after downloading the rootfs and writing it to a partition

Public

@arianvp @daandemeyer UX aside, couldn’t we just not enable switch-root (or whatever service starts stage2 in NixOS) and let the user run that manually, delegating mounting the correct filesystems to him?

Public

@moritz @daandemeyer yes. But I'm thinking of userless variant of this:

Initrd reads some credentials from hypervisor (through QEMU systemd credentials, cloud metadata server). Uses that to configure e.g. systemd-repart to format the disk. Then some service to populate the disk (e.g. sysupdate or nixos-install). And then we want to boot into that disk afterwards.