|
Bugzilla – Full Text Bug Listing |
| Summary: | grub2-reboot sets default boot entry permanently | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Mihai Petracovici <petracvv> |
| Component: | Bootloader | Assignee: | Michael Chang <mchang> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | arvidjaar, coproscefalo, fabian, fcastelli, forgotten_2ZOw4Ks_yC, forgotten_5AjadAhsgi, forgotten_DV81ZEWZkN, forgotten_TljacLiSMA, jdd, lbeltrame, lmuelle, maintenance, mgriessmeier, nico.kruber, wbauer, wstephenson |
| Version: | 13.2 | ||
| Target Milestone: | 13.2 | ||
| Hardware: | Other | ||
| OS: | openSUSE 13.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Patch to fix restoration of boot entry on resume | ||
|
Description
Mihai Petracovici
2013-12-19 19:06:18 UTC
That's because grub2 can't clear the flag due to no write support to the file system and LVM/mdadm. Ah ok, I wasn't aware of that limitation in grub2. Thanks for pointing it out. I guess there really isn't anything I can do about it then. How does LVM/mdadm come into play here? I have now seen this on a system with btrfs /boot, lvm/mdraid is only on some data disks which have nothing to do with grub. If we can identify the cases where grub2-reboot cannot be used, we can suppress it in the kdm reboot dialog (In reply to comment #3) > > If we can identify the cases where grub2-reboot cannot be used, we can suppress > it in the kdm reboot dialog GRUB does not support - writing to non-physical disks (LVM, MD RAID, crypto) - blocklists (required to write environment file) on the following filesystems: afs, btrfs, exfat, HFS+ with compression, minix, squashfs, ufs2, zfs. So as long as /boot/grub2/grubenv file is located on any of these, grub2 cannot write into it. (In reply to comment #3) > If we can identify the cases where grub2-reboot cannot be used, we can suppress > it in the kdm reboot dialog It would not suffice to suppress this in the kdm reboot dialog. As I just noticed, the same issue happens when you hibernate your system, because /usr/lib/pm-utils/sleep.d/99Zgrub calls grub2-once to set the default boot entry to the hibernated Linux system, and that in turn also calls grub2-reboot to do the actual work. So if this is going to be suppressed, it should be done in grub2-reboot itself instead, I think. PS: Why is this bug report marked as INVALID? IMHO this is a valid issue. By choosing a Windows boot entry in KDE's restart dialog you effectively lock yourself out of your Linux system and need a LiveCD or similar to repair that. Shouldn't it be reopened? Or should I maybe open a new bug about the hibernate issue? (but it is the same in the end) Reopened as per comment#5. Please feel free to close again if you don't agree. A quick workaround is use boot script to reset this flag. Anyone here would oppose this ? (In reply to comment #7) > A quick workaround is use boot script to reset this flag. Anyone here would > oppose this ? That will work for suspend to disk only. For grub-reboot into Window this script never gets chance to run, because grub will always boot Windows without any timeout. I can think of - block grub-reboot for known cases. Only partial solution - missing functionality and does not help if user manually sets variable - support checking e.g. Pressed SHIFT on boot and display menu. Not sure what it involves and how portable it is. Of course, we still need to reset this flag after we managed to boot openSUSE. One more possibility is to not reset timeout to 0 if writing grubenv failed. This will leave user with menu that can be used to reboot into Linux. It has two problems - it is not obvious to user, why menu is displayed, and there was problem that GRUB highlighted wrong menu entry making it even more confusing (I believe it should be fixed in current master and hence in Factory). Unfortunately I do not see any real fix for it at all, at least using filesystem as a store. Anything would be just a workaround. A workaround is better than nothing. After I hibernate my triple-boot system, I don't have the boot menu anymore and have to rm /boot/grub2/grubenv. I commented out the load_env in /etc/grub.d/00_header as a workaround. *** Bug 849718 has been marked as a duplicate of this bug. *** I see the same with openSUSE 13.2 too (grub2-2.02~beta2-20.5.1). Created attachment 614972 [details] Patch to fix restoration of boot entry on resume I attached a patch to fix pm-utils' 99Zgrub to restore the boot menu on resume. This should fix the hibernate case when grub2 is used in combination with btrfs at least. @Maintenance team: Can I submit this as update? This is critical for 13.2 now IMHO, as btrfs is the default / filesystem and another pending update is going to restore the usage of pm-utils for hibernation if they are installed (which they are by default). Without this fix, people using a default 13.2 installation will loose their boot menu after every hibernation. See also the discussion in bug#904828. Wolfgang, feel free to submit. I'll combine your fix with the current systemd-update, see bnc#904828c#24. Thanks! (In reply to Benjamin Brunner from comment #14) > Wolfgang, feel free to submit. I'll combine your fix with the current > systemd-update, see bnc#904828c#24. Done: https://build.opensuse.org/request/show/263102 Submit Request for utilities (devel project for Factory) is here: https://build.opensuse.org/request/show/263073 *** Bug 907965 has been marked as a duplicate of this bug. *** Update released for openSUSE 13.2 - resolved fixed Also released for openSUSE 12.3 and 13.1 openSUSE-RU-2014:1563-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 856391 CVE References: Sources used: openSUSE 13.1 (src): pm-utils-1.4.1-33.9.1 openSUSE 12.3 (src): pm-utils-1.4.1-26.25.1 openSUSE-RU-2014:1570-1: An update that has two recommended fixes can now be installed. Category: recommended (important) Bug References: 856391,904828 CVE References: Sources used: openSUSE 13.2 (src): pm-utils-1.4.1-38.4.1, systemd-210-25.8.1, systemd-mini-210-25.8.1 Reopening, as the actual issue that this bug report is about is _not_ fixed. The update only fixed the workaround in pm-utils' hibernate/resume script, so there shouldn't be a problem any more when hibernating. grub2-reboot/grub2-once still set the default boot entry permanently on certain systems (btrfs most prominently) though, which also affects KDE's restart menu. *** Bug 911250 has been marked as a duplicate of this bug. *** I think this has been fixed in TW. Thanks. (In reply to Michael Chang from comment #23) > I think this has been fixed in TW. Yes, it has been. But what about 13.2? This also has btrfs as default filesystem, and even "worse", the KDE4 desktop and KDM (both still the default in 13.2) offer a prominent Reboot menu where you can select the grub entry to boot, which if you use it of course triggers this problem. I am using your packages from https://build.opensuse.org/package/show/home:michael-chang:sle-12-merge/grub2 since some months on a 13.2 btrfs system, and they work fine. So maybe it would be an option to release them as update? *** Bug 849060 has been marked as a duplicate of this bug. *** Version 13.2 bootup also produces the message "error: sparse file not allowed" which shortly disappears as booting continues without choices that used to be visible at this stage. Until recently, on my single-OS laptop installed with defaults (including for the filesystem) and kept evergreen, I got a screen with several choices, a picture of a lizard-top logo, and soon text lines with a mention of the specific kernel being used in booting. Now I just get the kernel lines. Speed seems unaffected. For a cause in how I use the laptop, perhaps it began after I (accidentally) let the battery run down because I forgot to plug the AC in. I know both the rundown and the lack of choices happened near each other in time, but I'm not sure that the latter began on the next bootup after the rundown. I never explicitly use sleep or hibernate modes but when a battery runs low the OS starts nagging me and maybe on rundown it automatically went into that mode. I have cold-rebooted a bunch of times without the boot menu coming back. I don't want to edit internal files and risk unwanted consequences I'm not geeky enough to figure out. I have the OS on a refurbished debranded laptop, formerly probably a HP 2000 notebook. For this bug report, I'm reopening and updating the version. I don't doubt a repair for an earlier version. Relevant, including technical discussions, are forum threads https://forums.opensuse.org/showthread.php/501545-13-2-RC-1-sparse-file on ver. 13.2, https://forums.opensuse.org/showthread.php/506811-Grub-message-quot-sparse-file-not-allowed-quot-and-continuing-in-recovery-mode on 64-bit ver. 13.2 about a year ago, and https://forums.opensuse.org/showthread.php/514241-Error-Sparse-files-not-allowed on Leap 42.1. My hardware is an AMD laptop; I'm not sure if that's of an x86-64 architecture. I suppose we can close this again. 13.2 is out of support meanwhile, and this is fixed in later versions. |