| 19 May 2024 |
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 |
matthewcroughan | The bootloader install is probably calling cp, | 09:41:38 |
matthewcroughan | * The bootloader install is probably calling cp | 09:41:40 |
matthewcroughan | corpo-disko-images> + /nix/store/gc39rhvazg28s7y80c4c0a24x3hsv92p-postMountHook.sh
corpo-disko-images> + rm -rf /tmp/tmp.qOc2Qrmj2x
corpo-disko-images> warning: the group 'nixbld' specified in 'build-users-group' does not exist
corpo-disko-images> cp: cannot access '/nix/store/flqdgxi79hgv69k8vc1rdcxvn30m0i3r-perl5.38.2-HTTP-Cookies-6.10': Cannot allocate memory
corpo-disko-images> cp: cannot access '/nix/store/fzh5aadrdl76f7cn930ls979x6cgblyd-libsoup-2.74.3/share/locale/gl/LC_MESSAGES': Cannot allocate memory
| 09:41:58 |
| 21 May 2024 |
| bumperboat changed their display name from bumperboat (UTC+8) to bumperboat (UTC+7). | 04:34:19 |
matthewcroughan | lassulus: any comments on https://github.com/nix-community/disko/pull/643 ? | 11:31:00 |
matthewcroughan | I didn't really think it's worth setting up a boolean, since it passes all the tests and I can't yet imagine a use-case where you'd want to disable EFI, especially given that legacy types are not supported in disko properly anymore | 11:31:46 |
| Tanja (she/her) joined the room. | 11:37:13 |
matthewcroughan | thanks for the merge :D | 11:42:14 |
| 22 May 2024 |
| zrsk joined the room. | 10:05:06 |
zrsk | I'm interested into trying bcachefs with encryption using disko and I saw that there is a PR which is blocked because it should an abstraction for supporting multiple devices should be implemented before. I also saw there is another PR for supporting subvolumes. Would a PR where I try to integrate both the attempts together be appreciated? In terms of interface would you like something similar to the first proposal in this comment?
disko.devices = {
disk = {
x = {
type = "disk";
device = "/dev/nvme0";
content = {
type = "gpt";
content = {
type = "bcachefs";
label = "ssd.ssd1";
pool = "rpool";
};
};
};
y = {
type = "disk";
device = "/dev/sda";
content = {
type = "bcachefs";
label = "hdd.hdd1";
pool = "rpool";
};
};
};
bcachefs_pool = {
rpool = {
type = "bcachefs_pool";
mountpoint = "/";
passwordFile = "secret.key";
subvolumes = {
"/home" = { };
"/nix" = { };
"/testpath" = { };
"/testpath/subdir" = { };
};
};
};
};
| 10:06:36 |
lassulus | I answered in nixos-anywhere, but I can also answer here | 10:16:49 |
lassulus | I was a bit busy, I wil try to fix the multi disk stuff in general at some point. But not sure when I will have the time for that. I guess we could merge the encryption part without the multidisk part. I have no idea about subvolumes, but a new PR could be a good idea, just remind me every now and then to look at it :) | 10:17:18 |
zrsk | In reply to @lassulus:lassul.us I answered in nixos-anywhere, but I can also answer here Oh I saw it too late, let's keep the discussion here then :) Frankly I'm not particularly interested into subvolumes, which to my understanding are useful only for snapshots. I can try to rebase the first PR and see if everything works if you want. | 10:28:31 |
zrsk | Nevermind, I don't think it can be easily rebased. It looks like in master you are using the filesystem type while the PR added a new custom type. | 10:31:16 |
zrsk | Probably one could get encryption by simply setting extraArgs = [ "--encrypted" ] | 10:32:15 |
zrsk | At least if you are interested into using a passphrase, I tried yesterday to imperatively format a disk with --encrypted and it interactively asked a passphrase | 10:34:15 |