| 26 Jan 2025 |
 Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | In reply to @iridium:faui2k11.de
Now, the interesting question is if there's any other code that would access mounted FSes during restart... But that definitely seems to be one of them. The fsck services tend to access file systems too, and I did have issues with those hanging too. But that is unrelated, was failed hardening attempts.
Depending on your setup, pam mounts might try to access file systems too - likely not a running session, but if you have unfortunate timing on a login using pam (e.g. ssh) then uhh that might explode? This might especially run into similar issues on an weird ldap based system where users have their home directories essentially as network drives
| 23:22:10 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | What I find surprising: by your findings, this is basically just systemd+unavailable file systems, how is this not a known bug upstream?? | 23:23:55 |
| 27 Jan 2025 |
|  @brisingr05:matrix.org joined the room. | 02:51:09 |
 iridium | Yes, some puzzle piece is missing still I think... I also remember once just stopping NetworkManager and trying out systemd daemon-reexec, which worked. | 07:44:33 |
| 29 Jan 2025 |
|  matthewcroughan changed their display name from matthewcroughan to matthewcroughan (already in Brussels). | 13:28:34 |
|  glelong joined the room. | 14:56:45 |
| glelong | I cannot find clear information online on status of boot counting integration, does someone know the current status ? | 14:58:26 |
 Ramses 🇵🇸 | AFAIK, there was a PR that got merged but it introduced some issues, because our boot entries have user-controlled identifiers in them (specialisation names) and that broke some assumptions of the code that parsed them. So the PR was reverted. I think there are ideas on how to introduce it again without hitting that issue, but no one actually implemented it yet | 16:16:08 |
| matthewcroughan | In reply to @rvdp:infosec.exchange
AFAIK, there was a PR that got merged but it introduced some issues, because our boot entries have user-controlled identifiers in them (specialisation names) and that broke some assumptions of the code that parsed them. So the PR was reverted. I think there are ideas on how to introduce it again without hitting that issue, but no one actually implemented it yet Why not just implement it and throw an exception if users are using specialisations? | 16:54:22 |
| matthewcroughan | Assertion | 16:54:37 |
| glelong | thank you ! | 17:47:05 |
| Ramses 🇵🇸 | In reply to @matthewcroughan:defenestrate.it
Why not just implement it and throw an exception if users are using specialisations? That doesn't sound like a very reasonable comprise to me. There's also no way to know how many users actually rely on specialisations | 19:52:17 |
| matthewcroughan | Sure, but at the same time boot counting is super nice. | 20:16:25 |
| matthewcroughan | And it could always be fixed later by a minimal PR | 20:16:36 |
| 30 Jan 2025 |
|  @kira:jakira.space joined the room. | 04:27:47 |
 eyJhb | When was it that systemd initrd would become the default in NixOS?? | 11:25:41 |
| eyJhb | * When was it that systemd initrd would become the default in NixOS? | 11:25:44 |
 K900 | We were hoping for 24.11 | 11:36:39 |
| K900 | But there's still a few weird bugs | 11:36:45 |
| K900 | @ElvishJerricco knows more | 11:36:48 |
 ElvishJerricco | I had been hoping to get it enabled by default on unstable very early in the 24.11 cycle, so that it would be in 25.05 with a fair amount of real world testing by the broader nixos-unstable userbase, but life has very much been in the way of me accomplishing that so far | 11:38:45 |
| ElvishJerricco | the main issue is that we don't have the ISO using it yet, because of highly obscure bugs that disproportionately affect the ISO (which I've been struggling to solve for a good while now) | 11:39:57 |
| ElvishJerricco | The other main thing is that LUKS devices often timeout waiting for a password when they shouldn't, which happens because nixos-generate-config does the wrong thing and uses the UUID link instead of the mapper link. | 11:41:02 |
| ElvishJerricco | there's a number of other very minor odds and ends, but nothing serious enough to be a blocker IIRC | 11:41:34 |
| eyJhb | Is there a tracking issue for all this? | 11:43:31 |
| eyJhb | I somewhat want to upstream my LUKS GPG smartcard module as well, so that we don't have to drop support for boot.initrd.luks.devices.<name>.gpgCard as well | 11:44:01 |
| ElvishJerricco | The main way I keep track of everything is in the github "project" https://github.com/orgs/NixOS/projects/66 | 11:44:48 |
| ElvishJerricco | though admittedly that doesn't track which ones I would consider blockers | 11:45:04 |
| ElvishJerricco | Aren't smartcards basically just a marketing term for pkcs#11? Because systemd-cryptenroll / systemd-cryptsetup do support pkcs#11 tokens | 11:46:05 |
| eyJhb | Yeah, I think we discussed this before. But basically, it's a Yubikey with a GPG key on it, so it won't enroll into cryptenroll | 11:47:43 |
