.
ATM, there is no Bluetooth support in Stage 1. To unlock a LUKS encrypted HD for Booting, one has to attach a keyboard the traditional way, e.g. via PS/2, USB, proprietary Dongle…
So, what I’m looking for is some config.boot.initrd setting that adds the required modules, sets up the service to load before the LUKS prompt appears and also accepts some Bluetooth pairing info to copy into the initrd.
Alas, such mundane tasks are way beyond my current Nix skill level, but I’m open to team up with someone to tackle this after 22.05 has landed.
Disclaimer:
Having someone sniff the password from the Bluetooth connection is outside my thread model (at least for the machines, where I want this to work ;))
This seems like it falls well within the recently added systemd-based init. It might even be in the task list for that already.
What exactly are you looking for in terms of someone to team up with? Was adding this to the learning category intentional?
This does sound like fun, I’ve been meaning to find something to actually help with upstream, especially around the init because I want to understand it better. But then as always and like every programmer I feel like I lack time in the near term…
Yes, adding to the learning category was intentional as I thought it is the most fitting one.
About teaming up: I’m willing to test and probably can experiment with smaller changes (e.g. getting in the Bluetooth pairing info) by myself, but I need someone else to put in the basic stuff first.
I’ve noticed an increasing amount of requests to put new stuff into the initrd: networking, then systemd, openssh, now bluetooth.
I wonder, does stage1 still make sense at this point? I mean, why bother encrypting /nix if you’re going to copy half of it into the bootloader partition, anyway? Or am I missing something?
Yes, how would I do that? I didn’t find the .nix config receipt specifically for Bluetooth pairing keys in the docs, maybe some common approach would work here?
Are you trying to manage bluetooth associations from the NixOS configuration? If so, there’s no way to do that: pairing a device requires interaction and involves exchanging secrets that are different each time, so you can’t possible do that declatively.
Still, there’s real demand - I don’t want to repair all my BT devices on every reinstall, so prefer to keep the secrets between.
What is my best bet to solve it?
I would say it doesn’t actually differ from WiFi password restoration procedure, per se. That one supported declaratively I suppose?
From a user perspective, maybe: but the protocols don’t work the same way.
Yes, typical WiFi networks use a pre-shared key: you put that into your configuration and you’re done; but Bluetooth connections don’t. On pairing both devices derive a random key using a Diffie Hellman scheme: if you want to preserve the pairing you need to back up that key.
Ok, but it would drastically reduce the usability of the system restore procedure, as it includes manual steps now, isn’t it?
Well, unless you’re trying to build an embedded device you must have some state to manage yourself. DHCP leases, audio controls, bootloader, ssh host keys, printers, and… bluetooth pairings, yes.
I suppose you also have some files in your home directory. Don’t you back them up when reinstalling the OS?
Not per-se, you just treat that directory like data you want to restore from a backup. Use any backup tool with a restore feature, and call that from your installation script.
It’s just impossible to do bluetooth fully declaratively, unfortunately, for the reasons @rnhmjoj outlines.
Note that this will still not set up anything declaratively, you’re still in charge of maintaining backups yourself, and that will be manual unless you have a proper process for it. It does make it easier, but is fundamentally just a strategy for managing state, nothing magic.