Warning: partition destroyed after hibernate, boot from other hdd, write to partition, resume

English Install/Boot/Login
1

I want to warn/bug-report/ask about how an ext3 partition got destroyed and the policy considered best to prevent it.

In 12.3 x64, root partition a, while some files were opened on partition x, I clicked hibernate and booted from another hdd, 12.3 x68. Some data written to, and even shrinked some % partition x. Then a while later, no more aware about hibernation, booted from partition a again, noticing resume and geany asking wether it should reload a textfile. I noticed the textfile data was lost, fsck x reported “partitiontable or superblock corrupted”, month work to recover partition x.

I suspect the resumed session writing to partition x having corrupted the superblock. I think that won’t happen to me again. I intend to edit the grub2menu-entry to not resume from disk in such a situation.

If a resume from disk really can destroy a partition, I suggest to developers to make OpenSUSE more foolproof with a function to prevent this issue. A brainstorm: if it is not already so, flush data to disk before hibernation; after resume from disk, reopen files or check for altered metadata, filepositions; or mark a grubmenu-entry “hibernated”, warn users for this issue and present an easier option to reboot without resume.

What do you guys and girls consider the best policy to prevent this happening to others?
Sofar my 2 cents.

2

My way of avoiding the corruption is to avoid hibernation.

The general rule is that if you hibernate a system, then when you next boot you should make sure that you boot the hibernated system. You seem to have not followed that principle.

3

hibernation uses swap any other use of swap during an instance in hibernation will cause problems. Never boot any other OS if your system is in hibernation

4

On 2014-09-22 17:16, nrickert wrote:
>
> InspireMe;2665784 Wrote:
>> I want to warn/bug-report/ask about how an ext3 partition got destroyed
>> and the policy considered best to prevent it.
>
> My way of avoiding the corruption is to avoid hibernation.

No, hibernation is fairly safe. I use it daily since years. But…

On 2014-09-22 17:06, InspireMe wrote:

> In 12.3 x64, root partition a, while some files were opened on partition
>> x, I clicked hibernate and booted from another hdd, 12.3 x68. Some data
>> written to, and even shrinked some % partition x. Then a while later, no
>> more aware about hibernation, booted from partition a again, noticing

…but that is a disaster procedure.

> The general rule is that if you hibernate a system, then when you next
> boot you should make sure that you boot the hibernated system. You seem
> to have not followed that principle.

Exactly. The way openSUSE does it, you can not boot anything else after
hibernating. Grub menu is disabled, and on a laptop the bios is told
about it so that the bios also disables the menu to choose boot media
(if the functionality for this works on that particular laptop).

So, the developers have done what they needed to do, but I guess that
the OP somehow circumvented this, managing to boot another partition.
Perhaps he has two grubs installed, or uses grub from another distribution.

Issue:

Hibernate a system. All the mounted partitions are “dirty”, with
structures and data still “in memory”. In this state, if you boot
another operating system that tries to mount one or more of those
partitions, the first things it does is run an fsck against them,
because they are in dirty state. And it can not know about the data that
was in memory: if it needs to, it clears sectors from files that were
not written yet. Then it mounts the partition, with possibly already
some lost files or contents, but “clean”.

When you try to boot the initial system, unless you clear out swap, it
will continue using the same partitions it was using. And I say “use”,
not “mount”, because they remain mounted as far as it knows. But instead
of being dirty, they were cleaned, and this system knows nothing about
that operation! It just writes things to HIS filesystem as if it was not
modified. It may write data blocks of files that are no longer there, or
worse, metadata for files that no longer matches the on-disk state!

The result can be total destruction of those filesystems.

I know all that, because I did it once. I repeat, /once/, and I learned.
Painfully. :-}

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

5

1st resume after hibernate is clear to me. Thanks.

I think, if rebooting a hibernated session gets obstructed by some (soft) damage, a repair with a boot from cd or external disk, should not contain an fsck without prevention of resume.

I have installed openSUSE, including GRUB, on both internal and external disk, to be able to boot openSUSE from external disk in the case that booting from the internal disk is not possible due to hard or soft damage.

6

On 2014-09-23 15:56, InspireMe wrote:
>
> 1st resume after hibernate is clear to me. Thanks.
>
> I think, if rebooting a hibernated session gets obstructed by some
> (soft) damage, a repair with a boot from cd or external disk, should
> not contain an fsck without prevention of resume.

If you use some automatic program that claims to repair your system,
then that may be true - but I don’t know of any such program. There was
one, a YaST module, years ago, but it was abandoned because nobody
volunteered to maintain it.

However, if you use fsck, the onus is on you, as administrator, to do
all the manual actions necessary. In this case, I would reformat swap,
because I don’t remember if there is a way to clear the information that
says that there is an hibernated image in there, and it is much faster
to reformat swap that investigating it :wink:

You probably also need to clear certain flag in grub, but I don’t
remember where it is. And in grub 2 I don’t know where it is, anyway.

> I have installed openSUSE, including GRUB, on both internal and external
> disk, to be able to boot openSUSE from external disk in the case that
> booting from the internal disk is not possible due to hard or soft
> damage.

Well, in this case, the onus is on you :slight_smile:

The kernel might check, on restore from hibernation, that the mounted
partitions have changed since the system was hibernated, and ask to
abort restore. You might suggest this feature to the kernel developers,
but I’m unsure how to do it. I’m not even sure if it is the kernel, or
pm-utils - and if it is the later, it is being deprecated, by systemd.

You can try here:
openSUSE:openfate

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

7

PS

besides openSUSE x64, also on internal disk openSUSE x86, with its own boot/grub2 folder and swap and home partition, without being aware of circumventing auto-resume and its destruction fate.
I just executed “grub2-install” from the now most used OS partition, so boot from internal disk will auto-resume after hibernation again.

8

when I wrote PS, I somehow had not seen above 2nd reply from you. Now I have. Thank you.