Re: Full documentation for GRUB2
Chris Murphy wrote:
On Mar 29, 2011, at 9:19 AM, Patrick Strasser wrote:
Moreover googling is no alternative to proper documentation. I'd
like to contribute examples that I found to the grub docs, but the
manual gives no hint how to do so... ;-)
It's the developers task and skill to document features.
I agree, but from this outsider's perspective, it's abundantly clear
the developers have totally abdicated on this.
That's a bit harsh. The devs are a very small group and the technical
details are vast. There is some effort going on to do the
documentation, but it takes time. It is only a .98 release right now
which means it is under development. To describe what GRUB2 does will
take a moderate size book.
The entire project is a mini-operating system. I personally don't
really think a lot of the bells and whistles (e.g. scripting, graphics)
are needed for something that most users will look at for 5 seconds as
they boot (if at all).
My own grub.cfg looks like:
### grub.cfg
set default=0
set timeout=5
insmod ext2
set root=(hd0,1)
menuentry LFS SVN 20110204, Linux 2.6.37 {
linux /linux-2.6.37 root=/dev/sda14 ro
}
menuentry LFS SVN 20100627, Linux 2.6.34-label {
linux /linux-2.6.34 root=LABEL=lfs-svn ro
}
and it works fine. On the other hand, I don't do Windows, BSD, MAC,
serial IO for boot, nfs boot, tftp boot, a boot sector on raid, EFI,
initrd, grub-mkconfig, or a myriad of other things that GRUB supports.
-- Bruce
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Out of Memory Error
On 30.03.2011 15:27, Gus Zernial wrote: I can believe it's a BIOS problem, but ... 120 GB is a large drive? Could you try booting from external media and execute ls -l It should give you the total size in blocks as seen through BIOS. Also how is this disk accessed? PATA or AHCI? If first you can install GRUB with --disk-module=ata. If second, then you can do the same with --disk-module=ahci but only in experimental. Beware that AHCI in GRUB is alpha-quality right now. --- On Tue, 3/29/11, Jordan Uggla jordan.ug...@gmail.com wrote: From: Jordan Uggla jordan.ug...@gmail.com Subject: Re: Out of Memory Error To: The development of GNU GRUB grub-devel@gnu.org Cc: Gus Zernial gus_zern...@yahoo.com Date: Tuesday, March 29, 2011, 6:00 PM 2011/3/29 Gus Zernial gus_zern...@yahoo.com: Thanks for your reply. First of all, the error is Out of disk, not Out of memory, my bad Out of disk is a very different error from Out of memory. Out of disk means that you have a buggy BIOS which can't handle large drives properly. To work around this create a small /boot/ partition near the beginning of the drive. -- Jordan Uggla (Jordan_U on irc.freenode.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
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
Re: Testing On Macbook on enbug.org
On 31.03.2011 02:29, Chris Murphy wrote: re: http://grub.enbug.org/TestingOnMacbook I am wondering who the author of this page is, and if it's possible to get a more clear step by step of how a Macbook Pro 4,1 – one of the testing configurations on that page – was configured to successfully boot Linux in EFI native mode. So far I have been unable to reproduce it based on the information provided on that page, and have found no other guides or resources indicating it's possible. From quick look on the page it seems that you're able to load Linux but have trouble with graphical drivers. While some workarounds are possible on GRUB level, it's not GRUB territory to fix those. An advantage of GRUB2 here is the ability to use loadbios. But I have not been successful at getting this to work as described. loadbios is just a kludge. In perspective the settings currently retrieved from 0xc000 (VGA BIOS) zone should be retrieved from PCI ROM, using x86emu if necessary, or be in tables included in drivers. Also note that for loadbios to work, you need a VGA BIOS dump obtained while booted in *BIOS* mode. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
On 31.03.2011 10:39, Isaac Dupree wrote: 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. This is a good way but not bullet-proof since your modifications might not reach the real disk for a while, even if you issue a sync. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Improve documentation of BIOS installation
On 30/03/11 20:52, Colin Watson wrote: On Wed, Mar 30, 2011 at 08:00:46PM +0100, Barry Jackson wrote: On 29/03/11 13:40, Colin Watson wrote: With http://grub.enbug.org/BIOS_Boot_Partition being down at the moment, I went to look at what corresponding documentation there was in the manual. One question that I cannot find an answer for in the manual here :- 18.1 GRUB only offers a rescue shell It explains that the only available commands are ls, set, unset and insmod. So what use is it? Assuming that a module is missing or a variable is incorrect, and these are corrected with insmod and set - what next? I can see no way to boot after correcting things without a 'boot' command available. If you can't boot, why bother with set or insmod. I just don't get it! The manual even answers this question directly with an example: http://www.gnu.org/software/grub/manual/grub.html#GRUB-only-offers-a-rescue-shell See the example after then you can correct this and enter normal mode manually. (Once you are in normal mode with a correct prefix, then commands will be autoloaded, although you could insmod them manually if you really wanted. But this should be self-explanatory once you do it, as entering normal mode will give you a GRUB menu.) I've extended the text you refer to (http://www.gnu.org/software/grub/manual/grub.html#Commands) to link to this troubleshooting section. It'll be there the next time we push to the website. Regards, Thanks Colin, I was being a bit dim - or maybe it was late. I had not grasped the concept of the 'normal' command which was not included in the list of available commands. It's much clearer now. Maybe next time I'm hit with a rescue shell I may just be able to boot from it ;-) Barry ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
On 29.03.2011 17:58, Chris Murphy wrote: It is not due to laziness that Red Hat continues to hack GRUB Legacy, even for EFI support. It's very recent that GRUB2 is suitable for production use. Versions prior to 1.97 aren't suitable for anything else than use by a coder. When Red Hat needed EFI support, GRUB2 wasn't in a state to be included in a distro, so they did with what they had at the time. And switching bootloader isn't an easy task. Even if bootloader itself would be written in mathematically proven correct code, you'll still hit problems when you discover bugs in firmwares in question. So distros are reluctant to move to a new codebase -- Regards Vladimir 'φ-coder/phcoder' Serbinenkoh signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing On Macbook on enbug.org
On Thu, Mar 31, 2011 at 05:59, Chris Murphy bugzi...@colorremedies.com wrote: re: http://grub.enbug.org/TestingOnMacbook I am wondering who the author of this page is, and if it's possible to get a more clear step by step of how a Macbook Pro 4,1 – one of the testing configurations on that page – was configured to successfully boot Linux in EFI native mode. So far I have been unable to reproduce it based on the information provided on that page, and have found no other guides or resources indicating it's possible. See Ben Skaggs take on this I think you'll find the binary driver will also fail in this case with NVRM: failed to copy vbios to system memory. Unless there's some other magic way of retrieving the VBIOS image on these machines, there's not a lot we can do. https://bugzilla.redhat.com/show_bug.cgi?id=493754#c12 An advantage of GRUB2 here is the ability to use loadbios. But I have not been successful at getting this to work as described. I do not know who started the page and wrote most of it, but i merged http://grub.fsij.org/TestingOnEFI with http://grub.fsij.org/TestingOnMacbook (since the latter had more info, but the page itself is appplicable to both Apple and non-Apple systems). Most of the troubleshooting part was written by http://ubuntuforums.org/member.php?u=1121774 (nickname metatech). He is active in http://ubuntuforums.org/forumdisplay.php?f=328 sub-forum. You can try these instructions http://www.rodsbooks.com/ubuntu-efi/index.html written by the author of GPT fdisk (aka gdisk). If loadbios does not work, you can try fakebios, although i cant help you there since i have not used that option and i do not own a mac (i did my testing in a proper UEFI 2.3 x86_64 firmware - non Apple system). http://bugzilla.redhat.com/show_bug.cgi?id=691609 Basically this problem blocks Live CD's from natively EFI booting a large class of EFI supporting hardware. But even if it's not possible to get this to work with Live CD, it would be nice if a clear step by step were documented with best practice to get this working after a e.g. text only installation (under EFI native booting) were performed. Chris Murphy ___ Help-grub mailing list help-g...@gnu.org http://lists.gnu.org/mailman/listinfo/help-grub Regards. Keshav ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
On Thu, Mar 31, 2011 at 04:39:37AM -0400, Isaac Dupree wrote: 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). Does the -snapshot option do what you want? -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
schrieb Colin Watson am 2011-03-29 19:09:
On Tue, Mar 29, 2011 at 05:19:09PM +0200, Patrick Strasser wrote:
I had a simmilar experience regarding the loopback system
I've committed documentation of this command to trunk.
Thanks! Now that was fast.
From my experience it's not working to get some newbies or helpers to
write docs. It's the developers task and skill to document features.
Task, perhaps; skill, not necessarily.
Developers often do not make the best documenters. We understand the
software sufficiently well that it's often difficult to remember what
others don't understand, and thus it's hard to remember to make it a
priority over other things.
I agree that developers have the *responsibility* to document features
they add, and I've been trying to encourage this in GRUB where I can.
However, most of the problem is not new features, but the backlog.
Occasionally I attack it a bit, but there's a lot to do.
Sorry, mixed that up. I meant that it is the developers that know about
the features. They know the code from inside out, with all subtleties
and with all the intentions that where the reason to add or change features.
Of course just writing down knowledge does not make a good manual. This
needs skilled writers, which also see the user side and incorporate
issues and use cases that became evident by means of bug trackers or
mailing list request etc.
I regularly read in mailinglists of projects invitations for
documentation writers. Often this reads like We coders are too
{lazy,busy,uninterested} to write docs, just dig up the source and write
a manual from it.
I'd see it as a two step process: developers document the features, with
intended use cases and reasons; docs writers make a fine manual out of it.
What I would find really valuable, in addition to documentation patches,
is *constructive* criticism. GRUB's manual sucks just makes me feel
demotivated; I might as well do something else rather than bother.
Pointing out specific things that are unclear or need to be written is
much better.
GRUB 1 is really great, GRUB 2 is even better. I see that people put
effort in it, and it can do great things. Thanks for the work, and keep up.
I have the impression that GRUB 2 is a very powerful tool. Unfortunately
my impression is that I'm not adept enough to unleash all its powers.
Regards!
Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser patrick dot strasser at student dot tugraz dot at
Student of Telemati_cs_, Techn. University Graz, Austria
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
I've wondered occasionally whether it would be worth it to include something like GRUB_STATIC in upstream grub-mkconfig; if set, this would cause grub-mkconfig to do nothing, perhaps printing a message. This would mean you wouldn't have to figure out how to disable distribution facilities that run grub-mkconfig for you; you could just set GRUB_STATIC=1 and write your own grub.cfg if you wanted. Vladimir, do you think you'd take such a change for 1.99? Based on other messages in this thread, this likely wouldn't be very effective. Boot from a LiveCD? It won't have GRUB_STATIC set. IMO, a better option would be to control this from the config file itself (and obviously it's already too late from one perspective, there already exist distro releases with tools that won't respect it). I would lean toward a solution wherein the tools refuse to modify a config that contains any of config_protected 1 config_protected yes config_protected true (and prints an appropriate message so a user who is trying to run a boot fix-it tool is informed how to disable the protection, better have a specific exit code as well so that wrapper tools which don't show tool stdout/stderr to the user can detect this condition and display their own message, possibly localized) Then the tools can generate a config that starts with # this file is auto-generated, allow re-generation (manual edits will be lost) config_protected false Any user who opens the config in an editor should understand that a change needs to be made to switch off auto-generation, they can most likely infer the syntax they want or go read the documentation. Ben ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
On Thu, Mar 31, 2011 at 08:59:05AM -0500, richardvo...@gmail.com wrote: I've wondered occasionally whether it would be worth it to include something like GRUB_STATIC in upstream grub-mkconfig; if set, this would cause grub-mkconfig to do nothing, perhaps printing a message. This would mean you wouldn't have to figure out how to disable distribution facilities that run grub-mkconfig for you; you could just set GRUB_STATIC=1 and write your own grub.cfg if you wanted. Vladimir, do you think you'd take such a change for 1.99? Based on other messages in this thread, this likely wouldn't be very effective. Boot from a LiveCD? It won't have GRUB_STATIC set. Sure it will. If you're generating $pathtoroot/boot/grub/grub.cfg, then that will be based on $pathtoroot/etc/default/grub. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Your contributions to grub.enbug.org
Hello, when discussing after the temporary wiki problems it was decided that it would be better to migrate the information from wiki into the manual and developper manual where legal reasons permit. You have contributed to the wiki, would you agree to consider that your contributor agreement covers wiki as well? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Your contributions to grub.enbug.org
On Thu, 31 Mar 2011 21:17:10 +0200 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: Hello, when discussing after the temporary wiki problems it was decided that it would be better to migrate the information from wiki into the manual and developper manual where legal reasons permit. You have contributed to the wiki, would you agree to consider that your contributor agreement covers wiki as well? I agree that all my contributions to the GRUB wiki are covered by my contributor agreement. Regards, Colin signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Your contributions to grub.enbug.org
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, when discussing after the temporary wiki problems it was decided that it would be better to migrate the information from wiki into the manual and developper manual where legal reasons permit. You have contributed to the wiki, would you agree to consider that your contributor agreement covers wiki as well? Yes. No problem. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Fwd: Your contributions to grub.enbug.org
Sorry, Carles. Forgot to add you. Original Message Subject:Your contributions to grub.enbug.org Date: Thu, 31 Mar 2011 21:17:10 +0200 From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com To: Yoshinori K. Okuji ok...@gnu.org, Felix Zielcke fziel...@z-51.de, Robert Millan r...@gnu.org, plr.vinc...@gmail.com, ch...@nic.fi, Colin Watson cjwat...@debian.org, Lubomir Rintel lkund...@v3.sk, Yves Blusseau bluss...@zetam.org, Colin D Bennett co...@gibibit.com, Marco Gerards mgera...@xs4all.nl, Grégoire Sutre gregoire.su...@gmail.com CC: The development of GRUB 2 grub-devel@gnu.org Hello, when discussing after the temporary wiki problems it was decided that it would be better to migrate the information from wiki into the manual and developper manual where legal reasons permit. You have contributed to the wiki, would you agree to consider that your contributor agreement covers wiki as well? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Your contributions to grub.enbug.org
Le jeudi 31 mars 2011 21:17:10, vous avez écrit : would you agree to consider that your contributor agreement covers wiki as well? Sure, no problem. -- Vincent Pelletier ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Your contributions to grub.enbug.org
On 03/31/2011 09:17 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, when discussing after the temporary wiki problems it was decided that it would be better to migrate the information from wiki into the manual and developper manual where legal reasons permit. You have contributed to the wiki, would you agree to consider that your contributor agreement covers wiki as well? Yes, I agree that my contributor agreement covers wiki as well. Grégoire ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: Your contributions to grub.enbug.org
Yes, I do agree. On Mar/31/2011, Vladimir '??-coder/phcoder' Serbinenko wrote: Sorry, Carles. Forgot to add you. Original Message Subject: Your contributions to grub.enbug.org Date: Thu, 31 Mar 2011 21:17:10 +0200 From: Vladimir '??-coder/phcoder' Serbinenko phco...@gmail.com To: Yoshinori K. Okuji ok...@gnu.org, Felix Zielcke fziel...@z-51.de, Robert Millan r...@gnu.org, plr.vinc...@gmail.com, ch...@nic.fi, Colin Watson cjwat...@debian.org, Lubomir Rintel lkund...@v3.sk, Yves Blusseau bluss...@zetam.org, Colin D Bennett co...@gibibit.com, Marco Gerards mgera...@xs4all.nl, Grégoire Sutre gregoire.su...@gmail.com CC: The development of GRUB 2 grub-devel@gnu.org Hello, when discussing after the temporary wiki problems it was decided that it would be better to migrate the information from wiki into the manual and developper manual where legal reasons permit. You have contributed to the wiki, would you agree to consider that your contributor agreement covers wiki as well? -- Regards Vladimir '??-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
