| 20 May 2023 |
 @elvishjerricco:matrix.org | the systemd folks tend to think of this in terms of an installation process that just creates an ESP and a /usr partition, and then everything else is set up by the boot process | 00:02:11 |
 @uep:matrix.org | oh, on the same disk.. so a partially-constructed partition table and set of filesystems vs something like disk when building the disk image, all at once. | 00:18:17 |
| @elvishjerricco:matrix.org | There's sort of a lot you can do with it | 00:18:57 |
| @elvishjerricco:matrix.org | It's pretty flexible | 00:19:02 |
| @uep:matrix.org | hm. It seems to me like shuffling the deck chairs of when things get done, compared to (say) resizing partitions on first boot | 00:20:29 |
| @uep:matrix.org | but it is a more general version of that idea, so I suppose allows for more options | 00:20:55 |
| @elvishjerricco:matrix.org | I don't really understand that analogy but ok :P | 00:21:31 |
| @uep:matrix.org | old and not-really-busted: make a disk image with relevant partitions, as small as you can. Clone that, boot it, and expand the root fs to fill free space on first boot.
new systemd hotness: make a disk image with fewer relevant partitions, and free space. Clone that, boot it, and mkfs the root fs on first boot. | 00:24:55 |
| @uep:matrix.org | I was assuming kernel and initrd came from somewhere other than ESP (e.g. netboot) so the disk was blank | 00:25:57 |
| @elvishjerricco:matrix.org | That's another option, like the NixOS test example | 00:29:29 |
| @uep:matrix.org | that's what I mean about a more general version | 00:29:53 |
| @elvishjerricco:matrix.org | Ah yea | 00:30:01 |
| @uep:matrix.org | I jumped straight to "the disk can be blank" as the goal, whereas your comment about "systemd folks thinking about this as ..." seemed like less interesting/ambitious | 00:33:54 |
|  @aloisw:kde.org joined the room. | 05:10:14 |
 @nikstur:matrix.org | In reply to @uep:matrix.org
old and not-really-busted: make a disk image with relevant partitions, as small as you can. Clone that, boot it, and expand the root fs to fill free space on first boot.
new systemd hotness: make a disk image with fewer relevant partitions, and free space. Clone that, boot it, and mkfs the root fs on first boot. This is still the basic idea: create a disk image and make the installation of a systemd as simple as dding this image onto a disk. In the systemd world your disk image really only needs an ESP and a /usr but we can do a very similar thing in NixOS: ESP and the nix store. systemd-repart is also cool for A/B update schemes where you create a second partition and then write the update to this second partition. This gives you atomicity on the partition level. systemd-repart is really one of the basic buildings blocks of a vision of an image-based Linux which systemd is really pushing. | 22:22:31 |
| @nikstur:matrix.org | In reply to @uep:matrix.org
old and not-really-busted: make a disk image with relevant partitions, as small as you can. Clone that, boot it, and expand the root fs to fill free space on first boot.
new systemd hotness: make a disk image with fewer relevant partitions, and free space. Clone that, boot it, and mkfs the root fs on first boot. * This is still the basic idea: create a disk image and make the installation of a system as simple as dding this image onto a disk. In the systemd world your disk image really only needs an ESP and a /usr but we can do a very similar thing in NixOS: ESP and the nix store. systemd-repart is also cool for A/B update schemes where you create a second partition and then write the update to this second partition. This gives you atomicity on the partition level. systemd-repart is really one of the basic buildings blocks of a vision of an image-based Linux which systemd is really pushing. | 22:22:39 |
| 21 May 2023 |
| @uep:matrix.org | Ok, yeah, the A/B thing makes sense.. even more partitions :) | 02:45:49 |
| 22 May 2023 |
 Arian | Why does NixOS's image builder use Qemu again? | 13:39:56 |
| Arian | it's spending almost 70 seconds in QEMU :/ | 13:40:04 |
| Arian | shouldn't we be able to build an image without booting a VM? | 13:40:17 |
| @elvishjerricco:matrix.org | Don't we just run nixos-install in a VM to make an image or something? | 13:40:30 |
 K900 | It's surprisingly difficult, actually | 13:40:36 |
| K900 | Turns out it's pretty hard to create a filesystem that is only implemented in the kernel without the kernel | 13:41:11 |
| @elvishjerricco:matrix.org | but also we definitely make too many images now | 13:41:38 |
| @elvishjerricco:matrix.org | there's a lot of nixos tests that previously didn't need an image that do now | 13:41:48 |
| @elvishjerricco:matrix.org | because of some much-needed changes to qemu-vm.nix | 13:41:59 |
| Arian | I'm pretty sure all the filesystems the kernel implements are now exposed as userspace libraries | 13:44:08 |
| K900 | They are absolutely not | 13:44:19 |
| @elvishjerricco:matrix.org | yea wut | 13:44:24 |
| Arian | :( | 13:44:25 |
