Re: Full documentation for GRUB2

[Isaac Dupree]

On 03/30/11 21:15, Leslie Rhorer wrote:
> ...
>         If you ask me, that seems pretty dismissive of the idea the admin
> should manually edit grub.cfg.  The fact the file is blindly and willfully
> overwritten by configuration and upgrade utilities would seem to re-enforce
> the notion it is not a terribly good idea.

FWIW, I keep my GRUB installation including grub.cfg on a separate 
partition that is not listed in /etc/fstab for this very reason; I know 
no distro I run will try to overwrite that!  It's annoyingly harder to 
protect the MBR similarly; luckily distro installers tend to provide an 
opt-out from installing their own bootloader, that I haven't *yet* 
forgotten to select during the ten or so Linux installations I've done 
on my laptop...

>         [...]Maybe
> this is utterly obtuse, but what, exactly constitutes the "full name"?  For
> example, in the line:
>
> menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64 (recovery mode)'
> --class debian --class gnu-linux --class gnu --class os {
>
>         is the "full name" everything between the quote marks?  Inclusive or
> exclusive of the quote marks?  Heck, although I would not expect it to be
> the case, I suppose it might even be the entire line up to the brace.

I'd guess* it's like shell, where the "full name" is everything between 
the quote marks (exclusive of the quote marks), but you'll most likely 
use the quote marks anywhere else you write it too, as they make it a 
single shell-word (and disable some meta-characters) much more 
conveniently than a ton of backslashes would.  But:

*the manual seems to back me up, at least by skimming it and seeing that 
the special-character/quoting syntax is trying to resemble shell; 
http://www.gnu.org/software/grub/manual/grub.html#Shell_002dlike-scripting

> Given
> the consequences of screwing up the boot loader (all the systems I have
> running GRUB2 are headless), I'm not very inclined to experiment much.

That's fair!!

Maybe there's some way to test your experiments?
If QEMU/KVM had a way to make a disk read-only within the simulation*, 
then I'd try KVM with the whole disk but readonly.  Run, play with 
bootloader, abort KVM once it's booting a kernel (which will probably 
get confused soon anyway once it realizes it's unable to write to its 
root filesystem).  Can test config-syntax that way; cannot test hardware 
compatibility (BIOS, ATA etc.) because QEMU has its own emulation for 
BIOS and hardware interfaces.

(*which I have a feeling it doesn't - after Googling, this bug came up - 
the bug itself isn't directly relevant and might related to RedHat 
enhancements to something, but it refers to upstream QEMU's lack of 
readonly-ify-ing a disk https://bugzilla.redhat.com/show_bug.cgi?id=510612 )

-Isaac