-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Automatic failing on-disk version downgrades with when accidentally mounting under older kernel version #782
Comments
Yeah, we don't have an ideal solution to this yet. Prompting the user would require making our mount helper able to prompt, and that would have a lot of integration work to do to (systemd etc) to make sure the user can respond. That is something we do need, because that's what I plan on doing for degraded mounts, but we're not there yet. And in the near future I'm hoping to not be doing any more automatic forced version upgrades. But there's still one more coming for some backpointers work - hopefully that's the last. |
Thanks @koverstreet (and thanks again for making bcachefs!) Makes sense that prompting user on mount is tricky. The thing that got me was it tried to do a forced disk version DOWNGRADE - and seems to have had trouble doing so. Doing forced upgrades makes sense, but forced downgrades on older kernel versions seems like a much more risky thing (to me). |
Well, what we really want to avoid is a user mounting on a new kernel and not realizing they can't go back. Downgrades shouldn't be risky, the upgrade/downgrade paths just run certain fsck passes; but we did have issues on 6.9 where the downgrade section wasn't being read correctly. Lots to do :) |
@koverstreet have you thought about getting |
This bug report is some just interesting behavior from me being a newbie and unintentionally rolling back kernel versions.
I think it would be helpful to show a warning message instead of automatically doing some kind of strange "upgrade/downgrade" of disk versions when mounted on an older kernel to avoid a bunch of weird issues that could come up with disparate versions of bcachefs kernel code and on-disk versions.
At the very least, the current behavior is rather confusing to a newbie. Fortunately The data on this disk is quite small and backed up, so I will probably reformat and continue from there.
What I Did:
The thing that's interesting is it appears to try to "upgrade" the bcachefs version (without fsck) FROM version 1.7 TO version 1.12! - That sounds more like an automatic version downgrade?
The next mount attempt it says a similar message but w incomplete:
doing fsck works and mounts the drive (see full logs below)
Then the next boot it fails again (without fsck) & doesn't seem to know about which version it is on and says it needs to downgrade from version 1.2
Again running with Fsck allows the drive to mount.
This all doesn't make much sense from a newbie user perspective - I don't really know what version my disks are on now, and doesn't inspire confidence if someone were to make the same mistake in the future. I will try mounting again on fedora 41 later today
Full Logs
Pervious Bootup (Fedora 40)
journalctl -b -1
Second Bootup (still fedora 40)
What I did:
What got logged: (dmesg)
my fstab
bcachefs show-super /dev/nvme0n1p4
The text was updated successfully, but these errors were encountered: