On Tue, Apr 05, 2011 at 11:14:47AM -0400, Tom Easterday wrote:
> On Apr 5, 2011, at 8:45 AM, Stephen Wille Padnos wrote:
> > Note that with grub2, ie Ubuntu 10.04, there is a directory of files 
> > which are executed in order whenever grub is reconfigured.  It looks 
> > like the output of those files is concatenated, or the config file is 
> > piped from one to the next (I'm not sure of the actual mechanism).  In 
> > any case, you can make a filter script like this and add it as a 
> > separate executable file in /etc/default/grub/.  This is preferable to 
> > editing update-grub since the changes will be preserved through updates 
> > to grub.
> > 
> > This is all described in reasonable detail at the link I posted above, 
> > <http://ubuntuforums.org/showthread.php?t=1195275>.

The problem with grub2, both for my proposed fix and any solution in a
separate executable file in /etc/default/grub/ is that (as described at
the link) »update-grub actually runs the command
"grub-mkconfig -o /boot/grub/grub.cfg" This runs several scripts and
incorporates the results into /boot/grub/grub.cfg «

That redirection of stdout (&1) to /boot/grub/grub.cfg confirms that
"the output of those files is concatenated", as Stephen alluded. Both
examples on the webpage, and e.g. /etc/grub.d/20_memtest86+, take
no input (and so would break a pipe), and instead simply write to
stdout, relying on the "-o" above.

The page reinforces this with: "The order of the entries in the grub
menu is based on the order of the file names." Each /etc/grub.d/ file
simply spouts stuff, in the case of 20_memtest86+ it is just a basic
HERE-document.

> I don't fully understand how would integrate the script for modifying
> the kernel line (from Erik's messages) into the appropriate place to
> make this change live through changes to /boot/grub/grub.cfg. Perhaps
> it goes in one of the files in /etc/grub.d, but I am not sure at what
> point the line exists in order to modify it...

Prezactly! In the absence of piping to e.g. /etc/grub.d/40_custom, we
have to wait until grub-mkconfig's helper files have finished writing to
the file.

It could therefore be risky, I think, to just do this in
/etc/grub.d/40_custom :

                            ----------------
#!/bin/bash

# /etc/grub.d/40_custom, to auto post-edit bootargs,
# which have already been output.

sync        # Flush everything to disk, and wait for it.

            # Now we should be able to edit it:

gawk '
/^[ \t]*linux/ && $2 ~ /-rtai$/ {
   printf("%s %s\n",$0,"isolcpus=1")
   next
}

   { print $0 }

' /boot/grub/grub.cfg > /tmp/grub.cfg

cp -f /tmp/grub.cfg  /boot/grub/grub.cfg

                            ----------------

That would rely on the fact that we do not output to stdout, so that if
grub-mkconfig ends without spontaneous output, there is nothing to write
to disk when grub-mkconfig closes its filedescriptor _after_ all the
helper scripts, including ours, have run.

Safer ways to achieve boot parameter customisation are then:

   a) Append "sync" and editing snippet to update-grub, so that it runs
      after grub-mkconfig has done its stuff, and the file is written to
      disk. (We previously didn't sync.)

               OR

   b) Put a wrapper around update-grub, so that our snippet lives in
      either ~/bin/update-grub or /usr/local/bin/update-grub, and we
      ensure in /etc/bash.bashrc that the chosen directory is first in
      $PATH. (Avoids modifying any grub stuff.)

               OR

   c) Modify the update-grub stub, to redirect output to our script,
      which in turn redirects to /boot/grub/grub.cfg (Since
      /usr/local/bin/update-grub is just a wrapper around grub-mkconfig,
      make it do more useful work.)

Perhaps b) is the way to go?

Finally (out of sequence, because it's another issue):

> According to the instructions above I editted /etc/default/grub and change:
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
> to
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=1"
> 
> I then have to run "sudo update-grub" in a command line and the
> appropriate change is made.   This isn't done automatically during a
> reboot apparently.

No, the documented way to generate /boot/grub/grub.cfg from
/etc/default/grub is to run update-grub. At boot time, we can only
expect /boot/grub/grub.cfg to be used.

And that will change all kernel lines, not just the rtai ones.

Erik

-- 
Due to circumstances beyond our control, we regret to inform you that
circumstances are beyond our control.                    -Paul Benoit

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to