Skip partitions during OS probing

Hello devels,

I attached a patch I use on my machine to skip certain predefined partitions during OS probing by grub-mkconfig/30_os-prober. I started to work on this as grub2 adds the Win7 system partition of my dual-booted laptop to the boot menu, although only Win7s boot partition is actually needed. Not a big error, but it bugged me... ;)
But apart from this special case on my machine, I think it is handy to have a standardized way to exclude certain partitions from being auto-probed during execution of update-grub.

The patch updates two files. grub-mkconfig.in now exports an additional user variable called GRUB_SKIP_PARTITIONS, 30_os-prober.in adds a few lines to check whether the currently probed partition is contained in GRUB_SKIP_PARTITIONS, and if so, skips addition of the boot menu entry.

To skip one ore more partitions during OS probing, the user has to add the variable GRUB_SKIP_PARTITIONS to the grub config file (/etc/default/grub) and provide it with a space delimited list of partition names (e.g. GRUB_SKIP_PARTITIONS="sda2 sdb3").

I created the patch with the command 'bzr patch -p1'. If that is not the correct way, please let me know. I'm also open for suggestions on improving the patch.

Please let me know what you think,
thanks for the good work,

Axel

=== modified file 'util/grub-mkconfig.in'

@@ -257,7 +257,8 @@
   GRUB_INIT_TUNE \
   GRUB_SAVEDEFAULT \
   GRUB_ENABLE_CRYPTODISK \
-  GRUB_BADRAM
+  GRUB_BADRAM \
+  GRUB_SKIP_PARTITIONS
 
 if test "x${grub_cfg}" != "x"; then
   rm -f ${grub_cfg}.new

=== modified file 'util/grub.d/30_os-prober.in'

@@ -94,6 +94,12 @@
   LONGNAME="`echo ${OS} | cut -d ':' -f 2 | tr '^' ' '`"
   LABEL="`echo ${OS} | cut -d ':' -f 3 | tr '^' ' '`"
   BOOT="`echo ${OS} | cut -d ':' -f 4`"
+  PARTITION="`echo ${DEVICE} | grep -o '[^\/]\+$'`"
+
+  if [ "x${GRUB_SKIP_PARTITIONS}" != "x" -a "x`echo ${GRUB_SKIP_PARTITIONS} | grep -e '\b'${PARTITION}'\b'`" != "x" ] ; then
+    echo "Skipped ${LONGNAME} on ${DEVICE} by user request." >&2
+    continue
+  fi
 
   if [ -z "${LONGNAME}" ] ; then
     LONGNAME="${LABEL}"

Partition numbers tend to get moved around quite frequently, so this would be a fragile configuration, and require manual entry. It would be better to automatically notice that the partition is a Win7 system partition, and ignore it. If you must explicitly exclude manually chosen partitions, they should be specified by UUID.

Good point. I guess the proposed solution works well with internal HDDs, as they tend to always get the same device names during system initialization (at least I never observed different behaviour on my machine), but could be fragile for external drives.

I agree. But I guess on my machine it is not really grubs fault that the Win7 system partition is marked as bootable. I only have one of those Win7 licenses that come with recovery media, so I'm not able to do a manual, clean install and it seems the recovery installation always makes the system partition bootable. I'm probably not the only one experiencing this kind of faulty setup...

I guess we could work with UUIDs instead of partition names, but it also turns this little patch into something a bit more complicated. I'd be happy to look into it, but we should first decide if we really cover a use-case here or if the whole thing isn't worth the effort.

Thanks,

Axel

I have observed it on internal drives. If you have two controllers with different drivers and disks on both then there is no predicting which driver will load and initiallize first in some cases. Switching to UUIDs made the box much more reliable to boot (it was a 50/50 chance it would boot with the disks in the "right" order and work).

Len Sorensen

Turns out switching to UUIDs was very simple, grub already provides the necessary utility function. :)

The new patch is attached.

Thanks,

Axel

=== modified file 'util/grub-mkconfig.in'

@@ -257,7 +257,8 @@
   GRUB_INIT_TUNE \
   GRUB_SAVEDEFAULT \
   GRUB_ENABLE_CRYPTODISK \
-  GRUB_BADRAM
+  GRUB_BADRAM \
+  GRUB_SKIP_PARTITIONS
 
 if test "x${grub_cfg}" != "x"; then
   rm -f ${grub_cfg}.new

=== modified file 'util/grub.d/30_os-prober.in'

@@ -94,6 +94,12 @@
   LONGNAME="`echo ${OS} | cut -d ':' -f 2 | tr '^' ' '`"
   LABEL="`echo ${OS} | cut -d ':' -f 3 | tr '^' ' '`"
   BOOT="`echo ${OS} | cut -d ':' -f 4`"
+  UUID="`grub-probe --target=fs_uuid --device ${DEVICE}`"
+
+  if [ "x${GRUB_SKIP_PARTITIONS}" != "x" -a "x`echo ${GRUB_SKIP_PARTITIONS} | grep -i -e '\b'${UUID}'\b'`" != "x" ] ; then
+    echo "Skipped ${LONGNAME} on ${DEVICE} by user request." >&2
+    continue
+  fi
 
   if [ -z "${LONGNAME}" ] ; then
     LONGNAME="${LABEL}"

If you only have one controller, then the disks will tend to be enumerated in the same order each time, but many people have multiple controllers these days so the order jumbles around quite a bit. Often times a USB flash stick can be detected first and get sda, bumping the internal hard disks down.

Even if you only have one controller, sometimes a drive can take a little longer to spin up and one of the other drives can finish being detected first.

Fixing the underlying problem of detecting and ignoring the Win7 system partition would render the patch moot. If it does really still cover a use-case to be able to manually specify partitions to ignore, it needs to be done with UUIDs or something else more stable.

Just to tie up that loose end, I had a look at the way update-grub determines the presence of a bootable Win7 partition. Turns out it utilizes the os-prober package, which basically uses a four step process to check for a Win7 system:

1. check for presence of file /bootmgr
2. check for presence of directory /boot/
3. check for presence of file /boot/bcd
4. grep OS version string from file /boot/bcd

If all four steps succeed, the partition is classified as bootable and update-grub writes a boot meny entry.

The Win7 system partition on my machine passes all the checks os-prober does, but actually booting from that partition fails with an error message. To solve this, os-prober would have to include some kind of sanity check whether the bootloader configuration on the examined partition is set up correctly and really boots the system. I'm not sure if that is feasible and/or possible at all, and one could also argue that it's up to the user to fix the faulty boot setup on the partition and not blame grub/os-prober for detecting a messed up bootloader. :)

Thoughts?

BTW, I still think the patch covers a use-case and its functionality could be handy.

Thanks,

Axel