bCacheFS as root that worked (and continues to work) on 23.11 fails on 24.05 #316396
Comments
|
Only when you take pictures with the intention of sharing do you realize how utterly filthy your display is. Rest assured that this will be rectified. |
|
Hi there, could you try running fsck from a nix iso using the latest nix run github:koverstreet/bcachefs-tools#bcachefs-tools -- helpThen boot in your generation with 24.05. |
|
Will do! |
|
Okay so after running the fsck, the system now boots, but it still has all those crashes during bootup. (The same ones in fact) |
|
Which specific ones? Please post new screenshots |
|
boot.log |
|
Looks like the disk version update from 1.3 to 1.7 has been completed successfully. That's why it required fsck and took long time to boot the first time. I would recommend changing the hardware-configuration.nix like this. That should fix the error reading supeblock bug. In addition, see if you can reproduce the boot errors with the latest bcachefs-tools from the repository itself. Should be pretty easy if you are using a flake based setup. First add it to your flake inputs. bcachefs-tools.url = "github:koverstreet/bcachefs-tools";Set up an overlay in configuration.nix: nixpkgs.overlays = [
(final: prev: {
bcachefs-tools = inputs.bcachefs-tools.packages.${pkgs.system}.bcachefs-tools;
})
]; |
|
I had to adapt it to work with my flake setup, but the result is the same. Building now. |
|
It did not like that. More details once I can extract them... If I can Edit: okay so that crash happened before it was able to write a boot log to disk. Gunna have to resort to screen pictures. FWIW It looked like a list of files, and then it told me the root account was locked. |
|
I also can't boot after updating to NixOS 24.05, although my error messages look a little different.
UPD: I managed to solve my problem after a lot of tweaks. It appears that the problem was with the device name in my |
|
|
|
Just so you're aware, if the worst does come to pass and my filesystem utterly dies, nothing of value will be lost. I have well tested backups. |
|
Is that systemd initrd? Could you disable that and just change the hardware configuration to use /dev/disk/by-uiid/ just like I did? Systemd initrd is problematic and it does not have full support of bcachefs yet |
|
Yes, I turned it on since the commit you linked did as well. I'll turn it off again and try again. 👍 |
|
Same errors so far (from before systemd initrd), though it did complain about insufficient devices to start before mounting. |
|
If you are experiencing this bug with the bcachefs-tools master branch overlay, I'd recommend reporting this upstream. CC: @tmuehlbacher |
JohnRTitor
added
0.kind: regression
Which details would be relevant to include in the upstream issue report? |
|
I'd assume boot logs, like you included here, fstab, your kernel version. And the output of |
|
Well, I was experimenting, and I can no longer update my system. Got any tips? |
|
Try with: sudo nix-store --verify --check-contents --repair |
No luck :\ |
|
That doesn't look too good. Not super sure about how to go about fixing this. The concrete error about not being able to do hardlinks between |
JohnRTitor
removed
the
0.kind: regression
JohnRTitor
added
2.status: wait-for-upstream
They are on the same drive, at least from the perspective of they're both on the same partition under the umbrella of bCache. |
|
Yes, and that is the reason systemd initrd could not mount both disks at once. Hopefully that fixes with the 256 update. |
|
My auxiliary HD with encrypted bcachefs fails to boot after the systemd 255.4 to 255.6, I don't know if it is the root cause. Jun 04 17:09:56 localhost systemd-cryptsetup[261]: Device contains ambiguous signatures, cannot auto-recover LUKS2. |
|
Oh, do you have bcachefs inside of a LUKS container or do you use the native encryption feature from bcachefs? Or do you use |
|
Just an update, I need this laptop to be working properly in the near future, so I will be formatting it later today. I hope that what has happened in this thread (and the resulting upstream issue) helps to correct such issues in the future. |
Describe the bug
https://gitea.krutonium.ca/Krutonium/NixOS/src/commit/8943c3814582f48318142712da56384057d6dec0/devices/uMsiLaptop-hw.nix#L17-L26
On 23.11 this worked just fine, the system (admittedly slowly) mounted the bCacheFS root filesystem and successfully booted. On 24.05, the system fails to mount the filesystem and then kernel panics. The filesystem is a 2 disk filesystem, one ssd and one hdd, with compression enabled.
Steps To Reproduce
Steps to reproduce the behavior:
Expected behavior
The system should boot as normal.
Screenshots
Additional context
I am using a 2 disk filesystem with the goal of having lots of fast storage. It's working fine, albeit with high memory usage, but after the upgrade it seems to fail to boot.
Notify maintainers
I don't honestly know who to notify here.
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"and paste the result.Add a 👍 reaction to issues you find important.
The text was updated successfully, but these errors were encountered: