grub.enbug.org wiki database dump
Hi, I am user of grub2 and have edited a few wiki articles. YOu seems to have taken back control of this domain name. Can you make available the latest wiki database dump so that it can be hosted elsewhere. I am particularly interested in http://grub.enbug.org/TestingOnMacbook page (BIOS specific info is in official grub manual anyway). Thanks in advance. Regards. Keshav ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Improve documentation of BIOS installation
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. There actually was some, written variously by Vladimir and me,
but I felt that it could use a bit of reorganisation, and being put into
a form where we could give out a single link that discusses all the BIOS
installation issues in one place rather than being scattered around the
manual.
What do you think of this patch? It consolidates the existing
documentation into a new "BIOS installation" section and adds some
cross-references; I also wrote some new text to try to explain things
more clearly.
2011-03-29 Colin Watson
* docs/grub.texi (BIOS installation): New section, partly based on
previous text in other sections.
(Installing GRUB using grub-install): Replace BIOS discussion with a
cross-reference.
(Images): Likewise.
=== modified file 'docs/grub.texi'
--- docs/grub.texi 2011-03-09 17:35:16 +
+++ docs/grub.texi 2011-03-29 12:22:33 +
@@ -550,6 +550,7 @@ the @dfn{boot directory}.
* Installing GRUB using grub-install::
* Making a GRUB bootable CD-ROM::
* Device map::
+* BIOS installation::
@end menu
@@ -565,13 +566,8 @@ always. Therefore, GRUB provides you wit
@dfn{device map}, which you must fix if it is wrong. @xref{Device
map}, for more details.
-On BIOS platforms GRUB has to use a so-called embedding zone. On msdos
-partition tables, this is the space between the MBR and the first partition
-(called the MBR gap or the boot track), while on GPT partition tables it
-uses a BIOS Boot Partition (a partition with GUID
-21686148-6449-6e6f-744e656564454649). If you use GRUB on a BIOS system, make
-sure that the embedding zone is at least 31 KiB (512KiB or more
-recommended).
+For information on where GRUB should be installed on PC BIOS platforms,
+@pxref{BIOS installation}.
If you still do want to install GRUB under a UNIX-like OS (such
as @sc{gnu}), invoke the program @command{grub-install} (@pxref{Invoking
@@ -744,6 +740,70 @@ comments in the file if needed, as the G
just a comment if the first character is @samp{#}.
+@node BIOS installation
+@section BIOS installation
+
+@heading MBR
+
+The partition table format traditionally used on PC BIOS platforms is called
+the Master Boot Record (MBR) format; this is the format that allows up to
+four primary partitions and additional logical partitions. With this
+partition table format, there are two ways to install GRUB: it can be
+embedded in the area between the MBR and the first partition (called by
+various names, such as the "boot track", "MBR gap", or "embedding area", and
+which is usually at least 31 KiB), or the core image can be installed in a
+file system and a list of the blocks that make it up can be stored in the
+first sector of that partition.
+
+Each of these has different problems. There is no way to reserve space in
+the embedding area with complete safety, and some proprietary software is
+known to use it to make it difficult for users to work around licensing
+restrictions; and systems are sometimes partitioned without leaving enough
+space before the first partition. On the other hand, installing to a
+filesystem means that GRUB is vulnerable to its blocks being moved around by
+filesystem features such as tail packing, or even by aggressive fsck
+implementations, so this approach is quite fragile; this approach also has
+reliability problems if the @file{/boot} filesystem is not on the disk the
+BIOS boots from, because GRUB must rely on guessing BIOS drive numbers.
+
+The GRUB development team generally recommends embedding GRUB before the
+first partition, unless you have special requirements. You must ensure that
+the first partition starts at least 31 KiB (63 sectors) from the start of
+the disk; on modern disks, it is often a performance advantage to align
+partitions on larger boundaries anyway, so the first partition might start 1
+MiB from the start of the disk.
+
+@heading GPT
+
+Some newer systems use the GUID Partition Table (GPT) format. This was
+specified as part of the Extensible Firmware Interface (EFI), but it can
+sometimes also be used on BIOS platforms. With this format, it is possible
+to reserve a whole partition for GRUB, called the BIOS Boot Partition. GRUB
+can then be embedded into that partition without the risk of being
+overwritten by other software and without being contained in a filesystem
+which might move its blocks around.
+
+When creating a BIOS Boot Partition on a GPT system, you should make sure
+that it is at least 31 KiB in size. (GPT-formatted disks are not usually
+particularly small, so we recommend that you make it larger than the bare
+minimum, such as 1 MiB, to allow plenty of room for growth.) You must also
+make sure that it has the proper partition type. Using GNU Parted, you can
+set this using a command such as the following:
+
+@example
+# @kbd{p
Re: [PATCH] Improve documentation of BIOS installation
On 29/03/11 13:40, Colin Watson wrote: > +@node BIOS installation > +@section BIOS installation This is a good summary. > +(called by > +various names, such as the "boot track", "MBR gap", or "embedding area", and > +which is usually at least 31 KiB), Maybe mention the original name/reason; "DOS compatibility region" I'll link to this node from http://www.pixelbeat.org/docs/disk/ when it appears on line. cheers, Pádraig. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Improve documentation of BIOS installation
On 29.03.2011 15:11, Pádraig Brady wrote: > On 29/03/11 13:40, Colin Watson wrote: > >> +@node BIOS installation >> +@section BIOS installation >> > This is a good summary. > > >> +(called by >> +various names, such as the "boot track", "MBR gap", or "embedding area", and >> +which is usually at least 31 KiB), >> > Maybe mention the original name/reason; "DOS compatibility region" > > I think this name would be misleading since one can think that one needs it for DOS to load or that DOS would overwrite GRUB if it's installed on the disk. Since this term is rarely used I'd prefer to omit it. > I'll link to this node from http://www.pixelbeat.org/docs/disk/ > when it appears on line. > > cheers, > Pádraig. > > ___ > 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: grub.enbug.org wiki database dump
On Tue, Mar 29, 2011 at 4:11 AM, KESHAV P.R. wrote: > Hi, > I am user of grub2 and have edited a few wiki articles. YOu seems > to have taken back control of this domain name. Can you make available > the latest wiki database dump so that it can be hosted elsewhere. I am > particularly interested in http://grub.enbug.org/TestingOnMacbook page > (BIOS specific info is in official grub manual anyway). Thanks in > advance. > > Regards. > > Keshav > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > Hello! Which individual are you thinking of? Please explain what you perceive here as the problem. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.enbug.org wiki database dump
On Tue, Mar 29, 2011 at 19:58, Gregg Levine wrote: > On Tue, Mar 29, 2011 at 4:11 AM, KESHAV P.R. wrote: >> Hi, >> I am user of grub2 and have edited a few wiki articles. You seem >> to have taken back control of this domain name. Can you make available >> the latest wiki database dump so that it can be hosted elsewhere. I am >> particularly interested in http://grub.enbug.org/TestingOnMacbook page >> (BIOS specific info is in official grub manual anyway). Thanks in >> advance. >> >> Regards. >> >> Keshav >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel >> > > Hello! > Which individual are you thinking of? Please explain what you perceive > here as the problem. > The exact problem is the only grub2 wiki site grub.enbug.org has been taken back by its owner (I don't know whether its you or any other guy). I (and the grub2 devs) just want a dump of the wiki articles that existed in the site so that it can be hosted elsewhere. Thats all. Regards. Keshav > - > Gregg C Levine gregg.drw...@gmail.com > "This signature fought the Time Wars, time and again." > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Improve documentation of BIOS installation
On Tue, Mar 29, 2011 at 02:11:45PM +0100, Pádraig Brady wrote: > On 29/03/11 13:40, Colin Watson wrote: > > +@node BIOS installation > > +@section BIOS installation > > This is a good summary. Thanks. I've incorporated some feedback from Vladimir and committed this. Vladimir and I disagreed a bit over what the traditional partition table scheme should be called. Other parts of the GRUB manual describe it as "msdos", which is also the identifier used in GNU Parted's UI; and he pointed out that MBR is also used to refer to sector 0. I'm uncomfortable with the lower case there, and I also don't like attributing the scheme to a single company and (proprietary) operating system in a GNU manual. The GNU Parted manual uses "MS-DOS" in a number of places where prose is more suitable than the identifier, although some of the documentation it should have has "moved" to the non-existent "GNU Storage Guide". http://en.wikipedia.org/wiki/Master_Boot_Record talks about the "MBR partition table scheme", although I haven't checked to see whether that's long-lived terminology on Wikipedia. The GPT specification uses MBR in both senses: it refers to the "MBR disk layout", and also to the MBR which may be located at LBA 0. I like this terminology because it's company- and OS-neutral, although it does require careful phrasing in order to be clear. Does anyone have preferences here? I left it as "MBR" in my commit for the time being, although there may well be scope for a rephrasing through the whole manual. > > +(called by > > +various names, such as the "boot track", "MBR gap", or "embedding area", > > and > > +which is usually at least 31 KiB), > > Maybe mention the original name/reason; "DOS compatibility region" Vladimir's reaction was that a casual reader might think "Huh? What does this have to do with compatibility". Do you have a reference for this being the original name? > I'll link to this node from http://www.pixelbeat.org/docs/disk/ > when it appears on line. http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation You might like to link to (or contribute to!) http://www.gnu.org/software/grub/manual/grub.html#Images as well, in the context of your document. Cheers, -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.enbug.org wiki database dump
On Tue, Mar 29, 2011 at 10:28:45AM -0400, Gregg Levine wrote: > Which individual are you thinking of? Please explain what you perceive > here as the problem. Gregg, Keshav's mail was sent to a specific individual and CCed to grub-devel. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub.enbug.org wiki database dump
On Tue, Mar 29, 2011 at 11:15 AM, Colin Watson wrote: > On Tue, Mar 29, 2011 at 10:28:45AM -0400, Gregg Levine wrote: >> Which individual are you thinking of? Please explain what you perceive >> here as the problem. > > Gregg, Keshav's mail was sent to a specific individual and CCed to > grub-devel. > > -- > Colin Watson [cjwat...@ubuntu.com] > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > Hello! Understood. I wanted to make sure it wasn't anything caused by any of the regular group. Having looked at the site, I now clearly see the problem exactly as you and I, and of course, Keshav, understand it. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
schrieb Treutwein Bernhard am 2011-03-24 16:06: > Hi Bill & Robert, > > [...] >>> Is there some complete official documentation of GRUB2, or is GRUB2 full >>> documentation only in source code?;-) >> >> I think the Grub2 developers would welcome volunteers to help write >> documentation. > > this is kind of a hen & egg problem. > > I have no idea how I can find out how to use modules where I > have to guess how to use them. There was a nice remark on > by phcoder on the request list that there are usb mass storage > and uhci & ehci modules, which I tried and I was able to confirm > that insmod'ing uhci.mod and usbms.mod on a system, which is not > able to boot via bios from usb, enabled this system to boot > from usb by chainloading (usb0)+1. But it is very time consuming > and frustrating to experiment with different modules just for > documentation. I had a simmilar experience regarding the loopback system - which is by itself really great. The manual gives a hint of the command, but no description and no example. I got some working examples from Ubuntu [ubuntu] and from pendrivelinux.com [pendrive:0][pendrive:1], but no documentation. >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. Others can then edit this information into nice manuals and spice it with examples (which they can figure out easily with the raw docs). 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... ;-) Patrick [ubuntu] https://help.ubuntu.com/community/Grub2 [pendrive:0]http://www.pendrivelinux.com/boot-multiple-iso-from-usb-via-grub2-using-linux/ [pendrive:1] http://pendrivelinux.com/downloads/multibootlinux/grub.cfg 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: [PATCH] Improve documentation of BIOS installation
> -@strong{Caution:} Be very careful which partition you select! When GRUB
> -finds a BIOS Boot Partition during installation, it will automatically
> -overwrite part of it. Make sure that the partition does not contain any
> -other data.
+@xref{BIOS installation}, for details on where the core image can be
+installed on PC systems.
I would suggest NOT moving warnings into links introduced as "for
details". Something should be kept here, like:
( ! ) Caution: If your system has a BIOS Boot Partition, GRUB
automatic installation will overwrite it and data could be lost. Be
sure to read @xref{BIOS installation/GPT}.
And then that section needs to also contain a simple test which users
can do to discover that they have no BIOS Boot Partition to worry
about.
Please also check whether it's more correct to say that GRUB will
automatically overwrite during installation, or GRUB will overwrite
during automatic installation.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
On Tue, Mar 29, 2011 at 05:19:09PM +0200, Patrick Strasser wrote: > I had a simmilar experience regarding the loopback system - which is by > itself really great. The manual gives a hint of the command, but no > description and no example. I got some working examples from Ubuntu > [ubuntu] and from pendrivelinux.com [pendrive:0][pendrive:1], but no > documentation. I've committed documentation of this command to trunk. 2011-03-29 Colin Watson * docs/grub.texi (loopback): New section. 13.3.25 loopback -- Command: loopback [`-d'] device file Make the device named DEVICE correspond to the contents of the filesystem image in FILE. For example: loopback loop0 /path/to/image ls (loop0)/ With the `-d' option, delete a device previously created using this command. > >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. 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. > I'd like to contribute examples that I found to the grub docs, but the > manual gives no hint how to do so... ;-) Send patches against docs/grub.texi in GRUB trunk. If that's too hard, send plain-text suggestions and somebody can deal with marking them up. Note, though, that GRUB is a GNU project and thus contributions to it need to be copyright-assigned to the FSF: http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html http://www.gnu.org/licenses/why-assign.html If you aren't willing or able to do this, it would be better to describe your suggestion in general terms so that somebody who's done the assignment thing can write something up. But if you are, we can incorporate specific text from you. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: RFC: Plan for new "hwmatch" command
On Wed, Nov 17, 2010 at 08:58:43PM -0800, Evan Broder wrote:
>Based on some off-list discussion, I'd like to try a different
> angle for the Lua patches I submitted a week or two ago. For context,
> Ubuntu is interested in setting gfxpayload=keep as often as we can in
> the next release [1]. Since gfxpayload=keep doesn't work with all
> hardware/driver combinations, we need a way to selectively turn it on,
> based on a whitelist or blacklist.
This is an implementation of Evan's original proposal in C. I realise
that there was feedback on the list
(http://lists.gnu.org/archive/html/grub-devel/2010-11/msg00038.html)
that I haven't incorporated; my initial priority was solely to avoid
needing to ship the Lua grub-extras module in Ubuntu 11.04, since we had
feedback from Robert Millan among others that this would be undesirable.
I rather expect that any upstreamable implementation of this would want
to be built on more than just i386_pc, too.
But in case anyone is interested in using this as a starting point:
=== modified file 'grub-core/Makefile.core.def'
--- grub-core/Makefile.core.def 2011-03-26 11:59:02 +
+++ grub-core/Makefile.core.def 2011-03-29 15:10:11 +
@@ -595,6 +595,15 @@ module = {
};
module = {
+ name = hwmatch;
+ i386_pc = commands/i386/pc/hwmatch.c;
+ enable = i386_pc;
+ ldadd = libgnulib.a;
+ cflags = '$(CFLAGS_POSIX) $(CFLAGS_GNULIB)';
+ cppflags = '$(CPPFLAGS_POSIX) $(CPPFLAGS_GNULIB)';
+};
+
+module = {
name = keystatus;
common = commands/keystatus.c;
};
=== added file 'grub-core/commands/i386/pc/hwmatch.c'
--- grub-core/commands/i386/pc/hwmatch.c1970-01-01 00:00:00 +
+++ grub-core/commands/i386/pc/hwmatch.c2011-03-29 20:29:07 +
@@ -0,0 +1,139 @@
+/* hwmatch.c - Match hardware against a whitelist/blacklist. */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2011 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see
Re: Out of Memory Error
Thanks for your reply. First of all, the error is "Out of disk", not "Out of memory", my bad > Are you able to see the devices needed for boot if you type > "ls" ? > Also adding --debug-image=all to grub-install would enable > extra debug messages > Regards Vladimir 'φ-coder/phcoder' Serbinenko Yes I can see the devices needed to boot, when typing ls. After adding --debug-image=all here's what I get kern/disk.c: 245: Opening 'hd0,msdos1' ... partmap/msdos.c: 101: partition 0: flag 0x0, type 0x83, start 0x3f, len 0x75286e0 kern/fs.c: 54: Detecting ext2 ... kern/disk.c: 397: Read out of range: sector 0x440013f (out of disk). kern/disk.c: 330: Closing 'hd0' error: out of disk Entering rescue mode ... grub rescue> ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Out of Memory Error
On Mon, Mar 28, 2011 at 2:56 PM, Gus Zernial wrote: > I've posted my problem to this list before without getting a > solution - also to grub-help and Ubuntu forum(s), no answer - I'm > stumped and would really appreciate help. > > I have Kubuntu 10.10, a custom 2.6.37.1 kernel, and GRUB2. I was on > v1.98 when the problem started, I'm now on 1.99~rc1 which I downloaded > and compiled, the upgrade didn't help. > > My system has three disks - / is on an SSD, and /home is on the other Which SSD? This sounds rather like the infamous OCZ time warp. Are other changes made to the SSD lost, or only the boot sector? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Out of Memory Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/29/2011 05:48 PM, richardvo...@gmail.com wrote: > Which SSD? This sounds rather like the infamous OCZ time warp. Are > other changes made to the SSD lost, or only the boot sector? What OCZ time warp? I have an OCZ SSD and don't have any trouble with it. Hadn't noticed anything about this on their forums either. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2SfjsACgkQJ4UciIs+XuJiSgCfQGMZYEPxOd/+j/eXhT0WMWQo LLgAnidmNarKjR2k+kqzu+/SYknul/np =PIV/ -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Out of Memory Error
2011/3/29 Gus Zernial : > 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
Re: Out of Memory Error
> On 03/29/2011 05:48 PM, richardvo...@gmail.com wrote: >> Which SSD? This sounds rather like the infamous OCZ time warp. Are >> other changes made to the SSD lost, or only the boot sector? On Tue, Mar 29, 2011 at 7:50 PM, Phillip Susi wrote: > What OCZ time warp? I have an OCZ SSD and don't have any trouble with > it. Hadn't noticed anything about this on their forums either. I don't have any trouble with mine either, but it seems to plague certain systems. It was discussed extensively during the most recent firmware release cycle, which is how I learned about it. http://www.ocztechnologyforum.com/forum/search.php?securitytoken=guest&do=process&query=%22time%20warp%22 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
RE: Full documentation for GRUB2
> -Original Message- > From: help-grub-bounces+lrhorer=satx.rr@gnu.org [mailto:help-grub- > bounces+lrhorer=satx.rr@gnu.org] On Behalf Of Colin Watson > Sent: Tuesday, March 29, 2011 11:10 AM > To: grub-devel@gnu.org > Cc: help-g...@gnu.org > Subject: Re: Full documentation for GRUB2 > > >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. 'Not only that, but having the ability to speak to a machine does not necessarily imply the ability to speak to another human being. In the simplest case, the user and the developer may not have any human language in common. While the United States holds the greatest share of both developers and users, and while the USA is populated mostly by English speaking individuals, there are many people from both groups whose contribution to either is significant yet do not speak English. It is certainly no disgrace to come from a non-English speaking country. Even some people who do speak English well enough, however, are not capable of writing good documentation, regardless of how close or distant they may be to the subject at hand. Not to put too fine a point on it, some excellent code writers are just plain lousy at technical writing. It doesn't help any at all that writing documentation is far less satisfying and far more tedious than writing code. > 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. I sympathize, but only to a point. No matter how dreary or how daunting the volume of work, it is essential it be done. > 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. Point well taken. OK, here is what I might hope is a start: The first thing I want to know about any application is what it can and cannot do. It's very frustrating to search diligently for a means to accomplish something only to find in the end it can't be done at all. Conversely, failing to know something can be done potentially produces essentially the same result as if the developer had never bothered to implement the feature in the first place. In short, simply knowing whether something is supported by an application or not is half the battle. I think a good example of this is the sort order of the items in the boot list. Under GRUB legacy, editing the menu list order was quite simple. I did some significant searching to try to find a way to do this with GRUB 2, but as far as I was able to determine, there is no way to do it. Eventually I just gave up. If there is in fact a way, it would have been really nice for it to be fully documented, but if there were at least a reference to it being possible, I would not have given up. OTOH, a reference to it being not possible would have saved me a fair bit of trouble, or at least have induced me to request a feature, rather than fruitlessly searching for one which does not exist. On a related note, there does not seem to be any way to associate the default boot selection with a particular target. To the best of my ability to tell, one may only specify a specific entry number within the boot target list, not a specific target. Thus, if one, for example, has the third kernel target set as the default and then removes the second kernel from the drive, GRUB will now point to what was originally was the fourth kernel. Neither of these would have been an insurmountable issue in GRUB Legacy, but as far as I can tell, they are in GRUB 2. A simple, relatively brief list of the features in GRUB2 would be quite helpful, along with notations of which features are new, which are not, and which are no longer available would be extremely helpful. > > I'd like to contribute examples that I found to the grub docs, but the > > manual gives no hint how to do so... ;-) > > Send patches against docs/grub.texi in GRUB trunk. If that's too hard, > send plain-text suggestions and somebody can deal with marking them up. > > Note, though, that GRUB is a GNU project and thus contributions to it > need to be copyright-assigned to the FSF: > > http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html > http://www.gnu.org/licenses/w
Re: Full documentation for GRUB2
On 30.03.2011 03:18, Leslie Rhorer wrote:
> On a related note, there does not seem to be any way to associate
> the default boot selection with a particular target. To the best of my
> ability to tell, one may only specify a specific entry number within the
> boot target list, not a specific target. Thus, if one, for example, has the
> third kernel target set as the default and then removes the second kernel
> from the drive, GRUB will now point to what was originally was the fourth
> kernel.
>
>
Well documentation also needs to be read, not only written:
http://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html#Simple-configuration:
"The default menu entry. This may be a number, in which case it identifies
the Nth entry in the generated menu counted from zero, or the full name of a
menu entry, or the special string @samp{saved}. Using the full name may be
useful if you want to set a menu entry as the default even though there may
be a variable number of entries before it.
"
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
Leslie Rhorer wrote: I sympathize, but only to a point. No matter how dreary or how daunting the volume of work, it is essential it be done. I agree. I looked into helping do some of the documentation, but found that I just did not know enough of the internals to properly do it. I think a good example of this is the sort order of the items in the boot list. Under GRUB legacy, editing the menu list order was quite simple. I did some significant searching to try to find a way to do this with GRUB 2, but as far as I was able to determine, there is no way to do it. There is a way. Use emacs or vim. There is nothing that demands you use grub-mkconfig. It is fine for someone who uses a distribution and knows very little about the internals, but in my opinion, it just gets in the way of knowledgeable users. I'd like to contribute examples that I found to the grub docs, but the manual gives no hint how to do so... ;-) Send patches against docs/grub.texi in GRUB trunk. If that's too hard, send plain-text suggestions and somebody can deal with marking them up. Well, I might also like to contribute in some way, but speaking for myself, I don't even know where to start. Knowing where and how to submit documentation is not really the starting point. First one must know what GRUB can do and how one can make it do it. For those of us who did not develop GRUB 2, it's rather a chicken and egg problem. I agree. About the only was is to study the source and look at other (e.g. Multiboot) documentation. Unfortunately the source is really hard for a newbie to follow. You really have to understand the intricacies of a lot of different systems. I understand what's needed for the PC for DOS and Linux, but get lost in all the other file systems and BIOS issues. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
On 03/29/11 21:18, Leslie Rhorer wrote:
I think a good example of this is the sort order of the items in the
boot list. Under GRUB legacy, editing the menu list order was quite simple.
I did some significant searching to try to find a way to do this with GRUB
2, but as far as I was able to determine, there is no way to do it.
(warning - I haven't reinstalled my GRUB2 since some devel version
between 1.97 and 1.98, IIRC, so my experience *might* be outdated)
I maintain my own GRUB2 /boot/grub/grub.cfg . The sort order of the
items is exactly the order I write the menuentry "" {}s in the file. I
can re-order by moving the order of the entries in the file. Did you
start with a different-looking grub.cfg than mine? I heard that some
distros have been automatically generating some more-complicated
grub.cfgs: that might be complicating the grub-config-script ecosystem?
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Full documentation for GRUB2
On Tue, Mar 29, 2011 at 07:18:02PM -0600, Leslie Rhorer wrote: > Colin Watson wrote: > > 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. > > I sympathize, but only to a point. No matter how dreary or how > daunting the volume of work, it is essential it be done. Oh, I wan't trying to make excuses. It clearly needs to happen, and as I say I've made a reasonable dent in the backlog - just not as much as is needed. > > 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. > > Point well taken. OK, here is what I might hope is a start: > > The first thing I want to know about any application is what it can > and cannot do. It's very frustrating to search diligently for a means to > accomplish something only to find in the end it can't be done at all. > Conversely, failing to know something can be done potentially produces > essentially the same result as if the developer had never bothered to > implement the feature in the first place. In short, simply knowing whether > something is supported by an application or not is half the battle. > > I think a good example of this is the sort order of the items in the > boot list. Under GRUB legacy, editing the menu list order was quite simple. > I did some significant searching to try to find a way to do this with GRUB > 2, but as far as I was able to determine, there is no way to do it. > Eventually I just gave up. If there is in fact a way, it would have been > really nice for it to be fully documented, but if there were at least a > reference to it being possible, I would not have given up. OTOH, a > reference to it being not possible would have saved me a fair bit of > trouble, or at least have induced me to request a feature, rather than > fruitlessly searching for one which does not exist. 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 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 Booting::, and *note Shell-like scripting::), and to disable any system provided by their distribution to automatically run `grub-mkconfig'. (Remember that the biggest thing that often isn't obvious to developers is what their users find non-obvious!) > On a related note, there does not seem to be any way to associate > the default boot selection with a particular target. To the best of my > ability to tell, one may only specify a specific entry number within the > boot target list, not a specific target. Thus, if one, for example, has the > third kernel target set as the default and then removes the second kernel > from the drive, GRUB will now point to what was originally was the fourth > kernel. As Vladimir notes, the documentation does actually already say that you can set the default by menu entry title as well as by number (which wasn't possible in GRUB Legacy, incidentally, at least in any of the savedefault patches I ever saw). > Neither of these would have been an insurmountable issue in GRUB > Legacy, but as far as I can tell, they are in GRUB 2. A simple, relatively > brief list of the features in GRUB2 would be quite helpful, along with > notations of which features are new, which are not, and which are no longer > available would be extremely helpful. I added such a list to the manual a while ago: http://www.gnu.org/software/grub/manual/grub.html#Changes-from-GRUB-Legacy There's also http://www.gnu.org/software/grub/manual/grub.html#Features, which has been around a bit longer. > Well, I might also like to contribute in some way, but speaking for > myself, I don't even know where to start. Knowing where and how to submit > documentation is not really the starting point. First one must know what > GRUB can do and how one can make it do it. For those of us who did not > develop GRUB 2, it's rather a chicken and egg problem. I think that in many cases examples could be written by non-developers. Also, one set of necessary tasks is to complete the GRUB command reference in the manual. Doing so does normally involve code inspection,
Re: terminal_input=at_keyboard not working
Le Wed, 23 Mar 2011 20:34:36 +0100, Vladimir 'φ-coder/phcoder' Serbinenko a écrit : > Could you try this patch: > === modified file 'grub-core/term/at_keyboard.c' > --- grub-core/term/at_keyboard.c2011-01-08 00:45:57 + > +++ grub-core/term/at_keyboard.c2011-03-23 19:33:57 + > @@ -330,6 +330,11 @@ >return; > } > > +#if !(defined (GRUB_MACHINE_MIPS_YEELOONG) || defined > (GRUB_MACHINE_QEMU)) > + current_set = 1; > + return; > +#endif > + >grub_keyboard_controller_write (grub_keyboard_controller_orig >& ~KEYBOARD_AT_TRANSLATE); Hello Vladimir, I've tested your patch (adapted a little bit) on latest Debian's grub-pc package (1.99-rc1-6), and it worked well, my HP laptop doesn't freeze at Grub boot, and I can now use my custom keyboard layout ! Thanks, Fred. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
