| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When chomping the cache set UUID introduced in
6ae9056a5a82dd16b745188a7ee6122ed27239f0, this actually has brought a
bug to surface, because when the UUID wasn't chomped the cache device
hasn't been attached at all, because the resulting command looked like
this:
echo f994bcca-8e52-4b54-9c96-5f5af0711b55
> /sys/block/$bcache1/bcache/attach
Yes, that's a newline after the echo, so it's just echoing the UUID and
then writes *nothing* into /sys/block/$bcache1/bcache/attach.
Chomping the UUID now results in an error, because the attach is made
directly after creating the device.
So all we need to do here is wait until the cache device was registered
and then do the attach.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
This is just a minor nitpick and doesn't actually change a lot in
functionality, but I chomped all the other occasions, so let's be
consistent here as well.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
Since I got a new SSD for the machine (thanks @cvdnext), I also had the
opportunity to re-create my LUKS containers to LUKS2 with Argon2 key
derivation alongside creating bcache backing devices.
The change in order to support bcache is just a matter of adding
"bcache" to availableKernelModules and we're done.
However, as the storage configuration is not a very common one, I
decided to add a test specific to that to make sure future NixOS updates
won't prevent the machine from booting.
Signed-off-by: aszlig <aszlig@nix.build>
|