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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
