Having figured out how to put the PC into Suspend mode overnight via Task Scheduler, c/o KDE forums, this morning I woke to find it had killed my Ethernet connection, so shut down the PC and cold booted and watched the Ethernet connection re-establish itself, via the router lights, only to find I booted straight into opensuse bypassing my Windows dual boot option.
No problem I thought just reinstall grub2 and it should be sorted, yes? No. So went through the boot recovery process you sometimes do, reinstalling grub2 etc, rebooted, and same again. Had a quick look in YaST Boot Loader section and it reads ‘Boot from Root Partition’ - now I can’t remember if that should read ‘Boot from MBR’ or not, I think it might do. Do it? What gives?
In short, when hibernating, Grub2’s default entry is set to the current system, so that you cannot boot a different operating system and access the hibernated partitions there (as this would lead to data loss).
But grub2 has no write support for btrfs and LVMs yet, so cannot reset that option, and keeps booting this entry directly then.
Suspending should not cause this though.
No problem I thought just reinstall grub2 and it should be sorted, yes? No. So went through the boot recovery process you sometimes do, reinstalling grub2 etc, rebooted, and same again. Had a quick look in YaST Boot Loader section and it reads ‘Boot from Root Partition’ - now I can’t remember if that should read ‘Boot from MBR’ or not, I think it might do. Do it? What gives?
Remove the file /boot/grub2/grubenv.
Re-installing the boot loader is not necessary in this case, and won’t help either (as you noticed already).
Yep, you got it, it’s the first time I’ve tried BTRFS as my default, I’d heard good things about overall stability , etc, so am trying it. Thanks for the explanation, now I know. I didn’t know whether suspending had anything to do with it or not, just seemed coincidental. I’ll go and delete this grubenv file and report back. Thanks.
I used it as well on a fresh 13.1 installation I did in November, and it does work reliable and stable.
I only encountered two issues up to now:
the mentioned problem with grub2 (which is not really a btrfs issue per se of course). Btw, this also happens when you choose a specific entry to boot in KDE’s reboot menu. Bad if you choose Windows there, as you would need a Boot CD/DVD to get back into your Linux system then! (as Windows can’t access the btrfs partition either)
disk full errors although there are Gigabytes free. This is caused by the automatic creation of snapshots, which are ignored by tools like “df”. Deleting snapshots is easy enough (especially with YaST), but someone who doesn’t know about that feature (and that the space taken up by the snapshots is shown as free) would be extremely confused and wouldn’t know where to look for the problem.
There is a cronjob set up to automatically clean out the snapshots, but that doesn’t seem to work as it should. OTOH, since I deleted all snapshots in February (when I started to have the problem everytime when installing updates), I didn’t encounter it any more.
Is there a simple way I can auto-execute kdesu rm /boot/grub2/grubenv straight after I come out of suspend (actually using hybrid-sleep) ? I tried one of the workarounds mentioned in the bugzilla report but it did nothing.
I remember in Windows Task Scheduler, years ago, I did something similar only it was a timer and it automatically rebooted the machine after suspend.
You could put a script to /etc/pm/sleep.d/ (the exact name doesn’t matter), that looks like this:
#!/bin/sh
case "$1" in
thaw|resume)
rm -f /boot/grub2/grubenv
;;
esac
No need for “kdesu” or similar as this is run as root anyway.
But that script has to be owned by root and has to have the executable bit set. So create it like this f.e.:
Or remove /usr/lib/pm-utils/sleep.d/99Zgrub, that is the script that sets the default boot entry when hibernating.
Although I had a look now, and it should actually remove /boot/grub2/grubenv itself AFAICS. No idea why it doesn’t work then… I guess I have to investigate this.
That script would be re-created of course whenever there would be an update to pm-utils. You could also just uninstall pm-utils and prevent the problem that way, it shouldn’t really be needed nowadays but I’m not sure.
You could of course also just create some cronjob that removes that file regularly, but I suppose that pm script above is the best way, as it only gets called when you actually suspend or hibernate…
LOL. I looked at the option in TS to execute the command every minute, etc. And thought, hummmm, bit sledgehammer to crack a walnut. Must be a cleaner way.
I’ll shove that script file in sleep.d tonight and see what happens tomorrow. Thanks again for the help btw.
I managed to fix that /usr/lib/pm-utils/sleep.d/99Zgrub script…
It was a quite silly mistake really:
The script is designed to handle both grub1 and grub2, therefore it has a function named “prepare-parameters()” that checks whether grub1 or grub2 is in use and sets up some environment variables with things like the exact commands to run or in which file the default boot entry is stored f.e. (/boot/grub2/grubenv in our case).
On hibernate, this function is correctly called, and everything works as expected.
But on resume, when the script gets called fresh again, this function is not called, so those env vars are empty. The script runs “rm -f $GRUBDEFAULT”, which ends up as “rm -f” then, which does nothing of course.
It just seemed to work with most other filesystems, because grub2 itself removes that default boot entry.
I suppose that’s why nobody noticed that bug in the script.
I will submit a fixed version to be released as online update, but as it’s quite late here now, I’ll wait till tomorrow.
If you get a delayed response it’s because it’s the Tour de France this weekend, and I’m a cyclist, it comes very close to where I live, so I keep jetting off on the closed roads to get a view, so apologies.
When I said I tried one of the work-arounds from the bugzilla thread it was the very last one I tried that didn’t work.
I commented out the load_env in /etc/grub.d/00_header as a workaround.
So I tried the script you gave me last night and have probably done something wrong…
#!/bin/sh
case "$1" in
thaw|resume)
kdesu kwrite /etc/pm/sleep.d/99rmgrubenv
sudo chmod +x /etc/pm/sleep.d/99rmgrubenv
;;
esac
because I put it in *etc/pm/sleep.d but it did not remove the Grubenv file when I checked (very) early this morning. *** But I’ve probably missed a step, or missed the point, or something. :\
You should type those lines in the terminal to create the script.
The script itself, i.e. what you type into kwrite, should be exactly as I posted before. I.e. instead of those two lines marked in red, there should just be “rm -f /boot/grub2/grubenv”.
No, you don’t have to remove the old pm-utils first, the new package will just update it.
You should remove that custom script in /etc/pm/sleep.d/ of course, as the point of the fixed pm-utils is to need need that script any more.
And you might have to manually remove /boot/grub2/grubenv once, as the fixed script will save and restore it if it exists already when you hibernate.
You could have some custom stuff in there, so the script does not just remove it.
It makes a backup and then sets the boot entry when hibernating. And it removes the file it created and restores the backup on resume.
Yes, it might be there, but that’s not relevant.
The point is that the boot entry is not set in that file.
So please remove /boot/grub2/grubenv manually (to be sure that it’s no old version setting a boot entry).
Then hibernate (or hybrid-sleep), and resume.
It should not matter now whether grubenv exists or not.
Reboot the system to see whether the grub menu shows or not.
With the old pm-utils the menu would not be shown, with the new it should be shown.
Yeah, I had to cold boot - but it works after that. What it’s done is introduce two very fast error messages during boot that weren’t there before and it’s introduced a 5 second (ish) delay till you get to the login. You think it’s not doing anything , but you do get there.
Could you please post those error messages? (maybe take a picture with a digital camera)
I doubt really that they are related to my change in the 99Zgrub script. That’s not even called during boot.
Or do you mean when resuming from hibernation?
It worked briefly, then I ended up with error: sparse… (could not make out the rest) and then I lost the dual boot again and limped the way through to opensuse desktop and deleted grubenv again. Rebooted and the dual boot is back working normally.
I have no doubt if I put it in hibernate again the grubenv file would stop the dual boot on reboot though.
You can of course put that script back to /etc/pm/sleep.d that removes /boot/grub2/grubenv, but I have no idea now whether I should submit my fix to the official packages (although I doubt that it is the cause).
