RFC: Support Linux command line variants in grub-mkconfig

RFC: Support Linux command line variants in grub-mkconfig

[Martin Orr]

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

I would like to be able to choose between alternative Linux command 
lines in my GRUB menu (specifically, I want a "selinux=0" option, but I 
can imagine that people might want other things).  I could add an extra 
script to /etc/grub.d to do this, but then I have to copy the logic in 
10_linux to detect what kernel versions are available, and they do not 
appear in the correct place in the menu.  It would be simpler if you 
could specify variant command lines in /etc/default/grub and have them 
handled automatically in 10_linux.

The attached patch allows (for example) the following configuration in 
/etc/default/grub:
GRUB_LINUX_VARIANTS="noselinux kms"

GRUB_CMDLINE_LINUX_noselinux="selinux=0"
GRUB_LABEL_LINUX_noselinux="SELinux disabled"

GRUB_CMDLINE_LINUX_kms="i915.modesetting=1"
GRUB_LABEL_LINUX_kms="KMS enabled"

This patch is only intended as a demonstration: various details of the 
implementation still need to be sorted out, such as 
internationalization.  Suggestions of wildly different 
approaches/configuration interfaces are welcome.

Best wishes,

-- 
Martin Orr

[-- Attachment #2: grub-linux-variants.diff --]
[-- Type: text/x-diff, Size: 1746 bytes --]

=== modified file 'util/grub-mkconfig.in'
--- util/grub-mkconfig.in	2009-12-12 00:43:32 +0000
+++ util/grub-mkconfig.in	2010-01-18 21:01:34 +0000
@@ -222,6 +222,11 @@
   GRUB_GFXMODE \
   GRUB_DISABLE_OS_PROBER
 
+export GRUB_LINUX_VARIANTS
+for i in $GRUB_LINUX_VARIANTS; do
+  export GRUB_CMDLINE_LINUX_${i} GRUB_LABEL_LINUX_${i}
+done
+
 if test "x${grub_cfg}" != "x"; then
   rm -f ${grub_cfg}.new
   exec > ${grub_cfg}.new

=== modified file 'util/grub.d/10_linux.in'
--- util/grub.d/10_linux.in	2010-01-14 14:04:44 +0000
+++ util/grub.d/10_linux.in	2010-01-18 21:01:34 +0000
@@ -53,11 +53,15 @@
   version="$2"
   recovery="$3"
   args="$4"
+  label="$5"
   if ${recovery} ; then
     title="$(gettext "%s, with Linux %s (recovery mode)")"
   else
     title="$(gettext "%s, with Linux %s")"
   fi
+  if [ "x$label" != "x" ]; then
+    title="${title} (${label})"
+  fi
   printf "menuentry \"${title}\" {\n" "${os}" "${version}"
   save_default_entry | sed -e "s/^/\t/"
   if [ -z "${prepare_boot_cache}" ]; then
@@ -111,11 +115,17 @@
   fi
 
   linux_entry "${OS}" "${version}" false \
-      "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
+      "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" ""
   if [ "x${GRUB_DISABLE_LINUX_RECOVERY}" != "xtrue" ]; then
     linux_entry "${OS}" "${version}" true \
-	"single ${GRUB_CMDLINE_LINUX}"
+	"single ${GRUB_CMDLINE_LINUX}" ""
   fi
+  for i in ${GRUB_LINUX_VARIANTS}; do
+    eval cmdline=\${GRUB_CMDLINE_LINUX_${i}}
+    eval label=\${GRUB_LABEL_LINUX_${i}}
+    linux_entry "${OS}" "${version}" false \
+        "${cmdline}" "${label}"
+  done
 
   list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
 done

Re: RFC: Support Linux command line variants in grub-mkconfig

[Robert Millan]

On Mon, Jan 18, 2010 at 09:03:53PM +0000, Martin Orr wrote:
> I would like to be able to choose between alternative Linux command  
> lines in my GRUB menu (specifically, I want a "selinux=0" option, but I  
> can imagine that people might want other things).  I could add an extra  
> script to /etc/grub.d to do this, but then I have to copy the logic in  
> 10_linux to detect what kernel versions are available, and they do not  
> appear in the correct place in the menu.  It would be simpler if you  
> could specify variant command lines in /etc/default/grub and have them  
> handled automatically in 10_linux.
>
> The attached patch allows (for example) the following configuration in  
> /etc/default/grub:
> GRUB_LINUX_VARIANTS="noselinux kms"
>
> GRUB_CMDLINE_LINUX_noselinux="selinux=0"
> GRUB_LABEL_LINUX_noselinux="SELinux disabled"
>
> GRUB_CMDLINE_LINUX_kms="i915.modesetting=1"
> GRUB_LABEL_LINUX_kms="KMS enabled"
>
> This patch is only intended as a demonstration: various details of the  
> implementation still need to be sorted out, such as  
> internationalization.  Suggestions of wildly different  
> approaches/configuration interfaces are welcome.

I think this is growing severely overengineered.  It is already more
complex than it needs to be.

The scripts in /etc/grub.d *are* config files.  There's no reason you
can't edit them to suit your needs.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi

Re: RFC: Support Linux command line variants in grub-mkconfig

[Martin Orr]

On Tue 19 Jan 22:26:51 2010, Robert Millan wrote:

> On Mon, Jan 18, 2010 at 09:03:53PM +0000, Martin Orr wrote:
>> I would like to be able to choose between alternative Linux command
>> lines in my GRUB menu (specifically, I want a "selinux=0" option, but I
>> can imagine that people might want other things).  I could add an extra
>> script to /etc/grub.d to do this, but then I have to copy the logic in
>> 10_linux to detect what kernel versions are available, and they do not
>> appear in the correct place in the menu.  It would be simpler if you
>> could specify variant command lines in /etc/default/grub and have them
>> handled automatically in 10_linux.
>>
>> The attached patch allows (for example) the following configuration in
>> /etc/default/grub:
>> GRUB_LINUX_VARIANTS="noselinux kms"
>>
>> GRUB_CMDLINE_LINUX_noselinux="selinux=0"
>> GRUB_LABEL_LINUX_noselinux="SELinux disabled"
>>
>> GRUB_CMDLINE_LINUX_kms="i915.modesetting=1"
>> GRUB_LABEL_LINUX_kms="KMS enabled"
>>
>> This patch is only intended as a demonstration: various details of the
>> implementation still need to be sorted out, such as
>> internationalization.  Suggestions of wildly different
>> approaches/configuration interfaces are welcome.
>
> I think this is growing severely overengineered.  It is already more
> complex than it needs to be.
>
> The scripts in /etc/grub.d *are* config files.  There's no reason you
> can't edit them to suit your needs.

I agree that my solution does seem rather overengineered.

My problem is that while /etc/grub.d/* may be config files in some 
technical sense, they don't behave like them.  In particular for most 
config files, changes you make are largely "orthogonal" to the rest of 
the file whereas my changes to /etc/grub.d are mixed in with complex 
logic which I have no interest in changing.  Combined with frequent 
changes to the default version of the file, this makes merging new 
versions a burden.

My patch reduces the configuration needed to set up variant command 
lines to a few lines  in /etc/default/grub, which are indeed orthogonal 
to the rest of the file.

To specify more precisely what I dislike about just editing 10_linux, 
the change that I would want to make (and I would guess that this is 
the change people would most often want to make) is to add an extra 
call to linux_entry.  But linux_entry is an "internal" interface which 
could change its arguments in arbitrary ways, and it doesn't even 
provide the features I need (specifically a label argument, added to 
the title of the menu entry) so I end up having to patch linux_entry 
itself as well as adding a new call, and keep these matching whenever 
the default linux_entry changes.

Best wishes,

-- 
Martin Orr

Re: RFC: Support Linux command line variants in grub-mkconfig

[Joey Korkames]

>> I think this is growing severely overengineered.  It is already more
>> complex than it needs to be.
>>
>> The scripts in /etc/grub.d *are* config files.  There's no reason you
>> can't edit them to suit your needs.
> 
> I agree that my solution does seem rather overengineered.
> 
> My problem is that while /etc/grub.d/* may be config files in some 
> technical sense, they don't behave like them.  In particular for most 
> config files, changes you make are largely "orthogonal" to the rest of 
> the file whereas my changes to /etc/grub.d are mixed in with complex 
> logic which I have no interest in changing.  Combined with frequent 
> changes to the default version of the file, this makes merging new 
> versions a burden.
> 
> My patch reduces the configuration needed to set up variant command 
> lines to a few lines  in /etc/default/grub, which are indeed orthogonal 
> to the rest of the file.
>
 
To solve this exact problem I distribute my own grub.d/01_custom_entries and 
grub.d/40_custom_vars hooks on my systems. They rely on a ruby script that globs 
/boot/vmlinu* (and other operating systems kernels) and builds a hash of 
entries for every kernel and for all the variants of the command line I want 
or need on the systems. Because the entries come first, I can just 
index-count _my_ menu items and know they'll always be "first" and because 
the vars hook is at the end of the mkconfig run, I can "set default=3" from 
there and know it won't be overruled by the stock hooks.

The fact is that this patch would make it seem weird that none of the 
_other_ kernel types in grub.d will have variants either. Leading to a 
proliferation of GRUB_FOOBAROS_VARIANTS= in /etc/default/grub. Bourne 
shell is simply the wrong language for this kind of thing (no 
hashes/dictonaries/multi-dimensional-arrays) but it's all that can be 
demanded by any OS to support grub-mkconfig.

IMHO, the default mkconfig stuff shipped with grub should be considered a 
reference implementation that can be kept simple and working on all 
distros _of_ all OS's but its certainly not the only way to generate a good 
config for your site. Patching the stock system to your specific needs might 
make less burden for you now but more for everyone else down the road.

-joey