[Top][All Lists]

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

Re: Full documentation for GRUB2

From: Isaac Dupree
Subject: Re: Full documentation for GRUB2
Date: Thu, 31 Mar 2011 04:39:37 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110304 Lanikai/3.1.9

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...

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;

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 )


reply via email to

[Prev in Thread] Current Thread [Next in Thread]