| 19 May 2024 |
lassulus | hmm, resizing is not really delcarative? :D and not sure what the interface would look like | 14:46:11 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | systemd-repart has a really nice setup | 14:46:41 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) |
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 @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | This ended up being the final disko.nix for a pi to boot using bcachefs | 17:54:42 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | {
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 @ 39c3 (DECT 94667 or 97340 or 67192) | hmm.. disko won't quite work for riscv due to its architecture, will it? | 18:37:30 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | * 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 @ 39c3 (DECT 94667 or 97340 or 67192) | My next project was going to be making images for visionfivev1/2 | 18:42:05 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | * My next project was going to be making images for visionfivev1/2 that boot with bcachefs too | 18:42:13 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | Why does disko care? | 20:51:25 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | https://github.com/qemu/qemu/blob/master/hw/core/loader.c#L924 | 21:18:14 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Anything other than a gzipped kernel is not supported in QEMU | 21:18:31 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | FFFFFFFFFFFFFF | 21:18:34 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | It was me who implemented that though, so I should feel bad | 21:44:38 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | https://github.com/nix-community/disko/pull/467 | 21:44:53 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | The solution is uefi, but is there a use case for not using UEFI? | 22:05:38 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | I can make the PR, but wondering if I should make it boolean | 22:06:10 |
| 20 May 2024 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | https://github.com/nix-community/disko/pull/643 | 08:46:42 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | Closer to finding memory leaks.. | 09:34:35 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | I switched to systemd-boot from generic-extlinux, and now I'm getting the "Cannot allocate memory" all the time | 09:34:50 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | increasing memory to 16384 fixed it | 09:40:09 |
matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | but this part of the build never arrives unless I increase the memory size | 09:40:51 |