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 > To: Yoshinori K. Okuji , Felix Zielcke > , Robert Millan , plr.vinc...@gmail.com, > ch...@nic.fi, Colin Watson , Lubomir Rintel > , Yves Blusseau , Colin D Bennett > , Marco Gerards , Grégoire Sutre > > CC: The development of GRUB 2 > > > > 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
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: 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
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 To: Yoshinori K. Okuji , Felix Zielcke , Robert Millan , plr.vinc...@gmail.com, ch...@nic.fi, Colin Watson , Lubomir Rintel , Yves Blusseau , Colin D Bennett , Marco Gerards , Grégoire Sutre CC: The development of GRUB 2 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
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
Re: Your contributions to grub.enbug.org
On Thu, 31 Mar 2011 21:17:10 +0200 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? 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
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: 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
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
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
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
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: Testing On Macbook on enbug.org
On Thu, Mar 31, 2011 at 05:59, 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. > 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 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: [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 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: 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 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: Full documentation for GRUB2
On Wed, Mar 30, 2011 at 07:15:37PM -0600, Leslie Rhorer wrote: > Colin Watson wrote: > > That's a reasonable point, thanks. I've added this text to the "Simple > > configuration" node: > > > > `grub-mkconfig' does have some limitations. While adding extra > > custom menu entries to the end of the list can be done by editing > > `/etc/grub.d/40_custom' or creating `/boot/grub/custom.cfg', changing > > the order of menu entries or changing their titles may require making > > complex changes to shell scripts stored in `/etc/grub.d/'. This may be > > Yeah, exactly, or perhaps more accurately, not exactly. I'm not > grousing at you or anyone else who has contributed to the very large volume > of work that has clearly gone into GRUB2, but digging into the shell > scripts involved with GRUB 2 can be rather daunting. I say that as someone > who has far more than a passing familiarity with *nix scripting. The above paragraph isn't intended to indicate that it's easy to hack those scripts, just that it's the only option right now if you want to use grub-mkconfig while doing those things. I tried to make it clear by the phrasing that we considered this a problem, too. > > improved in the future. In the meantime, those who feel that it would > > be easier to write `grub.cfg' directly are encouraged to do so (*note > > Easier? I'm not sure that it is. More importantly, it may not be > effective. In particular it isn't reliably permanent. Even discounting > distro upgrades, I can't count the number of times I have had to run > update-grub or had it run for me. This is why I said "and to disable any system provided by their distribution to automatically run `grub-mkconfig'". I don't think we can sensibly include details in the upstream distribution. On Debian/Ubuntu, you can reliably disable all automatic calls to update-grub like this: dpkg-divert --rename --add /usr/sbin/update-grub ln -s /bin/true /usr/sbin/update-grub (To undo this, 'rm /usr/sbin/update-grub; dpkg-divert --rename --remove /usr/sbin/update-grub'.) 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? > Can you say, "Countless Kernel Upgrades"? That's indeed a situation where grub-mkconfig really helps. grub-mkconfig was originally written by Debian people, and thus grew out of the 'update-grub' script shipped in Debian's GRUB Legacy packages. Debian ships versioned kernel images, and so it's important to keep boot loader configuration up to date on Debian. One of the problems with the GRUB Legacy version of update-grub was that it mixed input and output in a single file. This had the virtue that you could edit menu.lst and your changes would be preserved, at least if you did it the right way; on the other hand, you had to be careful to edit only parts of that file marked with magic comments, and this frequently confused users who found that their changes were not as permanent as they thought. grub-mkconfig makes a strict separation between input and output to try to avoid this problem, but that creates new problems that grub-mkconfig has to support all the different kinds of configuration you might possibly want. It's not an easy problem. > From my reading previously, not to mention what I think I understand of GRUB > 2's engineering paradigms, I inferred manually editing grub.cfg was not a > particularly good idea. For example, one of the tutorials I read when > making the move from GRUB Legacy was here: > > http://ubuntuforums.org/showthread.php?t=1195275 > > Of course, this does not constitute official documentation, but in > this tutorial the author repeatedly stresses things such as the following: > > " Manual editing of /boot/grub/grub.cfg is not encouraged. Think of grub.cfg > as a result, not as an initiator..." > > What's more, this isn't the only place I have seen such suggestions. > Such references are easily found, by far not the least (apparently) > authoritative of which is the text at the very top of the grub.cfg file > itself: > > # > # DO NOT EDIT THIS FILE > # > # It is automatically generated by grub-mkconfig using templates > # from /etc/grub.d and settings from /etc/default/grub > > If you ask me, that seems pretty dismissive of the idea the admin > should manually edit grub.cfg. You must not edit grub.cfg if grub-mkconfig is going to overwrite it. However, if you're in a situation where your boot environment is relatively static - and there's a pretty decent constituency of people in such a situation, then there really is absolutely no reason why
