LinuxQuestions.org - Bootloader Erased After Suspend to RAM

- Linux - Laptop and Netbook (https://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/)

- - Bootloader Erased After Suspend to RAM (https://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/bootloader-erased-after-suspend-to-ram-4175447800/)

Bootloader Erased After Suspend to RAM

This thread is related to this thread. I can't figure out why Mandriva, Mageia, Mint and Fedora destroyed the bootloader after suspending to RAM. Each distro was tested after installed on my netbook via suspend to RAM menu on KDE.

My netbook is an ASUS 1215B with AMD E350 APU which the spec you can see here.

Everything works just fine after wake up from sleeping mode except that after rebooting I always found that the bootlader was erased. I got "_" blinking on the upper-left corner of the screen.

I have to reinstall GRUB via live USB to fix this.

It is (extraordinarily) unlikely the Linuxen are doing this.
Check your BIOS for a "Virus Protection" option that may be getting in the way. Dell laptops have some "handy" Windoze tools that protect you and have this effect - only when run unannounced from Windoze tho'.

Linuxen? I've never heard anything about that. Can you explain me what is Linuxen?

Okay, I've searched through my BIOS settings but there is not something like "Virus Protection" exists.

Could you verify if anything actually gets changed on the MBR and/or /boot partition while suspending? Do a binary compare before and after suspend.

Quote:

Originally Posted by displace (Post 4880514)

Could you verify if anything actually gets changed on the MBR and/or /boot partition while suspending? Do a binary compare before and after suspend.

How could I verify that? Sorry, but I'm a noob.

What exactly did you mean that GRUB disappears / gets erased? Did you mean that the screen becomes black and doesn't show the bootloader screen on reboot? That does not necessarily mean your entire boot loader is gone. It's still strange that you get a black screen. And this only happens after you suspend, not poweroff/reboot normally without suspending?

What is the partition layout for your setup? In a terminal type "fdisk -l" and print the output here. Do you have a swap partition? What is the amount of your RAM?

You can calculate a hash for any file (or partition while logged in as root - in linux a partition is a file!). Assuming your /boot files are on a separate partition you can do "shasum /dev/sda1" inside a root terminal. This should print something like:

a57ab8c4f4c7800b3ab649eee3200419794a2f13 /dev/sda1

Do it before and after suspending. Compare both numbers - they must be identical. If not then something has been modified for sure!

Quote:

Originally Posted by displace (Post 4880814)

Yeah. It's only after a suspend to RAM. I thought the bootloader was erased because it was restored after I reinstalled GRUB.

This is fdisk -l output.

Code:

Disk /dev/sda: 320.1 GB, 320072933376 bytes

255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0xbe28290d



  Device Boot      Start        End      Blocks  Id  System

/dev/sda1  *        2048    2099199    1048576    7  HPFS/NTFS/exFAT

/dev/sda2        2099200  535330815  266615808    7  HPFS/NTFS/exFAT

/dev/sda3      535332861  625137659    44902399+  f  W95 Ext'd (LBA)

/dev/sda5      535332864  575978444    20322790+  83  Linux

/dev/sda6      575985664  584364374    4189355+  82  Linux swap / Solaris

/dev/sda7      584368128  625137659    20384766  83  Linux

Yes, I have a swap partition for about the same amount of my actual RAM.

Code:

            total      used      free    shared    buffers    cached

Mem:      3647076    3504472    142604          0    2383236    255560

-/+ buffers/cache:    865676    2781400

Swap:      4189348        44    4189304

The 'current' hash of my Linux root. I don't have /boot in another partition.

Code:

f322f3215a6f08f18a830d737d1f78e5dfd856b3 /dev/sda5

This is the hash of my Linux root after suspending.

Code:

d95fbd674a44acd0126d01cf82fc42bff4efb605 /dev/sda5

It's changed.

The root hash isn't going to do here because it hashes the entire root partition. The files on root partition are bound to change over time - take the /var/log folder for example where the logs can change every minute. I see you're dual-booting linux and windows.

If your /boot is not on another partition then you can do this instead:

tar -cf - /boot | shasum

You might also want to check the first 2047 sectors (including MBR) that reside on your HDD before the 1st partition:

dd if=/dev/sda of=/root/sectors.tmp bs=512 count=2047
shasum /root/sectors.tmp

Exercise caution when using the "dd" as the root account because you can easily erase your MBR, if you're not careful!

~dis

Some new bios's do an odd deal where you can only return to the saved OS if you hibernate. It may be that some issue is going on there.

It also might even be some oddity of overlapping partitions.

Swap has to be (I forget how much) more than ram but use some factor more.

Quote:

Originally Posted by displace (Post 4880856)

I've tried your command and nothing was changed after suspending to RAM.

Strange. And you say this happens after rebooting, but only if you suspend to ram before rebooting? Does it happen if you reboot without suspending to ram? The only other thing I can imagine is that something changes when you poweroff/reboot. Could you repeat the process to get the black screen at boot again? Then when the "grub disappears", boot to a rescue system and do the hashing from there. Hashing the first 2047 sectors should be the same as above, but you will need to mount the main partition to hash the /boot folder. I hope you still have the old HASH numbers somewhere!

cd /mnt
mkdir disk
mount /dev/sda5 /mnt/disk
tar -cf - /mnt/disk/boot | shasum
umount /mnt/disk

If this doesn't show any changes then there must be a hardware/firmware problem somewhere. Likely with BIOS.

Quote:

Originally Posted by displace (Post 4881118)

Okay, thanks! I'll try it soon.

Yeah, it's not "being erased". I've tried to suspend to RAM and then reinstalled GRUB immediately, rebooted and still got "_" blinking on the top-left corner.

Even more surprising is that after I booted to Debian Live, Mageia Installer without doing anything and then rebooting, I could get into my installed Mageia in sda5.

I haven't done that shasum thing.

edit: I have tried it and the hash wasn't changed.

Does the black screen only happen when you suspend? Does it happen, if you install Mageia and reboot a couple of times without suspending to ram? I see that the boot loader remains unchanged, so there's little point in reinstalling grub2.

This blank screen never occurred before the day I started to suspend my system.