[opensuse-factory] DO NOT HIBERNATE on 13.2 (and Factory?), File sytem corruption.
Hi all, just as a warning for everyone, dracut is even more broken than I had imagined: https://bugzilla.suse.com/show_bug.cgi?id=906592 Do not hibernate if you don't like to corrupt your file systems. Good luck, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2014-11-21 15:26, Stefan Seyfried wrote:
Hi all,
just as a warning for everyone, dracut is even more broken than I had imagined: https://bugzilla.suse.com/show_bug.cgi?id=906592
Do not hibernate if you don't like to corrupt your file systems.
Uh, the bug report seems to mix up suspend (suspend to disk) and hibernate (suspend to ram). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 21 Nov 2014 17:22, Jan Engelhardt <jengelh@...> wrote:
On Friday 2014-11-21 15:26, Stefan Seyfried wrote:
Hi all,
just as a warning for everyone, dracut is even more broken than I had imagined: https://bugzilla.suse.com/show_bug.cgi?id=906592
Do not hibernate if you don't like to corrupt your file systems.
Uh, the bug report seems to mix up suspend (suspend to disk) and hibernate (suspend to ram).
Grrr, well, back on OSS 12.3 after a restore from backup. Tested, sadly confirmed, "suspend to disk" aka "hibernate" does not work, and shows exactly the behaviour from the bug. For "suspend to ram" aka "suspend", the wake up happens fast enough that the fs-check happens after the restore is complete. [sarcasm on] Praise be systemd for loosing the control over what happens, and when. [sarcasm off] IMHO, Dracut is not necessary the cause but also the victim here. Just which code in the startup starts the fs-check? And why is this code active during a "wakeup", that's reserved for a clean, full boot, isn't it? Initrd and SysV-Init may have been slower, but easier to debug. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2014-11-21 17:42, Yamaban wrote:
Do not hibernate if you don't like to corrupt your file systems.
Grrr, well, back on OSS 12.3 after a restore from backup.
For "suspend to ram" aka "suspend", the wake up happens fast enough that the fs-check happens after the restore is complete.
With s2r, there should not be any fsck call, because the filesystem remains mounted. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.11.2014 um 18:00 schrieb Jan Engelhardt:
With s2r, there should not be any fsck call, because the filesystem remains mounted.
The filesystem remains mounted with s2d, too, that's why there must not be a fsck during resume :-) The difference is: The kernel stays the same for s2r, there is no bootloader executed. The firmware (ACPI BIOS) just returns control to the kernel at the place where the kernel passed control to the firmware during suspend. Because parts of the machine had been powered off (CPU, peripherals, ... but *not* memory), the kernel needs to restore CPU state and reinitialize hardware, but then just continues. For s2d first another kernel is booted which then loads the image, overwrites itself with the kernel from the restored image and continues at the exact place where it had left off during suspend. It also has to restore CPU state and reinitialize hardware as in s2r case. S2disk was for a long time "easier", because even though you need to do some more stuff (save image, load image), you could count on the BIOS initializing stuff to a known state during the "resume boot", which was a big plus when drivers were *not* able to reinitialize hardware from scratch. Especially in the dark old times when we did not had KMS drivers and such. And when the BIOSes were buggy. Nowadays (funnily after Microsoft starting with Vista forced the vendors to ship not-so-broken BIOSes) with better BIOS support and better drives, s2r is often easier to do than s2d. Because since s2d is partly handled in userspace, and userspace hackers often are not kernel hackers and don't have to fear Linus' anger, the code is just so much more buggy :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.11.2014 um 17:42 schrieb Yamaban:
On Fri, 21 Nov 2014 17:22, Jan Engelhardt <jengelh@...> wrote:
On Friday 2014-11-21 15:26, Stefan Seyfried wrote:
just as a warning for everyone, dracut is even more broken than I had imagined: https://bugzilla.suse.com/show_bug.cgi?id=906592
Do not hibernate if you don't like to corrupt your file systems.
Grrr, well, back on OSS 12.3 after a restore from backup.
Tested, sadly confirmed, "suspend to disk" aka "hibernate" does not work, and shows exactly the behaviour from the bug.
For "suspend to ram" aka "suspend", the wake up happens fast enough that the fs-check happens after the restore is complete.
Suspend to ram never goes through grub / kernel load during resume, or it is not suspend to ram, so with suspend to ram, this issue can not happen. That's also the reason why I did not notice it at all during the last year of running factory: suspend to RAM is so reliable for me, that I never suspend to disk anymore. I just noticed because I got a bugreport against suspend, telling me to remove mkinitrd support, so I thought it would be good to first try if it works with dracut... well, it does not.
[sarcasm on] Praise be systemd for loosing the control over what happens, and when. [sarcasm off]
IMHO, Dracut is not necessary the cause but also the victim here.
I don't care. Suspend to disk worked with mkinitrd. Because the people who implemented it for mkinitrd cared for it and knew what they were doing.
Just which code in the startup starts the fs-check? And why is this code active during a "wakeup", that's reserved for a clean, full boot, isn't it?
I tried to find out but after two hours I just gave up and filed the bug.
Initrd and SysV-Init may have been slower, but easier to debug.
It was not slower. 13.2, which has all "fixed" for systemd takes much longer to boot than 13.1, which still had a legacy xdm init script. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.11.2014 um 17:22 schrieb Jan Engelhardt:
On Friday 2014-11-21 15:26, Stefan Seyfried wrote:
Hi all,
just as a warning for everyone, dracut is even more broken than I had imagined: https://bugzilla.suse.com/show_bug.cgi?id=906592
Do not hibernate if you don't like to corrupt your file systems.
Uh, the bug report seems to mix up suspend (suspend to disk) and hibernate (suspend to ram).
hibernate == suspend to disk suspend == suspend to ram. I know why I never liked this windows terminology, but the GNOME developers forced it onto the linux world also, because "suspend to ram is too technical, users will not understand" (I still remember the discussions from 10 years ago :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Jan Engelhardt -
Stefan Seyfried -
Yamaban