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 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: 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: 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: 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 Lrobo.om...@gmail.com 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
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
[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
m...@isaac.cedarswampstudios.org 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: 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
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: 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: [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: 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: [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: 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: [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: 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 ?
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's
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: [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:
vbox
label text=Hello /
label text=World /
/vox
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 DIRECTORY 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: 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 (at least once we can make the legislators do what we want, rather than what big rich
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: 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: A _good_ and valid use for TPM
Alex Besogonov wrote: On Wed, Feb 18, 2009 at 4:52 PM, Isaac Dupree m...@isaac.cedarswampstudios.org 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: 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: 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: 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: 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
[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] 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
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] 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: [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
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: 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
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 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: 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: - 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: 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: 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
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
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: 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: 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:
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
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: 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: 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 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
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: 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: 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
Re: x86_64 EFI support for grub2 ?
Bean wrote: Hi, I just wonder if anybody is working on x86_64 EFI support ? If none, I'd like to add it soon, as it's essential for grub2 to work with Apple's 64-bit Intel Mac. not me, but I'll help you test it, as I have one of those machines (currently I'm using a nearly-a-year-old CVS version of grub2 in Apple's emulated BIOS mode, rather than using the EFI support which didn't work for me at the time). Is it essential -- or does building an x86 EFI binary work just as well? (oh, since I'm running a 32-bit Linux on my 64-bit machine right now, I'm not sure if I'll actually be a useful tester?) BTW, I notice that grub-mkimage for efi convert elf to efi internally, how about use the gnu-efi tool chain, this could make it more portable between ia32 and x86_64. Is its license sufficiently compatible? Is it maintained sufficiently (or else, can we take on some of the maintainership burden?) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub 2 on Intel Macs?
Alexandre Boeglin wrote: Apple provided firmware updates that should fix the keyboard issues that have been reported some time ago, so make sure to update your machine if you have such troubles. I installed those updates on my June-2007 MacBook and those keyboard issues were not fixed for me... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] read --echo=[yes|no|wildcard]
Robert Millan wrote: Adds a parameter to define echoing behaviour in read. Then one can use --echo=no or --echo=wildcard to make it suitable for reading passwords. I wonder how suitable it is for passwords -- is the memory always erased before jumping to e.g. Linux? (and is it important to hide it from the prying eyes of the root system? Probably...) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] read --echo=[yes|no|wildcard]
Robert Millan wrote: I think that it'd be better to just erase all our environment in grub_machine_fini() or a similar routine, than to give read specific knowledge that its data needs this kind of special protection. Besides, it wouldn't be that simple since the data is controlled by the user via grub.cfg, not directly by GRUB. I wonder if this erasing would take any significant amount of time (in which case there would be a reason not to implement that to happen all the time) Anyway, untill we support hashing this doesn't provide any additional security, since you can get the same from grub.cfg ;-) fairly true, assuming nothing weird happens like grub.cfg being thoroughly deleted in the meantime :-) anyway if a hash is used that takes (by design) around one second on the machine (e.g. sha256 repeated thousands? millions? of times), then I suppose the time taken to erase the memory used by GRUB would be trivial in comparison, assuming(rightly or wrongly) a good implementation... -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] if timeout is set to zero, don't bother drawing the menu
Yoshinori K. Okuji wrote: On Sunday 10 February 2008 13:55, Robert Millan wrote: We could make the behaviour be, that if ESC is pressed at any time before an input line is completed, the operation is aborted, read returns non-zero, and it doesn't save the line to any variable. What do you think? Not bad. :) :) In GRUB Legacy, the hidden menu uses ESC, because if it uses ENTER, and the user pushes ENTER too long, and a key repeat occurs, then the first item may be selected quick as a flash. But we could avoid this problem by vacuuming all inputs before showing a menu, so it might be acceptable to use ENTER instead. This is still error-prone. Even if you vacuum the input buffer, we still have a race between user unholding ENTER and GRUB showing the menu. Vacuuming the buffer just gives us more time, but doesn't garantee good results. Sure, but I think it would be good enough in reality. most realities. Probably it will bite someone some day. A 1/10th second delay or so after display before listening for input might reduce the chances of that, though increase the very same chances of the enter-press for the menu being intentional but dropped. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] read --echo=[yes|no|wildcard]
Robert Millan wrote: On Sun, Feb 10, 2008 at 01:00:50PM -0500, Isaac Dupree wrote: anyway if a hash is used that takes (by design) around one second on the machine (e.g. sha256 repeated thousands? millions? of times), then I suppose the time taken to erase the memory used by GRUB would be trivial in comparison, assuming(rightly or wrongly) a good implementation... The problem is not time, it's just to find the right way to do it. yeah. probably involves thinking about GRUB's allocation and deallocation mechanisms, which I don't know anything about and don't have time to investigate :-/ -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] erase variable data on user unset
Robert Millan wrote: On Sun, Feb 10, 2008 at 03:00:31PM -0500, Isaac Dupree wrote: Robert Millan wrote: On Sun, Feb 10, 2008 at 01:00:50PM -0500, Isaac Dupree wrote: anyway if a hash is used that takes (by design) around one second on the machine (e.g. sha256 repeated thousands? millions? of times), then I suppose the time taken to erase the memory used by GRUB would be trivial in comparison, assuming(rightly or wrongly) a good implementation... The problem is not time, it's just to find the right way to do it. yeah. probably involves thinking about GRUB's allocation and deallocation mechanisms, which I don't know anything about and don't have time to investigate :-/ This should address your concern. As to why I propose to put this in unset command rather than kernel, since GRUB itself doesn't have any mechanisms where a variable would contain sensible information, I think it's better to protect user variables only. okay, is the idea that the script should explicitly unset sensitive variables, or are they all automatically unset upon boot? (if unset command is loaded?) Anyway, thanks for looking into this! -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] erase variable data on user unset
on second thought, if grub is going to be able to boot kernels that are on encrypted partitions, the password might go more places in grub and/or have to be retained until boot time, depending how it works... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub2 on a Macbook.
Eoin Hennessy wrote: Hello all, I've been taking a look at grub2 on an EFI Apple Macbook. I've installed a build from CVS HEAD and I can chainload grub.efi via the rEFIt loader. When grub loads I'm seeing the 'grub rescue' command prompt. As a test, I'd like to chainload OSX's boot.efi using the 'chainloader' command listed at [0] but the command is reported as 'unknown'. I've also tried the instructions at [1] but it allooks like grub.cfg is being ignored. Perhaps someone could point me in the right direction. In May/June 2007 I failed at using Grub2 cvs - efi on my new MacBook too, with the same issue. But I'm using Grub2 with legacy boot sequence to boot... because it understands GPT :) and that works except the keyboard usually doesn't work during boot because of Apple's buggy bios. I'm not sure if chainloading would work due to grub2 not understanding HFS+ ? I tried putting grub2-efi and a linux kernel image on a FAT16/vfat partition. Anyway I can probably help test anything if needed. Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
