On Wed, Nov 05, 2025 at 08:09:03AM -0500, James Bottomley wrote: > On Wed, 2025-11-05 at 12:47 +0100, Christian Brauner wrote: > > On Thu, Oct 30, 2025 at 02:35:51PM +0100, Ard Biesheuvel wrote: > [...] > > > commit 0e4f9483959b785f65a36120bb0e4cf1407e492c > > > Author: Christian Brauner <[email protected]> > > > Date: Mon Mar 31 14:42:12 2025 +0200 > > > > > > efivarfs: support freeze/thaw > > > > > > actually broke James's implementation of the post-resume sync with > > > the underlying variable store. > > > > > > So I wonder what the point is of all this complexity if it does not > > > work for the use case where it is the most important, i.e., resume > > > from hibernation, where the system goes through an ordinary cold > > > boot and so the EFI variable store may have gotten out of sync with > > > the hibernated kernel's view of it. > > > > > > If no freeze/thaw support in the suspend/resume path is > > > forthcoming, would it be better to just revert that change? That > > > would badly conflict with your changes, though, so I'd like to > > > resolve this before > > > going further down this path. > > > > So first of all, this works. I've tested it extensively. If it > > doesn't work there's a regression. > > I haven't yet got around to finding the test image I used for this, but > I'll try to do that and get a test running this week. > > > And suspend/resume works just fine with freeze/thaw. See commit > > eacfbf74196f ("power: freeze filesystems during suspend/resume") > > which implements exactly that. > > > > The reason this didn't work for you is very likely: > > > > cat /sys/power/freeze_filesystems > > 0 > > > > which you must set to 1. > > Actually, no, that's not correct. The efivarfs freeze/thaw logic must > run unconditionally regardless of this setting to fix the systemd bug, > so all the variable resyncing is done in the thaw call, which isn't > conditioned on the above (or at least it shouldn't be).
It is conditioned on the above currently but we can certainly fix it easily to not be.
