How to prevent Markov booting?

English Install/Boot/Login
1

Translation: How does one prevent grub2 from using “resume” during bootup?

I have two copies of SuSE 13.1 on two separate drives in one computer. Both use the same swap partition. Here is what happens. I boot SuSE from drive A. On exit, something apparently saves “resume” data in the swap partition. Next, I boot from drive B. After the boot is complete, I find that the SuSE on drive A is running. It is Markov in the sense that what actually boots depends on what was booted last, not on what partition is given boot control. I am looking for a way to get grub2 to actually give control to the partition whose boot sector I have booted, ignoring what may be in the swap partition.

I am using Terabyte Unlimited Boot-It Bare Metal (BiBM) to control the boot process. It transfers control directly to the partition I have selected. I specified “boot from /” when I installed SuSE, but it still put some code in the MBR. I replaced that by BiBM.

I have tried using the Yast “Boot Loader” tool to remove the “resume=” parameter, but it locks up when it tries to save the boot code. I am comfortable either using Yast or directly editing from a terminal. Can someone suggest a solution, or point me to documentation that might help? Thanks!

2

I’m not sure of this, but I think it will work.

Edit “/etc/default/grub” and change the “resume=string” to “noresume” (in the “GRUB_CMDLINE_LINUX_DEFAULT” line).

Edit “/etc/sysconfig/bootloader”, and make a similar change (to the “DEFAULT_APPEND” line).

Run


# mkinitrd

I think that fixes all references to “resume=”. I’m not sure if the “mkinitrd” is needed – perhaps running


# grub2-mkconfig -o /boot/grub2/grub.cfg

is sufficient.

You will probably need to do this on both systems.

3

Indeed, it works! Thanks very much for the help.

For anyone else reading this, there is another parameter, XEN_KERNEL_APPEND, in the bootloader file that you might want to similarly alter. I’m not using virtual machines on this computer, so it doesn’t matter to me.

The “grub2-mkconfig -o /boot/grub2/grub.cfg” was enough, and it had the additional benefit of identifying the other OSs that were accessible to the particular SuSE partition I was applying it to. mkconfig is smart enough to look at all the visible partitions and add the OS names to the boot options. For example:


Found Ubuntu 11.04 (11.04) on /dev/sda2
Found openSUSE 13.1 (x86_64) on /dev/sdb1
Found Scientific Linux release 6.3 (Carbon) on /dev/sdb2

This is the first time I have dealt with Grub2. You have convinced me it is a big improvement over the alternatives! Thanks again!

4

AFAIK /etc/sysconfig/bootloader is not respected by grub2.

But YaST->System->Boot Loader should work.
One guess:
Do you have a floppy drive?
If not, try to disable it in the BIOS settings.

It could try to access the floppy drive and seem to freeze because it’s not there…
You could also have this problem when installing updates.

5

That’s probably a bug of some kind – the left hand not knowing what the right hand is doing.

Here’s my situation:

I have a box where I use randomly encrypted swap.

When installing on that box, I tell the bootloader installer to set the default to “noresume”. That’s from the “Options” button in Yast installer, if I recall correctly.

The “noresume” does get into the default boot line in “/etc/default/grub”.

But then, when booting, I always see a message about unable to find resume file system. So the “noresume” in “/etc/default/grub” (as set by Yast) is not being honored.

I eventually tracked that down to “/etc/sysconfig/bootloader”, and the change there fixes the boot message.

And no, there’s no floppy drive here and the BIOS knows that there is no floppy drive.

It’s probably an inconsistency between what “Yast” uses and what “grub2-mkconfig” uses.

6

Maybe the grub2 maintainer(s) didn’t want to modify grub2 to respect the distribution-specific /etc/sysconfig setting?

When installing on that box, I tell the bootloader installer to set the default to “noresume”. That’s from the “Options” button in Yast installer, if I recall correctly.

The “noresume” does get into the default boot line in “/etc/default/grub”.

I just tried here. If I edit the boot options in YaST->System->Boot Loader->Boot Loader Options, they do get written to /etc/default/grub and /boot/grub2/grub.cfg (and not to /etc/sysconfig/bootloader).

But then, when booting, I always see a message about unable to find resume file system. So the “noresume” in “/etc/default/grub” (as set by Yast) is not being honored.

Of course it’s not. Grub2 only respects the configuration in /boot/grub2/grub.cfg.
You have to run ‘grub2-mkconfig -o /boot/grub2/grub.cfg’ to generate that from /etc/default/grub as stated in that file.
And YaST does call that.

I eventually tracked that down to “/etc/sysconfig/bootloader”, and the change there fixes the boot message.

Again, grub2 or grub2-mkconfig don’t care about /etc/sysconfig/bootloader.
Are you sure you are using grub2?
What’s “LOADER_TYPE” set to in /etc/sysconfig/bootloader?

And how did you change it? Changing that file alone doesn’t have any effect in any case.
If using YaST->/etc/sysconfig/ Editor the boot loader gets reinstalled automatically, so the settings in /etc/default/grub would have been applied then.

And no, there’s no floppy drive here and the BIOS knows that there is no floppy drive.

Then you’re lucky. :wink:

Some (many?) BIOSes tell the kernel there is a floppy drive although there isn’t, if it’s not explicitely disabled.
This can cause long “freezes” when trying to install the boot loader or when starting the installation. There are (still open) bug reports about that.

That’s why I suggested to the OP that he should have a look.

7

We might be talking past one another here.

I just booted the particular system. I’m pretty sure it has 13.1RC1 (installed date appears to be Oct 16th).

I’m not using Plymouth, so I see the messages scroll by while booting.

There’s a message, fairly early in the boot, which says (approximately):
" resume device not found (ignored)".

I can’t find that message in any logs at the moment. I’m not sure where it is coming from.

The boot line in grub.cfg says “noresume”
The line from “/etc/default/grub” is:


GRUB_CMDLINE_LINUX_DEFAULT=" noresume splash=silent quiet showopts"

The line from “/etc/sysconfig/bootloader” is:


DEFAULT_APPEND="resume=/dev/mapper/cr_swap splash=silent quiet showopts"

Experience from earlier (probably with Beta1) tells me that if I change that bootloader line to use “noresume” in places of the “resume=path” and run “mkinitrd”, then that boot message will disappear.

The “/etc/crypttab” line for the swap partition is


cr_swap         /dev/disk/by-id/ata-WDC_WD3200AAKS-75SBA0_WD-WCAPZ2050503-part8 /dev/urandom swap
8

Well, I just tried to change DEFAULT_APPEND in /etc/sysconfig/bootloader and run “grub2-mkconfig -o /boot/grub2/grub.cfg” (on 13.1 final).
The changes in bootloader did not show up in /boot/grub2/grub.cfg.
/etc/sysconfig/bootloader:

DEFAULT_APPEND="resume=/dev/sdb2 splash=silent quiet showopts wolfi"

/etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT=" resume=/dev/sdb2 splash=silent quiet showopts"

grub.cfg after running grub2-mkconfig:

                linux   /boot/vmlinuz-3.11.6-4-desktop root=UUID=e2c9b751-d87b-4dbd-b240-391e01dbd8cd   resume=/dev/sdb2 splash=silent quiet showopts

So only the stuff from /etc/default/grub is taken.

And I can’t find any mentioning of /etc/sysconfig in grub2-mkconfig (it’s just a shell script).

9

I just read this EMail: Re: [opensuse-factory] What script use /etc/sysconfig/bootloader : XEN_A

So actually /etc/sysconfig/bootloader is not used at all! (except for storing the bootloader type).
The kernel appends from there are only fallback defaults, when they cannot be determined otherwise.

10

Not sure if this is what is causing your resume problem, but have you tried this?

Choose Configure Desktop from the launcher menu,

Under System Administration group, choose Startup and Shutdown.

In there, choose the Session Management tab.

At the bottom section “On Login”, try selecting “Start with an empty session”

It might work, if it does, let us know. :question:

-fb

11

I doubt it.

KDE’s session management has absolutely nothing to do with the kernel’s hibernate and resume…

12

Right, but the original post said:

On exit, something apparently saves “resume” data in the swap partition.

So, deductive reasoning suggests the possibility of a stored session, or else shutting down with the Hibernate function instead of a full shutdown.

-fb

13

But KDE’s session management doesn’t write anything to the swap partition.
And has nothing to do with shutting down fully vs. hibernate.

If you hibernate or resume from hibernate, KDE’s session management is not even involved.
It only saves in your home directory which (graphical) applications are running when you logout, and restarts them on login.

14

Saved KDE session entries are in ~/.kde4/share/config/sessions
No way a desktop user should be able to change system matters. Which this is.

15

Okay, thank you.

That makes a lot more sense than it does in that other “operating” system…

In it, on Hibernate, the full state is written into a file (hiberfil.sys, I think it was called, or close to that).

There is no way then (I know of) that the machine can be booted into anything else – not with CD, DVD, USB boot device, or through a disk manager – except the hibernating system. I think (wasn’t important enough for me to investigate further, with the limited time I have for playing with such things) that other “o”/s manipulates the boot process then.

I am aware of that because of several dual-boot systems and boot CDs and USB boot devices I have worked with in the past.

I guess, another reason to celebrate the full migration to Linux. Thanks to my pleasant experience with OpenSUSE in the past couple of years, I know longer have any of my machines booting that other “o”/s, not even in a dual-boot situation.

And after 33 years of computing, mostly under that system, I don’t miss it one tiny bit!

-fb

16

???
It’s the same in Linux. On Hibernate the full state is written, not to a file, but to the swap partition (or swap file).
How else would you be able to restore the full state afterwards?

But, again, this has absolutely nothing to do with KDE’s session management (or even KDE at all), which only remembers which user applications are running over logout/login.

There’s no sense in comparing KDE’s session management with Windows’ Hibernate. They are completely different things.

There is no way then (I know of) that the machine can be booted into anything else – not with CD, DVD, USB boot device, or through a disk manager – except the hibernating system. I think (wasn’t important enough for me to investigate further, with the limited time I have for playing with such things) that other “o”/s manipulates the boot process then.

You should be able to boot from CD, DVD or USB, even with Windows’ Hibernate.
That’s a function of the BIOS. The OS isn’t involved with that.

No idea how the situation is with UEFI boot though.

Btw, if you hibernate Linux, you won’t get the boot menu either when you turn on your system again. Instead, Linux is resumed immediately (at least with grub2 and, I believe, grub legacy).

17

This I already know. And, I have examined the SWAP partition (swapoff) with a disk editor in the past to get an overview sense of the structure.

But, again, this has absolutely nothing to do with KDE’s session management (or even KDE at all), which only remembers which user applications are running over logout/login.

That I didn’t know, since I assumed that when operating in the KDE desktop, anything I had open or was working on was being at times fed back & forth from the SWAP partition, as needed. It then made sense, to me, that a stored session would also be saved there.

I never bothered looking further into it, because, as I said, I am too busy to have the pleasure of such explorations until they are required.

And that requirement has not presented itself, yet, in my endeavours.

Although, I had the sense that something more was being carried over in “resume session”, which is why I disengaged it on my machines.

There’s no sense in comparing KDE’s session management with Windows’ Hibernate. They are completely different things.

I did not actually do that, if you read again.

You should be able to boot from CD, DVD or USB, even with Windows’ Hibernate.

Try it in XP or newer.

Get back to me.

Btw, if you hibernate Linux, you won’t get the boot menu either when you turn on your system again. Instead, Linux is resumed immediately (at least with grub2 and, I believe, grub legacy).

Duh, really?

18

How do you think about to reactivate a corresponding feature request?

19

Although I was sure of my facts, I now even tried it out (with Windows XP).
And it is as I wrote.

You can boot just fine from an USB stick after you hibernated Windows.
And since Windows doesn’t know anything about grub, you will even get to the normal boot menu after you hibernated Windows, and can still boot your Linux system.

Maybe you mixed up Hibernate with Suspend (Standby)?
In the latter case, you can’t boot anything else of course, since the system is not shut down or boots when you turn it on again.
With Suspend the current state is kept in RAM with minimal power consumption.
But if you completely disconnect the power, all will be lost and you will do a normal boot again.

Then there’s of course hybrid suspend, which does both and will therefore even survive a power cut. But in that case we’re back to point 1 again, i.e. normal boot with boot menu.

Duh, really?

Yes, for quite some time already.

20

Well, I personally don’t care really, since I don’t use hibernate anyway.

But you’re free of course to reopen that feature request (not sure if that’s possible) or file a new one.
Or maybe use a different boot loader, LILO f.e. doesn’t have something like this AFAICS.

Or just remove the file /usr/lib/pm-utils/sleep.d/99Zgrub as hinted in that feature request, that’s what’s responsible for this feature.