Re: [PATCH] drivemap fixes
On Fri, 2009-06-05 at 16:27 +0200, Vladimir 'phcoder' Serbinenko wrote: > Hello. As suggested by Javier Martín I move this to a new thread. This > patch fixes some problems with determining bios number of a disk. > biosnum is in boot.mod because it's where it will cause the least of > possible core.img increase (3 of 5 loaders on pc need biosnum). > Thisforced to move boot.mod to platform-specific files but this > inflexibility of build system is a subject for another patch I'll appreciate if you also provide ChangeLog. Also, it would be great if you specify, which exactly problems the patch fixes. As for the fixes to the handler, I think they should be submitted separately. Please avoid non-words like "postamble". Comments would be nice. I would try to avoid having two long calls if possible. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: insmod uhci causes computer to reset
On Sun, 2009-06-07 at 21:22 +0100, Oliver Henshaw wrote: > 2009/6/7 Pavel Roskin : > > Maybe the crash is in usb_keyboard? > I don't think that can be it. AFAICS usb_keyboard would only be called > if I manually loaded the model. And I've never done that. I see. Anyway, the USB code needs a lot of work, and I appreciate your effort. The original author of the USB code, Marco Gerards, wrote recently that he doesn't have much time for the GRUB work. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/4] bus/usb minor cleanups
Hello, Oliver! Your patches are sent as attachments, which makes it hard to view and comment them. It's better to send everything inline. My preference is to use STGit with the git mirror of grub, which is located at git://repo.or.cz/grub2.git Then "stg mail" will send the messages inline. Use the first line of the description for the subject, the second line for the word "ChangeLog" (otherwise git will reformat the changelog). I know that the ohci module hangs in qemu. It's good to see that you found out the reason. It would be great if you don't include any spacing changes with your patches. We are discussing the global removal of the trailing whitespace, but it's a separate issue. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: insmod ohci fails to register usb ports
2009/6/7 Oliver Henshaw : > Even with the fixes mentioned previously, grub fails with an OHCI > controller (NEC ohci/ehci chipset on a PCI card). It seems to successfully > initialise the > controller, but fails to enumerate the ports. The same output is seen with a > mouse > attached as with no devices attached. I forgot to mention what I've tried so far. * I read the Host Controller initialisation part of the OHCI spec and checked whether the controller is initially under SMI or BIOS control - but it's not. * I then took a look at the freebsd[1] usb controller drivers and tried out the quirks and workarounds they use - but they didn't make any difference. What I haven't done is put any effort into figuring out what more needs to be done to make sure all queue-related registers are correctly set. It doesn't look like everything suggested in the OHCI spec is implemented. Also, it looks like the freebsd driver does still more than the spec recommends. Oliver [1] For some reason, the usb drivers in FreeBSD 7 are still BSD+Advertising license. Luckily, the drivers in svn head are not. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: insmod uhci causes computer to reset
2009/6/7 Pavel Roskin : > Maybe the crash is in usb_keyboard? I don't think that can be it. AFAICS usb_keyboard would only be called if I manually loaded the model. And I've never done that. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: insmod uhci causes computer to reset
On Sun, 2009-06-07 at 20:03 +0100, Oliver Henshaw wrote: > Even with the fixes described previously, grub fails with an UHCI > controller (VIA uhci > chipset on the motherboard). When no devices are attached, module > loading completes > successfully. When a mouse is attached, module loading completes but > listing the device with > 'usb' causes the machine to reset. If I try without 'set debug=uhci' > then 'insmod uhci' causes > the computer to hang. Maybe the crash is in usb_keyboard? I know that term/usb_keyboard.c assumes that there is exactly one USB keyboard. It there is no USB keyboard, the code would crash because usbdev is NULL. Also, the matching of the keyboard is incorrect. It checks the device descriptor (even that code is a hack), but not the interface descriptor. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
insmod ohci fails to register usb ports
Even with the fixes mentioned previously, grub fails with an OHCI controller (NEC ohci/ehci chipset on a PCI card). It seems to successfully initialise the controller, but fails to enumerate the ports. The same output is seen with a mouse attached as with no devices attached. grub> insmod ohci ../bus/usb/ohci.c:180: class=0x0c 0x03 interface 0x10 base=0xe2102000 ../bus/usb/ohci.c:184: OHCI revision=0x10 ../bus/usb/ohci.c:195: OHCI reset ../bus/usb/ohci.c:213: OHCI HCCA ../bus/usb/ohci.c:219: OHCI enable: 0x02 ../bus/usb/ohci.c:180: class=0x0c 0x03 interface 0x10 base=0xe2103000 ../bus/usb/ohci.c:184: OHCI revision=0x10 ../bus/usb/ohci.c:195: OHCI reset ../bus/usb/ohci.c:213: OHCI HCCA ../bus/usb/ohci.c:219: OHCI enable: 0x02 ../bus/usb/ohci.c:622: root hub ports=2 ../bus/usb/ohci.c:604: detect_dev status=0x00 ../bus/usb/ohci.c:604: detect_dev status=0x00 ../bus/usb/ohci.c:622: root hub ports=3 ../bus/usb/ohci.c:604: detect_dev status=0x00 ../bus/usb/ohci.c:604: detect_dev status=0x00 ../bus/usb/ohci.c:604: detect_dev status=0x00 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
insmod uhci causes computer to reset
Even with the fixes described previously, grub fails with an UHCI controller (VIA uhci chipset on the motherboard). When no devices are attached, module loading completes successfully. When a mouse is attached, module loading completes but listing the device with 'usb' causes the machine to reset. If I try without 'set debug=uhci' then 'insmod uhci' causes the computer to hang. With no devices: grub> insmod uhci ../bus/usb/uhci.c:188: class=0x0c 0x03 interface 0x00 base=0xe400 ../bus/usb/uhci.c:278: UHCI initialized ../bus/usb/uhci.c:188: class=0x0c 0x03 interface 0x00 base=0xe800 ../bus/usb/uhci.c:278: UHCI initialized ../bus/usb/uhci.c:636: detect=0x48a port=0 ../bus/usb/uhci.c:636: detect=0x58a port=1 ../bus/usb/uhci.c:636: detect=0x48a port=0 ../bus/usb/uhci.c:636: detect=0x48a port=1 ../bus/usb/uhci.c:668: registered grub> With a mouse attached: grub> insmod uhci ../bus/usb/uhci.c:188: class=0x0c 0x03 interface 0x00 base=0xe400 ../bus/usb/uhci.c:278: UHCI initialized ../bus/usb/uhci.c:188: class=0x0c 0x03 interface 0x00 base=0xe800 ../bus/usb/uhci.c:278: UHCI initialized ../bus/usb/uhci.c:636: detect=0x48a port=0 ../bus/usb/uhci.c:636: detect=0x5ab port=1 ../bus/usb/uhci.c:582: enable=1 port=1 ../bus/usb/uhci.c:593: detect=0x5ab ../bus/usb/uhci.c:602: reset completed ../bus/usb/uhci.c:608: waiting for the port to be enabled ../bus/usb/uhci.c:613: >3detect=0x5a7 ../bus/usb/usbtrans.c:43: control: reqtype=0x80 req=0x06 val=0x100 idx=0x00 size =18 ../bus/usb/uhci.c:408: transaction: endp=0, type=2, addr=0, toggle=0, size=8 dat a=0x67ad0 td=0x2403e000 ../bus/usb/uhci.c:408: transaction: endp=0, type=0, addr=0, toggle=1, size=18 da ta=0x2403d760 td=0x2403e020 ../bus/usb/uhci.c:408: transaction: endp=0, type=1, addr=0, toggle=1, size=0 dat a=0x0 td=0x2403e040 ../bus/usb/uhci.c:481: setup transaction 0 ../bus/usb/uhci.c:487: initiate transaction ../bus/usb/uhci.c:498: >t status=0x440007 data=0x67ad0 td=0x2403e000 ../bus/usb/uhci.c:504: t status=0x440007 ../bus/usb/uhci.c:509: >>t status=0x440007 ../bus/usb/uhci.c:548: transaction failed ../bus/usb/usbtrans.c:43: control: reqtype=0x00 req=0x05 val=0x01 idx=0x00 size= 0 ../bus/usb/uhci.c:408: transaction: endp=0, type=2, addr=0, toggle=0, size=8 dat a=0x67b10 td=0x2403e040 ../bus/usb/uhci.c:408: transaction: endp=0, type=0, addr=0, toggle=1, size=0 dat a=0x0 td=0x2403e020 ../bus/usb/uhci.c:481: setup transaction 0 ../bus/usb/uhci.c:487: initiate transaction ../bus/usb/uhci.c:498: >t status=0x440007 data=0x67b10 td=0x2403e040 ../bus/usb/uhci.c:504: t status=0x440007 ../bus/usb/uhci.c:509: >>t status=0x440007 ../bus/usb/uhci.c:548: transaction failed ../bus/usb/uhci.c:636: detect=0x48a port=0 ../bus/usb/uhci.c:636: detect=0x48a port=1 ../bus/usb/uhci.c:668: registered grub> usb USB devices: USB version 0.0, VendorID: 0x00, ProductID: 0x00, #conf: 0 Low speed device Interface #0: #Endpoints: 22 ../bus/usb/usbtrans.c:43: control: reqtype=0x80 r eq=0x06 val=0x3c3 idx=0x409 size=1 (and then the computer resets) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Link usb controller struct only when initialised
When controller initialisation is aborted in grub_uhci_pci_iter
(grub_ohci_pci_iter) control
jumps to "fail:", where any allocated memory is freed. However, the
struct grub_uhci *u
(struct grub_ohci *o) for that controller remains linked to the list
of UHCI (OHCI)
controllers. This causes problems later, when grub iterates over
controllers to initialise
their ports.
The solution is to link only when the usb controller is successfully
initialised, and just
before returning from the function.
This patch is tested with real hardware and with qemu and the rescue image.
Thanks,
Oliver
ChangeLog:
* bus/usb/ohci.c: Link struct only after initialising controller.
* bus/usb/uhci.c: Likewise.
Index: bus/usb/ohci.c
===
--- bus/usb/ohci.c (revision 2216)
+++ bus/usb/ohci.c (working copy)
@@ -153,9 +153,6 @@ grub_ohci_pci_iter (int bus, int device, int func,
if (! o)
return 1;
- /* Link in the OHCI. */
- o->next = ohci;
- ohci = o;
o->iobase = (grub_uint32_t *) base;
/* Reserve memory for the HCCA. */
@@ -189,6 +186,10 @@ grub_ohci_pci_iter (int bus, int device, int func,
grub_dprintf ("ohci", "OHCI enable: 0x%02x\n",
(grub_ohci_readreg32 (o, GRUB_OHCI_REG_CONTROL) >> 6) & 3);
+ /* link to ohci now that initialisation is successful. */
+ o->next = ohci;
+ ohci = o;
+
return 0;
fail:
Index: bus/usb/uhci.c
===
--- bus/usb/uhci.c (revision 2216)
+++ bus/usb/uhci.c (working copy)
@@ -173,8 +173,6 @@ grub_uhci_pci_iter (int bus, int device, int func,
if (! u)
return 1;
- u->next = uhci;
- uhci = u;
u->iobase = base & GRUB_UHCI_IOMASK;
u->framelist = 0;
u->qh = 0;
@@ -287,6 +285,10 @@ grub_uhci_pci_iter (int bus, int device, int func,
}
#endif
+ /* link to uhci now that initialisation is successful. */
+ u->next = uhci;
+ uhci = u;
+
return 0;
fail:
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 4/4] Define fields in terms of the Class Code register
usb-change-to-class_code Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 3/4] Check usb programming interface
usb-check-interface Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 2/4] Fix inteface definition for ohci
usb-fix-interface Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 1/4] bus/usb minor cleanups
usb-minor-cleanup Description: Binary data ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Grub needs to check the programming interface for usb controllers
Grub needs to check that the usb programming interface is of the correct type. Otherwise, hilarity ensues when e.g. bus/usb/ohci.c attempts to initialise an uhci controller. This can easily be reproduced by typing 'insmod ohci' in the grub rescue disk in qemu, with usb enabled. Additionally, the usb interface (which was defined but not used in bus/usb/ohci.c) was set to the wrong value. I've split this into a patch series bookended by more cosmetic patches. The first patch consists of minor fixes: removing some doubled lines (which look like a pasto, but I could be wrong), changing an int to a grub_uint32_t (to match the types of all other similar variables) and I've added some whitespace fixes. The final patch is purely cosmetic: it defines the pci Class, Subclass and Programming Interface fields in terms of the Class Code register, so that the code better reflects the spec. This last patch may seem minor, but the (previously unused) usb interface was set to the wrong value in bus/usb/ohci.c up to now - this means that the code now better reflects the structure of the Class Code register, and better documents the specification. The patch series has been tested on on real hardware, and each patch has been tested with qemu and a grub rescue image. Both ohci and uhci cases have been tested (qemu has a virtual ohci controller, but the option to enable it must be patched in). Thanks, Oliver ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] support of hfsx ( case comparaison )
On Sun, 2009-06-07 at 11:10 +0200, Vladimir 'phcoder' Serbinenko wrote: > On Sun, Jun 7, 2009 at 4:18 AM, Pavel Roskin wrote: > >> Improving > >> strcasecmp is possible and may even be compact. Even if unicode counts > >> a lot of alphabets only few are bicameral. AFAIK main ones are Latin, > >> Greek, Cyrillic and Armenian. I hope that in most cases the lowercase > >> conversion can be done with some simple arithmetic operations > > > > We are using grub_strcasecmp() on data in other encodings in some cases. > > I think short names on the FAT filesystem are never in UTF-8. > Normally not but fat code passes short filenames to grub without any > encoding conversion. In other words fat code assumes short filenames > are in utf8. A problem in both hfs and fat is that it uses local > encoding and at least in case of fat it's impossible to know which one > from filesystem alone. We would need something like mount option to > get this right. It could be sth like > hd0_0_codepage=437 Fortunately, it would only matter if the user tries to access a file with non-ASCII characters using a capitalization different from the one used by the filesystem. > > Also, > > case comparison depends on the locale. That's too much complexity for > > the code GRUB. I would prefer the case comparison for hfsplus to be in > > the hfsplus module if we decide to implement it correctly. > I agree with you. I see no reason for users to have unicode characters > in kernel names. And so getting it right is too much work for an > almost zero benefit I case of hfsplus, there is a chance to miss a file in the binary tree if there are non-ASCII files in the same directory. But I agree, it's not worth the trouble at this point. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] add drivemap support to 30_os-prober.in and use UUIDs
On Sun, 2009-06-07 at 17:37 +0200, Felix Zielcke wrote: > Attached patch uses `prepare_grub_to_access_device' to set the root in > the generated entrys. > And it adds drivemap to the chainload ones, if root isn't (hd0). > > The Debian grub-installer adds map only with Dos and Windows, should I > do the same or is it okay to do it for all? Perhaps it would be better to avoid it when it's not needed. But it may be tricky to determine what bootloader we are using. Let's do it always and eliminate the cases where it's harmful or definitely useless. > -# update-grub helper script. > +# grub-mkconfig helper script. > Does this needs to be mentioned in ChangeLog? The standard says: 'When you change just comments or doc strings, it is enough to write an entry for the file, without mentioning the functions. Just "Doc fixes" is enough for the change log.' -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] add drivemap support to 30_os-prober.in and use UUIDs
Attached patch uses `prepare_grub_to_access_device' to set the root in
the generated entrys.
And it adds drivemap to the chainload ones, if root isn't (hd0).
The Debian grub-installer adds map only with Dos and Windows, should I
do the same or is it okay to do it for all?
-# update-grub helper script.
+# grub-mkconfig helper script.
Does this needs to be mentioned in ChangeLog?
--
Felix Zielcke
2009-06-07 Felix Zielcke
* util/grub.d/30_os-prober.in: Source
${libdir}/grub/grub-mkconfig_lib. Use prepare_grub_to_access_device
to set the root device.
diff --git a/util/grub.d/30_os-prober.in b/util/grub.d/30_os-prober.in
index 7d4d17e..9a6dff4 100644
--- a/util/grub.d/30_os-prober.in
+++ b/util/grub.d/30_os-prober.in
@@ -1,7 +1,7 @@
#! /bin/sh -e
-# update-grub helper script.
-# Copyright (C) 2006,2007,2008 Free Software Foundation, Inc.
+# grub-mkconfig helper script.
+# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.
#
# GRUB is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -16,6 +16,12 @@
# You should have received a copy of the GNU General Public License
# along with GRUB. If not, see
Re: [PATCH] savedefault
Hello. Welcome back On Sun, Jun 7, 2009 at 11:35 AM, Bean wrote: > Hi, > > Actually, I'm thinking about a more generic method to implement this > feature with events. The menu viewer fire events at certain > circumstance, and we can configure the commands to execute. For > example, we could have a menu.select event fire when a menu item is > selected, and use something like this in grub.cfg: > > event add menu.select save_env saved_entry > > Command "save_env saved_entry" would be run automatically, no need to > patch up the menu items. Often user doesn't want some entries to be saved as default. E.g. "single user" entries. I know that it's easy to revert to other method but if nearly everyone does your work will be effort for nothing > > One advantage with the event model is that it can handle password at > the same time, for example, we could write something like this: > > event add menu.select_check password > event add menu.commandline_check password > > password command is run when user tries to select the menu item or > enter command line. > > On Mon, Jun 1, 2009 at 6:48 PM, Vladimir 'phcoder' > Serbinenko wrote: >> Hello. Here is a long-awaited savedefault patch. Works correctly only >> if my scripting fix is applied >> >> -- >> Regards >> Vladimir 'phcoder' Serbinenko >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel >> >> > > > > -- > Bean > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: 2273 lines in 170 files consists of only space and tabulators
Am Samstag, den 06.06.2009, 21:59 -0400 schrieb Pavel Roskin: > By the way, our style is slightly different from that used by GNU > indent. GRUB uses space after "!", whereas GNU indent doesn't. Also, > some GRUB sources use one space before labels, and GNU indent starts > labels from the first column. I just noticed that emacs indents util/grub.d/30_os-prober different then it was written. And the coding style isn't always that consistent. For example sometimes `if (! pointer)' is used and sometimes `if (pointer == NULL)' -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] savedefault
Hi, Actually, I'm thinking about a more generic method to implement this feature with events. The menu viewer fire events at certain circumstance, and we can configure the commands to execute. For example, we could have a menu.select event fire when a menu item is selected, and use something like this in grub.cfg: event add menu.select save_env saved_entry Command "save_env saved_entry" would be run automatically, no need to patch up the menu items. One advantage with the event model is that it can handle password at the same time, for example, we could write something like this: event add menu.select_check password event add menu.commandline_check password password command is run when user tries to select the menu item or enter command line. On Mon, Jun 1, 2009 at 6:48 PM, Vladimir 'phcoder' Serbinenko wrote: > Hello. Here is a long-awaited savedefault patch. Works correctly only > if my scripting fix is applied > > -- > Regards > Vladimir 'phcoder' Serbinenko > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] savedefault
On Sun, Jun 7, 2009 at 9:50 AM, Felix Zielcke wrote: > Am Montag, den 01.06.2009, 12:48 +0200 schrieb Vladimir 'phcoder' > Serbinenko: >> Hello. Here is a long-awaited savedefault patch. Works correctly only >> if my scripting fix is applied > > What happens if this is used on RAID? Then writing is handled by raid module which always return GRUB_ERR_NOT_IMPLEMENTED_YET which would make save_env fail. If users circumvent raid module they do a faulty install and it's their fault if their RAID gets desynchronised > Especially when the grubenv file is wrapped by the chunksize? > We should consider this if we use saven_env by default. > -- > Felix Zielcke > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] support of hfsx ( case comparaison )
On Sun, Jun 7, 2009 at 4:18 AM, Pavel Roskin wrote: >> Improving >> strcasecmp is possible and may even be compact. Even if unicode counts >> a lot of alphabets only few are bicameral. AFAIK main ones are Latin, >> Greek, Cyrillic and Armenian. I hope that in most cases the lowercase >> conversion can be done with some simple arithmetic operations > > We are using grub_strcasecmp() on data in other encodings in some cases. > I think short names on the FAT filesystem are never in UTF-8. Normally not but fat code passes short filenames to grub without any encoding conversion. In other words fat code assumes short filenames are in utf8. A problem in both hfs and fat is that it uses local encoding and at least in case of fat it's impossible to know which one from filesystem alone. We would need something like mount option to get this right. It could be sth like hd0_0_codepage=437 > Also, > case comparison depends on the locale. That's too much complexity for > the code GRUB. I would prefer the case comparison for hfsplus to be in > the hfsplus module if we decide to implement it correctly. I agree with you. I see no reason for users to have unicode characters in kernel names. And so getting it right is too much work for an almost zero benefit > > -- > Regards, > Pavel Roskin > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] savedefault
Am Montag, den 01.06.2009, 12:48 +0200 schrieb Vladimir 'phcoder' Serbinenko: > Hello. Here is a long-awaited savedefault patch. Works correctly only > if my scripting fix is applied What happens if this is used on RAID? Especially when the grubenv file is wrapped by the chunksize? We should consider this if we use saven_env by default. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
