[PATCH] grub-mkconfig patch for MINIX

[PATCH] grub-mkconfig patch for MINIX

[Fam Zheng]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

Hi,

`os-prober` was not able to detect recent MINIX installations, so we patched
for the new detection and sent the patch to Debian, it's found at:
http://lists.debian.org/debian-boot/2010/08/msg00282.html

<http://lists.debian.org/debian-boot/2010/08/msg00282.html>MINIX is now able
to be Multibooted besides chainloading, so it's necessary to handle the
result of os-prober accordingly. The patch for GRUB 2 is made then, to
generate a Multiboot menu entry when detected system type is "minix".

Patch content:

=== modified file 'util/grub.d/30_os-prober.in'
--- util/grub.d/30_os-prober.in 2010-07-04 22:45:14 +0000
+++ util/grub.d/30_os-prober.in 2010-08-13 11:31:07 +0000
@@ -197,6 +197,23 @@
 }
 EOF
     ;;
+    minix)
+      case ${LONGNAME} in
+ Minix*)
+  cat << EOF
+menuentry "${LONGNAME} (on ${DEVICE}, Multiboot)" {
+EOF
+          save_default_entry | sed -e "s/^/\t/"
+          prepare_grub_to_access_device ${DEVICE} | sed -e "s/^/\t/"
+      cat << EOF
+ multiboot /boot/image_latest
+}
+EOF
+      ;;
+        *)
+          echo "  ${LONGNAME}(multiboot) is not yet supported" >&2
+      esac
+    ;;
     *)
       echo "  ${LONGNAME} is not yet supported by grub-mkconfig." >&2
     ;;


-- 
Best Regards!
Fam Zheng

[-- Attachment #2: Type: text/html, Size: 2393 bytes --]

Re: [PATCH] grub-mkconfig patch for MINIX

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

On 08/15/2010 12:59 PM, Fam Zheng wrote:
> Hi,
>
> `os-prober` was not able to detect recent MINIX installations, so we
> patched for the new detection and sent the patch to Debian, it's found at:
> http://lists.debian.org/debian-boot/2010/08/msg00282.html
>
> MINIX is now able to be Multibooted besides chainloading, so it's
> necessary to handle the result of os-prober accordingly. The patch for
> GRUB 2 is made then, to generate a Multiboot menu entry when detected
> system type is "minix".
>
> Patch content:
>
> === modified file 'util/grub.d/30_os-prober.in <http://30_os-prober.in>'
> --- util/grub.d/30_os-prober.in <http://30_os-prober.in> 2010-07-04
> 22:45:14 +0000
> +++ util/grub.d/30_os-prober.in <http://30_os-prober.in> 2010-08-13
> 11:31:07 +0000
> @@ -197,6 +197,23 @@
>  }
>  EOF
>      ;;
> +    minix)
> +      case ${LONGNAME} in
> + Minix*)
Why do you need to check LONGNAME separately? This shouldn't be necessary.
> +  cat << EOF
> +menuentry "${LONGNAME} (on ${DEVICE}, Multiboot)" {
> +EOF
> +          save_default_entry | sed -e "s/^/\t/"
> +          prepare_grub_to_access_device ${DEVICE} | sed -e "s/^/\t/"
> +      cat << EOF
> + multiboot /boot/image_latest
is it always named like this? Is /boot never a mountpoint?
> +}
> +EOF
> +      ;;
> +        *)
> +          echo "  ${LONGNAME}(multiboot) is not yet supported" >&2
> +      esac
> +    ;;
>      *)
>        echo "  ${LONGNAME} is not yet supported by grub-mkconfig." >&2
>      ;;
>
>
> -- 
> Best Regards!
> Fam Zheng
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: [PATCH] grub-mkconfig patch for MINIX

[Erik van der Kouwe]

Hi,

>> + multiboot /boot/image_latest
> is it always named like this? Is /boot never a mountpoint?

There are always two images in /boot: image_big which is the image that 
was installed and image_latest which is the last image that was compiled 
(or, on a fresh installation, equal to the former). There may be more 
images in the /boot/image directory, but their names are variable which 
is not convenient for GRUB.

The MINIX installation script only supports a configuration with three 
partitions: /, /home and /usr. Although theoretically it is possible for 
someone to hack together a different configuration, this is very 
unlikely and not a 'supported' set-up. It seems reasonable that in such 
a case the user also manually configure GRUB.

With kind regards,
Erik van der Kouwe