| 30 Jan 2025 |
 eyJhb | * Yeah, I don't think I would be able to handle to upstream it to systemd. But maybe one could make a(n)/ issue for it. | 11:53:03 |
| eyJhb | * Yeah, I don't think I would be able to handle to upstream it to systemd. But maybe one could make a(n)? issue for it. | 11:53:07 |
| eyJhb | (keep in mind, this doesn't respect the current setup, at all, it would need to be modified) | 11:54:19 |
 ElvishJerricco | This is the sort of stuff I'm very hesitant about. The reason is a combination of this being a bespoke scheme that no one else in the world uses besides us and the fact that it's just a big pile of code that doesn't receive the same level of security review as upstream systemd. | 12:01:10 |
| ElvishJerricco | Like that's why I'm kinda unhappy with our clevis stuff. It'd be better if it was based on systemd credentials, just because systemd does handle those with quite a bit of care. But I tried to implement that a while ago and it was... a tad tricky so I haven't tried to finish it yet. | 12:03:36 |
| eyJhb | I fully understand that, and I have absolutely zero reason to push for the above. I'm happy if I can just run it myself. It's as you say, very niche | 12:10:31 |
 gdamjan | which one is it exactly? I think all that have GPG support have pkcs too? | 13:12:16 |
| eyJhb | Yes, they have pkcs support (AFAIK), but that can't be used in my setup, as I have more than 1 yubikey, which have identical GPG keys on them. So I can use any of them, to unlock my system | 13:13:37 |
| ElvishJerricco | You could enroll multiple key slots, one for each yubikey. Course that's rather inconvenient if you expect to be replacing yubikeys with new ones often | 13:16:12 |
| ElvishJerricco | but that seems like an unlikely concern eyJhb :P | 13:16:46 |
| eyJhb | Not often, but I don't want to forget about it, and be shit out of luck :D | 13:17:13 |
| eyJhb | It's all about your threat model, and in theory, mine should be "shits and giggles" | 13:17:38 |
 Rayane Nakib (ريّان نقيب) | Hello, I need help setting up impermanence with the option initrd.systemd.enable enabled, The option boot.initrd.PostDeviceCommands does not work. | 20:35:22 |
| Rayane Nakib (ريّان نقيب) | 
Download This is the config that I have right now, But it's giving me an error when I try to rebuild my system. | 20:35:34 |
| Rayane Nakib (ريّان نقيب) | 
Download This is the error that I am getting. | 20:35:48 |
| eyJhb | Rayane Nakib (ريان نقيب): have you seen this? https://discourse.nixos.org/t/devices-not-visable-using-initrd-systemd-with-btrfs/42871 | 20:39:59 |
| eyJhb | Or this https://www.reddit.com/r/NixOS/comments/1d3iwy0/rollback_script_for_luksencrypted_btrfs_system/ | 20:41:10 |
| eyJhb | But would be nice if impermanence updated that part of the readme, to be ready for systemd-initrd | 20:41:23 |
| Rayane Nakib (ريّان نقيب) | I don't have the service systemd-cryptsetup@enc.service in my system, Is it only available in the initrd? If so what does the enc stand for? | 20:44:47 |
| Rayane Nakib (ريّان نقيب) | 
Download I got this error before the prompt to type the LUKS password. | 21:03:51 |
| Rayane Nakib (ريّان نقيب) | 
Download This is my current config. | 21:04:34 |
| 31 Jan 2025 |
| ElvishJerricco | Is enc actually the name of your luks volume? | 00:10:46 |
 uep | I noted an issue on my test laptop the other day; didn't have time to look further yet. It has:
- rpool with native zfs encryption, prompted for passphrase during stage 1
- tpool, with native zfs encyption, prompted during stage 2 via extraPools
- plymouth (which is only used here and what i was testing last)
I hadn't used it in a while, and updated to current. The problem was that the second passphrase prompt with plymouth didn't get any keyboard input/focus/whatever. I suspect/assume it's something new with updated systemd, it worked fine before the upgrade. I got as far as confirming it also works normally if removing splash from the kernel boot commandline.
| 01:11:58 |
| uep | * I noted an issue on my test laptop the other day; didn't have time to look further yet. It has:
- rpool with native zfs encryption, prompted for passphrase during stage 1
- tpool, with native zfs encyption, prompted during stage 2 via extraPools
- plymouth (which is only used here and what i was testing last)
I hadn't used it in a while, and updated to current. The problem was that the second passphrase prompt with plymouth didn't get any keyboard input/focus/whatever. I suspect/assume it's something new with updated systemd, it worked fine before the upgrade. I got as far as confirming it also works normally if removing splash from the kernel boot commandline so there's no graphical plymouth overlay
| 01:13:10 |
| uep | Can potentially look further on the weekend. It will also have jumped from 6.6.x to 6.12.x in the same upgrade | 01:15:04 |
| uep | I'm not sure how easy it will be to separate those things since they all landed in the same staging merge IIUC | 01:16:05 |
| uep | * I noted an issue on my test laptop the other day; didn't have time to look further yet. It has:
- rpool with native zfs encryption, prompted for passphrase during stage 1
- tpool, with native zfs encyrption, prompted during stage 2 via extraPools
- plymouth (which is only used here and what i was testing last)
I hadn't used it in a while, and updated to current. The problem was that the second passphrase prompt with plymouth didn't get any keyboard input/focus/whatever. I suspect/assume it's something new with updated systemd, it worked fine before the upgrade. I got as far as confirming it also works normally if removing splash from the kernel boot commandline so there's no graphical plymouth overlay
| 01:17:36 |
| uep | * I noted an issue on my test laptop the other day; didn't have time to look further yet. It has:
- rpool with native zfs encryption, prompted for passphrase during stage 1
- tpool, with native zfs encryption, prompted during stage 2 via extraPools
- plymouth (which is only used here and what i was testing last)
I hadn't used it in a while, and updated to current. The problem was that the second passphrase prompt with plymouth didn't get any keyboard input/focus/whatever. I suspect/assume it's something new with updated systemd, it worked fine before the upgrade. I got as far as confirming it also works normally if removing splash from the kernel boot commandline so there's no graphical plymouth overlay
| 01:17:47 |
| Rayane Nakib (ريّان نقيب) | In reply to @elvishjerricco:matrix.org
Is enc actually the name of your luks volume? No, It's crypted, I fixed that issue. | 09:04:38 |
| Rayane Nakib (ريّان نقيب) | I got permission issues when trying to delete the root subvol, And I fixed them using this command chattr -i /btrfs_tmp/root/var/empty, But the initrd I got this error chattr: command not found, How can I remove the file /btrfs_tmp/root/var/empty in the initrd? | 09:37:21 |
