| 29 May 2023 |
 Winter (she/her) | cc ElvishJerricco -- happy to debug this, but not sure how :) everything looks okay from the configuration's end. | 18:08:30 |
 @elvishjerricco:matrix.org | Winter (she/her):
MACAddressPolicy=
persistent
If the hardware has a persistent MAC address, as most hardware should, and if it is used by the kernel, nothing is done. Otherwise, a new MAC address is generated which is guaranteed to be the same on every boot for the given machine and the given device, but which is otherwise random. This feature depends on ID_NET_NAME_* properties to exist for the link. On hardware where these properties are not set, the generation of a persistent MAC address will fail.
| 18:20:26 |
| @elvishjerricco:matrix.org | So if the hardware doesn't have a persistent MAC address, then udev probably generates a MAC address based on stuff like the machine-id or something, which we don't currently add to the initrd | 18:21:11 |
| @elvishjerricco:matrix.org | so without a machine-id, I bet it becomes random | 18:21:19 |
| @elvishjerricco:matrix.org | but | 18:21:21 |
| @elvishjerricco:matrix.org | My impression is that it's very odd if your hardware doesn't have a persistent MAC address | 18:21:36 |
| @elvishjerricco:matrix.org | so it should just be using that | 18:21:41 |
| Winter (she/her) | In reply to @elvishjerricco:matrix.org
My impression is that it's very odd if your hardware doesn't have a persistent MAC address it almost definitely does, yeah. | 18:26:18 |
| Winter (she/her) | In reply to @elvishjerricco:matrix.org
My impression is that it's very odd if your hardware doesn't have a persistent MAC address * it almost definitely does have one, yeah. | 18:26:43 |
| Winter (she/her) | especially since udhcpc uses a persistent one | 18:27:19 |
| Winter (she/her) | is this worth opening an issue about, so at least it's recorded? | 18:31:22 |
| Winter (she/her) | can't think of what the issue would be configuration-wise. | 18:31:29 |
| @elvishjerricco:matrix.org | Probably | 18:31:56 |
| @elvishjerricco:matrix.org | we should probably try to create a nixos test to reproduce the problem | 18:32:34 |
 @uep:matrix.org | "and if it is used by the kernel" seems like one possible path of investigation | 22:26:15 |
| 31 May 2023 |
|  Copa Dium joined the room. | 10:43:23 |
| Copa Dium | I'm not sure what I'm doing wrong, but since I switched to initrd.systemd.enable I don't get a password prompt when using ZFS on luks. The service is just waiting for 1m30 and then I get an emergency shell. Is there something I have to configure manually? | 10:45:34 |
 @lily:lily.flowers | In reply to @copadium:matrix.org
I'm not sure what I'm doing wrong, but since I switched to initrd.systemd.enable I don't get a password prompt when using ZFS on luks. The service is just waiting for 1m30 and then I get an emergency shell. Is there something I have to configure manually? How did you configure luks? Is your config publicly available on github or anything? | 10:46:46 |
| @lily:lily.flowers | (It should figure it out from the boot.initrd.luks settings, or whatever they are called) | 10:47:04 |
| Copa Dium | It's not public but I used disko to configure it. | 10:47:07 |
| @lily:lily.flowers | I meant nixos config for luks | 10:47:26 |
| Copa Dium | Yeah disko does that too, my boot.initrd.luks is defined | 10:48:24 |
| Copa Dium | Systemd also has a job waiting on the device, but there just is no prompt | 10:48:46 |
| Copa Dium | This is what disko generated:
nix-repl> myhost.config.boot.initrd.luks.devices.encryptedpool
{ allowDiscards = true; bypassWorkqueues = false; crypttabExtraOpts = [ ... ]; device = "/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_34163169-part3"; fallbackToPassword = false; fido2 = { ... }; gpgCard = null; header = null; keyFile = null; keyFileOffset = null; keyFileSize = null; keyFileTimeout = null; name = "enc-rpool"; postOpenCommands = ""; preLVM = true; preOpenCommands = ""; tryEmptyPassphrase = false; yubikey = null; }
| 10:50:14 |
| Copa Dium | * This is what disko generated:
nix-repl> myhost.config.boot.initrd.luks.devices.encryptedpool
{ allowDiscards = true; bypassWorkqueues = false; crypttabExtraOpts = [ ... ]; device = "/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_34163169-part3"; fallbackToPassword = false; fido2 = { ... }; gpgCard = null; header = null; keyFile = null; keyFileOffset = null; keyFileSize = null; keyFileTimeout = null; name = "encryptedpool"; postOpenCommands = ""; preLVM = true; preOpenCommands = ""; tryEmptyPassphrase = false; yubikey = null; }
| 10:50:33 |
| @lily:lily.flowers | Can you share the file at config.boot.initrd.systemd.contents."/etc/crypttab".source? | 10:51:38 |
| Copa Dium | Sure, it contains just this one line:
encryptedpool /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_34163169-part3 - discard
| 10:52:34 |
| @lily:lily.flowers | In the emergency shell does that device exist? (Are you missing availableKernelModules for initrd?) | 10:53:33 |
| Copa Dium | Uh I'm not sure, I assumed it existed since there was no error. One minute, I'll start the server again | 10:54:42 |
| Copa Dium | Now I'll have to wait for the timeout :D | 10:55:49 |
