Re: Experiments with git. Hold your commits for today
On 10/22/2013 02:24 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 22.10.2013 11:33, Vladimir 'φ-coder/phcoder' Serbinenko wrote: As was discussed previously, move to git is generally considered positive with noone opposing it strongly. So I'll try to do the move. 5405 is the latest currect revision. I back up the whole bzr repo including personal branches. After this I'll attempt to do git. Depending on results I'll either move forward or rollback. GIT repo is up and running now it's main repo. You can commit your patches to it. Keep a copy of any patch you commit in case I have to reimport repository. Where is the new Git repo? The download page is now out of date: https://www.gnu.org/software/grub/grub-download.html Thanks, -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Lists and aliasing (Re: Freeze on 27 February)
On 02/22/2012 06:03 PM, Lennart Sorensen wrote: On Wed, Feb 22, 2012 at 05:50:37PM -0500, Lennart Sorensen wrote: Now I get: gcc-4.6 -DHAVE_CONFIG_H -I. -I../../../grub-core -I.. -Wall -W -I../../../include -I../include -DGRUB_MACHINE_EMU=1 -DGRUB_MACHINE=POWERPC_EMU -DGRUB_TARGET_CPU_POWERPC=1 -m32 -DGRUB_FILE=\"normal/charset.c\" -I. -I../../../grub-core -I.. -I../../.. -I../../../include -I../include -I../../../grub-core/lib/posix_wrap -Os -Wall -W -Wshadow -Wold-style-declaration -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Warray-bounds -Wattributes -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcoverage-mismatch -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wempty-body -Wendif-labels -Wfloat-equal -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wunsafe-loop-optimizations -Wlogical-op -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-fo rmat-attribute -Wmissing-noreturn -W mudflap -Wmultichar -Wnonnull -Woverflow -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wsync-nand -Wtrigraphs -Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wmissing-parameter-type -Wnested-externs -Wstrict-prototypes -Wpointer-sign -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -m32 -fno-stack-protector -Werror -Wno-trampolines -DUSE_ASCII_FAILBACK=1 -DHAVE_UNIFONT_WIDTHSPEC=1 -ffreestanding -fno-builtin -Wno-redundant-decls -c -o normal/normal_module-charset.o `test -f 'normal/charset.c' || echo '../../../grub-core/'`normal/charset.c ../../../grub-core/normal/charset.c: In function 'bidi_line_wrap': ../../../grub-core/normal/charset.c:737:55: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] cc1: all warnings being treated as errors For some reason the compiler thinks GRUB_INT_MIN which is defined as -0x8000 is unsigned. That's probably because "-0x8000" *is* unsigned. 0x8000 is an integer literal that does not fit into (32-bit) int but does fit into (32-bit) unsigned int. The negation operator does not change the signedness of its operand's type. It should probably be signed, e.g. #define GRUB_INT_MIN (-0x7fff - 1) ___ Grub-devel mailing list Grub-devel@gnu.org https://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 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: hybrid DOS/GPT and BIOS Boot Partition
On 01/23/11 15:39, walt wrote: Is there a way to make this configuration work? (I've used gdisk to convert DOS partition tables to GPT, so far.) Yes... make a BIOS Boot Partition! Such a partition couldn't hurt with DOS tables, too (I think there isn't a way to mark the partition table type as such in msdos tables, though? So maybe it can't be done / done easily.) Basically, on msdos partitions, there's usually a post-MBR "gap" where there are no partitions and a part of GRUB is put there. It can't be put in a filesystem because filesystems can shift their files around, and it's loaded by the <512 byte MBR, which can't be very smart. GPT tends to fill up all the space you'd have a post-MBR gap in, so you have to do the more-explicit-and-reasonable approach of making a partition for the GRUB data (in GRUB2 we call it core.img). [if my terminology is wrong, someone correct me] -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Improperly nested partitions, help needed!
On 09/21/10 09:13, Isaac Dupree wrote: On 09/21/10 03:31, Svante Signell wrote: I should have posted to help-grub, but I am not subscribed to that list, only grub-devel. Then subscribe to help-grub! It's not hard to do, and that list gets less email than grub-devel these days so you shouldn't be overwhelmed with email... hang on, I meant to send this message privately (so as not to spam all of you more). Why does grub-devel set Reply-to:, unlike every other technical e-mail-list I'm on? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Improperly nested partitions, help needed!
On 09/21/10 03:31, Svante Signell wrote: I should have posted to help-grub, but I am not subscribed to that list, only grub-devel. Then subscribe to help-grub! It's not hard to do, and that list gets less email than grub-devel these days so you shouldn't be overwhelmed with email... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#588208: grub-efi-ia32: breaks video of Mac Mini Core 2 Duo
On 07/06/10 16:52, Vladimir 'φ-coder/phcoder' Serbinenko wrote: It's possible that some video registers are preserved accross soft reboots. Buggy firmware may be unable to restore these registers to working state. Try disconnecting power completely. And wait a few minutes to improve chances that capacitors and other persistent electrical effects discharge/randomize! (At least, there's a similar effect with my laptop's built-in webcam) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#588208: grub-efi-ia32: breaks video of Mac Mini Core 2 Duo
On 07/06/10 04:54, Colin Watson wrote: Can anyone on grub-devel comment on this? It seems remarkable that we could be breaking video for future boots, and I wouldn't know where to start looking. (Full configuration details at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588208.) I'm tempted to ask (but you probably shouldn't try it!*), what if you clear the BIOS/EFI state (NVRAM) in case it's been corrupted somehow relevant -- hold Command-Option-P-R while booting http://support.apple.com/kb/ht1533 *WARNING! If it doesn't fix the problem, then you obviously still won't be able to see... and, however it was configured such that GRUB would automatically be booted is likely to be broken now, leading to unhappiness :-( (A safer way to investigate this thought would be to dump the contents of your NVRAM and upload it and compare it to what the default state looks like, if anyone knows how to do that?) Does booting from a Linux LiveCD give you graphics? (via grub or refit or holding 'c' when you boot) -- both as some sort of failsafe, and it *might* give us a bit of information. (disclaimer: I don't develop grub2 so far, I just use it [on my Macbook, using grub2 BIOS based since I haven't gotten grub2 EFI to boot Linux very well yet], and read the mailing-list) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 and hybrid MBR booting
On 07/01/10 15:42, Vladimir 'φ-coder/phcoder' Serbinenko wrote: After moving of partitions containing it's recommended to reinstall bootloader But I don't see the need to standartise the interface between MBR code and the rest. Standartisation is good only for interoperability between different software. But in this case both parts are from the same bootloader so it will only reduce flexibility. Two pieces of software: bootloader (e.g. GRUB 2) and partition mover/rearranger (e.g. Parted). I say it would be nice if on GPT with recommended GRUB install (including using BIOS Boot Partition), if we did not "[recommend] to reinstall bootloader" but instead promised that everything* would keep working without any bootloader reinstall. *except if partition numbering is rearranged and grub.cfg uses partition numbers not UUIDs, then the grub.cfg may need editing, but this is no different than a Linux partition's /etc/fstab maybe needing editing. Is it possible for us to promise that?--what are the disadvantages of doing so? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: update-grub & Xen boot stanza generation
On 05/24/10 00:48, Joey Korkames wrote: This is aready worked on but the problem is that it generates too much entries. If you have 5 different versions of hypervisor and 10 different kernels you have 100 entries. What if I add a max_entries option. Say, don't generate more than 4 stanzas total. Although I suppose then I need to go through and pick the most recent kernel and hypervisor versions. It feels like a kludgy solution It seems like the non-kludgy setup (while avoiding quadratic menu sizes) would be one in which, in one menu you pick which Xen hypervisor, and in the next menu you pick which Xen kernel. Is that feasible to implement? useful? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Migrations to xorriso
On 05/19/10 08:13, Colin Watson wrote: On Wed, May 19, 2010 at 02:01:50PM +0200, Thomas Schmitt wrote: - Option --diet saves about 400 kB of image size without losing much benefit. I don't have much of an opinion on this; but if it doesn't lose much, why would it not be the default? Or, put another way, why would somebody want to turn this option off? What size range are the whole images? For example, saving 400 kB off of 500 MB seems less useful than saving 400 kB off of 2 MB. (Also I guess no one compresses whole ISOs so it needn't be asked how well the extra kilobytes compress.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: search and boot using GPT GUID values
On 04/06/10 04:22, Simon Kitching wrote: So what do you think about (a) adding root=GUID as a kernel option That's something you need to ask Linux folks, not GRUB folks. For non-initrd usage, it sounds plausible to me that you'd have a chance of achieving some linux-kernel-change (as long as you restrict the code-bloat to when GPT or a similar partition-table-format-with-uuids is enabled in the kernel-config). But it ought to work in common initrds too, not just non-initrd mode! (Distributors, such as Debian, I think are the people who arrange initrds currently...) So you have a few people to chase down, and ask, and possibly follow up by sending patches to, etc... good luck! Be ingenious in response to flames! (b) optionally using the search command from (1) above so that something like the following can be done: gpt-guid has been discussed on this GRUB list quite recently -- did you see Vladmir's post? http://www.mail-archive.com/grub-devel@gnu.org/msg15345.html -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB and network (was Re: GRUB and Google Summer of Code)
On 04/01/10 16:59, Vladimir 'φ-coder/phcoder' Serbinenko wrote: There is already some crypto imported for password support so adding enough to have SSL would hopefully not be too difficult. Not true. Although we have ciphers and hashes we don't have either asymetric algorithms or random generator. The first is easy to import but generating random numbers involves gathering entropy which is cornerstone of network cryptography. Without a good random number generator most SSL algorithms will only make the user happier without adding any security against attacker. Is it reasonable to generate some random data during grub-install, and write it to the disk, where GRUB will then use it? Maybe in combination with real-time clock, this can be good enough initial entropy? (But I have not consulted with security research--this is just a guess.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] search for partition using GPT GUID
On 03/11/10 09:43, KESHAV P.R. wrote: GPT GUID is one of the best FILESYSTEM-INDEPENDENT way of uniquely identifying a partition. I am not sure if Linux supports gpt-uuids (I didn't find any hints of it via google!), but this sounds like it could be great news for Linux encrypted swap -- the current enc-swap recommendations destroy the partition contents on every boot, with a new random encryption-key and new `mkswap` inside it, so you have to refer to it like /dev/sda5. And then "/dev/sda5" partition gets destroyed on every boot, so the failure mode for wrong-partition is even worse than normal. But with a UUID stored outside the partition, it would be more possible to uniquely identify that partition. (Or a different encrypted-swap format, but no one seems interested in doing that :-( ) Maybe even the GPT Disk GUID can be used to reference a GPT disk (instead of confusion over whether it is (hd1) or (hd2) and so on. oh, interesting, that could perhaps be nice for something -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Licensing Re: Lead-up message 'Welcome to GRUB!' ...
On 02/21/10 15:38, richardvo...@gmail.com wrote:
On Sun, Feb 21, 2010 at 4:00 AM, Robo L wrote:
Hi all,
Firstly I would like to thank everyone for the reply and Your time.
I would like to clarify the issue.
First I need to hide the very first Welcom message because I need to hide
GRUB for other users of MS Windows on my PC. I need it only for myself.
I'm not entirely certain, but:
(1) I think GRUB is licensed under GPLv3 or higher only
yes
(2) GPLv3 covers what were considered to be loopholes in GPLv2
(firmware enforced signature, software-as-a-service)
therefore
well, GPLv3 is not identical to GPLv2, but I don't think the differences
are important to this issue.
(3) Your use of GRUB (copying it into the boot record) requires you to
provide your users with notice of their GPL rights to your version of
GRUB.
No, I think it probably does not. Firstly, because Robo L may not be
"conveying" the program (see definition in GPLv3), and if not, cannot
possibly be violating GPLv3.
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
Secondly, even if installing it to the hard disk of a computer that is
shared between you and other people (or other corporations) is
"conveying", GPLv3 Section 5 says, "d) If the work has interactive user
interfaces, each must display Appropriate Legal Notices; however, if the
Program has interactive interfaces that do not display Appropriate Legal
Notices, your work need not make them do so."
I didn't check whether mainstream GRUB interaction displays Appropriate
Legal Notices. ("Welcome to GRUB!" is most certainly NOT an Appropriate
Legal Notice.) If it doesn't, you're free. If it does, I think you
still do not need to display Appropriate Legal Notices until
"interactive user interfaces" have been activated; say, by typing in the
secret code that activates them. In section 0. Definitions, "An
interactive user interface displays “Appropriate Legal Notices” to the
extent that it includes a convenient and prominently visible feature
that [says it's GPLed, etc.]. If the interface presents a list of user
commands or options, such as a menu, a prominent item in the list meets
this criterion." I don't see "interactive user interfaces" defined
anywhere in the GPL or mentioned in GPL-FAQ, so I am hardly sure whether
a secret password-entry system that only interacts by secretly reading a
password (and then brings up the "real" interactive interface) would
count as an interactive interface in its own right that must tell the
user about itself even when they don't know the password... The
Affero-GPL is written with further language about interaction, but as I
guess that the normal GPL wouldn't make a GPL'd SSH server program have
to break the SSH protocol in order to fulfill Legal Notices, there must
be some limits on what is considered "interaction"...
I doubt the GPL was written with surreptitious installation of software
on other people's computers in mind... well, maybe it was
So one can hardly say that "another user on my PC not venture a guess
that there is a GRUB" if you are required to tell them that GRUB is
there and offer them the source code.
Richard: redirection is not good idea for me, becouse II need classical
console. I wrote a module with hidden password (secret process - no response
on console - silent) If match then redirect to boot linux. The nature of the
process is that another user on my PC not venture a guess that there is a
GRUB and secound linux OS!
Security through obscurity is never a good idea and especially not
when you have to give away the source code.
You have to give the source code when requested, or distribute it
on-disk along with the binary... neither of which compromise security
here. It's not a secret algorithm; it's a secret that GRUB is there at
all. (GPLv3 section 5.d , if obeyed strictly, might break this secret --
but that is all).
Depending what Robo L's threat model is, this "no messages until secret
code entered" may be sufficient security. Suppose it's to prevent other
people from giving Robo a hard time about using Linux (they'd never
suspect it in the first place! Or, they wouldn't mind terribly much if
they found out.). Or suppose it's part of spying on these people (and
getting caught means Robo runs away but has succeeded in doing some
spying in the meantime).
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[Off-topic] C++ enums
On 02/16/10 13:15, richardvo...@gmail.com wrote:
On Tue, Feb 16, 2010 at 12:03 PM, Isaac Dupree
wrote:
On 02/16/10 10:52, Michal Suchanek wrote:
enum allows it just fine
Not here:
typedef enum t1 { BTI1 = 1,
typo, should be "BIT1". then it works. (In C. Also remember not to get
confused by the fact that it doesn't work in C++, for type-related reasons
Says who?
OK, I guess I'll get into it, since you asked...
Comeau is perfectly happy with this code, in strict C++ mode:
enum flags
{
BIT1 = 1,
BIT2 = 2,
BIT12 = BIT1 | BIT2
};
In C and C++, enums are their own type distinct from int. In C, there
exist implicit conversions both from and to all enum types and int. In
C++, there only exist implicit conversions from enum types to int.
Bitwise and arithmetic operators only operate on int, not enum types
(unless a C++ operator overload is declared); these operators appear to
work with enums because of all the implicit conversion.
Your example works even in C++ because the right-hand side of an "=" in
an enum-declaration is of type int, rather than the enum type (as you
can see from the fact that you can put "1" there as well). Now BIT1,
BIT2, and BIT12 are all (in C++) values (rvalues) of type "flags" (note
this does not apply to the left-hand sides in the enum declaration that
define their constant values, but it does apply to those right-hand sides).
Now try and combine your with this main function:
int main(int argc, char** argv) {
flags foo1 = BIT1; // fine
flags foo12 = BIT12; // fine
int bar = BIT1 | BIT2; // fine
flags baz = BIT1 | BIT2; // error
return 0 ;
}
(If you want to see it compile in C, add "typedef enum flags flags;"
before main().)
See http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.19 for some
discussion by a C++ expert. And then return to GRUB2 coding where none
of this matters. The only weird thing about enums in C is that they're
not guaranteed by the standard to be isomorphic to type "int"; each enum
might correspond to a different-size, (possibly even
different-signedness), integral type, if this is possible given the
range of values in the particular "enum{...};" declaration. (This weird
thing also affects C++ but I omitted it in the above explanation of enum
versus integral types.)
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Framebuffer rotation patch
On 02/16/10 10:52, Michal Suchanek wrote:
enum allows it just fine
Not here:
typedef enum t1 { BTI1 = 1,
typo, should be "BIT1". then it works. (In C. Also remember not to get
confused by the fact that it doesn't work in C++, for type-related
reasons that we don't need to get into here because GRUB is written in C.)
BIT2 = 2,
BIT12 = BIT1 + BIT2} t;
int main(int argc, char** argv) { return 0 ; }
testenum.c:3: error: ‘BIT1’ undeclared here (not in a function)
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: handling "/"
Carles Pina i Estany wrote: Is this not everywhere? I've not verified if POSIX paths says this, but would avoid the things that has been patching and unpatching today. I believe it is POSIX mandated paths behavior. (Windows on the other hand has limitations on the number of slashes/backslashes... I heard somewhere that it allows two but not three-or-more) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Trouble booting from a large USB hard drive
Colin Watson wrote: Unfortunately, I rather suspect that the very problem being addressed there means that we won't be able to implement your idea automatically. Me too, but for this reason: putting /boot near the beginning will be normal partitioner stuff, but this person's reason for caring about the partition order is that he knows which partition he wants to be mounted by Windows, and that's "#1". Which is an idea that could be implemented in a GUI, given the right libraries, (potentially though, if there's a different current partition-#1, at the expense of anything that refers to *that* partition by number) (and it might be too hacky an idea, i.e. being Windows-related and all, for gnu/linux developers to want to support so cleanly anyway) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Trouble booting from a large USB hard drive
Daniel Richard G. wrote: What all but confirmed it for me was an ingenious solution I saw posted somewhere: an out-of-order partition table. Put the Linux partitions first on I accidentally have an out-of-order partition table and I was surprised that such a thing is possible (vs. that everything gets automatically numbered in order). Nevertheless, it is a useful feature, though not obvious how to control with 'gparted' and the like. "extended partitions" probably add a bit of complication too. With all that said, I don't consider this to be a bug in GRUB, and this is not meant to be taken as a bug report. (I presume grub-pc can't work around such limitations in the BIOS, because there isn't enough room in the MBR to stuff in a disk-reading library that makes BIOS disk calls unnecessary.) Rather, I think it is a corner case of which users should be aware---and perhaps GRUB and/or the Ubuntu installer could do a better job of warning the user if grub-install, which doesn't have code space limitations, could possibly check for it, it would be a great help. But is it possible for a running system to check the BIOS like that? (or possible for grub to check somehow on a non-running system in a safe testing sort of manner?) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multiboot ammendment: non-VBE video
Robert Millan wrote:
In this case color_info is defined as following:
I'd appreciate if a native English speaker confirms this, but I believe
this should say "as follows" (same for the other instances of this
construct).
"as follows" reads naturally to me, as a native speaker (also checked:
online dictionaries mention the phrase "as follows" without saying it's
specific to my area -- northeast U.S. -- so I think it's right to use)
+...@samp{framebuffer_palette_addr} contains address of array of
@samp{framebuffer_palette_num_colors} following structures:
There seems to be some word missing here.
"the following structures"?
"as follows" would also work well if "structures" isn't an important
word to keep?
wait, it's like saying "array of 3 following structures", each of the
same type. hmm. "@samp{framebuffer_palette_num_colors} structures as
follows"?
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] spaces (label, UUID)
Carles Pina i Estany wrote:
+ grub_putchar (' ');
+ grub_printf_ (N_("- Label \"%s\""), label);
...
Avoiding to have trailing spaces helps the translators (they will do
less mistakes).
In this case it is a space at the beginning, not the end of the string
-- does it still have this problem for translators? Or are you perhaps
just trying to make code a bit more consistent re: beginning/end of strings?
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
Zhu Yi wrote: On Fri, 2009-12-25 at 05:21 +0800, Robert Millan wrote: I think making a backup is a fine idea, but I'd rather avoid the "option creep". It doesn't hurt to simply dump the files in /boot/grub/. If user later discovers that valuable data was overwritten, she can figure out how to call dd just as she can figure out the right parameters for grub-install. OK. My only concern is the start position of grub core.img (as in disk sectors) is a variable (see find_usable_region_xxx). This ends up the backup file is not a simple dump. I used below format in my patch. <512 bytes MBR> + + Option 2 is to put the start position in a separated file. Option 3 is to use the information in boot.img (as I used in my patch as a verification method) to get the start position, i.e. `od -j92 -N8 -An -td8 $grubdir/boot.img`. Option 4 is to backup everything from MBR to the end of core.img (including the holes in the middle). This ends up with a bigger image. Option 1~3 requires the recover has the knowledge of the backup file format somehow, but a simple dd is enough for option 4. What do you think? If the partitioning had been changed in the mean time, 4 would overwrite it with the older values. Similar problem for a weird setup with partitions in between (I dunno, might be possible with GPT or other weirdness). I think option 2 or 3 is soundest. Option 2 would have three separate files of information, (right?), and there must be a pretty straightforwards `dd` option to skip to the correct start position. Option 3 would omit the "start position" file... but that file is really cheap, maybe we'd better keep things simple for restorers and stick with three separate files.(Or, we could do something weird like putting start-position somewhere in the filename of the backup.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
Zhu Yi wrote: On Mon, 2009-12-14 at 11:24 +0800, Isaac Dupree wrote: hmm bootloader installation is often done by distro install-CDs. Will the distro be smart enough to save these backups to the disk somewhere sensible, rather than to the temporary in-memory filesystem? The backup files will (normally) be stored in /boot/grub/ together with grub.cfg and core.img. if it's there, then excellent, you are right. After all, /boot/grub needs to be permanently on the disk in order for the installed bootloader to work, also :-) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
richardvo...@gmail.com wrote: An automatic backup is valuable both for savvy users who know how but forgot, and for those who will find the backup and restore procedures online only after their computer is bricked. hmm bootloader installation is often done by distro install-CDs. Will the distro be smart enough to save these backups to the disk somewhere sensible, rather than to the temporary in-memory filesystem? I'm... Just being paranoid enough to ask this question -- I never quite trust by install CDs not to install a bootloader, because I have to find the right place in the GUI install sequence to disable doing so (and hope that disabling works -- as a supposedly "advanced" option, sometimes it's not been tested enough). Anything GRUB2 upstream can do to make this less risky will make me happy! ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
Zhu Yi wrote: 3. The backup policy. Garimella's patch backups every time before grub-setup overwrote the boot sectors. There might be a problem when someone run grub-setup/grub-install twice. So the backup image ends up with the grub2 boot sectors. This makes the recovery for the "real" boot sectors impossible. My patch won't overwrite if a previous backup image already existed. grub-install will remove the backup image after a successful recovery. maybe the boot sector is small enough that we could just keep separate additional backup files each time grub-setup/grub-install is used? e.g. backup-1 backup-2 backup-3 or maybe using date/time instead of sequential numbering would be nicer. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot ammendment firmware info
Vladimir 'phcoder' Serbinenko wrote: If flags[13] is set 2 fields are defined on addresses 104-107 resp 108-116 First field is firmware type 2 - BIOS. 16-bit mode BIOS interrupts are available. Second field is invalid 5 - 32-bit EFI. Second field contains pointer to EFI system table. What about on Apple's EFI with its "compatibility" BIOS also activated? Don't both firmware interfaces work then, and one could theoretically want to pass both EFI and BIOS as parameter here? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] import multiboot1 specification in grub trunk
Vladimir 'phcoder' Serbinenko wrote: On Mon, Aug 24, 2009 at 8:38 PM, Isaac Dupree wrote: Vladimir 'phcoder' Serbinenko wrote: 8) COPYING contains GPLv2. fdl.texi isn't imported. I'm not a lawyer but following is my analysis AFAICT only example kernel is under GPL (v2 to be precise) the rest is either custom license, unclaimed copyright or non-copyrightable. IMO multiboot specification should be FDL with cover text "Multiboot specification" It's better IIRC not to have any cover texts or invariant sections if we have a choice. I've checked and it revealed that I had false idea about cover texts. ACtually the requirement I wanted to impose is that modified copies can't have the title "Multiboot Specification". Sorry for using incorrect idea. quite right; we certainly don't want to *require* that modified texts call themselves Multiboot Specification! Instead we'd like them not to be called that. I'm not sure if copyright law is the right way to do that; sometimes trademarks are; however here we have FDL 1.3 requirement for modified versions: "A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. " GPLv3: "The work must carry prominent notices stating that you modified it, and giving a relevant date." and allows certain additional restrictions, especially "c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or" "e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or" ...which are used in Micropolis, based on SimCity code released as GPLv3 by EA who owns the SimCity trademark and guards it jealously <http://code.google.com/p/micropolis/wiki/License> I think the FDL version 1.3 requirement above is quite sufficient for this document. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] import multiboot1 specification in grub trunk
Vladimir 'phcoder' Serbinenko wrote: 8) COPYING contains GPLv2. fdl.texi isn't imported. I'm not a lawyer but following is my analysis AFAICT only example kernel is under GPL (v2 to be precise) the rest is either custom license, unclaimed copyright or non-copyrightable. IMO multiboot specification should be FDL with cover text "Multiboot specification" It's better IIRC not to have any cover texts or invariant sections if we have a choice. If we have any, then it doesn't fall within the Debian Free Software Guidelines and Debian et al. will be annoyed and not distribute it as much. (Or we could use GPL3 or CC-BY-SA for the specification... or has the FSF produced any revisions of the FDL recently? I forget) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: TPM support status ?
Duboucher Thomas wrote: Also, you are not owning a computer by using a chain of trust. You are only sure that the software you trust on your computer haven't been tampered. And you can keep trusting them, even if they have a backdoor you weren't aware of! ;) well it's true, even with the most open computer-hardware-design by manufacturers, you won't get anything as well-tested and understood and obviously trustworthy as 18/8 stainless steel (I was just thinking of an analogy to Klean Kanteen, who advertise how their 18/8 stainless steel water bottles are obviously safer than plastics, or than aluminium + secret-formula-enamel , http://www.kleankanteen.com/faqs/faqs.html ) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: TPM support status ?
Michael Gorven wrote: On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote: Even if they can't stop from working at all they can make it effectively useless by e.g. not allowing you to see online videos, buy online or even just send an e-mail (saying it's "spam control") if you aren't TPM-checked That falls under the supporting-possibly-harmful-technology argument. It's not very different from saying "you must use Silverlight to view videos" and whatnot. If you don't want to follow their requirements, then don't. 2) The similar features can be implemented without resorting to TPM by using coreboot and make every stage verify the signature of every next stage. Trust has to start somewhere, and the more difficult it is to compromise that the better. flash rom with cut write wire is impossible to compromise without physical access. Valid solution, but does it protect the contents of the flash ROM? (i.e. can you read the contents?) A minor point is that it does mean you can't upgrade your BIOS anymore. It also gets tricky if you're wanting to securely store a hardrive decryption key though. 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value of a previous (safe) boot. We assume that the previous link of the chain of trust (BIOS?) has already checked that GRUB hasn't been tampered before starting it. You propose to check that our checksum in PCR is ok but you already assume GRUB wasn't tampered. If you assume grub wasn't tampered no need to checksum. If you don't it's useless to checksum. That isn't assumed -- the BIOS checks that GRUB isn't tampered with before moving control to it. Coreboot can make this too. And firmware doesn't need TPM to do such checks. Yes, except coreboot isn't widely supported. A full support of TPM means that GRUB should also be able to ask to a remote authority if the content of the PCR is still ok... Why do I as user need someone else to check my computer? Because you don't always own or completely control the computer. Then someone is already holding you hostage. We won't help them to restrict your freedom further. Or you're the person who owns and wants to secure the computer. Maybe you want to co-locate your server and make sure the technicians at the DC can't compromise it, or you're guarding against data loss if your laptop gets stolen without having to enter decryption passwords on boot, or a whole lot of other situation where *you* are putting *your* computer in an untrusted environment. Suppose you are the proud technical support person at a third-world school that just bought a thousand OLPC XOs. You, as part of your country's government, are instructed to own those XOs. If they are stolen and get into the hands of innocent third-world civilians who want a computer, those computers are instructed to shut off within 24 hours and demand to be returned to their original location before they're willing to work again. This harms ordinary users who loved their student computer; they might choose not to return it anyway. It does not harm the thieves who steal the XOs and break them down into parts and sell the parts. Civilians with enough expertise might be able to replace the BIOS flash to get a working computer again, but there will be many ordinary users who can't figure out how to do this (or perhaps, don't have the tools). This restriction is not necessarily what makes OLPC designers happy, it is merely a condition set by many governments who decided to shell out lots of money for the XOs for schools. Technical measures can never decide who, morally, "owns" a computer. When software technical measures do try to decide that, it is almost always the technically adept and/or the manufacturers who win. In a project for a Free world, I suspect we want to give our best chance to anyone who ends up with a computer by any means... It's why I still have set an unrestricted boot option on my computer (without access to my personal-data encryption password of course - it's in my head) so that if someone accidentally ends up with my computer and doesn't return it and doesn't figure out how to reinstall an OS on it, the computer won't economically go completely to waste... :-) The cost of taking that stance is that when you remote-access a computer, it (more easily)* might be running different software than you expected. Is that so unreasonable? If you need an Internet-connected secured computer, maybe you can put it in your home, or rent one from a local company (or friend) who you trust to keep your data safe because you know them? *some options: - Lock down not very much at all: Let anyone boot a CD, or even log in directly as root, or at least replace your hard drive. Allowing only the former probably makes you safer from someone lazy grabbing your computer out of your hands and deleting your files in a stroke of anger; adding some time/practicality delay that
Re: [PATCH] Disable debug messages in reiserfs.mod
Vladimir 'phcoder' Serbinenko wrote: Hello. Recently we had no bug-reports about ReiserFS and ... Maybe it's because people aren't using grub to load things on ReiserFS? I've stuck with Ext3 everywhere for awhile now and so do a lot of distros' defaults. (not arguing against it, just thinking...) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New object format
Bean wrote: Hi, This patch implement a new object format, the advantages are: Reduce size dramatically, some result: Size of all modules: original: 645575 new: 519093 [I thought I sent this message a few days ago, guess not?] What are the compressed-size comparisons? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Configuration option to disable os-prober?
Pavel Roskin wrote: On Wed, 2009-07-08 at 16:38 +0100, Colin Watson wrote: Hi, Some people seem to want to disable os-prober for various reasons (e.g. they have lots of test installations lying around that they don't normally want to get in the way, or they don't want installations on external drives to be included permanently in the boot menu, etc.). Now, they can just remove the os-prober package, but that doesn't really scale as other packages are allowed to depend on it too. Perhaps we could have a configuration option for this? Patch attached. Fine with me (but I'd like to hear from somebody who actually runs Debian or Ubuntu). I run Ubuntu... I can't say I've yet wanted to do anything that needed this patch, but it seems like the right idea to me... or, er, hmm, Configure option versus runtime option? I don't know from my cursory inspection if there's an issue here, but you (Colin) would be able to describe how/whether that's relevant -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] New menu design based on MVC
Bean wrote:
Implement the menu viewer in lua. Colin's patch already make extensive
use of lua, so perhaps we can just standardize the interface a little
bit, and make it easier to write components using either c or lua.
and (out of order,)
Use xml to store data. With Colin's graphic menu path, we are already
introducing a new file format - the theme file. But the current
representation is a little awkward, for example, to write a label, it
uses:
+vbox{ +label{ text="Hello" } +label{ text="World" } }
I think it would be more natural to write it like this:
XML is a bit complicated to parse, unfortunately, compared to the ideal
hierarchical data format.(of-course we might choose it despite that)
If graphical menu is going to rely on Lua, why not write the data in Lua
too? It's designed for this sort of usage IIRC (use its table
syntaxes), though I don't recall it well enough to give a good example
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Warning free build achieved, coreboot documentation updated
Vladimir 'phcoder' Serbinenko wrote: The remaining is util/hostdisk.c:1061: comparison between signed and unsigned The problem comes from the following declaration # define GRUB_LONG_MIN -2147483648UL As you see we declare a negative number with UL. This works correctly on i386 but what about other architectures? Can this warning be just silenced with a cast or do we have a real problem here? it is portable since C standard defines unsigned numbers to have modular arithmetic. However it therefore can't be silenced with a cast to a signed number (which doesn't have that guarantee!) Note that casts between signed/unsigned of the same size are guaranteed to work as expected. this should work without warnings I guess?: # define GRUB_LONG_MIN (0UL - 2147483648UL) do you want it to be of a signed type, though? then cast that to (long) afterwards. (-1L - 2147483647L) would work too. it's annoying isn't it that C doesn't actually have negative numeric literals :-) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub Scripting
Chris Umphress wrote: > Hey, > > We have some computers that need a boot loader to self-destruct at the > end of a school year. In order to accomplish this we would like to use > Grub scripting. From what I have been able to find, the support is > incomplete and we would have to write the code to self-destruct > somehow. I can think of a couple ways to do what you say: - if there is a date/time command in GRUB, have the `grub.cfg` check the date and refuse to offer any booting options after that date (where I suppose the hardware-clock supplies that date) - alternatively to "not booting", you could have it boot DBAN which will erase everything on all disks :-) Or have a human manually boot the self-destruct option (which should require an administrator password probably) (how do you expect to re-use these computers, if they have a nonfunctional boot-loader, by the way?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Video mode fixes in linux loader
Robert Millan wrote: > > > > Some > > > > kernels may not support VESA modes at all. > > > > > > I don't think this is applicable; all modern versions of Linux include > > > vesa modesetting in its 16-bit entry code, and older versions are > > > already detected by the new loader (user is prompted to use linux16). > > > > I can disable CONFIG_FB, and then the screen remains blank until X > > starts. It's entirely possible that some distros don't enable CONFIG_FB > > to save memory, and I don't always enable it in the kernels I configure > > myself. > > Makes sense for official GRUB. > > However, I'd still like to add a macro check that can be enabled on distros > that ship Linux builds with CONFIG_FB and want to enable seamless mode > transition (this will be the case for e.g. Debian). Can we have GRUB2 not be distro-dependent, because I often depend on it to launch multiple different distros (and I'd rather not worry too much about which distro installed my grub2)? It [i.e., whether to use seamless mode transition] can be a setting in the grub.cfg if necessary. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
Peter Cros wrote: > I don't think it is compatible with current MBR/GPT hybrid ?partitioning on > intel macs for grub-pc booting. well, it doesn't necessarily order the partitions in the same way as e.g. rEFIt gptsync does, but that's because this GRUB implementation gives you more control! You can even pick different MBR-partition-configurations, before booting different OSes. Vladimir Serbinenko wrote: > Here there are 2 differences. First partition type for hfs+ isn't > autodetected, I will fix this, just I thought it ws unnecessary AFAIK every > OS which understands HFS+ understands GPT. At least Mac OS X 10.3 and earlier don't understand GPT, and it actually makes a difference with Apple's "target disk mode"! And there may be a few other combinations. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
Vladimir Serbinenko wrote: > Syntax: > hfspbless > It works only on HFS+ volumes. Could it be named 'hfsplusbless' (or possibly 'hfs+bless') (I guess our current naming style involves no underscores or other word-separation)? For example, Linux `mount` calls the filesystem `hfsplus`, and I like naming- consistency. But feel free to mention counterexamples too! -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: grub: Fix handling of long printf arguments on 64-bit.
> - grub_ltoa (tmp, c, l);
> + grub_lltoa (tmp, c, l);
> }
> else
> {
> n = va_arg (args, int);
> - grub_itoa (tmp, c, n);
> + grub_lltoa (tmp, c, n);
Do you think they deserve a comment saying why lltoa and that e.g. grub_ltoa
would work equally well there except for space reasons? (In case we ever
decided to change that code back, it would be easier to figure out.)
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: how to open files with grub_file_open
Rev. Mr. Gary Meerschaert wrote: > need to modify grub for a project in my security class. I am adding a a > check of a key stored on a usb drive. I also have the key stored in the > /boot/grub2, /boot/grub, and /boot. I can not open any of them. My > system dual-boots, and the fedora install is in hd0,1. > I have tried the file name as (hd0)/boot/key, (hd0)/boot/grub/key with > the same results. did you try (hd0,1)/boot/grub/key, or whatever other partition-number you've put grub on (if it's different from the fedora partition)? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/7]: Fix sparc64 setjmp implementation.
David Miller wrote: > "unsigned long" is always safe because it is going to be > the largest natural word size on the machine, at least > as large as a pointer will be. er... C standard doesn't guarantee this, and I think that Windows in fact has 32-bit longs on machines with 64-bit pointers > We've been using "unsigned long" for storing virtual addresses in the > Linux kernel for 10+ years and it works just fine. :-) and Linux kernel uses GCC compiler in precise ways I believe that ptrdiff_t is the proper standardized type for an integer the size of a pointer. except... it's always signed :-) Can you just use pointer types and pointer arithmetic? also, standards aside, a common way to get such a type, is "configure" script testing various possibilities like "unsigned long" and "unsigned long long" and seeing which one is the right size for the target architecture. (not sure if that works when cross-compiling though) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: > On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote: > > On Saturday 21 February 2009 15:51:42 Robert Millan wrote: > > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote: > > > > TPM can be used for good or for bad, but this is the case for > > > > everything involving cryptography. We don't refuse to use encryption > > > > algorithms because they could be used for DRM, so why should we > > > > refuse to use TPM? > > > > > > I don't agree with this analogy. Unlike cryptography, TPMs have been > > > designed from the ground up to serve an evil purpose. They *could* > > > have designed them with good intent, for example either of these could > > > apply: > > > > > > - Buyer gets a printed copy of the TPM's private key when they buy a > > > board. > > > > > > - An override button that's physically accessible from the chip can > > > be used to disable "hostile mode" and make the TPM sign everything. > > > From that point physical access can be managed with traditional methods > > > (e.g. locks). > > > > > > But they didn't. > > > > Just to clarify, are you objecting to the use of TPM on principle and > > because you don't want to encourage use of it, or because you think this > > specific use (trusted boot path) is dangerous? > > I can't reply to this question, because it's not just a specific use, it's > part of the design, of its purpose. One of the design goals is remote > attestation, which is a threat to our freedom and is unethical. > > If there was a device that behaves like a TPM except remote attestation is > not possible (e.g. by one of the means described above), I wouldn't object > to it, and I think the GNU project wouldn't either, but then referring to > that as "TPM" is misleading. (warning, I accidentally wrote a long essay exploring when these TPM-like things are evil) Okay, suppose we use this means to make them not-so-evil: "Buyer gets a printed copy of the TPM's private key when they buy a board." I'll call them "(pseudo)TPMs" when they meet GNU demands. (They could be built with Free software, openly specified hardware designs, etc... why not throw in a bonus :-)) Alex Besogonov's use case is still possible. Which should make us suspicious of whether our moral problem is solved. Here's how it's possible: Assume he has access to computer A, which is physically secured. He buys computer B, which he wants to be able to wander around in the world without much effort put into physical security. He accepts that the hard drive contents can be tampered with, but he's willing to pay for a smaller cryptographic unit that guards its secrets jealously -- the (pseudo)TPM -- in order to "prove" to computer A that computer B hasn't been changed. Alex is the buyer, so he received the printed copy of the private key, and (for example) stashes it where computer A is, or burns it. How does that make computer B free? Computer A and its buddies (if any) will still refuse to communicate with B if B runs different software than what Alex had put on it. Unless there are laws in place, Alex can go on to sell (or lease) computer B to someone else, without giving *them* the printed private key. Or in the case of the "override button" and securing the (pseudo)TPM with physical locks, Alex could secure it with a lock, and then sell computer B without giving the lock's key to person who buys the computer from him. This look at (pseudo)TPM makes them look to me as a weak way of asserting at- a-distance your legal/political ownership of a computer. Even if manufacturers cooperate with GNU demands, resulting (pseudo)TPMs are only useful for a purpose that is arguably evil... although the political arguments might be different between an end-user, a small non-computer-focused corporation, a large one, and a computer-manufacturer, asserting ownership. And it depends on whether they share such information (with police, public internets or other networks) in an attempt to detect fugitive computers. I think, in the U.S. we can make laws that coerce corporations pretty effectively, and individuals don't have much power (most people buy their computing devices from mass marketers, large corporations, not people on the streets), so -- if we chose -- we could make laws that ensured that (pseudo)TPM technology was not used for its most serious moral transgressions. (I'm not sure though, because the Internet is so strange.) Also because most software is made by big corporations that can be sued (e.g. Microsoft, Apple), and most Free non-corporate software isn't evil. But I suspect that in a part of the world where people know their immediate oppressors more intimately, where the mass market (the "free market"?) isn't trusted as much, the TPM (well, like any other piece of software or hardware, only worse) could be abused to control people. I could spin that argument one way to say that U.S. capitalism is to be desired
Re: SHA-1 MBR
Jan Alsenz wrote: > Yes, that was my point. You need a trusted first step. > But the only thing besides a TPM, that can be used for this is the BIOS, > which can be flashed. > And even, if we assume, that we can construct a BIOS that only boots if the > MBR hash matches and can not be flashed prior to this point, there are > still two points missing: > - After the system has started, the BIOS could be flashed. This is a very > possible scenario in a multi user environment. > - They could take out the disk and put it in another machine, tamper with > the boot code and switch it on. And all your protection is gone. > Ok, you could try to put a needed key in the BIOS too, but then we're > back to problem one - and the BIOS can not check if a request for the key > is valid. I'm not even sure, if something in the BIOS can be read > protected. BIOS could be in ROM, un-flashable, including hash/keys and all! Refuse to boot if the hash doesn't match! Admittedly this poses some limitations on whether the system can be upgraded, depending how sophisticated you want to be. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Alex Besogonov wrote: > On Wed, Feb 18, 2009 at 4:52 PM, Isaac Dupree > > wrote: > > Alex Besogonov wrote: > > But guess what? While your system is running, they can take out your RAM > > and read it (disk-encryption key and all) before the RAM forgets its > > contents, see e.g. http://blogs.zdnet.com/security/?p=900 > > I know. But there's no way to guard against this attack, so there's no > sense fretting over it for now. well, it's relatively straightforward for an attacker who knows what they're doing, so perhaps you should assume that *privacy* is at least partly compromised. but the most that attack can achieve is observing? Can that attack make it so that, when the system starts running again, it will be in a compromised state? - they can steal all crypto identity keys and try to run a completely different computer with different software there, if not for TPM - I don't know how the magic of TPM knowing everything about the state of your computer works, maybe they can modify what's in memory and put it back and confuse things? Also why does GRUB need to do any explicit interaction with TPM? (I'm ignorant and unimportant here, but maybe it will edify people, to have this conversation.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Alex Besogonov wrote: > There's no way to break this chain of trust without hacking TPM (which > I consider very unlikely) fair to say "unlikely" > doing uber-dirty hardware tricks (like > modifying RAM on-the-fly using DMA from rogue PCI devices) yeah, it's probably technically possible, but enough work to do that it's not worth guarding against. But guess what? While your system is running, they can take out your RAM and read it (disk-encryption key and all) before the RAM forgets its contents, see e.g. http://blogs.zdnet.com/security/?p=900 > or > exploiting some local vulnerability (which is rather unlikely). maybe. But how do you patch security vulnerabilities in e.g. the GRUB install, if modification = tampering? (I guess there's a way to do it, though.) > >If you suppose that your attacker is unable to tamper the hardware then > >bios and grub password is all you need. If you suppose that he can then > >you can't even trust your ram modules. It can be tampered in many ways > >like serving hacked bootloader or just being non-volatile then an > >attacker can read the key from memory. > > I'm trying to guard against attacker who can _steal_ the server itself > and/or tamper with the hardware. which is very difficult. Why do you have to reboot, though? and is there some way you can store the key locally in those cases, without compromising it further? > PS: please, at least read the relevant specs before calling TPM > 'Treacherous'. the ones that say to keep the keys in the hands of the manufacturers?(no I haven't read the specs either, maybe Robert Millan has though) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-install message should mention --recheck
[EMAIL PROTECTED] wrote: Please implement these changes in making this typical grub-install message. Thanks. # grub-install /dev/hda Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. -Check if this is correct or not. If any of the lines is incorrect, -fix it and re-run the script `grub-install'. +If not correct try --recheck, or fix and rerun. but the original message was much more clear about what you should do. And what do you mean by --recheck.. is this correct interpretation?: -- Check if this is correct or not. If any of the lines is incorrect, try `grub-install --recheck` (or is it `grub-install --recheck /dev/hda`?). Or (under what circumstances should you try which solution?) edit /boot/grub/device.map, and then re-run grub-install (i.e., `grub-install /dev/hda`). -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI report w/ linux 2.6.26.2
Bean wrote: Hi, Please take a look at the wiki page and see if you can make graphic work by following the instructions: http://grub.enbug.org/TestingOnMacbook sorry I feel a little busy right now, and I'd have to figure out how to kick those agp modules out of the initrd too. By the way, why doesn't AGP work in EFI mode? (Does Linux currently not know how to initialize it without getting BIOS help? Or something else?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
EFI report w/ linux 2.6.26.2
I tested with both video=vesafb and video=efifb on a self-compiled Linux-2.6.26.2 with a config based on Ubuntu's, both with my own compile of GRUB SVN head and with Bean's grub2-efi compile that had mysteriously worked better for me in some ways. linux /... video=...fb agp=off root=/dev/sda4 gpt initrd /... boot + loading the 50MB initrd worked fine (I have no idea why my self-compiled Linux .ko modules are 5x the size of Ubuntu's :-) + it booted fine, except the graphics and sound (I could tell because of listening to disk noises and pressing the power button on the login screen did a clean shutdown as normal for Ubuntu; maybe I should've checked ssh-ing) - Linux failed at graphics both in console and X: Linux made a funny pattern on the screen that didn't change (though it was different the two times I tried booting through EFI). - No sound when there probably should've been maybe I'm still doing something wrong, I dunno :-) ... BIOS boot is still working great. Although, I tried putting grub2-bios on a USB Flash drive's MBR[is that the right terminology? it is partitioned, not superfloppy], and when I tried booting from it on my MacBook, rEFIt told me that booting it failed and that it's probably because Apple's support for USB-boot is not very good. So I don't think I got even as far as the point of discovering whether grub worked (it had mentioned an odd device.map(IIRC) to me when installing). -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Platform information services
my view of the "interface breakage" problem in this project: Either the property of the kernel you're relying on is going to change, or it isn't; it doesn't/shouldn't have stable APIs, and it will change only if there's a reason for it to change. So I think the best we can do is to document what code relies on what properties of the kernel. Wherever's appropriate and will likely be noticed and kept up-to-date. for example: if you rely on a property of the kernel, you should document it somewhere in the kernel, and document everyone (hopefully) who relies on that property; or the users could have some symbol in the source that you can search for. It doesn't have to be a function that takes up any actual kernel disk-space. a bit at a distance, -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New command checktime
Bean wrote: On Sun, Aug 10, 2008 at 5:32 PM, Robert Millan <[EMAIL PROTECTED]> wrote: It wouldn't be hard to make update-grub gather time zone information from the host system and put it in a variable in grub.cfg, or something like that. Hi, Oh right, but the handling of timezone is not trivial, especially when it across date boundary. Perhaps we just ignore it for now. also, even if one's computer always stays in the same place, Daylight Savings can change the timezone you're in, while grub.cfg stays the same. What is it that we're doing when we "ignore" it specifically? Assuming local-time and hardware-clock-time are both UTC? (and therefore if the date specifies a timezone, which is specified numerically, convert the time to UTC before doing anything with it) (The above behavior means that if the hardware-clock is actually local time, one could specify the time without a timezone / with timezone Z, and it will work to set the time, despite the incorrect assumptions.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New command checktime
Bean wrote: I agree with Colin the datetime representation should be more intuitive, but we should stick to one layout. I use the following format now: date [[year-]month-day] [hour:minute[:second]] date is separated by `-' , and time `:', year and second part can be omitted. I'm also a fan of ISO 8601, which has similarities to that above format http://en.wikipedia.org/wiki/ISO_8601 (well, we may only want to use a subset of ISO 8601's formats.) It did remind me since it has optional time zone info, that time zones exist :-) ... does GRUB have any idea what the local timezone is, or will it have to require the time-zone part? What about whether the hardware clock is UTC or local-time? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH][RFC] gdb support in GRUB build system
In that case, should --enable-debug be the default, or --disable-debug? I'd prefer to disable debug as default. What do others think? It only creates extra files in the build, unless something is done with them? It's not the /boot or core.img getting expanded here. Also, if users need debugging info, it's much more reliable to fall back on files of debugging symbols that are already generated and match the installed grub binary compile. Or did I get confused? I didn't think they were incredibly huge size files either, so I'd say enable them by default. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Drivemap module
Javier Martín wrote: You understand my concern, but seemingly do not understand that in order to conform to the Holy Coding Style you are asking me to write code that can become buggy (and with a very hard to trace bug) with a simple deltion! (point: did you notice that last word _without_ a spelling checker? Now try to do so in a multithousand-line program). well, maybe a bit off topic. But I can't imagine how, after code is written, I could accidentally delete an "=" character even when editing it. I prefer the (to me) intuitive meaning of (variable == value) in my own code. That particular problem has never bitten me. Although, in C++ coding style, a lot more local variables are "const" and therefore the error could be caught by the compiler anyway. It seems like an odd paranoia to choose. Say, take "uint32_t". It's only a one-character deletion to become int32_t and then there is subtle breakage. "htons" and many other functions with similar names and suffixes. Etc.? It's half C language and culture, and half inevitable in programming, IMHO. point[2]: I half did notice the typo (only "half" because I've trained myself not to be too distracted by people's spelling), and I'm generally more precise when looking at code (maybe). ;-) Anyway, since "they" are more likely to maintain the code in the long run than you, in general, the question is whether the code is more likely to become buggy by their hacking on it, if it follows project coding style or someone else's (your) "safer" coding style. Likely it's safer if using a consistent programming style. Although I personally don't see that it's very helpful to have a style that makes things down to the order of "==" arguments be consistent within the project; haphazard only slows reading the tiniest bit, and I don't think it makes a different what order the arguments are... -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)
Robert Millan wrote: Then again, on BIOS we only use UUIDs when the situation is desperate, like on a cross-disk install. If you're concerned about security and/or reliability, don't do cross-disk installs. that's good This line of thinking is what is commonly used to justify draconian measures (i.e. Treacherous Computing) but it doesn't make any sense. If your security policy is such that you don't trust users with physical access I'm actually a little more worried about the combination of overworked/confused sysadmins making mistakes, and GRUB (potentially) not being completely deterministic in the face of additional drives (which is inherently confusing because it rarely matters). And some of my situations are hit-or-miss anyway: if you (the intrepid user trying to boot from CD) don't even trust the contents of the hard disk, most likely the BIOS or boot process could be corrupted too. I suppose I haven't yet seen any duplicate UUIDs, even including FAT ids, so I shouldn't worry so much. Anyway, I *don't* wish to trust the random CDs and USB drives I plug in without my explicit say-so, and that's been true at least on the Mac for years and years before TPM chips became common, probably even before CDs became common. The point is that giving my explicit say-so is easy. The way I interpret that in the case of a bootloader that's not built in but that's on one of the drives, is that GRUB only trusts the drive it's on (and the RAM, CPU etc.) by default, or whatever configuration of hardware you want to specify allowing in grub.cfg? (Or maybe just a well-defined search order is sufficient -- but it would be odd to find something identified by UUID on a different disk than it was originally, so the user might want to be asked if all is as s/he intended.) Of course at GRUB commandline you can still boot from CD! Locking away GRUB's powers from its user is a completely different matter! try any of the following: - Crypt your whole disk. Have your /boot in a usb drive you carry with you. (well, I do crypt my home-directory with LUKS and a long random password made with physical dice, which would be a decent way of keeping someone who steals my computer from reading/changing my documents, except that I hardly ever shut down my computer. Besides that LUKS password, and my very short login passwords, my computer trusts the user-with-physical-access completely.) - Remove your CD drive and unexpose USB slots (use locks or if really paranoid sink your board in concrete). Hehe, those are completely unnecessary, me choosing "don't ever insert CD or USB" is quite sufficient. I trust myself even when I don't trust my computer to do what I naively believe it should do. But never inserting CD/USB makes it infinitely harder for me to use CD/USB! (for innocuous data purposes -- I tend to assume that data can't have viruses in it because Linux programs aren't very buggy, which is perhaps a foolish assumption. But it's in contrast to booting something on bare hardware, which requires no software bugs (on my hard disk) in order to modify my system.). So-called "Trusted" Computing is just a blatant excuse to steal your music and your documents. Don't drink the kool aid. I was a bit worried that my using words like "genuine" and "trust" and "attacker" was going to make people think "oh no, DRM!", which is when I have software that doesn't trust me (eeek!), rather than vice versa (in my experience, I could only trust my computer completely if I knew exactly what all software on it was supposed to *do* and it was bug-free, because no computer interface in history has been perfectly safe and undo-able). Actually I suppose I was describing something a little more subtle: software that doesn't trust other software (unless I say so, which is an important "unless"). But it's just like in Linux: software run as "root" doesn't trust most other software unless I say "sudo", which is a tricky way of making sure overly helpful user-level software doesn't try to mess with my system behind my back; which works because that software doesn't think it knows my password. Luckily, programs don't "helpfully" try to memorize my login password, because it's obvious to their devs that *that's* insecure, and some people have heavier security needs that deserve passwords that have significant strength. "Attacker" is just such a convenient description. Many issues that can be caused by an attacker can be caused with somewhat less likelihood by mistake or complicated situation, and can be treated as ordinary design issues. Understanding how each computer works, helps; DRM harms. Or use a crypto module where you load a key from a secure environment and use that to implement measurement during boot. The TPM could have become such module, but they decided to cripple it by: a) Loading the key themselves. b) Not giving you a copy of the k
Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)
Robert Millan wrote: Perhaps we are over-engineering a bit here. In the long run, maybe it makes more sense to always use UUIDs and drop the make_install_device() complexity. I'm also concerned that UUID may not be unique. For instance, a disk was cloned, and a filesystem of the clone was modified without changing the UUID. I think in the long term the solution to that is that cloning software becomes UUID-aware and picks the right option between generating or copying the UUIDs (of course, the right option could just be what the user says! but this is outside of our scope ;-)). Is using UUIDs alone resilient against this situation: An attacker finds out the UUIDs on your hard-disk. S/he makes a USB drive or CD (that preferably looks innocuous when plugged into a running system), but has a UUID on it equal to that of the GRUB boot partition (which might not be mounted on a running system). Anyway, when the system (core.img) boots, can it tell the difference well enough to prefer the GRUB that's on the disk that it was originally installed to? (Equally well, you could have a GRUB core.img and /boot on a CD or unwriteable USB drive that you're trying to boot when you don't entirely trust the computer's hard disk.) Furthermore, perhaps all the modules that the attacker provided are the same as the genuine ones; only grub.cfg differs... only the most paranoid of us would try to put a hash in core.img that complains whenever grub.cfg has changed from the original state? To try to answer my own questions: If it's BIOS-based and a same-drive install (and if we trust the BIOS, and it's not too buggy...), and the BIOS has started booting from our drive, then we should be able to check the same drive first? But if we don't understand anything about how the boot-process selected us to boot, or if it's a cross-drive install, then there's no way for us to tell the difference between "our disk" and a malicious duplication of the disk with a few modifications? Maybe by interface type (e.g. we expected it to be on an ATA not a USB drive)?? I'm sure I might be way off track, but I worry about the predictability of my bootloader.. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: menu loop (patch)
Carles Pina i Estany wrote: Hello, On Jul/19/2008, Isaac Dupree wrote: Carles Pina i Estany wrote: fast check in KDE: it's looping Also, Iceweasel menus are looping here (maybe because it's executed in KDE and there is some GTK Widget with a different behaviour? I have no idea) GTK menubar-menus are looping for me. But I'm not sure about menus that consist of selecting from a list in a box (maybe some login window?). I don't care personally, because my GRUB-lists are not terribly long... hmm, if you hold down a (arrow) key in GRUB, is there auto-repeat? no, there isn't auto-repeat (this is what the patch that we are talking does). GRUB-lists shouldn't be terrible long, but quite users needs to go from the first option to the last option quite often (at least is what i see). is this because tools tend to add options to the *end* of the list -- the same way my browser adds bookmarks to the end of the bookmarks menu? That's the situation I find myself really using looping regularly in my OS (Firefox, Linux). It might be worth the effort to add a config option, if there are people who have to deal with their boot-menu on a regular basis (are there? probably...). Then if they're like me, they'll want to be able to fix its annoying behavior for the future. So it's worth it for them; and if there are a significant number of people like that, the one-time cost of *implementing* the option may be worth it. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: menu loop (patch)
Carles Pina i Estany wrote: fast check in KDE: it's looping Also, Iceweasel menus are looping here (maybe because it's executed in KDE and there is some GTK Widget with a different behaviour? I have no idea) GTK menubar-menus are looping for me. But I'm not sure about menus that consist of selecting from a list in a box (maybe some login window?). I don't care personally, because my GRUB-lists are not terribly long... hmm, if you hold down a (arrow) key in GRUB, is there auto-repeat? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
Markus Halm wrote: What is the URI of the subversion repository, btw? I am new to this mailing list, so please excuse me if it already has been said. No one else said it, so I had to guess from the generic Savannah page, and this seems to be working, but I rather don't like that no one else has said a word on this exact subject: (svn co) svn://svn.savannah.gnu.org/grub/trunk/grub2/ Or if you want an HTTP url I think it is http://svn.savannah.gnu.org/svn/grub/trunk/grub2/ -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
Bean wrote: It have switched to svn now, cvs is not updated anymore. like this, then svn co svn://svn.savannah.gnu.org/grub/trunk/grub2/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] GRUB Loading message
Pavel Roskin wrote: Quoting Isaac Dupree <[EMAIL PROTECTED]>: As per the "GRUB Loading kernel" discussion (interpreting silence as "send a patch"). I guess I need to write a ChangeLog entry, is there anything telling me how to do that? I looked at other examples on this list and wasn't sure how to apply them here. Is there anything else I'm missing? I forgot to test that it does anything more than compile, is there some way to test in an emulator (documented somewhere? Maybe QEMU, parted etc. work with a file as a whole set of partitions?) It's already applied (with small "l"). I should have posted it to the list, sorry. Odd, I didn't see it changed in boot/i386/pc/diskboot.S when I do `cvs up`? Or have we switched over to SVN now?(in which case what svn co should I do?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] GRUB Loading message
As per the "GRUB Loading kernel" discussion (interpreting silence as "send a patch"). I guess I need to write a ChangeLog entry, is there anything telling me how to do that? I looked at other examples on this list and wasn't sure how to apply them here. Is there anything else I'm missing? I forgot to test that it does anything more than compile, is there some way to test in an emulator (documented somewhere? Maybe QEMU, parted etc. work with a file as a whole set of partitions?) -Isaac Index: grub2patching/boot/i386/pc/diskboot.S === --- grub2patching.orig/boot/i386/pc/diskboot.S 2008-07-10 11:16:18.0 -0400 +++ grub2patching/boot/i386/pc/diskboot.S 2008-07-10 11:17:23.0 -0400 @@ -326,7 +326,7 @@ /* go here when you need to stop the machine hard after an error condition */ stop: jmp stop -notification_string: .string "Loading kernel" +notification_string: .string "Loading" notification_step: .string "." notification_done: .string "\r\n" ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: On Sun, Jul 6, 2008 at 7:02 AM, Isaac Dupree <[EMAIL PROTECTED]> wrote: Bean wrote: Hi, Perhaps you can also try the binary version at: http://grub4dos.sourceforge.net/grub2/grub.efi.1 A friend of mine have tested in in 32-bit EFI firmware, there is no problem for him. It confuses me! I could boot it from refit as EFI. Then it claimed to be GRUB 0.97. The "help" looked slightly different that what I was familiar with (but I've never used grub1 so I don't know...); and `reboot` worked. I didn't test more yet.. should I? Hi, That's the fedora efi loader, have you used the right file ? BTW, you need to rename it as grub.efi, refit can't find files with .1 suffix. oh, oops :-/ Now, actually using that file :-) -- reboot and lspci work, unlike in my version (I wonder why they're different??) -- appleloader works equally badly as with my compile. -- I tried passing video=intelfb to linux; it worked under grub2-pc but didn't improve anything under efi. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: "GRUB Loading kernel..." message
Robert Millan wrote: On Sat, Jul 05, 2008 at 07:24:56PM -0400, Isaac Dupree wrote: I thought I remembered somewhere a discussion how the message "GRUB Loading kernel" is confusing, because it doesn't say what kernel it's loading, and grub loads lots of kernels I think this is not accurate. GRUB loads payloads. It doesn't care if they're a standalone OS like invaders.elf or the kernel part of an OS that resides on disk/network/whatever. okay, I'm getting pedantic, but that is very much from GRUB point-of-view; GRUB certainly does load payloads, but from non-GRUB point-of-view, those payloads are often also OS kernels. So if you know GRUB terminology, GRUB would never say it was loading a kernel when it was loading a payload, because it neither knows nor cares whether anyone else would call that payload a "kernel". Rather convincing. Although, it would still be as accurate for a user to say that "GRUB is loading linux kernel" as it would be, if I'm blindly eating food, for someone to say I'm eating a banana. But I don't care so much about philosophy, just that "GRUB Loading kernel" confuses lots of people and it seems we've found a just-as-good wording that doesn't :-) Anyway, any change of the message vs. GRUB Legacy means that we can tell from the message whether it's GRUB1 or GRUB2 :-D should I send a patch to change the message from "Loading kernel" to "Loading"? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: "GRUB Loading kernel..." message
Pavel Roskin wrote: On Sat, 2008-07-05 at 19:24 -0400, Isaac Dupree wrote: . Although, looking at the files, boot/i386/pc/boot.S outputs "GRUB " and boot/i386/pc/diskboot.S outputs "Loading kernel", so the parts actually mean different things: maybe it's important that it prints "GRUB " first in case it never prints anything else? perhaps there are other possible code-paths? In any case, then maybe it should say "GRUB Loading GRUB kernel", or, "GRUB Loading itself" :-) Considering that diskboot.img is limited to 512 bytes, I'd rather go with "loading" without "kernel". The result would be "GRUB loading", which would look better than your proposals. The saved bytes could be used for some good purpose eventually. I like that wording: concise and clear (although maybe so concise that it gets hard for a user having a problem, to Google for it). By the way, currently the "Loading" seems to have the first letter capitalized (I don't care either way) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
"GRUB Loading kernel..." message
I thought I remembered somewhere a discussion how the message "GRUB Loading kernel" is confusing, because it doesn't say what kernel it's loading, and grub loads lots of kernels (this message means that the "kernel" is a core part of GRUB, and the subject "GRUB" the message mentions is different: it's some early loading code.) There is an argument that "kernel" does not mean the same thing as "Linux kernel", which is quite right: that's why the message is not at all incorrect, just highly ambiguous. It seems like it should be "Loading GRUB kernel" . Although, looking at the files, boot/i386/pc/boot.S outputs "GRUB " and boot/i386/pc/diskboot.S outputs "Loading kernel", so the parts actually mean different things: maybe it's important that it prints "GRUB " first in case it never prints anything else? perhaps there are other possible code-paths? In any case, then maybe it should say "GRUB Loading GRUB kernel", or, "GRUB Loading itself" :-) to preserve the usefulness and increase the clarity. (Albeit, someone who doesn't know how GRUB works might be confused by how it can be loading itself: it's actually one part of GRUB loading a bigger part of GRUB. But we'll never be able to properly explain that to a nontechnical person :-) (Am I missing something, since this is my first time looking at GRUB code?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: Hi, Perhaps you can also try the binary version at: http://grub4dos.sourceforge.net/grub2/grub.efi.1 A friend of mine have tested in in 32-bit EFI firmware, there is no problem for him. It confuses me! I could boot it from refit as EFI. Then it claimed to be GRUB 0.97. The "help" looked slightly different that what I was familiar with (but I've never used grub1 so I don't know...); and `reboot` worked. I didn't test more yet.. should I? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] LZMA support in i386-pc kernel
by the way, is LZMA decoding slow enough to be noticable on old machines, every boot time? (say, more than 1 second to decode core.img?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
Robert Millan wrote: A more elegant solution (also may be interesting for security at some point) would be for update-grub to hash each file it generates access commands for and embed the sum in grub.cfg as a check parameter, like if verify_hash /file x ; then do_something_with_file /file fi So, if we take for granted those two things: - That GRUB should never crash no matter what you feed to it. - That update-grub instructs GRUB to verify file consistency via hashing. also?, - That whenever someone wants to boot a new kernel (or whatever), they re-run update-grub. Which definitely doesn't apply if they're interactively poking around with the GRUB commandline. But it could be a safety check for some cases. Would it ever make sense to *ask* the user whether to proceed, if the file is different? (they might have changed the file deliberately!) But, with that code you mentioned for grub.cfg, I suppose it can be adjusted to do that, if desired by whoever controls grub.cfg. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Eliminating grub_size_t
size_t has different size on 32-bit and 64-bit systems, but we should strive to make the userspace utilities work like the bootloader, so that possible problems can be detected early and debugged easily. I didn't understand this. What do you mean with "US working like the bootloader?" I mean that if, say, GRUB fails to read reiserfs, I'd like to be able to reproduce the problem in grub-fstest even if I'm compiling it on x86_64. In this case, so we're producing a 32-bit, pc grub image. To have a similar effect in grub-fstest, we'd need to define grub_size_t to be a 32-bit quantity when compiling that too, am I right? Is there any reason not to just have grub-fstest try to imitate whatever the bootloader image decides it needs? So if some platform requires a 64-bit bootloader and we're running on 32-bits, we may need a 64-bit grub_size_t in both places (well, this is maybe not likely to work entirely, but GCC can generate the operations -- or we could just use 32 bit for grub-fstest then if we think it's the least-nonsensical thing to do in that hypothetical situation). -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe detects ext4 wronly as ext2
+#define EXT3_FEATURE_INCOMPAT_RECOVER 0x0004 /* Needs recovery */ +#define EXT2_DRIVER_SUPPORTED_INCOMPAT ( EXT2_FEATURE_INCOMPAT_FILETYPE ) I suspect this will mean that journalled ext3 when the system crashed (so the filesystem "needs recovery" from the journal) won't load. (Of course, properly speaking that would load grub's code to replay the journal...) But I think that (without other changes) that would make the system unbootable every time there was a power outage? (Of course it was not guaranteed to load correctly when ignoring the journal when it needed recovery, but it was likely to work, IIUC.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: I wonder if there is bug in the hfsplus module. You can check it out with grub-fstest command: sudo ./grub-fstest /dev/sda3 ls / This would list the content of root directory. outputs nothing, just a blank line, for /dev/sda2 which is my hfsplus (it works fine for fat16, ext3 partitions). You can also create a small hfs+ image and test it with grub-fstest, if it does have problem, you can upload the image for me to test. not sure how to create a hfs+ image... the one I have is many gigabytes and came with the laptop (I just shrunk it to 30GB to fit my linuxes, is all). Does Linux or MacOSX provide a way to create a small HFSJ image? (also I could try going to MacOSX and turning off journalling and see if it affects grub2's ability to read it at all, perhaps - although for just reading, not writing, I doubt it makes a significant difference) cpuid would check if cpuid exists and set return code, there is no output. oh, okay, then it's just the command's help description that was confusing me The result is lspci is a little strange. Is there any output before hanging ? no, I hit enter and never get back a prompt or any output When you use video=efifb or video=vesafb. It enum pci to get the frame buffer address, if it doesn't hang there, it shouldn't hang here as well. odd, because that definitely didn't hang (when loading linux-2.6.25 that is). reboot could be a firmware related issue, I can check it out. okay, maybe it is Oh btw, do you compile from source or use the binary version ? I compile grub2 from source -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: Perhaps command line is not passed to loader correctly, you can verify it with the OSX loader: set root=(hd0,2) chainloader /System/Library/CoreServices/boot.efi -- -v boot Please try this out, if parameter -v is passed to the loader, you will see console screen before switching to GUI. That 'chainloader' didn't work at all: It seems GRUB2 here isn't understanding the HFS+(journaled) filesystem at all. Neither in EFI nor BIOS grub2 can I see anything on that partition, even though I have module hfsplus loaded (I think - but lsmod in grub takes up more than the whole screen, so I can't see them all - is there any way to get around that?). Also I decided to play around and try a few other commands in grub2. cpuid (efi or pc) -- finishes instantly without outputting anything lspci (efi) -- hangs (but it works properly in pc) reboot (efi) -- hangs (but it works properly in pc) every time I've tried Ubuntu with a different kernel... it has problems. Ubuntu has a fancy initrd, modules, lots of patches, Upstart as init, >and who knows what assumptions about the boot process... but maybe. I could use the kernel from the Ubuntu development branch, if I >had any idea how to use APT to upgrade just a few specific things from an unstable package-source and not my whole system (the kernel >binary obviously doesn't depend on system libraries, so it should be uniquely easy to do this...). Do you know about debians -- if that's >possible? In debian, all I have to do is to add the sid line to /etc/apt/source.list, apt-get update, then apt-get install linux-image-xxx. Ubuntu is based on debian, the process should be similar. yes it is similar (and I'd probably try and use the Ubuntu development branch for the next release, "intrepid") : however, what bothers me is that this seems to make the whole apt repo, not just the part I want, be a first-class citizen; so that if it contains a newer version number of any package on my system, it will install that if I ask to install the package, or it will offer to upgrade to that version if it's already installed (so I can't even begin to pick out which are the Ubuntu-stable updates). I hope I'm missing some option that lets me avoid this risky nuisance, while still keeping tabs on the unstable linux-image packages? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: I'm using the 2.6.25 kernel from debian sid, it works fine. I think ubuntu can use debian packages as well. To solve the screen problem, you need the following command line: video=efifb agp=off If you're interested, you can also try amd64 kernel. You can use it on 686 linux directly, no need to install a full amd64 system. every time I've tried Ubuntu with a different kernel... it has problems. Ubuntu has a fancy initrd, modules, lots of patches, Upstart as init, and who knows what assumptions about the boot process... but maybe. I could use the kernel from the Ubuntu development branch, if I had any idea how to use APT to upgrade just a few specific things from an unstable package-source and not my whole system (the kernel binary obviously doesn't depend on system libraries, so it should be uniquely easy to do this...). Do you know about debians -- if that's possible? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: I take a look at 0.9 source, the handling is the same. Are you sure you type the command exactly as it is ? appleloader HD boot what should I expect the result to be, given that refit is the only thing that's ever touched my MBR since Apple's manufacturing? (so there's a fake partition table created by refit's gptsync, and maybe there's whatever you were saying about refit using hacks with the mbr to boot grub-pc from my third partition, but I've never specifically installed any bootloaders to this mbr) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: Also, you can try adding video=efifb to the command line, does it show kernel message ? I'll try that soon, does it need any special customization of the kernel? You can try the kernel I extract from Fedora's efidisk: http://grub4dos.sourceforge.net/grub2/efi.rar It's 2.6.25. But there is a small problem with this kernel, the screen would scramble after some kernel output. This is caused by the agp driver, not grub's fault. Results: Whatever linux kernel I pick, adding video=efifb to its commandline causes grub to output a couple extra lines in response to `linux`: Video mode: [EMAIL PROTECTED] Video framebuffer: 8000 Even with video=efifb, the Ubuntu kernel works no better. But that Fedora kernel you mentioned, does work: - with video=efifb, the penguin and kernel messages flash onto the screen for a moment before the screen turns into gibberish. - without, the screen just turns into different gibberish, which is still an improvement over the GRUB screen remaining there :-) Of course, that Linux kernel doesn't bring me to anything *usable*... but it shows that we're loading Linux and it's probably possible to work in practice by compiling a new enough Linux with the right configs (and maybe patches) - appleloader always tells me "Model : Core Duo/Solo" and nothing else (no matter whether I give it a parameter or not). If I say "boot" nothing happens, it just stays in GRUB prompt and I can enter more commands. (admittedly, I think I didn't *have* anything to boot in my CD drive, USB or MBR) The model is quite old, it's possible that it uses xom. Is there a /System/Library/CoreServices/xom.efi in the OSX partition ? only one year old :))) Interesting, according to refit, this should be an early 2006 model. Refit does work, doesn't it ? refit doesn't tell *me* anything about the model when I'm in refit. In case what your appleloader says was confusing you, I actually have a 2.16 GHz Intel Core 2 Duo CPU (yes, 64-bit capable, I've just never used it in that way). I'm still running refit 0.9 though since I never yet bothered to upgrade to 0.10 or 0.11, and since it works fine for me. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: - linux then initrd doesn't run out of memory (that fix is still there). On the other hand, 'linux' with wrong parameters so I repeated the command, did give me such an error. In any case, trying again perfectly and booting, gave me the same (as my last test with your EFI patches) hanging on the GRUB terminal, not booting successfully. What's the kernel version ? Perhaps you need the latest 2.6.25 series. oh, maybe. It's an Ubuntu kernel. > uname -a Linux east 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008 i686 GNU/Linux Also, you can try adding video=efifb to the command line, does it show kernel message ? I'll try that soon, does it need any special customization of the kernel? - appleloader always tells me "Model : Core Duo/Solo" and nothing else (no matter whether I give it a parameter or not). If I say "boot" nothing happens, it just stays in GRUB prompt and I can enter more commands. (admittedly, I think I didn't *have* anything to boot in my CD drive, USB or MBR) The model is quite old, it's possible that it uses xom. Is there a /System/Library/CoreServices/xom.efi in the OSX partition ? only one year old :))) No, there isn't.. the only .efi file in that directory is /System/Library/CoreServices/boot.efi -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: On Sat, Jun 21, 2008 at 1:04 AM, Bean <[EMAIL PROTECTED]> wrote: Hi, This new patch add the following function to the original x86_64 EFI patch: 1, Fix menu drawing problem It maps the unicode char to EFI char so that the rectangle box is showed properly 2, Handle command line option for chainloader command 3, Add new command appleloader The command is used to enable bios boot in apple's bootcamp, for example boot from legacy mbr: appleloader HD boot boot from legacy cd: appleloader CD boot boot from usb: appleloader USB boot The usb booting may not work in some machine. Hi, I also fix a few problem in the linux loader, now it can load both 686 and x86_64 kernel from 64-bit EFI firmware. Would someone test it in 32-bit EFI ? with just that patch against CVS, for me - linux then initrd doesn't run out of memory (that fix is still there). On the other hand, 'linux' with wrong parameters so I repeated the command, did give me such an error. In any case, trying again perfectly and booting, gave me the same (as my last test with your EFI patches) hanging on the GRUB terminal, not booting successfully. - appleloader always tells me "Model : Core Duo/Solo" and nothing else (no matter whether I give it a parameter or not). If I say "boot" nothing happens, it just stays in GRUB prompt and I can enter more commands. (admittedly, I think I didn't *have* anything to boot in my CD drive, USB or MBR) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New x86_64 EFI patch
Bean wrote: On Sat, Jun 21, 2008 at 1:04 AM, Bean <[EMAIL PROTECTED]> wrote: Hi, This new patch add the following function to the original x86_64 EFI patch: 1, Fix menu drawing problem It maps the unicode char to EFI char so that the rectangle box is showed properly 2, Handle command line option for chainloader command 3, Add new command appleloader The command is used to enable bios boot in apple's bootcamp, for example boot from legacy mbr: appleloader HD boot boot from legacy cd: appleloader CD boot boot from usb: appleloader USB boot The usb booting may not work in some machine. I'm not so sure about that syntax. Is there really only one way to boot from HD or USB? (for example I've been storing pc-GRUB2 in fat16 header on third partition, not mbr, and rEFIt finds it there). How does Windows do it (can we boot Windows using this)? (even though Apple made BootCamp for windows, I don't want to find out personally.) I guess you're stuck with some limitations of the apple bios software? Also , "appleloader CD" makes me think it should be used even for Mac OS X boot-CD's, which I doubt it should? Hi, I also fix a few problem in the linux loader, now it can load both 686 and x86_64 kernel from 64-bit EFI firmware. do you mean linux successfully booting, or hanging as before? Would someone test it in 32-bit EFI ? I get an error during `make`, after (from a clean tree) cvs up; patch -p1 -l < ~/../downloads/efi_5.diff; ./configure --with-platform=efi; make cat kernel_syms.lst def-normal.lst def-_chain.lst def-chain.lst def-_linux.lst def-linux.lst def-cpuid.lst def-halt.lst def-reboot.lst def-fshelp.lst def-fat.lst def-ufs.lst def-ext2.lst def-ntfs.lst def-ntfscomp.lst def-minix.lst def-hfs.lst def-jfs.lst def-iso9660.lst def-xfs.lst def-affs.lst def-sfs.lst def-hfsplus.lst def-reiserfs.lst def-cpio.lst def-udf.lst def-afs.lst def-amiga.lst def-apple.lst def-pc.lst def-sun.lst def-acorn.lst def-gpt.lst def-raid.lst def-lvm.lst def-hello.lst def-boot.lst def-terminal.lst def-ls.lst def-cmp.lst def-cat.lst def-echo.lst def-help.lst def-font.lst def-search.lst def-test.lst def-loopback.lst def-configfile.lst def-terminfo.lst def-blocklist.lst def-hexdump.lst def-elf.lst def-gzio.lst def-read.lst def-sleep.lst /dev/null \ | mawk -f ./genmoddep.awk und-kernel.lst und-normal.lst und-_chain.lst und-chain.lst und-_linux.lst und-linux.lst und-cpuid.lst und-halt.lst und-reboot.lst und-fshelp.lst und-fat.lst und-ufs.lst und-ext2.lst und-ntfs.lst und-ntfscomp.lst und-minix.lst und-hfs.lst und-jfs.lst und-iso9660.lst und-xfs.lst und-affs.lst und-sfs.lst und-hfsplus.lst und-reiserfs.lst und-cpio.lst und-udf.lst und-afs.lst und-amiga.lst und-apple.lst und-pc.lst und-sun.lst und-acorn.lst und-gpt.lst und-raid.lst und-lvm.lst und-hello.lst und-boot.lst und-terminal.lst und-ls.lst und-cmp.lst und-cat.lst und-echo.lst und-help.lst und-font.lst und-search.lst und-test.lst und-loopback.lst und-configfile.lst und-terminfo.lst und-blocklist.lst und-hexdump.lst und-elf.lst und-gzio.lst und-read.lst und-sleep.lst > moddep.lst \ || (rm -f moddep.lst; exit 1) grub_pci_make_address in _linux is not defined make: *** [moddep.lst] Error 1 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] add a counter in grub_dprintf
Javier Martín wrote: El sáb, 21-06-2008 a las 16:19 +0200, Robert Millan escribió: But space in post-mbr area is precious, and if we can save a bit, it means less users who will run into trouble in first place. Disclaimer: the following is just the product of brainstorming from a mind tortured by hours of studying projective geometry. Use with care ^^ Why not modify the build system to create _two_ instances of kernel.img, one with and another without debugging? grub_mkimage would create the normal, smaller core.img (without dprintf) for installing and embedding; and store a core_dbg.img in the /boot/grub folder, so that if instrumentation is required the only thing the users needs to do is chain that debug version of GRUB: grub> multiboot /boot/grub/core_dbg.img grub> boot or even to install it if necessary (if it fits! But multiboot, if it works, could help *some* of the time too). I think that prebuilt debug image is important, otherwise when users rebuild a debug version it's much more likely to be built differently somehow from the corresponding non-debug version (especially if it originally came through a packaging system such as Debian). Robert Millan wrote: OTOH, it could add maintainance burden for us when we have to explain everyone that they have to rebuild and reinstall GRUB to get the debug output _and_ it opens the door for heisenbugs. But space in post-mbr area is precious, and if we can save a bit, it means less users who will run into trouble in first place. the possibility for heisenbugs does seem very real given the diversity of hardware out there. Would it mitigate this to only disable the dprintfs (by default) in space-critical images such as x86 pc? (or would it make things worse...) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] add a counter in grub_dprintf
Robert Millan wrote: How about adding a counter to grub_dprintf to make it easy to instrument GRUB and find which are the bottlenecks in boot time? Sidenote: perhaps it'd be a good idea to conditionalize all grub_dprintf calls with #ifdef DEBUG to obtain a smaller core.img. It's not hard to ask a user to rebuild if dprintf is needed, Are the dprintf's useful for users' debugging, not just debugging GRUB bugs? If it is, I'm not sure... If I accidentally broke something on my disk so that the core image couldn't find the modules/configuration, then it might be a little hard to rebuild grub and reinstall on that machine. Obviously I'll be able to, somehow, if my computer isn't completely hosed, but I'd rather be able to search for debugging information I recorded ASAP so I need fewer iterations of nuisance for myself. Perhaps a minor issue. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] split floppy support off biosdisk
if it's not too much work to maintain multiple decompression algorithms, maybe we can have grub-install pick the weakest compression that still shrinks the image enough to fit? Then only "complicated" setups will need LZMA's memory excesses. (Might not be worth the effort though.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix grub-install to use prefix for modules dir
Pavel Roskin wrote:
On Tue, 2008-06-17 at 10:51 -0700, Colin D Bennett wrote:
I fixed ``grub-install`` so it can function when installed
to a prefix other than ``/usr/local``. This simply meant adding
--directory="${pkglibdir}
to the command line arguments for grub_mkimage.
The default is GRUB_LIBDIR, which is set to pkglibdir at the compile
time. Your patch would have no effect if anything is compiled and
installed properly.
indeed, grub-install works for me with ./configure --prefix=$PWD/inst;
make; make install; sudo ./inst/sbin/grub-install ...
-Isaac
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Some concern about the journal support
Pavel Roskin wrote: On Fri, 2008-06-13 at 15:45 -0400, Isaac Dupree wrote: can you send a message when GRUB2 CVS is considered no longer broken for use with ext3? (so I'll know when is a good time for me to install a newer version -- since I'm not in a hurry -- or is it a better bet stability-wise within the next month, to go with a revision from May instead?) I'm afraid it's not going to work this way. I can imagine that some fixes will be applied, but it's also possible that they will be incomplete. true enough: grub's ext3 support is relatively unstable for now, so if I use it I should be prepared to report problems and help debug them. Partly I just get confused (although patches are frequently discussed on the list) which patches have actually been applied to CVS, and whether any of the *known* issues are still known to be unfixed in CVS. (That is, I'm usually willing to be a tester, but it's generally not useful to anyone to test things that are known to be broken) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Some concern about the journal support
can you send a message when GRUB2 CVS is considered no longer broken for use with ext3? (so I'll know when is a good time for me to install a newer version -- since I'm not in a hurry -- or is it a better bet stability-wise within the next month, to go with a revision from May instead?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Bean wrote: Use -l option in patch to ignore space. If it still not work, you can make the changes manually, it's quite simple: /naive me thanks you for mentioning -l Ok, I can basically make everything else work, even chainloading OS X, but it just don't boot Linux. Kernel and initrd loads properly, but it hangs when boot. I start to wonder if this is the kernel's fault. I apply the patches from mactel-linux.org, not working either. And elilo also fails to load linux. same here, initrd loading looks to be working properly now with your patch, and Linux seems to get equally stuck even when I boot a kernel that doesn't need/have an initrd (despite all with CONFIG_EFI=y, and other _EFI_ things on too; in particular, it wasn't on the network when I had ethernet cable plugged in, and it normally would be, so that's my evidence that it definitely didn't boot). (though I didn't try chainloading OSX). So it seems your patches improve matters; but we're not in paradise yet :-), and may not be for a while, so the patches should probably go into grub and the symptoms documented? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Bean wrote:
On Wed, Jun 4, 2008 at 7:01 PM, Isaac Dupree
<[EMAIL PROTECTED]> wrote:
how do you apply this patch? With `patch -p1` I'm getting:
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
any more infos needed?
There maybe some code mixups, try this one:
nope, against latest CVS:
> patch -p1 <../grubinitrd2.patch
patching file loader/i386/efi/linux.c
Hunk #1 FAILED at 601.
Hunk #2 FAILED at 612.
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
BTW, are you using a customized kernel ? Some people reports that efi
booting don't work. They have 32-bit firmware just like yours, but
hangs even without the initrd.
Well, I'll see what happens. (Ubuntu kernel is very customized by the
Ubuntu devs.) I have a theory that the console display doesn't work so
I need to get feedback some other way (X? Sound? File modification?
Visibility on network (plug into ethernet first)?) to see if linux has
booted. Also once I have got this patch tried, I'll try adding your
other patch(es) for x86-64 and see if a 64-bit EFI image makes any
difference (although I doubt it will work any *better*, and possibly
worse. but who knows.)
Does grub2 "multiboot"-ing itself, work yet? (just so we could test that
too under EFI)
diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index ee3fb99..5ace7c0 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -601,7 +601,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
lh = (struct linux_kernel_header *) real_mode_mem;
- addr_max = grub_cpu_to_le32 (lh->initrd_addr_max);
+ addr_max = (grub_cpu_to_le32 (lh->initrd_addr_max) << 10);
if (linux_mem_size != 0 && linux_mem_size < addr_max)
addr_max = linux_mem_size;
@@ -612,7 +612,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
addr_max -= 0x1;
/* Usually, the compression ratio is about 50%. */
- addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12);
+ addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12)
+ + page_align (size);
/* Find the highest address to put the initrd. */
mmap_size = find_mmap_size ();
@@ -625,8 +626,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
{
if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY
- && desc->physical_start >= addr_min
- && desc->physical_start + size < addr_max
&& desc->num_pages >= initrd_pages)
{
grub_efi_physical_address_t physical_end;
@@ -635,6 +634,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
if (physical_end > addr_max)
physical_end = addr_max;
+ if (physical_end < addr_min)
+continue;
+
if (physical_end > addr)
addr = physical_end - page_align (size);
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
how do you apply this patch? With `patch -p1` I'm getting:
2 out of 4 hunks FAILED -- saving rejects to file
loader/i386/efi/linux.c.rej
any more infos needed?
-Isaac
Bean wrote:
Hi,
I figure it out now, there is some problem with the initrd allocation
algorithm, the following patch should fix it:
diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index ee3fb99..8d0e0c2 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -601,7 +604,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
lh = (struct linux_kernel_header *) real_mode_mem;
- addr_max = grub_cpu_to_le32 (lh->initrd_addr_max);
+ addr_max = (grub_cpu_to_le32 (lh->initrd_addr_max) << 10);
if (linux_mem_size != 0 && linux_mem_size < addr_max)
addr_max = linux_mem_size;
@@ -612,7 +615,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
addr_max -= 0x1;
/* Usually, the compression ratio is about 50%. */
- addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12);
+ addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12)
+ + page_align (size);
/* Find the highest address to put the initrd. */
mmap_size = find_mmap_size ();
@@ -625,8 +629,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
{
if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY
- && desc->physical_start >= addr_min
- && desc->physical_start + size < addr_max
&& desc->num_pages >= initrd_pages)
{
grub_efi_physical_address_t physical_end;
@@ -635,6 +637,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
if (physical_end > addr_max)
physical_end = addr_max;
+ if (physical_end < addr_min)
+continue;
+
if (physical_end > addr)
addr = physical_end - page_align (size);
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Bean wrote: Hi, The problem with initrd is that it can't allocate enough memory. Please try the following patch, it will show some info that could be be useful in debugging. linux (hd0,4)/vmlinuz [Linux-EFI, setup=0x2a00, size=0x1d2798] initrd (hd0,4)/initrd.img 679000 1ffe 832 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Searching UUID on floppies
Robert Millan wrote: On Sat, May 31, 2008 at 03:06:30PM -0400, Isaac Dupree wrote: Robert Millan wrote: Some of our commands use --no-floppy. Also supported in GRUB Legacy (by 'find' or so, can't remember). Perhaps it's better to use that for consistency? It is the floppy scan which everyone hates; for other devices I don't think people will mind if GRUB spends a few ms on them. I don't know if it's relevant... but there is a situation that is maybe similar when my MacBook boots up (before it even gets to GRUB), if there's a CD in the drive, it wastes about 15 extra seconds spinning it up to look at it, even if I'm not booting from CD. So that might be a sort of thing to watch out for, when making GRUB search? Does it happen before or after you get the "Welcome to GRUB!" message? *That* happens even if I never enter grub at all -- so I guess you would say "before". GRUB doesn't have that problem for me as far as I know, but the only things I have in my config are (hd0,x) -- no boot-from-CD option, only the Linuxes on the disk that I have configured precisely and numerically. look, here is my boot sequence: EFI firmware boots the MacOSX partition by default, if I don't hold down "option"/"alt" (if I do, then the firmware puts up a menu of choices). rEFIt is installed in such a way that it is booted rather the standard MacOSX at that point. It puts up a nice menu of choices including MacOS, any bootable CD/DVDs, and all the GRUBs it can find. It's rEFIt's appearance that is delayed when there's a CD in the drive. rEFIt knows how to boot both EFI and BIOS GRUBs. -- MacOSX: boots normally if selected in rEFIt. -- GRUB2: well, you know about that. From there, I can potentially boot my Linuxes that are on various of my partitions. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Robert Millan wrote: On Sat, May 31, 2008 at 02:57:21PM -0400, Isaac Dupree wrote: You're confusing BIOS-based boot with msdos partition labels. You can use GPT just fine when booting from BIOS (although Intel tries to hide that fact by embedding the GPT spec inside the EFI spec). I have the hack which combines the two partition labels so I have both GPT and msdos labels. Which means that my first four partitions (only) are listed in msdos, and GPT is the really accurate one that MacOS and Linux use. I'm not sure if this would confuse GRUB partition-wise. Can it access all partitions? yes, I was booting from the fifth partition for a while -- grub just needs the gpt module while running, obviously. That disk layout is a standard hack, there are tools for it named e.g. "gptsync" that the rEFIt guys mention/include. However, I can't find a way to get into bootloader-land via BIOS without going through the msdos partitioning mechanism. grub-setup may, too, be confused by this hack. Saving that, you should be able to install GRUB in MBR following the normal procedure, without any need for msdos-style partition table (other than the dummy 0xee one). Would be nice if you can verify GRUB works in both situations. I bet it works fine that way too -- but I don't really have any way to get back to having just one dummy msdos-partition without wiping my disk, as far as I know. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Searching UUID on floppies
Robert Millan wrote: Some of our commands use --no-floppy. Also supported in GRUB Legacy (by 'find' or so, can't remember). Perhaps it's better to use that for consistency? It is the floppy scan which everyone hates; for other devices I don't think people will mind if GRUB spends a few ms on them. I don't know if it's relevant... but there is a situation that is maybe similar when my MacBook boots up (before it even gets to GRUB), if there's a CD in the drive, it wastes about 15 extra seconds spinning it up to look at it, even if I'm not booting from CD. So that might be a sort of thing to watch out for, when making GRUB search? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Robert Millan wrote: On Fri, May 30, 2008 at 05:01:51PM -0400, Isaac Dupree wrote: You don't need to use the header of one of your partitions. You can use the MBR or even have a dedicated partition for core.img. Then you can install the rest of GRUB in a filesystem that's not case unsensitive! ;-P I know, but I don't entirely understand how it works and I'd rather not... and it gives me limited options: theoretical maximum of 5 I think, 1 in MBR and 1 in each of first four partitions (each with their own hacks). You're confusing BIOS-based boot with msdos partition labels. You can use GPT just fine when booting from BIOS (although Intel tries to hide that fact by embedding the GPT spec inside the EFI spec). I have the hack which combines the two partition labels so I have both GPT and msdos labels. Which means that my first four partitions (only) are listed in msdos, and GPT is the really accurate one that MacOS and Linux use. However, I can't find a way to get into bootloader-land via BIOS without going through the msdos partitioning mechanism. I much prefer being able to put as many .efi files as fit all on one partition, for refit to find. As it is, when I upgrade GRUB, there always has to be the fear that I did something wrong that I can't easily fix because it's not just in the location of my files (it's hidden in mbr/partition headers), and because I can't boot into Linux anymore because I broke the bootloader :-) It's been very lucky that I can so far always boot into OS X without going through GRUB, and edit my grub.cfg from there... That, and keeping 10.4 updated, are the two main reasons I ever boot into MacOS :-) I think what we need here is to support MacOS boot from GRUB. Then you can use GRUB as your bootloader and don't need to use it as a piece of glue between Refit and Linux.. Want to help us on that? :-) that'd be nice... although I kind of like it how it is for me now, choosing Mac vs. GRUB in rEFIt, so I'm not *particularly* inspired to help :-) Btw what's a CSM? "Compatibility Support Modules", it's a name for the BIOS substitute that Apple added to EFI to support their "Boot Camp"/Windows. Notice that, like "EFI", "BIOS" doesn't imply any underliing implementation; it just defines an interface (Intel uses this confusion to pretend their firmware is free, when in fact only its shell -EFI- is). Unless I missed something, Apple's BIOS is as much a BIOS as is any other one. I think you're right about that. (Except that I don't think that even the EFI part of the firmware is free on Apple computers, as far as I know they've done proprietary modifications to the free example-implementation and not been interested in releasing firmware sources.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Robert Millan wrote: On Fri, May 30, 2008 at 12:29:59PM -0400, Isaac Dupree wrote: It's fixed now for my hardware, Intel's new video driver in Xorg 7.3 doesn't need any BIOS hacks or anything, I believe. Anyway, I'll find out if it works just as soon as I manage to actually get into linux-kernel under EFI, so *if* it doesn't break, then I can keep using that and avoid (1) the unnecessary and potentially buggy CSM, (2) the hassles of installing a pc-bios-style bootloader on the header of one of my partitions. (and (3) be able to report bugs (in whatever software is affected) that happen later on when doing it that way.) It can't hurt to try... You don't need to use the header of one of your partitions. You can use the MBR or even have a dedicated partition for core.img. Then you can install the rest of GRUB in a filesystem that's not case unsensitive! ;-P I know, but I don't entirely understand how it works and I'd rather not... and it gives me limited options: theoretical maximum of 5 I think, 1 in MBR and 1 in each of first four partitions (each with their own hacks). I much prefer being able to put as many .efi files as fit all on one partition, for refit to find. As it is, when I upgrade GRUB, there always has to be the fear that I did something wrong that I can't easily fix because it's not just in the location of my files (it's hidden in mbr/partition headers), and because I can't boot into Linux anymore because I broke the bootloader :-) It's been very lucky that I can so far always boot into OS X without going through GRUB, and edit my grub.cfg from there... That, and keeping 10.4 updated, are the two main reasons I ever boot into MacOS :-) Btw what's a CSM? "Compatibility Support Modules", it's a name for the BIOS substitute that Apple added to EFI to support their "Boot Camp"/Windows. Looking at the page http://refit.sourceforge.net/myths/ "Fact: You need BIOS compatibility for 2D/3D accelleration" (which hasn't been updated for a long time...) it looks like if I want the console (rather than X) to display anything, I'll still need video BIOS... good to know when testing to see if anything works ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Bean wrote: On Sat, May 31, 2008 at 12:06 AM, Isaac Dupree <[EMAIL PROTECTED]> wrote: Robert Millan wrote: On Fri, May 30, 2008 at 10:42:02AM -0400, Isaac Dupree wrote: okay, I just tried a few days ago's grub2 CVS without patches for i386 efi, because presumably if that doesn't work for me then nothing else will either (though it's possible that a working x86-64 would work better for this particular EFI firmware, I suppose) Actually, I think it's better supported via grub-pc. In BIOS we have a workaround for the keyboard bug. Was there any other kind of trouble? No it's not. I can't use the keyboard on BIOS here, except sometimes for one single keystroke or more if I get lucky (true for linux CD booting, not just grub2); but the keyboard works fine on EFI and always has. (Or was that workaround you mentioned in grub2 introduced sometime in the last year, in which case I should upgrade my grub2-bios installation?) This problem should be gone by now, try the cvs version ? okay, I guess I will try it BTW, I think you should use bios if you can. I remember seeing some post about the video driver needs video bios for initialization. In pure EFI mode, it will fallback to frame buffer mode which is slower. I don't know if this have been fixed by now. It's fixed now for my hardware, Intel's new video driver in Xorg 7.3 doesn't need any BIOS hacks or anything, I believe. Anyway, I'll find out if it works just as soon as I manage to actually get into linux-kernel under EFI, so *if* it doesn't break, then I can keep using that and avoid (1) the unnecessary and potentially buggy CSM, (2) the hassles of installing a pc-bios-style bootloader on the header of one of my partitions. (and (3) be able to report bugs (in whatever software is affected) that happen later on when doing it that way.) It can't hurt to try... -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: macbook EFI experiences
Robert Millan wrote: On Fri, May 30, 2008 at 10:42:02AM -0400, Isaac Dupree wrote: okay, I just tried a few days ago's grub2 CVS without patches for i386 efi, because presumably if that doesn't work for me then nothing else will either (though it's possible that a working x86-64 would work better for this particular EFI firmware, I suppose) Actually, I think it's better supported via grub-pc. In BIOS we have a workaround for the keyboard bug. Was there any other kind of trouble? No it's not. I can't use the keyboard on BIOS here, except sometimes for one single keystroke or more if I get lucky (true for linux CD booting, not just grub2); but the keyboard works fine on EFI and always has. (Or was that workaround you mentioned in grub2 introduced sometime in the last year, in which case I should upgrade my grub2-bios installation?) In any case I want to help debug grub2 efi to at least specify what still doesn't work, (if anything), even if the keyboard issue is fixed for bios. Then the question becomes whether Ubuntu can survive being booted without the BIOS CSM enabled -- which I have yet to see, because I couldn't get elilo to work for me either. But that's not the bootloader's problem, right? (although ideally it would be able to find a way to -- optionally -- enable the CSM, but I don't think a way has been found yet to enable it at all?) The other thing I noticed is, while running grub2-efi, the fan goes on to max speed/noisyness. (But grub2 isn't intended to be a huge fancy OS so there may be nothing reasonable to do about this.) Sounds like a firmware bug (busy polling for keyboard input). Does this device have an AT keyboard? Our keyboard driver has the same bug, too, but at least we can fix it ;-) I have no idea what kind of keyboard it is... I know there's a built-in keyboard that I'm typing on, but I can't find it with `sudo lshw`, I can't think of anywhere more thorough to look, and Apple's specs don't seem to say <http://www.apple.com/macbook/specs.html>. Plugging in an Apple USB keyboard was no better than the built-in one. P.S. the bios-bootloader-keyboard failure is a well known Apple firmware bug that they claim to have fixed but it didn't seem fixed to me after I installed their firmware update -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
macbook EFI experiences
okay, I just tried a few days ago's grub2 CVS without patches for i386 efi, because presumably if that doesn't work for me then nothing else will either (though it's possible that a working x86-64 would work better for this particular EFI firmware, I suppose) I forget how I installed grub2-bios. Is there a proper way to install grub2-efi that makes it know where all of its modules are so that I don't have to load them manually or include them in the .efi image? I had to explicitly set `prefix=(hd0,3)/efi/grub` in order for `insmod (hd0,3)/efi/grub/linux.mod` to find the modules it depends on. I think I might have just included *.mod in my grub2-bios image (which I put on a 200MB FAT partition) so that it would have any modules that might be needed in the future, configfile wouldn't need to be loaded explicitly, etc. etc. etc. (and I'm not sure how it finds that grub.cfg automatically either)... and yet I still have the individual modules copied around there for some (or no) reason. Then the `linux` command worked... but `initrd` told me "error: no free pages available". So I couldn't even get as far as loading the initrd (and `boot` after loading boot.mod, obviously didn't work since I need my initrd for Ubuntu). Then if I tried to go back and `linux` again (say, because I needed to change the arguments to `linux`), it told me " cannot allocate pages Aborted. Press any key to exit. " (And I pressed a key and it returned me to the rEFIt menu.) A memory leak? At that point, it shouldn't be using memory for the initrd because that never successfully loaded, and probably doesn't need the old linux when it's loading a new one. The other thing I noticed is, while running grub2-efi, the fan goes on to max speed/noisyness. (But grub2 isn't intended to be a huge fancy OS so there may be nothing reasonable to do about this.) any advices? -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: x86_64 EFI support for grub2 ?
Robert Millan wrote: On Tue, May 27, 2008 at 08:23:09PM +0800, Bean wrote: It's possible to create multiple arch image, but it requires some extra work. We need to compile i386-efi and x86_64-efi separately, then use a tool to merge them. This can't be done in a single step. Why not just drop the -m32 and always build "native" images? So if you build the i386-efi target on i386, you get a 32-bit image and if you build it on x86_64 you get a 64-bit one? take the MacBook. There are different versions, let's call them (A), the original MacBook, 32-bit CPU; (B), mine, 64-bit CPU; and (C), Bean's, 64-bit CPU. A and B require 32-bit EFI image. (actually, B might accept both 32 and 64 bits images, I'm not sure) C requires 64-bit EFI image. I can run a 32-bit distro and linux-kernel on any of them -- A, B or C. I can run a 64-bit distro on B or C. Basically, neither CPU nor system arch tells you what kind of EFI image is "native". There must be some way to find out what kind of image *is* native -- but I have no idea what it is. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
