Re: [RFC] make output of compiling a bit less verbose to make warnings more visible
Felix Zielcke wrote on 20080902: > I think it would be good if the output from compiling wouldn't be that > verbose. * shameless plug mode on * Maybe my hmake wrapper for gnu make does what you want : A make and cc/c++ output (color)filter written in perl. Especially useful if your warning level is so high that the compiler starts to complain about your system header files. See http://lambermont.dyndns.org/hmake * shameless plug mode off * regards, Hans Lambermont -- Hans Lambermont, M.Sc. - Newtec - OS-Platform&VAS http://newtec.eu/t:+31408519234m:+31629064887 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
Am Mittwoch, den 03.09.2008, 01:38 +0200 schrieb Javier Martín: > But ata and reiserfs > are quite the bloaters... The reiserfs case is particularly strange: in > the linux kernel, the reiserfs module is 50% bigger than ext3.ko; while > in GRUB, reiserfs.mod (without journaling) is twice the size of ext2.mod > (which includes full support for ext2, partial journal support in ext3 > and extents in ext4). ata.mod needs work anyway to be ready to end up in core.img fs/ext2.c doestn't support the journaling at all. The code was reverted, just not 100% complete. The structures are still defined but not used, just use your favourite editor and search for `journal'. But comparing the size difference between ext2.ko and reiserfs.ko (or however exactly it's called, I used it ages ago last) with the size difference of grub2's ext2.mod and reiserfs.mod is probable like apples and oranges. Kernel has full support for everything, wheres grub2 only needs small read support. > Thus, while you are right in prioritizing kernel size; why not optimize > reiserfs a bit instead of killing our (and future maintainers') eyes and > brains to shave less than 40 bytes from kernel? I suppose the story > would be similar with ata, because it is a new module that is yet in > development. If you can reduce the size of the modules, without making the code ugly then feel free to do so, but please keep things consistently to the current commited code. If you want to introduce new ideas/concepts then I suggest you do a [RFC] topic on the list to discuss it first. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can LUA e coming with future Grub2
On Wed, Sep 3, 2008 at 12:56 PM, y.volta <[EMAIL PROTECTED]> wrote: > For the Grub2 internal script engine, yes, it is little. but need more work > to be improved. About the size, i think, Lua can be a replacement if this > lua.mod is available at runtime. at the same time, why not load gziped mod > file from disk? this will reduce the size of lua module: 100,436 bytes -> > 49,766. > > But the benifit of using Lua, i think, is for graphic menu. the gfxmenu uses > a strange script engine, it is hard to learn for a common user; but the Lua, > it is easy. ;-) > > > So, it is good to have lua support in Grub2. Hi, In my suggestion to split normal mode, the script engine is separated and can be replaced, as long as they export a certain interface that return information like the menu items, etc. But now, I'm waiting for the handler patch, as it's the basic of the new model. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] make output of compiling a bit less verbose to make warnings more visible
On Wed, Sep 3, 2008 at 2:59 PM, Felix Zielcke <[EMAIL PROTECTED]> wrote: > There exists even a thing called `GNU automake' which converts > Makefile.am files to Makefile.in > I never used it though, so I don't really know if it would be easier > with it then in that ruby stuff currently used. > > I'd really love to have this, but if these overrides are not acceptable > then I doubt we will have it ever. > I would need ages to find out how to do it with that ruby stuff or even > how to rewrite the whole build system :( > I myself wrote only some small little Makefiles not Makefile.am not > Makefile.in but a final small Makefile. Hi, I think automake can't do the job. The grub2 build process is complicated. For example, it needs to go through all the object files to generate the module dependence trunk, and append it to *.o to form the final *.mod. I believe it's very tricky to write a automake script to handle this. However, I don't like that it uses ruby to generate makefiles. Ruby is not a standard component, so there is a chance that user don't install it. I guess perl would be better. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
Javier Martín wrote: > El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió: >> Hello, again. >> Javier Martín wrote: >>> We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the >>> first is used by the MBR). >>> >> I've just rechecked on my system. My first partition begins at sector >> number 63. This is the value I've seen at most systems. So last usable >> sector is 62. Sector 0 is MBR. So we have 62 sectors > Oops, true! How strange. So there was no sector 63 in the CHS model and > that is why the first sector of cyl 1 (the start of the first partition) > is LBA 63... Does anyone know the historical reasons for this? > int 0x13:0x08 can't return more than 63 sectors per track. http://en.wikipedia.org/wiki/Int_13h#INT_13h_AH.3D08h:_Read_Drive_Parameters >> I'll have a look at it but not sure to find anything since I'm not >> familiar with either ata or reiserfs internal structure. > I was not suggesting that it was you or me who did it; it was a general > "call" for GRUB devs... (ahem xD) > I understand. I was saying that I'll just have a look at least to know what I'm talking about. But even if we manage to decrease the size of reiserfs module there are still other FS which could result in big modules e.g. ZFS. >>> Thus, while you are right in prioritizing kernel size; why not optimize >>> reiserfs a bit instead of killing our (and future maintainers') eyes and >>> brains to shave less than 40 bytes from kernel? I suppose the story >>> would be similar with ata, because it is a new module that is yet in >>> development. >> Well the point is that if we don't do it now and then one day we'll have >> to squeeze the core it will be very difficult to find places like this. > Yes, but my point is that 40 bytes is so small a difference 40 bytes are small but 40 bytes per small interface is a big difference > that it can > offset by simply rewriting error strings in kernel and other smallish > non-intrusive changes and thus we should prioritize future > maintainability. However, eventually this is not our decision to make: > the Overlords here (mainly Marco, but also Robert, Vesa and Bean) are > the ones who should, likely only once the interface is established, > decide how to conjugate the Prime Directive of "keep kernel small" with > code complexity in this particular case. > You have the point. But if we don't discuss this matter the choice made by maintainers can be random. > -Habbit Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] add custom strings to the help list
Hello all. In old good time of grub-legacy one could obtain the help about "root" command with > help root Now "root" is a variable and so "help root " gives no information. I suggest that it should be possible to add custom strings to help command in normal mode. Something like grub_register_help (title, contents); grub_unregister_help (title); what do you think about it? Vladimir 'phcoder' Serbinenko P.S. Of course I'm ready to implement it ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[RFC]swapfso and "ioctl" function for filesystems
Hello, all. For some FS sometimes additional functions are needed. It could be some type of control (e.g. in ZFS manage zpools) or preparation for OS booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the root directory). While theese functions are quite specific to FS sometimes are important to implement. So I suggest to add to grub_fs a pointer to an array in which fs module can put custom functions. Also in many filesystems it's quite difficult to add a new file or remove already existing one it's often quite easy to exchange 2 files or directories. So I intend to implement a call "swapfso" (FSO=File System Object) at least for fat and ext2. Such a call could be useful to have multiple OS on the same partition or to have multiple configurations of the same OS (e.g. normal and backup). Then I think to have this function in this extended list (even if this function can be implemented for more FS) unless maintainers suggest that such function should be a part of grub_fs. In this case a good idea would be to have 2 modules for fat,ext2,...: one with swapfso and one without for core image. Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] Boot parameters and geometrical stability
Hello, all. Now when core image can be booted by multiple sources perhaps it would be a good idea to recieve some boot arguments in case boot method (e.g. multiboot) supports it. Probably the best way is to recieve pairs which can be easily imported to environment. Another possibility of improving boot process is to detect the prefix even if partition map changed it can be done e.g. with UUID but this comprises a security risk in case an attacker can plug a device (cdrom, floppy, USB-memory,..) containing a partition with the same UUID. What do you think about it Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can LUA e coming with future Grub2
On Wed, Sep 03, 2008 at 04:25:12PM +0800, Bean wrote: > On Wed, Sep 3, 2008 at 12:56 PM, y.volta <[EMAIL PROTECTED]> wrote: > > For the Grub2 internal script engine, yes, it is little. but need more work > > to be improved. About the size, i think, Lua can be a replacement if this > > lua.mod is available at runtime. at the same time, why not load gziped mod > > file from disk? this will reduce the size of lua module: 100,436 bytes -> > > 49,766. > > > > But the benifit of using Lua, i think, is for graphic menu. the gfxmenu uses > > a strange script engine, it is hard to learn for a common user; but the Lua, > > it is easy. ;-) > > > > > > So, it is good to have lua support in Grub2. > > Hi, > > In my suggestion to split normal mode, the script engine is separated > and can be replaced, as long as they export a certain interface that > return information like the menu items, etc. But now, I'm waiting for > the handler patch, as it's the basic of the new model. Note that size is still an issue, though. For example coreboot users will usually want to use scripting for the grub.cfg they store in their ROM. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC]swapfso and "ioctl" function for filesystems
On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote: > Hello, all. > For some FS sometimes additional functions are needed. It could be some > type of control (e.g. in ZFS manage zpools) or preparation for OS > booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the > root directory). While theese functions are quite specific to FS > sometimes are important to implement. What would be the purpose of that? Please describe a use case. > [...]. So I intend to implement a call "swapfso" (FSO=File System > Object) at least for fat and ext2. Do you mean a filesystem write that swaps two file references? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: Move kernel to upper memory
Hi, What is the conclusion of this thread? is this idea still explored? Robert Millan wrote: The first concern that comes to mind is how would GRUB coexist with the payload area which precisely starts at 0x10. But I expect we'd face many unexpected issues. Does this mean, GRUB needs to fit within 1MB limit when all its modules are loaded? More clearly, are there any limits on where (and how many) grub modules can be dynamically loaded currently? Since payload(s) needs to be present at their precise positions only after the boot command, we can always deterministically /schedule/ memmove operation to be executed as part of boot command. Since boot command is the last command executed by GRUB (correct me if not), we can overwrite any GRUB code/data at that point. This also needs boot command to exist in low memory. The main advantage i see here is that it removes any arbitrary limits on number of modules or their placement, if at all limits exists. thanks, -- bvk-chaitanya ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] make output of compiling a bit less verbose to make warnings more visible
Am Mittwoch, den 03.09.2008, 16:37 +0800 schrieb Bean: > However, I don't like that it uses ruby to generate makefiles. Ruby is > not a standard component, so there is a chance that user don't install > it. I guess perl would be better. I had somehow already the impression that this ruby based build system isn't really well maintained ;) I looked now even a bit over the automake[0] documentation. For me personally it just looks easier to get into that, because it is just made for Makefile's instead of some perl/python/ruby script which generates them. If automake isn't enough maybe we could use a combination of it with a small perl script or so? Though I don't know any perl/python/ruby at all. I'm willing to really look into this automake stuff if there are no strong objections against it, in the hope that in the end the build system is clean, easily understandable and can be well maintained :) Though this will probable take a little while so I still think Colin's way would be a good short term solution and for long term we remake the whole build process with that idea integrated from the beginning. [0] http://www.gnu.org/software/automake/manual/automake.html -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
On Wednesday 03 September 2008, Javier Martín wrote: > El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió: > > Hello, again. > > > > Javier Martín wrote: > > > We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the > > > first is used by the MBR). > > > > I've just rechecked on my system. My first partition begins at sector > > number 63. This is the value I've seen at most systems. So last usable > > sector is 62. Sector 0 is MBR. So we have 62 sectors > > Oops, true! How strange. So there was no sector 63 in the CHS model and > that is why the first sector of cyl 1 (the start of the first partition) > is LBA 63... Does anyone know the historical reasons for this? Well, the point is, in CHS addressing sector numbering starts with 1, not 0, and since there are only 6 bits available for the sector number (the other 2 being used for cylinder number bits #8 and #9), the maximum number of sectors per track in CHS in 63. Regards, Niels ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote: > Hello, all. > Now when core image can be booted by multiple sources perhaps it would > be a good idea to recieve some boot arguments in case boot method (e.g. > multiboot) supports it. Probably the best way is to recieve pairs > which can be easily imported to environment. I assume you talk about GRUB loading itself; what kind of information would you pass from one GRUB to the other? > Another > possibility of improving boot process is to detect the prefix even if > partition map changed it can be done e.g. with UUID We use UUIDs already, but only when drives can't be referred to unambigously, check how grub-install does it. > but this comprises a > security risk in case an attacker can plug a device (cdrom, floppy, > USB-memory,..) containing a partition with the same UUID. What do you > think about it I think people who want this level of security (i.e. local media is not trusted) should use crypto checksums to verify they're loading what they expected, with or without UUIDs. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
Hi again, El mié, 03-09-2008 a las 11:10 +0200, phcoder escribió: > >> I'll have a look at it but not sure to find anything since I'm not > >> familiar with either ata or reiserfs internal structure. > > I was not suggesting that it was you or me who did it; it was a general > > "call" for GRUB devs... (ahem xD) > > > I understand. I was saying that I'll just have a look at least to know > what I'm talking about. But even if we manage to decrease the size of > reiserfs module there are still other FS which could result in big > modules e.g. ZFS. Of course, but even though we should strive to support te widest module configurations possible, GRUB is no panacea. Even when an initialized GRUB could cope with a ZFS partition in a LVM+RAID on SATA drives not supported by the BIOS, one should not really expect to be able to boot directly off it - get a simpler boot scheme, man! extN, FAT or even SFS are way simpler filesystems which should be used for boot partitions. More complex filesystems such as ReiserFS or NTFS require _less_ complex schemes such as no LVM+RAID in order to keep the total core size manageable. signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC]swapfso and "ioctl" function for filesystems
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote:
>> Hello, all.
>> For some FS sometimes additional functions are needed. It could be some
>> type of control (e.g. in ZFS manage zpools) or preparation for OS
>> booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the
>> root directory). While theese functions are quite specific to FS
>> sometimes are important to implement.
>
> What would be the purpose of that? Please describe a use case.
>
With ZFS or ext3cow: Suppose you made a huge mistake and installed
unbootable kernel and have no backup in another file. But ZFS/ext3cow
has its own backup. So ZFS/ext3cow driver may provide a call something like
static grub_err_t zfs_timeback (int timeref);
And anounce it like:
add_funcs={
{"timeback", zfs_timeback},
{0, 0}
};
Then a module timeback.mod can suply a command like
timeback
which uses the function supplied by zfs and ext3cow.
With FAT: suppose you have let's say DR-DOS and windows on the same
partition. Great their boot files have different names so they shouldn't
conflict. But in fact they do because both require their boot files
(io.sys/msdos.sys or ibmbio.com/ibmdos.com) to be first entries in root
directory. So fat module can provide a call like
fat_put_rootfile_to_slot (char *filename, int place);
Then a module "dosprep.mod" can do something like:
put_rootfile_to ("io.sys",0);
put_rootfile_to ("msdos.sys",0);
>> [...]. So I intend to implement a call "swapfso" (FSO=File System
>> Object) at least for fat and ext2.
>
> Do you mean a filesystem write that swaps two file references?
>
Exactly. It's easy to implement (just exchange inode numbers and
filetype fields in dirent). It's also another usage case for first part
of my email.
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
Robert Millan wrote: > On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote: >> Hello, all. >> Now when core image can be booted by multiple sources perhaps it would >> be a good idea to recieve some boot arguments in case boot method (e.g. >> multiboot) supports it. Probably the best way is to recieve pairs >> which can be easily imported to environment. > > I assume you talk about GRUB loading itself; what kind of information would > you pass from one GRUB to the other? Boot device, configuration file, parameters for scripts. But much more useful this is for network boot. In this case GRUB can recieve server info in boot parameters so when this info changes there is no need to regenerate grub images. > >> but this comprises a >> security risk in case an attacker can plug a device (cdrom, floppy, >> USB-memory,..) containing a partition with the same UUID. What do you >> think about it > > I think people who want this level of security (i.e. local media is not > trusted) should use crypto checksums to verify they're loading what they > expected, with or without UUIDs. > I was thinking about the scenario when ide drives are trusted but not USB or removable devices. Cryptographic checksums wouldn't bring much because if attacker can modify harddrive he can also modify GRUB to skip checksum check. Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] update configure.ac to autoconf 2.61
Attached patch is generated via `autoupdate --force' from autoconf 2.61 a svn-diff after ./autogen.sh doestn't show anything more, because the ./configure script in SVN is already generated with autoconf 2.61. autoconf 2.61 is dated 17.11.2006 on ftp.gnu.org Debian etch + lenny have autoconf 2.61 etch has been released 8th April 2007 Ubuntu has it since feisty which has been released 19th April 2007 I haven't checked the others but I think this is recent enough for the configure.ac (remember it's generated by ./autogen.sh anyway) Yes I really want to get rid of old stuff and if you even only need to call `autoupdate --force' ;) Debian experimental has autoconf 2.62 which I normally use, there is some other stuff deprecated and so changed by `autoupdate' but I'll leave that for the future. -- Felix Zielcke 2008-09-03 Felix Zielcke <[EMAIL PROTECTED]> * configure.ac (AC_INIT): Quote version number. (AC_PREREQ): Bumped to 2.61. (AC_TRY_COMPILE): Replace deprecated macro with .. (AC_COMPILE_IFELSE): ... this. Index: configure.ac === --- configure.ac (Revision 1845) +++ configure.ac (Arbeitskopie) @@ -31,8 +31,8 @@ dnl (such as TARGET_CC, TARGET_CFLAGS, e dnl type. -AC_INIT(GRUB, 1.96, [EMAIL PROTECTED]) -AC_PREREQ(2.53) +AC_INIT([GRUB],[1.96],[EMAIL PROTECTED]) +AC_PREREQ(2.61) AC_CONFIG_SRCDIR([include/grub/dl.h]) AC_CONFIG_HEADER([config.h]) @@ -266,7 +266,7 @@ if test "x$TARGET_CFLAGS" = x; then # optimization flags. AC_CACHE_CHECK([whether optimization for size works], grub_cv_cc_Os, [ CFLAGS=-Os -AC_TRY_COMPILE(, , grub_cv_cc_Os=yes, grub_cv_cc_Os=no) +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],[grub_cv_cc_Os=yes],[grub_cv_cc_Os=no]) ]) if test "x$grub_cv_cc_Os" = xyes; then TARGET_CFLAGS="$TARGET_CFLAGS -Os" @@ -278,7 +278,7 @@ if test "x$TARGET_CFLAGS" = x; then if test "x$target_cpu" = xi386; then AC_CACHE_CHECK([whether -falign-loops works], [grub_cv_cc_falign_loop], [ CFLAGS="-falign-loops=1" - AC_TRY_COMPILE(, , [grub_cv_cc_falign_loop=yes], [grub_cv_cc_falign_loop=no]) + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],[grub_cv_cc_falign_loop=yes],[grub_cv_cc_falign_loop=no]) ]) if test "x$grub_cv_cc_falign_loop" = xyes; then ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] update configure.ac to autoconf 2.61
Am Mittwoch, den 03.09.2008, 15:27 +0200 schrieb Felix Zielcke:
> Yes I really want to get rid of old stuff and if you even only need to
> call `autoupdate --force' ;)
>
Oh and config.guess and config.sub have
timestamp='2007-07-22'
whereas the versions from automake 1.9 and 1.10 have
timestamp='2008-01-23
On a Debian system you find them in /usr/share/automake-/
Any objection that I update these 2 files too?
Attached is a patch for these 2 files.
Not really necessary but well a bit outdated ;)
--
Felix Zielcke
2008-09-03 Felix Zielcke <[EMAIL PROTECTED]>
* config.guess: Update to version from `2008-01-23'
* config.sub: Likewise.
Index: config.guess
===
--- config.guess (Revision 1846)
+++ config.guess (Arbeitskopie)
@@ -1,10 +1,10 @@
#! /bin/sh
# Attempt to guess a canonical system name.
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-# 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation,
-# Inc.
+# 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
+# Free Software Foundation, Inc.
-timestamp='2007-07-22'
+timestamp='2008-01-23'
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
@@ -56,8 +56,8 @@ version="\
GNU config.guess ($timestamp)
Originally written by Per Bothner.
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
-Free Software Foundation, Inc.
+Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
+2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -532,7 +532,7 @@ EOF
echo rs6000-ibm-aix3.2
fi
exit ;;
-*:AIX:*:[45])
+*:AIX:*:[456])
IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | sed 1q | awk '{ print $1 }'`
if /usr/sbin/lsattr -El ${IBM_CPU_ID} | grep ' POWER' >/dev/null 2>&1; then
IBM_ARCH=rs6000
@@ -799,6 +799,9 @@ EOF
EM64T | authenticamd)
echo x86_64-unknown-interix${UNAME_RELEASE}
exit ;;
+ IA64)
+ echo ia64-unknown-interix${UNAME_RELEASE}
+ exit ;;
esac ;;
[345]86:Windows_95:* | [345]86:Windows_98:* | [345]86:Windows_NT:*)
echo i${UNAME_MACHINE}-pc-mks
@@ -833,7 +836,14 @@ EOF
echo ${UNAME_MACHINE}-pc-minix
exit ;;
arm*:Linux:*:*)
- echo ${UNAME_MACHINE}-unknown-linux-gnu
+ eval $set_cc_for_build
+ if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
+ | grep -q __ARM_EABI__
+ then
+ echo ${UNAME_MACHINE}-unknown-linux-gnu
+ else
+ echo ${UNAME_MACHINE}-unknown-linux-gnueabi
+ fi
exit ;;
avr32*:Linux:*:*)
echo ${UNAME_MACHINE}-unknown-linux-gnu
@@ -954,8 +964,8 @@ EOF
x86_64:Linux:*:*)
echo x86_64-unknown-linux-gnu
exit ;;
-xtensa:Linux:*:*)
- echo xtensa-unknown-linux-gnu
+xtensa*:Linux:*:*)
+ echo ${UNAME_MACHINE}-unknown-linux-gnu
exit ;;
i*86:Linux:*:*)
# The BFD linker knows what the default object file format is, so
@@ -1474,9 +1484,9 @@ This script, last modified $timestamp, h
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from
- http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess
+ http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
- http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub
+ http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
If the version you run ($0) is already up to date, please
send the following data and any information you think might be
Index: config.sub
===
--- config.sub (Revision 1846)
+++ config.sub (Arbeitskopie)
@@ -1,10 +1,10 @@
#! /bin/sh
# Configuration validation subroutine script.
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-# 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation,
-# Inc.
+# 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
+# Free Software Foundation, Inc.
-timestamp='2007-06-28'
+timestamp='2008-01-16'
# This file is (in principle) common to ALL GNU software.
# The presence of a machine in this file suggests that SOME GNU software
@@ -72,8 +72,8 @@ Report bugs and patches to ___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can LUA e coming with future Grub2
Robert Millan wrote: > On Wed, Sep 03, 2008 at 04:25:12PM +0800, Bean wrote: >> On Wed, Sep 3, 2008 at 12:56 PM, y.volta <[EMAIL PROTECTED]> wrote: >>> For the Grub2 internal script engine, yes, it is little. but need more work >>> to be improved. About the size, i think, Lua can be a replacement if this >>> lua.mod is available at runtime. at the same time, why not load gziped mod >>> file from disk? this will reduce the size of lua module: 100,436 bytes -> >>> 49,766. >>> >>> But the benifit of using Lua, i think, is for graphic menu. the gfxmenu uses >>> a strange script engine, it is hard to learn for a common user; but the Lua, >>> it is easy. ;-) >>> >>> >>> So, it is good to have lua support in Grub2. >> Hi, >> >> In my suggestion to split normal mode, the script engine is separated >> and can be replaced, as long as they export a certain interface that >> return information like the menu items, etc. But now, I'm waiting for >> the handler patch, as it's the basic of the new model. > > Note that size is still an issue, though. For example coreboot users will > usually want to use scripting for the grub.cfg they store in their ROM. Hi, I like the idea of using Lua personally for graphical menu related scripting and in my opinion it could be additional script that could be used. User could in example defined scripting language in a bit same way that you do that in HTML pages: lua:"script-filename.lua" grub:"exec grub-script-filename" own-extension:"do this and this effect that is integrated to some other module" In order to one of those work, you need to load script module that registers handler for it. Do anyone have skills to decipher Lua's license is it compatible with GPLv3 ? Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
phcoder wrote: > I was thinking about the scenario when ide drives are trusted but not > USB or removable devices. Cryptographic checksums wouldn't bring much > because if attacker can modify harddrive he can also modify GRUB to skip > checksum check. Then you password protect it :) Once that is supported. But really, if attacker has access to your HDD then there is not a really reason why we should do defense against that one as they can overwrite us at will. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
Hi,
How about following (may not be syntaxically correct):
In kernel:
/* Variable holding pointer to preboot hook function. */
preboot_hook:
.long 0
...
/* Check if there is preboot hook installed. */
movlpreboot_hook, %eax
testl %eax, %eax
jne 1f
call%eax
1:
/* Continue boot. */
Then in module code:
void grub_preboot_hook_handler(void)
{
/* Process list of registered preboot hooks. */
}
void grub_preboot_register_hook(...);
void grub_preboot_unregister_hook(...);
GRUB_MOD_INIT(preboot)
{
preboot_hook = grub_preboot_hook_handler;
}
GRUB_MOD_FINI(preboot)
{
preboot_hook = 0;
}
If preboot.mod gets loaded then it goes and registers preboot handler to
kernel to do its tricks. Other modules then would use preboot.mod to
register their own handlers.
This would have minimal impact for kernel.
Thanks,
Vesa Jääskeläinen
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
Vesa Jääskeläinen wrote: > phcoder wrote: >> I was thinking about the scenario when ide drives are trusted but not >> USB or removable devices. Cryptographic checksums wouldn't bring much >> because if attacker can modify harddrive he can also modify GRUB to skip >> checksum check. > > Then you password protect it :) Once that is supported. > > But really, if attacker has access to your HDD then there is not a > really reason why we should do defense against that one as they can > overwrite us at will. But consider a scenario when attacker can't overwrite the existing harddrive but can plug new one. Then the attacker can prepare a harddrive having a partition with the same UUID as our boot partition. Then he plugs it and depnding on factors like order of interfaces, devices, phase of the moon, ... GRUB can load attacker's modules. While it's ok to use UUID on personal desktop system when attacker can't plug his devices it shouldn't be the default. Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
El mié, 03-09-2008 a las 20:07 +0300, Vesa Jääskeläinen escribió:
> Hi,
>
> How about following (may not be syntaxically correct):
>
> In kernel:
>
> /* Variable holding pointer to preboot hook function. */
> preboot_hook:
> .long 0
>
> ...
> /* Check if there is preboot hook installed. */
> movlpreboot_hook, %eax
> testl %eax, %eax
> jne 1f
> call%eax
> 1:
> /* Continue boot. */
>
>
> Then in module code:
>
> void grub_preboot_hook_handler(void)
> {
> /* Process list of registered preboot hooks. */
> }
>
> void grub_preboot_register_hook(...);
> void grub_preboot_unregister_hook(...);
>
> GRUB_MOD_INIT(preboot)
> {
> preboot_hook = grub_preboot_hook_handler;
> }
>
> GRUB_MOD_FINI(preboot)
> {
> preboot_hook = 0;
> }
>
> If preboot.mod gets loaded then it goes and registers preboot handler to
> kernel to do its tricks. Other modules then would use preboot.mod to
> register their own handlers.
This is certainly a good solution, and would probably add less than 10
bytes to the kernel. I only have to add two things:
* This is not as elegant as it could be, as it forces us to expose
preboot_hook in the kernel, thus breaking encapsulation a bit. But it is
a price that I'm more than willing to pay.
* I doubt: is the current DL system in GRUB able to hand dependencies
directly? In other words, is our "insmod" more like modprobe or Linux
insmod? This affects the handling of "insmod drivemap" or "insmod
sendkey" if preboot.mod is not loaded beforehand.
-Habbit
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
Am Mittwoch, den 03.09.2008, 19:23 +0200 schrieb Javier Martín: > * I doubt: is the current DL system in GRUB able to hand dependencies > directly? In other words, is our "insmod" more like modprobe or Linux > insmod? This affects the handling of "insmod drivemap" or "insmod > sendkey" if preboot.mod is not loaded beforehand. Urm /boot/grub/moddep.lst ? I think grub2 is able to handle module dependencys. Though I haven't bothered to check the code ;) -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
Hello. In this case we can transfer the whole functionality located in
kern/loader.c to a dedicated module boot.mod. This module will also
register "boot" command. In this way the encapsulation won't be broken
and kernel will become even smaller.
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrote:
> Hi,
>
> How about following (may not be syntaxically correct):
>
> In kernel:
>
> /* Variable holding pointer to preboot hook function. */
> preboot_hook:
> .long 0
>
> ...
> /* Check if there is preboot hook installed. */
> movlpreboot_hook, %eax
> testl %eax, %eax
> jne 1f
> call%eax
> 1:
> /* Continue boot. */
>
>
> Then in module code:
>
> void grub_preboot_hook_handler(void)
> {
> /* Process list of registered preboot hooks. */
> }
>
> void grub_preboot_register_hook(...);
> void grub_preboot_unregister_hook(...);
>
> GRUB_MOD_INIT(preboot)
> {
> preboot_hook = grub_preboot_hook_handler;
> }
>
> GRUB_MOD_FINI(preboot)
> {
> preboot_hook = 0;
> }
>
> If preboot.mod gets loaded then it goes and registers preboot handler to
> kernel to do its tricks. Other modules then would use preboot.mod to
> register their own handlers.
>
> This would have minimal impact for kernel.
>
> Thanks,
> Vesa Jääskeläinen
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
phcoder wrote: > But consider a scenario when attacker can't overwrite the existing > harddrive but can plug new one. Then the attacker can prepare a > harddrive having a partition with the same UUID as our boot partition. > Then he plugs it and depnding on factors like order of interfaces, > devices, phase of the moon, ... GRUB can load attacker's modules. While > it's ok to use UUID on personal desktop system when attacker can't plug > his devices it shouldn't be the default. That is a valid point. Would you prefer to use hardware path to device or what you had in mind then? Because this is something that we can left for expert people. Most common problem is that user plugs in new drive to system and bios/hardware order gets changed or something like that, and that renders system unbootable. UUID is perfect solution for that case. Possibilites are there, but basically they are limited to something like: (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0) I do not know if those all would be valid, but I hope you get the idea. Alternative would be that you integrate some module to core that validates your system that there is no extra devices or such. Thanks, Vesa Jääskeläinen ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
phcoder wrote: > Hello. In this case we can transfer the whole functionality located in > kern/loader.c to a dedicated module boot.mod. This module will also > register "boot" command. In this way the encapsulation won't be broken > and kernel will become even smaller. Remember that realmode code needs to reside below < 1 MiB. That is the reason realmode code is embedded in kernel. In there you only see jumps to RM and back to PM. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Multiple partition maps
Hello. I was looking at the grub code and seen that if a disk has multiple partition tables (e.g. macintel with bootcamp) then only first one will be detected. In some cases it can lead to unreachable partitions if for some reason partition is present only in one table. Does anyone has an idea how theese cases may be treated compactly and efficiently? Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Sendkey patch
Vesa Jääskeläinen wrote: > phcoder wrote: >> Hello. In this case we can transfer the whole functionality located in >> kern/loader.c to a dedicated module boot.mod. This module will also >> register "boot" command. In this way the encapsulation won't be broken >> and kernel will become even smaller. > > Remember that realmode code needs to reside below < 1 MiB. That is the > reason realmode code is embedded in kernel. In there you only see jumps > to RM and back to PM. > kern/loader.c is always executed in PM. It just chooses which kernel-specific function to call next. RM helpers are found in kern/i386/loader.S and kern/i386/pc/startup.S (for chainloader). Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
Vesa Jääskeläinen wrote: > That is a valid point. > > Would you prefer to use hardware path to device or what you had in mind > then? Because this is something that we can left for expert people. Most > common problem is that user plugs in new drive to system and > bios/hardware order gets changed or something like that, and that > renders system unbootable. UUID is perfect solution for that case. > Yes it is, but in my opinion price is too high (shame ubuntu uses this solution). It's somewhat similar to some solutions found in windows when for user convenience they open a big gate for the hackers (e.g. all users by default are administrators in winxp) > Possibilites are there, but basically they are limited to something like: > > (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0) > > I do not know if those all would be valid, but I hope you get the idea. Yes. This is a solution found in grub legacy and I think it's a good one. > > Alternative would be that you integrate some module to core that > validates your system that there is no extra devices or such. It's bigger since you require module and has no advantages over using hardware names. But what we can do is to check if 2 partitions share the same UUID and if it's the case prompt for password. The problem is that if the same device is visible twice then it will result in a false positive. Another solution would be to checksum modules we load. But in this case after partial update or configuration modification a run checksum-updater is necessary or at least user will have to enter his password on the next boot. > > Thanks, > Vesa Jääskeläinen Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
phcoder wrote: > Vesa Jääskeläinen wrote: >> That is a valid point. >> >> Would you prefer to use hardware path to device or what you had in mind >> then? Because this is something that we can left for expert people. Most >> common problem is that user plugs in new drive to system and >> bios/hardware order gets changed or something like that, and that >> renders system unbootable. UUID is perfect solution for that case. >> > Yes it is, but in my opinion price is too high (shame ubuntu uses this > solution). It's somewhat similar to some solutions found in windows when > for user convenience they open a big gate for the hackers (e.g. all > users by default are administrators in winxp) Well... That is your opinion. I acknowledge that it opens another door for local hacker. But if you are able to do that, then you can do some other actions that are much more fatal... But the gain can still supersede the security need. Its kinda same thing that you are required to change your password monthly. People start putting those on stickers and then the game is lost anyway. >> Possibilites are there, but basically they are limited to something like: >> >> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0) >> >> I do not know if those all would be valid, but I hope you get the idea. > > Yes. This is a solution found in grub legacy and I think it's a good one. We already have (hdX) and (ataY) in GRUB 2. Especially (hdX) has lots of problems that this UUID was used to workaround. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Boot parameters and geometrical stability
Vesa Jääskeläinen wrote: > phcoder wrote: >> Yes it is, but in my opinion price is too high (shame ubuntu uses this >> solution). It's somewhat similar to some solutions found in windows when >> for user convenience they open a big gate for the hackers (e.g. all >> users by default are administrators in winxp) > > Well... That is your opinion. I acknowledge that it opens another door > for local hacker. But if you are able to do that, then you can do some > other actions that are much more fatal... If attacker is unable to open computer, bios is under password, boots only from HD and grub is password-protected than I don't see which other action can lead to the same result (complete control of computer). > > But the gain can still supersede the security need. Its kinda same thing > that you are required to change your password monthly. People start > putting those on stickers and then the game is lost anyway. > This is eternal problem of security and its cost (see B.Schneier Beyond Fear). If someone find this compromise of security OK on his computer then fine. Just the user has at least to be warned about security risks it represents and have an alternative. I think a WARNING with description of the problem with a promt after it and possibility to do it otherwise (with hardware path or entering the disk manually) should be enough. Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub 1.96 svn 20080813 and circular lvm2 metadata
Hans,
could you please address Marco's issues and send a new patch so the
topic is brought up again?
Am Freitag, den 29.08.2008, 18:08 +0200 schrieb Marco Gerards:
>
> > diff -uwr grub-1.96_svn20080813-org/ChangeLog
> > grub-1.96_svn20080813-new/ChangeLog
> > --- grub-1.96_svn20080813-org/ChangeLog 2008-08-13 17:24:36.0
> > +0200
> > +++ grub-1.96_svn20080813-new/ChangeLog 2008-08-29 10:33:03.0
> > +0200
> > @@ -1,3 +1,8 @@
> > +2008-08-28 Hans Lambermont <[EMAIL PROTECTED]> (tiny change)
> > + Jan Derk Gerlings <[EMAIL PROTECTED]> (tiny change)
> > +
> > + * disk/lvm.c: Add capability to read circular metadata
>
> Please describe changes in the changelog entry, not the effect.
>
> For example:
>
> * disk/lvm.c (grub_lvm_scan_device): Allocate buffer space for the
> worst case scenario.
> (grub_lvm_scan_device): ...
>
> Where ... has to be filled in, I have no idea what this code actually
> does or what you changed ;-)
>
> The tiny change syntax does not seem familiar to me, AFAIK it is not
> from the GCS. Can you please change that? Furthermore, if you both
> worked on there two parts of the patch, please send in separate
> patches. It will make my life a lot easier... :-)
>
> If only one person worked on this, for example Jan Derk, which Hans
> only forwards this patch, please only list Jan Derk as the
> contributor.
>
> > 2008-08-12 Robert Millan <[EMAIL PROTECTED]>
> >
> > * loader/i386/pc/multiboot.c (grub_multiboot_load_elf32): Move part
> > diff -uwr grub-1.96_svn20080813-org/disk/lvm.c
> > grub-1.96_svn20080813-new/disk/lvm.c
> > --- grub-1.96_svn20080813-org/disk/lvm.c2008-08-28 14:32:53.0
> > +0200
> > +++ grub-1.96_svn20080813-new/disk/lvm.c2008-08-28 18:31:19.0
> > +0200
> > @@ -281,7 +281,8 @@
> >goto fail;
> > }
> >
> > - metadatabuf = grub_malloc (mda_size);
> > + /* alloc for circular worst-case scenario */
>
> Nitpick: Please start a sentence with a capital letter and end with a
> `.'. So this will become:
>
> /* Assume circular buffer in a worst case scenario. */
>
>
> > + metadatabuf = grub_malloc (2*mda_size);
>
> Please use spaces around operators:
>
> 2 * md_size
>
> >if (! metadatabuf)
> > goto fail;
> >
> > @@ -300,6 +301,12 @@
> > }
> >
> >rlocn = mdah->raw_locns;
> > + if (rlocn->offset + rlocn->size > mdah->size)
>
> Here rlcon->offset seems to be little endian (64 bits), so please use
> grub_le_to_cpu64. Same for rlocn->size, please check the size of this
> member before you use a macro (I couldn't find it immediately...).
>
> > +{
> > + /* metadata is circular */
>
> Same as above.
>
> > + grub_memcpy(metadatabuf + mda_size, metadatabuf + mdah->start,
> > + ((rlocn->offset + rlocn->size) - mdah->size));
> > +}
>
> Please check and correct the endianess. you use a lot of
> parenthesises. Actually, I think none are requires.
--
Felix Zielcke
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] update configure.ac to autoconf 2.61
On Wed, 2008-09-03 at 15:27 +0200, Felix Zielcke wrote: > Attached patch is generated via `autoupdate --force' from autoconf 2.61 > a svn-diff after ./autogen.sh doestn't show anything more, because > the ./configure script in SVN is already generated with autoconf 2.61. > > autoconf 2.61 is dated 17.11.2006 on ftp.gnu.org > > Debian etch + lenny have autoconf 2.61 > etch has been released 8th April 2007 > Ubuntu has it since feisty which has been released 19th April 2007 > > I haven't checked the others but I think this is recent enough for the > configure.ac (remember it's generated by ./autogen.sh anyway) > > Yes I really want to get rid of old stuff and if you even only need to > call `autoupdate --force' ;) I don't see any old stuff being removed. I don't see any justification for any of the changes. The new code is longer and less readable. I don't think AC_TRY_COMPILE is a big problem yet. It's not like it won't produce a valid test. In any case, please try to avoid extra long lines where it can be easily avoided. Okuji wrote that he uses Autoconf 2.59, so it would be nice to check that your changes would still work with that version. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] update configure.ac to autoconf 2.61
On Wed, 2008-09-03 at 16:51 +0200, Felix Zielcke wrote: > Am Mittwoch, den 03.09.2008, 15:27 +0200 schrieb Felix Zielcke: > > Yes I really want to get rid of old stuff and if you even only need to > > call `autoupdate --force' ;) > > > > Oh and config.guess and config.sub have > timestamp='2007-07-22' > > whereas the versions from automake 1.9 and 1.10 have > timestamp='2008-01-23 You can get the current config.* files from CVS: cvs -d :pserver:[EMAIL PROTECTED]:/sources/config co config They are maintained in a very conservative matter, so it may be better to use the CVS versions. Actually, it's possible that they are the same as those you have. > On a Debian system you find them in /usr/share/automake-/ > > Any objection that I update these 2 files too? > Attached is a patch for these 2 files. > > Not really necessary but well a bit outdated ;) Fine with me. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
