| 19 May 2024 |
matthewcroughan | systemd-repart has a really nice setup | 14:46:41 |
matthewcroughan |
systemd-repart (mostly) operates in a purely incremental mode: it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions. The service is intended to be run on every boot, but when it detects that the partition table already matches the installed repart.
| 14:46:46 |
matthewcroughan | Which more or less sound exactly like disko's philosophy, and some of the goals you have for your own incremental mode | 14:47:09 |
matthewcroughan | This ended up being the final disko.nix for a pi to boot using bcachefs | 17:54:42 |
matthewcroughan | {
boot.postBootCommands = ''
# On the first boot, resize the disk
if [ -f /disko-first-boot ]; then
set -euo pipefail
set -x
# Figure out device names for the boot device and root filesystem.
rootPart=$(${pkgs.util-linux}/bin/findmnt -n -o SOURCE /)
bootDevice=$(lsblk -npo PKNAME $rootPart)
partNum=$(lsblk -npo MAJ:MIN $rootPart | ${pkgs.gawk}/bin/awk -F: '{print $2}')
# Resize the root partition and the filesystem to fit the disk
echo ",+," | sfdisk -N$partNum --no-reread $bootDevice
${pkgs.parted}/bin/partprobe
${pkgs.bcachefs-tools}/bin/bcachefs device resize $rootPart
# Prevents this from running on later boots.
rm -f /disko-first-boot
fi
'';
disko = {
extraPostVM = ''
${pkgs.zstd}/bin/zstd --compress $out/*raw
rm $out/*raw
'';
devices = {
disk = {
disk1 = {
imageSize = "10G";
type = "disk";
device = "/dev/mmcblk0";
postCreateHook = ''
lsblk
sgdisk -A 1:set:2 /dev/vda
'';
content = {
type = "gpt";
partitions = {
firmware = {
size = "30M";
type = "EF00";
content = {
type = "filesystem";
format = "vfat";
mountpoint = "/firmware";
postMountHook = toString (pkgs.writeScript "postMountHook.sh" ''
(cd ${pkgs.raspberrypifw}/share/raspberrypi/boot && cp bootcode.bin fixup*.dat start*.elf *.dtb /mnt/firmware/)
cp ${pkgs.ubootRaspberryPi4_64bit}/u-boot.bin /mnt/firmware/u-boot-rpi4.bin
cp ${configTxt} /mnt/firmware/config.txt
'');
};
};
boot = {
size = "100M";
content = {
type = "filesystem";
format = "ext4";
mountpoint = "/boot";
};
};
root = {
name = "root";
size = "100%";
content = {
type = "filesystem";
format = "bcachefs";
mountpoint = "/";
postMountHook = toString (pkgs.writeScript "postMountHook.sh" ''
touch /mnt/disko-first-boot
'');
};
};
};
};
};
};
};
};
}
| 17:54:46 |
matthewcroughan | hmm.. disko won't quite work for riscv due to its architecture, will it? | 18:37:30 |
matthewcroughan | This same problem would be solved by running the vmTools on the hostPlatform, and allowing it to do binfmt, instead of treating the VM performing the disk partitioning/formatting as something that needs to run on the native platform | 18:38:17 |
matthewcroughan | * This same problem would be solved by running the vmTools on the hostPlatform, and allowing it to do binfmt, instead of treating the VM performing the disk partitioning/formatting as something that needs to run on the system arch of the nixosConfig | 18:38:37 |
matthewcroughan | My next project was going to be making images for visionfivev1/2 | 18:42:05 |
matthewcroughan | * My next project was going to be making images for visionfivev1/2 that boot with bcachefs too | 18:42:13 |
matthewcroughan | Is this perhaps another way that disko's architecture fails because of the hostPlatform issue?
corpo-disko-images> qemu-system-aarch64: could not load kernel '/nix/store/fqwx7jpif67dzqhiggnnj69nhch8jp23-kernel-modules/vmlinuz.efi'
error: build of '/nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv' on 'ssh-ng://matthewcroughan@aarch64.nixos.community' failed: builder for '/nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv' failed with exit code 1;
last 2 log lines:
> unable to handle EFI zboot image with "zstd22" compression
> qemu-system-aarch64: could not load kernel '/nix/store/fqwx7jpif67dzqhiggnnj69nhch8jp23-kernel-modules/vmlinuz.efi'
For full logs, run 'nix log /nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv'.
| 20:51:22 |
matthewcroughan | Why does disko care? | 20:51:25 |
matthewcroughan | disko is trying to load the kernel from my nixosConfig, but why? That should only be relevant for an installTest if anything | 20:53:51 |
matthewcroughan | Yes.. inheriting the kernel from the host is not quite right https://github.com/nix-community/disko/blob/master/lib/make-disk-image.nix#L13 | 21:11:43 |
matthewcroughan | https://github.com/qemu/qemu/blob/master/hw/core/loader.c#L924 | 21:18:14 |
matthewcroughan | Anything other than a gzipped kernel is not supported in QEMU | 21:18:31 |
matthewcroughan | FFFFFFFFFFFFFF | 21:18:34 |
matthewcroughan | Although it does highlight that disko shouldn't be using the target kernel, just to make the disk image for the target | 21:19:38 |
matthewcroughan | It was me who implemented that though, so I should feel bad | 21:44:38 |
matthewcroughan | https://github.com/nix-community/disko/pull/467 | 21:44:53 |
matthewcroughan | The solution is uefi, but is there a use case for not using UEFI? | 22:05:38 |
matthewcroughan | I can make the PR, but wondering if I should make it boolean | 22:06:10 |
| 20 May 2024 |
matthewcroughan | https://github.com/nix-community/disko/pull/643 | 08:46:42 |
matthewcroughan | Closer to finding memory leaks.. | 09:34:35 |
matthewcroughan | I switched to systemd-boot from generic-extlinux, and now I'm getting the "Cannot allocate memory" all the time | 09:34:50 |
matthewcroughan | increasing memory to 16384 fixed it | 09:40:09 |
matthewcroughan | corpo-disko-images> setting up /etc...
corpo-disko-images> Initializing machine ID from random generator.
corpo-disko-images> File system "/boot" is not a FAT EFI System Partition (ESP) file system.
corpo-disko-images> Traceback (most recent call last):
corpo-disko-images> File "/nix/store/hk9khalas7ig9lpd8xygb00jgx9kjv2d-4d4f3f52hgwgk63d4fjg1rj4c1jdg9mn-systemd-boot", line 394, in <module>
corpo-disko-images> main()
corpo-disko-images> File "/nix/store/hk9khalas7ig9lpd8xygb00jgx9kjv2d-4d4f3f52hgwgk63d4fjg1rj4c1jdg9mn-systemd-boot", line 377, in main
corpo-disko-images> install_bootloader(args)
corpo-disko-images> File "/nix/store/hk9khalas7ig9lpd8xygb00jgx9kjv2d-4d4f3f52hgwgk63d4fjg1rj4c1jdg9mn-systemd-boot", line 292, in install_bootloader
corpo-disko-images> subprocess.check_call([f"{SYSTEMD}/bin/bootctl", f"--esp-path={EFI_SYS_MOUNT_POINT}"] + bootctl_flags + ["install"])
corpo-disko-images> File "/nix/store/vbfsfi87f7ks3hndbvn72n4334f9xll0-python3-3.11.9/lib/python3.11/subprocess.py", line 413, in check_call
corpo-disko-images> raise CalledProcessError(retcode, cmd)
corpo-disko-images> subprocess.CalledProcessError: Command '['/nix/store/wh5wyrs4nxdx7kh3ip0psn11rc2kknl1-systemd-255.4/bin/bootctl', '--esp-path=/boot', '--no-variables', 'install']' returned non-zero exit status 1.
| 09:40:12 |
matthewcroughan | And then I see this for the first time, which is good. It warns me that my FS hasn't got the right type | 09:40:38 |
matthewcroughan | but this part of the build never arrives unless I increase the memory size | 09:40:51 |
matthewcroughan | though the "Cannot allocate memory" errors come from cp.. actually. | 09:41:18 |