[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to boot with the "irqpoll" option?



Quoting Darac Marjal (mailinglist@darac.org.uk):
> On Mon, Mar 09, 2015 at 07:49:04PM -0700, Rusi Mody wrote:
> > 3rd option.
> > Do the addition to the linux (ie kernel) line of /boot/grub/grub.cfg
> > 
> > Yeah the file says dont do that.
> > The grub guys make that suggestion but dont really follow it themselves!
> > This will work until the next time some upgrade changes the cfg file
> 
> Which is exactly WHY you're encouraged not to edit that file. People
> tend not to like having their configurations disappear without warning,
> so there's a big warning at the top of the file.

There are pretty simple ways of dealing with this. In my case, I
prefer to use LABELs rather than UUIDs in grub.cfg, but I also use the
same trick so as to have different kernel options available in the
grub menu without having to remember/retype complicated options,
eg "libata.force=3.00:disable" because one machine has a dicky bus,
"video=efifb fbcon=rotate:3" to rotate the console, etc.

So step 1 is, bung all those string in /etc/default/grub so they get
put in by default.
Step 2, mkconfig and copy the resulting configuration to
grub.cfg-uuids for later use.
Step 3, run a python script on grub.cfg-uuids that converts UUIDs to
LABELs using /run/udev/data info, putting it in grub.cfg-labels
Step 4, edit grub.cfg-labels to grub.cfg-edited doing things like
duplicating submenus and removing the options above that you don't
want from some of them (and any other cosmetic changes).
Step 5, copy grub.cfg-edited over grub.cfg.

Now whenever grub or linux-image is upgraded, just check with
diff /boot/grub/grub.cfg /boot/grub/grub.cfg-uuids
that nothing's changed and
cp /boot/grub/grub.cfg-edited /boot/grub/grub.cfg
to restore normality.

And if you forget, you just get all those complicated options that you
couldn't remember how to type (or "E" them away at the grub menu, as
previously suggested in this thread).

Cheers,
David.


Reply to: