Grub 2 seems to be the default boot loader in OpenSUSE 12.2. The set up process scans all partitions and adds entries for all partitions that contain a working OS. Sounds nice? Not so nice if one has a multi boot machine with a Windows recovery partition like my HP laptop. These laptops come with four primary partitions all occupied by Windows. One of these is a recovery partition which can be used to reinstall Windows. It is not visible in Windows and it should not be used unless needed for recovery purposes.
I installed OpenSUSE by sacrificing one of the primary partitions. I turned it into an extended partition, readjusted partition sizes and recreated the original primary partition at the end of the extended partition. After installation of OpenSUSE my laptop boots from the extended partition, which is marked active in the partition table. Works fine until someone boots Windows recovery partition. In this case the boot process automatically marks the Windows boot partition active. This in effect hides the OpenSUSE installation. I have to boot the laptop from a USB stick or similar and put the active flag back to the extended partition. I might be careful enough not to boot from the recovery partition. Unfortunately experience show that other family members are not and they occasionally borrow the laptop.
So I am trying to find a sustainable way to remove the dangerous entry. I could edit the grub.cfg file, but it gets overwritten. I could also tamper with the scripts in grub.d but that does not sound a good idea either. And before anybody suggest using YAST, take note that it does not allow removing automatically discovered entries.
So, I don’t know of but two ways to do this. One is to remove the entry manually from the grub.cfg file, or to modify the ‘/etc/grub.d/30_os-prober’ file as root and as suggested in the following forum post (see #10):
What bothers me (not having used Grub2 nor 12.2 (r more days), is that you can say that you can not configure this through YaST.
When I interprete the above correctly, that is an omission and you remark “Grub2 implementation in OpenSUSE looks somewhat experimental still.” looks a bit like an understatement then.
Is this something to file as a feature whish, or maybe even as a bug?
The ability to skip over an unwanted Partition when the ‘/etc/grub.d/30_os-prober’ file is run seems like a feature we should request. You would do this to prevent a recovery or other Windows like partition from becoming a OS boot selection in grub 2 and it is something I would add to the /etc/default/grub file as a setting to be acted on by the os-prober bash script when it is run I think.
Sorry for not being clear enough. Everything I wrote is based on OpenSUSE 12.2. RC2. Grub2 was installed by default even when I updated from12.1. YAST still offers the choice of the bootloader to use. One can choose grub2, grub legacy or lilo and even have EFI bios support.
In the previous version of grub boot options where configured in the menu.lst file. YAST allowed editing entries in the file. In grup2 grub.cfg file should not be edited directly since it will be overwritten.
.
In principal automatic detection of additional OSs is a good thing. I think you can’t call YAST’s behaviour as a bug. Maybe one could miss additional features like a possibility to choose, which automatically detected entries to include in the menu or maybe automatic omission of Windows recovery partitions. Since I am not sure what to wish I don’t think I am going to file a wish.
The README.OpenSUSE file should be updated to reflect the fact that grub2 is now the default bootloader. Maybe it would also be in order to use the standard naming conventions for grub2 and to use something like grup1 for legacy grub. I leave this for others to judge.
woth
Well personally I would allow a YAST user to choose whether to include the the automatic entries in the menu. If the user chose not to include them all, I would allow him or her to pick and chose those entries to include. I would most likely implement this by first running the detection script in order to find out possible choices. I then would turn off the executable bit for the detection script and put the selected entries into an other script. Of course it would be nice to be able to add own entries in YAST as well. But for the time being I can survive with the more manual procedure.
Interesting thread. This makes us aware of how t to handle the coming Grub2. IMHO it is not alone about “dangerous” boot entries. As System Manager you want to be able to have your boot menu as you want it. I have e.g. either a new openSUSE level for test, or still the older version (fall back during the first days, but left there until the space is used for the testing of the new one in the cycle). And I might want to make it invisible for my users.
And as YaST is the system mangement tool of openSUSE, it “should” (but who am I) cater for the posibilities to handle at least things that we had. Editing the /etc/grub.d files directly is of course possible, but when you propagate that, then you can dismiss YaST at all.
Perhaps, though you did not say which version of Windows you are using.
I have tried booting that Windows recovery partition (for Windows 7). It boots windows just fine. When I boot windows that way
I see exactly the same Windows as if I boot from the primary Windows partition. The recovery partition is still not visible in Windows, even though I booted from it.
It is my understanding that the recovery partition is there, in part, to allow having the main Windows drive encrypted with the Windows BitLocker software.
In opensuse, I use an encrypted LVM. Booting is done via a separate “/boot” which is not encrypted. The windows arrangement with the recovery partition is similar. The recovery partition is not encrypted, so can be used for booting an encrypted windows partition. The boot code in the recovery partition can setup the crypto drivers, to allow access to the main partition.
I think, to boot in recovery mode, you have to hit F8 early in the boot (or something similar). You can’t get there by just booting the recovery partition.
As far as I know, the use of the recovery partition in Vista is similar.
After the forum post here about trying to skip a restore partition from the openSUSE Grub 2 OS selection menu, I have come up with a patch you can use to allow the skipping of any partition from the automatic menu generation. Below is a patch, to be applied to the file /etc/grub.d/30_os-prober as root. Save the following patch file (inside the code tags) as the text file I am calling “30_os-prober.patch”
--- /Software/grub/30_os-prober.org 2012-09-02 04:22:34.512661000 -0500
+++ /etc/grub.d/30_os-prober 2012-09-02 08:06:05.233988062 -0500
@@ -21,6 +21,11 @@
exec_prefix="/usr"
datarootdir="${prefix}/share"
+# Patch to prevent some partitions being autodetected. Add just the partition
+# name(s) like sda1 between quotes,leaving a space between if more than one.
+GRUB_SKIP_DEVICE=""
+# End of patch
+
export TEXTDOMAIN=grub2
export TEXTDOMAINDIR="${datarootdir}/locale"
@@ -113,6 +118,13 @@
LABEL="`echo ${OS} | cut -d ':' -f 3 | tr '^' ' '`"
BOOT="`echo ${OS} | cut -d ':' -f 4`"
+ # Patch to prevent some partitions being autodetected
+ PARTITIONNAME="`echo ${DEVICE} | cut -c 6- 2> /dev/null`"
+ if "`echo ${GRUB_SKIP_DEVICE} | grep -e ${PARTITIONNAME} 2> /dev/null`" ] ; then
+ continue
+ fi
+ # End of patch
+
if -z "${LONGNAME}" ] ; then
LONGNAME="${LABEL}"
fi
Lets assume you have saved in your $HOME/Documents folder using the name I used above. Once the file is saved, open up a terminal session and run the command:
Once the patch is applied, you can use my bash script grub2cmd to edit the newly patched file /etc/grub.d/30_os-prober and add the partition you want to skip. You could modify the following line like this:
GRUB_SKIP_DEVICE="sda1"
and save your modification. Next, you must run the Grub2Cmd option 3) Update grub.cfg Menu File , so your changes will take effect.
Now, when the 30_os-prober is run, it will skip the partition named /dev/sda1, placing no entry found for that partition in your grub 2 OS selection menu. It is possible if you get an update for the Grub 2 package, this update patch shown here will get over written. Just re-run the patch when required, and leave me a comment here if the patch no longer is working and I can make another.
Hmmm… That’s not the right way to do it. You should take a look at /usr/lib/os-probes/mounted/20microsoft to see how your version of os-prober identifies Windows partitions. I’m using version 1.53 (it’s in my repo). On a WIndows + openSUSE + Ubuntu machine here’s what I see when running os-prober from openSUSE:
# os-prober
No volume groups found
/dev/sda1:**Windows Recovery Environment **(loader):Windows:chain
/dev/sda2:Windows 7 (loader):Windows1:chain
/dev/sda6:Ubuntu 12.04.1 LTS (12.04):Ubuntu:linux
Now if you want os-prober to not create a boot entry for Windows RE, you should skip the partition which has the LONGNAME (or LABEL, not no sure right now) “Windows Recovery Environment” in 30_os-prober. But I think it’s not a good idea. There aren’t dangerous boot entries, just dangerous people who should not be allowed to boot computers.
Let me say that the ability to skip over a partition should be based on its device name, like sda1 and it then matters not what you want to skip over. I was unable to figure out how to add a value to the /etc/default/grub file to be read by the os-prober file. The value name I added would be in the environment, but not its value. I don’t know if the values you place in the /etc/default/grub (using the correct format) are limited to the ones already looked for by Grub 2 or not. It was kind of strange to find the Value name in the environment, but it did not retain the string value assigned to it in the grub file. Thus, I put it at the top of the 30_os-prober file. The option as I set it up, allows the os-prober to look for anything else and is the not the same as just disabling the os-prober entirely for which an option exists. The original quest was to stop a restore partition from being a grub 2 selection option, but imagine that you still want a Windows load option to appear. I am open to any other suggests in said modification of Grub 2.
No. I can not let you say that, James … Well, I can certainly let you say everything … but no!
Maybe. But that’s another problem. That you’re not able to do something is not an excuse to do it wrong. I know that’s the first reason that would come in people’s mind …, but no.
Well, I could do it but:
I can not help at the moment (I don’t have 12.2. I looked in Ubuntu’s 30_os-prober while running os-prober under openSUSE on the same machine).
I don’t think it’s a good idea to blacklist boot entries … but it’s debatable.
What the OP did was the right thing to do. When you dualboot with Windows only, there is absolutely no advantage in running the os-prober. Just put your WIndows chainloader in /etc/grub.d/40_custom and you’ll be fine. You could even deinstall os-prober completely. You don’t need it.
I don’t know which os-prober version 12.2 now runs. But 1.49 still has bugs which got fixed in 1.53. I posted links to the bug reports several times in the forum. My os-prober version mounts ufs2 properly (I’m sure very few people care but anyway) and updateGrub2 includes a function which patches 30_os-prober to add FreeBSD/NetBSD/openBSD support to Grub2. That was all 12.1 stuff. I read that updateGrub2 won’t run without errors under 12.2 because they moved a library. I’ll eventually fix that.
openSUSE has been updated to grub 2 version 2.00, the latest version as far as I know. There is more than one way to skin a cat and you have your way and I have mine. As luck would have it, I have no restore partitions on my PC to worry about. It was none the less an interesting exercise which can help you understand just what the different grub 2 bash scripts are doing. And I say bash, but apparently, it is its own language of sorts. And its OK for us to disagree, I would not have it any other way. lol!
Ouuuh… Don’t tell me the uncompressed core size has changed … and findgrub won’t detect it!
As usual … evrerything breaks or changes at the same time.
No. A boot manager is not a cat. And there is only one way to deal with device names when it gets about booting operating systems (at least Linux): avoid them!. Grub2 has finally managed not to use device names for booting and you want to reintroduce them in the boot problematic?!
James, Grub2 and os-prober are 2 different things. Grub2 doesn’t ‘need’ os-prober to do its job and os-prober doesn’t need Grub2 (I provided os-prober in my repo a long time before it was introduced in factory and way before Grub2 was available for openSUSE). The os-prober maintainer for openSUSE will certainly agree with that - I used once a grub2 library in one of my os-prober patches and he told me that it was a bad idea because it would involve and require grub2 … and he was right. I rewrote my patch. However whatever os-prober can do is useless if 30_os-prober doesn’t make use of it (it means that if you add a feature, such as a mount test to os-prober, you’ll have to add a new condition or a new test in 30_os-prober as well.)
It’s ‘sh’ actually, which makes sense for portability (Grub is not Linux) but might bet a little bit annoying for pure bash programmers.
OK, I tried on Ubuntu. Ubuntu uses os-prober 1.51. I use os-prober 1.53 on openSUSE. Which version do you have? Anyway, the scripts may be located somewhere else or have different names (grub-mkconfig vs grub2_mkconfig) and the patch might not work, but it’s only about explaining the concept:
Because of this conditional statement in /usr/lib/os-probes/mounted/20microsoft (just watch the text in red):
if item_in_dir -q bootmgr "$2"; then
# there might be different boot directories in different case as:
# boot Boot BOOT
for boot in $(item_in_dir boot "$2"); do
bcd=$(item_in_dir bcd "$2/$boot")
if -n "$bcd" ]; then
if grep -qs "W.i.n.d.o.w.s. .8" "$2/$boot/$bcd"; then
long="Windows 8 (loader)"
elif grep -qs "W.i.n.d.o.w.s. .7" "$2/$boot/$bcd"; then
long="Windows 7 (loader)"
elif grep -qs "W.i.n.d.o.w.s. .V.i.s.t.a" "$2/$boot/$bcd"; then
long="Windows Vista (loader)"
elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8. .R.2." "$2/$boot/$bcd"; then
long="Windows Server 2008 R2 (loader)"
elif grep -qs "W.i.n.d.o.w.s. .S.e.r.v.e.r. .2.0.0.8." "$2/$boot/$bcd"; then
long="Windows Server 2008 (loader)"
elif grep -qs "W.i.n.d.o.w.s. .R.e.c.o.v.e.r.y. .E.n.v.i.r.o.n.m.e.n.t" "$2/$boot/$bcd"; then
long="**Windows Recovery Environment (loader)**"
elif grep -qs "W.i.n.d.o.w.s. .S.e.t.u.p" "$2/$boot/$bcd"; then
long="**Windows Recovery Environment (loader**)"
else
long="Windows Vista (loader)"
fi
short=Windows
found=true
break
fi
done
fi
You would add the following line in /etc/grub.d/30_os-prober:
if you want to prevent grub-mkconfig from creating a boot entry for Windows RE. … It might be desired in some situations, but generally speaking, it’s not a good idea to blacklist boot entries. Alternately, you can also modify the conditions in /usr/lib/os-probes/mounted/20microsoft and then edit /etc/grub.d/30_os-prober accordingly. Looking at this in this way, there is more than one way to skin a cat. But doing anything with kernel device names since Linux relies on udev to generate them is not skinning a cat but simply wrong - and potentialy dangerous. But I’ve said that soooo many times…and I don’t know what else to say if people rather believe whatever they believe.
BTW, I never skinned a cat … or maybe a long time ago
Yes, this is what you should use. Don’t patch anything!
And to the others, I did not suggest to use the patch above. I just explained how it could be done. Also notice that this is only about Grub2 and os-prober. It doesn’t guarantee that the Perl Bootloader is not going to mess up the boot entries in the same way it does with Legacy Grub under 12.1 and previous versions (but tha’ts another problem and doesn’t affect openSUSE/Windows dualboot).
In my case there are actually three Windows 7 partitions. 1st Windows boot, 2nd rest of Windows, 3rd Windows recovery. In addition there was a fourth primary partition with some applications that could be started without starting the whole Windows. The problem with the recovery partition is that at least in my case booting from it automatically clears the active bit for the partition where grub2 resides and sets it for the Windows boot partition. Windows will boot fine on subsequent boot attempts, but there will be no grub menu since grub will never be run and no linux either. The situation might be a little different if t grub were installed in the MBR.
Not if you boot in Windows RE. It will just overwrite the MBR with a generic boot code. Actually if you had the Grub boot loader in a primary but not the extended partition, you could use diskpart under WIndows to re-activate it, but diskpart can not set the bootflag on the extended partition. Booting from the extended partition is also an opensusism which has other inconveniences and limitations … but I know that it’s useful and popular among Windows users.
Well, If I let OpenSUSE to install grub in the boot record of a partition, there will be no changes in the MBR. The original Windows boot code gives control to whichever partition happens to be marked active. This is the very reason I can recover just by clearing the active bit for the Windows partition and then setting the same bit for my grub partition. Had I chosen MBR things would be a little different since I would have to reintroduce grub in the MBR.
I suppose it is as you say: diskpart does not let you set an extended partition as active. If so this is just a limitation in diskpart.
