Re: [PATCH] fix grub-setup on kfreebsd by adding 0x10 to the sysctl ("kern.geom.debugflags") flags
Am Montag, den 13.04.2009, 21:11 +0200 schrieb Robert Millan:
> How about [__FreeBSD__ || __FreeBSD_kernel__] ?
Ok.
> > + if (sysctlbyname ("kern.geom.debugflags", &sysctl_oldflags,
> > &sysctl_size, NULL, 0))
> > +grub_util_error ("cannot get current flags of sysctl
> > kern.geom.debugflags");
>
> I'd just return grub_error instead. Otherwise we abort the program even if
> failure to read a drive is not critical (e.g. lvm.mod scannning all drives,
> grub-emu, etc).
Ok.
> > + if (! sysctl_oldflags & 0x10 && sysctlbyname ("kern.geom.debugflags",
> > NULL , 0, &sysctl_flags, sysctl_size))
> > +grub_util_error ("cannot set flags of sysctl kern.geom.debugflags");
>
> Just a matter of taste, I'd suggest nested ifs to make it more readable.
Changed too.
I commited this now.
--
Felix Zielcke
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: status grub2 port of grub-legasy map command
Am Montag, den 13.04.2009, 21:03 -0400 schrieb John Stanley: > Hi all, > I was wondering what the current status of a grub2 port of the grub-0.97 > "map" and "rootnoverify" commands is? I have found some work done to > this end in the "drivemap.patch" work, but I find nothing more recent > than drivemap.patch.8 dated around Aug 2008. The current status of it are exactly what you found out. I don't know if that'll ever change. > Could anyone give me any pointers/direction on what might be happening > here? Could it be that the "norootverify"-functionality of grub-legasy > is lacking here? Or, perhaps, that the "--force" option is not being > honored ? rootnoverify isn't needed anymore, because root is now just a variable and not anymore a command which tried to verify it. So basically rootnoverify is default now. chainloader --force just skips the check for 0xaa55, normally it shouldn't be needed with a valid windows bootsector. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] FreeBSD 64-bit kernel support
What's the advantage of booting with an mfsroot? Also, will it be advantageous to me? (FreeBSD installations contained within a UFS, UFS2 &/or ZFS logical partition) On Tue, Apr 14, 2009 at 7:36 AM, Joey Korkames wrote: > That did the trick - amd64 boots with a mfsroot now. thanks! > > -joey > > phcoder writes: > >> Try this >> Joey Korkames wrote: >>> >>> phcoder writes: >>> Joey Korkames wrote: > > Hmm, FreeBSD seems to choke when trying to load the grub-bootstrapped > mfsroot.gz (as the root device - haven't tried loading without rooting > from > it)... > > > ___ > 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: grub-fstest build issue in grub2-r2071 +
An update: I looked at the change between r2077 and r2104 and it looks
like the relevant code is util/hostdisk.c; I've attached a patch that
appears to fix the problem.
John
Hi Again,
Thanks, r2104 builds with --enable-grub-fstest now, but a new problem,
not present in r2101 has surfaced: the command grub-probe now aborts on
my system with xfs filesystems. Therefore, I cannot run grub-install
(even with --modules=xfs). With rev's 2101, 2087, 2077, 2071, and 2065
grub-probe ran without error. Here's my hd config:
#device mount-point fs type options dumpfsck
/dev/hda1 swapswapdefaults0 0
/dev/hda2 / xfs defaults1 1
and here's the output of grub-probe (r2104):
# grub-probe -v --target=fs --device /dev/hda2
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: /dev/hda2 starts from 2056320
grub-probe: info: opening the device hd0
grub-probe: info: the size of hd0 is 156301488
Aborted
thanks again,
John
Pavel Roskin wrote:
On Mon, 2009-04-13 at 21:06 -0400, John Stanley wrote:
Hi all,
I have built grub2-r2065 and it works nicely for me so far for linux
boots (love the graphics!!). However, beginning with r2071, I am unable
to build it with the "--enable-grub-fstest" option due to several
undefined refs:
It started in r2067.
To handle this (I'm now building r2101), I add normal/datetime to the
grub-fstest build specs,
Fixed in subversion. Thank you!
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
*** grub2-r2104.orig/util/hostdisk.c2009-04-13 23:06:08.0 -0400
--- grub2-r2104/util/hostdisk.c 2009-04-14 04:57:48.736246452 -0400
***
*** 625,636
int len = strlen(map[drive].drive);
char *p;
! if (dos_part >= 0)
! len += 1 + ((dos_part + 1) / 10);
if (bsd_part >= 0)
len += 2;
! p = xmalloc (len);
sprintf (p, "%s", map[drive].drive);
if (dos_part >= 0)
--- 625,644
int len = strlen(map[drive].drive);
char *p;
! if (dos_part >= 0) {
! // Add in char length of dos_part+1
! int tmp = dos_part + 1;
! ++len;
! while ( (tmp /= 10) ) len++;
! }
if (bsd_part >= 0)
len += 2;
! // Length to alloc is: char length of map[drive].drive, plus
! // char length of (dos_part+1) or of bsd_part, plus
! // 2 for the comma and a null/end of string (\0)
! p = xmalloc (len+2);
!
sprintf (p, "%s", map[drive].drive);
if (dos_part >= 0)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove BSD partition number from install_drive/grub_drive in grub-install
Awesome. BTW: How do these update to GRUB2 work, I mean to the patches, once proven automatically get integrated into GRUB2 (and released to the official website)? On Mon, Apr 13, 2009 at 9:44 PM, Felix Zielcke wrote: > Am Samstag, den 11.04.2009, 23:52 +0200 schrieb Felix Zielcke: >> Hi, >> >> on BSD grub-install thinks that you're wanting to do a cross-install >> when in fact you won't. >> The problem is that in install_drive the BSD partition number isn't >> removed before doing the cross-install check. >> I'm not sure if the regexp is okay so or if it could be better, but at >> least it works for me. > > I commited this now. > All other variants of the regexp I tried didn't work except that one. > -- > Felix Zielcke > > > > ___ > 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: status grub2 port of grub-legasy map command
Thanks Felix, Hurm.. Well, if anyone is interested, I have just made a couple of additional updates to the drivemap.path.8 code, and now with r2104 the "unaligned pointer" issue is gone, and it is working great on my systems. I can post the patch if you or anyone else is interested. John Felix Zielcke wrote: Am Montag, den 13.04.2009, 21:03 -0400 schrieb John Stanley: Hi all, I was wondering what the current status of a grub2 port of the grub-0.97 "map" and "rootnoverify" commands is? I have found some work done to this end in the "drivemap.patch" work, but I find nothing more recent than drivemap.patch.8 dated around Aug 2008. The current status of it are exactly what you found out. I don't know if that'll ever change. Could anyone give me any pointers/direction on what might be happening here? Could it be that the "norootverify"-functionality of grub-legasy is lacking here? Or, perhaps, that the "--force" option is not being honored ? rootnoverify isn't needed anymore, because root is now just a variable and not anymore a command which tried to verify it. So basically rootnoverify is default now. chainloader --force just skips the check for 0xaa55, normally it shouldn't be needed with a valid windows bootsector. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot module in grub2 --with-platform=efi --target=i386
Hi Uzer Cheg.
Any progress on the Xserve?
On Mar 18, 2009, at 6:22 AM, uzer cheg wrote:
Dear all,
I'm trying to run Xen Dom0 kernel on my Xserve.
As I see I need Grub's entry like this:
menuentry "Xen 3.3 unstable -i386
{
search --set /boot/xen-3.3.gz
multiboot /boot/xen-3.3.gz
module /boot/vmlinuz-2.6.29-rc8-tip root=LABEL=/ ro console=tty0
module /boot/initrd-2.6.29-rc8-tip.img
}
I just downloaded from svn latest grub2 (revision 2032) and tried to
build it.
# cd grub2
# ./configure --with-platform=efi --target=i386
# make
# ./grub-mkimage -d . -o grub.efi apple appleldr boot cat chain
configfile cpio date ext2 echo fat gpt help hexdump hfs hfsplus
iso9660 linux ls normal pc reboot reiserfs scsi search sleep xfs
multiboot module
I got error message
# grub-mkimage: error: cannot stat ./multiboot.mod
I think that make did not build multiboot.mod for efi.
Help me please.
Tell me please how to enable multiboot and module support in efi
grub2?
Thank you in advance.
___
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: no commit allowed under discussion
Hi Peter Cros, If you need anyone to run tests on the Xserve, I have a score of machines that we want to use on Linux... On Apr 9, 2009, at 7:23 AM, Peter Cros wrote: Hi, It will be good to get this resolved and on SVN grub2 so people (ubuntuforums) can build for Apple efi with the latest 'hacks' (fakebios, loadbios etc) found necessary in testing. Particlarly Xserve which requires efi boot. On 4/7/09, Bean wrote: On Tue, Apr 7, 2009 at 8:37 AM, Yoshinori K. Okuji wrote: On Tuesday 07 April 2009 01:43:17 Bean wrote: On Sat, Apr 4, 2009 at 8:53 PM, Bean wrote: On Sat, Apr 4, 2009 at 5:30 PM, Yoshinori K. Okuji > wrote: I've undone r2063, since we're still discussing how to / not to split modules. Bean, you must respect teamwork. If you are unable to follow such a fundamental rule, I will have to disable your permission. Hi, I thought the previous mail is about replacing grub_printf with grub_dprint, I'm ok with that. This patch has been in mail list for sometime, it is essential to get a working display in intel macs. Hi, How about this patch ? The split is necessary as it introduces new command loadbios and fakebios that uses the fake_bios_data function, and it would be ugly to put them all inside linux.c. Do you have any strong reason to make loadbios and fakebios separate? I think the overhead is negligible. Hi, loadbios and fakebios are sort of like hacks for the efi platform, I think they shouldn't be placed in the linux loader. Also, by moving the platform dependent code out, we can merge it with i386 generic loader loader/i386/linux.c. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ 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: gettext patch (beta)
Hello, On Apr/11/2009, phcoder wrote: > Hello, thanks for your work. It's a nice stuff, however it has some > minor problems During last months I have been extremely busy :-( and I think that I will be during some more weeks, that's the reason that I have not been following up :-( I will catch up it as soon as possible (merge with the current SVN and do your changes). Thanks for pointing some mistakes. -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: status grub2 port of grub-legasy map command
I haven't yet looked in depth in drivemap patch but it has some problems. It uses preboot hook interface for which I proposed an update in my recent patch "preboot hooks". Also it doesn't update memorymap correctly. For this it should use my "mmap services" interface John Stanley wrote: Thanks Felix, Hurm.. Well, if anyone is interested, I have just made a couple of additional updates to the drivemap.path.8 code, and now with r2104 the "unaligned pointer" issue is gone, and it is working great on my systems. I can post the patch if you or anyone else is interested. John Felix Zielcke wrote: Am Montag, den 13.04.2009, 21:03 -0400 schrieb John Stanley: Hi all, I was wondering what the current status of a grub2 port of the grub-0.97 "map" and "rootnoverify" commands is? I have found some work done to this end in the "drivemap.patch" work, but I find nothing more recent than drivemap.patch.8 dated around Aug 2008. The current status of it are exactly what you found out. I don't know if that'll ever change. Could anyone give me any pointers/direction on what might be happening here? Could it be that the "norootverify"-functionality of grub-legasy is lacking here? Or, perhaps, that the "--force" option is not being honored ? rootnoverify isn't needed anymore, because root is now just a variable and not anymore a command which tried to verify it. So basically rootnoverify is default now. chainloader --force just skips the check for 0xaa55, normally it shouldn't be needed with a valid windows bootsector. ___ 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: grub-fstest build issue in grub2-r2071 +
From: John Stanley Date: Tue, 14 Apr 2009 05:17:44 -0400 > An update: I looked at the change between r2077 and r2104 and it looks > like the relevant code is util/hostdisk.c; I've attached a patch that > appears to fix the problem. Sorry about that bug. I did test that patch, I wonder why it worked for me :-) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: no commit allowed under discussion
Hi, SVN rev 2074 should be good for Xserve1,1 and 1,2 according to tests we ran at ubuntu forums. On Tue, Apr 14, 2009 at 6:23 PM, Drew Rosen wrote: > Hi Peter Cros, > > If you need anyone to run tests on the Xserve, I have a score of machines > that we want to use on Linux... > > > > > On Apr 9, 2009, at 7:23 AM, Peter Cros wrote: > > Hi, >> It will be good to get this resolved and on SVN grub2 so people >> (ubuntuforums) can build for Apple efi with the latest 'hacks' >> (fakebios, loadbios etc) found necessary in testing. Particlarly >> Xserve which requires efi boot. >> >> >> On 4/7/09, Bean wrote: >> >>> On Tue, Apr 7, 2009 at 8:37 AM, Yoshinori K. Okuji >>> wrote: >>> On Tuesday 07 April 2009 01:43:17 Bean wrote: > On Sat, Apr 4, 2009 at 8:53 PM, Bean wrote: > >> On Sat, Apr 4, 2009 at 5:30 PM, Yoshinori K. Okuji >> > wrote: > I've undone r2063, since we're still discussing how to / not to split >>> modules. Bean, you must respect teamwork. If you are unable to follow >>> such a fundamental rule, I will have to disable your permission. >>> >> >> Hi, >> >> I thought the previous mail is about replacing grub_printf with >> grub_dprint, I'm ok with that. This patch has been in mail list for >> sometime, it is essential to get a working display in intel macs. >> > > Hi, > > How about this patch ? The split is necessary as it introduces new > command loadbios and fakebios that uses the fake_bios_data function, > and it would be ugly to put them all inside linux.c. > Do you have any strong reason to make loadbios and fakebios separate? I think the overhead is negligible. >>> >>> Hi, >>> >>> loadbios and fakebios are sort of like hacks for the efi platform, I >>> think they shouldn't be placed in the linux loader. Also, by moving >>> the platform dependent code out, we can merge it with i386 generic >>> loader loader/i386/linux.c. >>> >>> -- >>> Bean >>> >>> >>> ___ >>> Grub-devel mailing list >>> Grub-devel@gnu.org >>> http://lists.gnu.org/mailman/listinfo/grub-devel >>> >>> >> >> -- >> Cros (pxw) >> >> >> ___ >> 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 > -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-fstest build issue in grub2-r2071 +
From: David Miller Date: Tue, 14 Apr 2009 01:53:00 -0700 (PDT) > From: John Stanley > Date: Tue, 14 Apr 2009 05:17:44 -0400 > >> An update: I looked at the change between r2077 and r2104 and it looks >> like the relevant code is util/hostdisk.c; I've attached a patch that >> appears to fix the problem. > > Sorry about that bug. > > I did test that patch, I wonder why it worked for me :-) I commited your fix with some minor coding style fixes. Thanks! ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: no commit allowed under discussion
I posted binaries from grub2 rev 2074 with all modules, for further evaluation - http://ubuntuforums.org/showpost.php?p=7061606&postcount=595 (post #595 grub2074.tar.gz ) On Tue, Apr 14, 2009 at 9:17 PM, Peter Cros wrote: > Hi, > SVN rev 2074 should be good for Xserve1,1 and 1,2 according to tests we ran > at ubuntu forums. > > > On Tue, Apr 14, 2009 at 6:23 PM, Drew Rosen wrote: > >> Hi Peter Cros, >> >> If you need anyone to run tests on the Xserve, I have a score of machines >> that we want to use on Linux... >> >> >> >> >> On Apr 9, 2009, at 7:23 AM, Peter Cros wrote: >> >> Hi, >>> It will be good to get this resolved and on SVN grub2 so people >>> (ubuntuforums) can build for Apple efi with the latest 'hacks' >>> (fakebios, loadbios etc) found necessary in testing. Particlarly >>> Xserve which requires efi boot. >>> >>> >>> On 4/7/09, Bean wrote: >>> On Tue, Apr 7, 2009 at 8:37 AM, Yoshinori K. Okuji wrote: > On Tuesday 07 April 2009 01:43:17 Bean wrote: > >> On Sat, Apr 4, 2009 at 8:53 PM, Bean wrote: >> >>> On Sat, Apr 4, 2009 at 5:30 PM, Yoshinori K. Okuji >>> >> wrote: > >> I've undone r2063, since we're still discussing how to / not to split modules. Bean, you must respect teamwork. If you are unable to follow such a fundamental rule, I will have to disable your permission. >>> >>> Hi, >>> >>> I thought the previous mail is about replacing grub_printf with >>> grub_dprint, I'm ok with that. This patch has been in mail list for >>> sometime, it is essential to get a working display in intel macs. >>> >> >> Hi, >> >> How about this patch ? The split is necessary as it introduces new >> command loadbios and fakebios that uses the fake_bios_data function, >> and it would be ugly to put them all inside linux.c. >> > > Do you have any strong reason to make loadbios and fakebios separate? I > think > the overhead is negligible. > Hi, loadbios and fakebios are sort of like hacks for the efi platform, I think they shouldn't be placed in the linux loader. Also, by moving the platform dependent code out, we can merge it with i386 generic loader loader/i386/linux.c. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel >>> >>> -- >>> Cros (pxw) >>> >>> >>> ___ >>> 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 >> > > > > -- > Cros (pxw) > > > -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Removing autogenerated files from svn
On Sun, Apr 12, 2009 at 01:47:49PM +0200, phcoder wrote: > Hello, we all know how annoying are these autogenerated files. We could > remove it. The main argument against it is that people will not be able > to compile without installing a lot of developement tools. It changes > nothing for the users wanting to modify the code. So I propose to remove > these files but in compensation setup a nightly build server. I'm ready > to supply all necessary scripts to create a source tar.gz with > autogenerated files, binary tar.gz and rescue iso for all platforms > where applicable. Please do. Even without the nightly tarballs, I don't think the requirement to have a few tools installed to build from the VCS is that bad. People who compile software from SVN should be used to this. There was also talk of rewriting the ruby scripts into any other language, preferably shell. That would make things a bit more simple. -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ jo...@sindominio.net jo...@debian.org http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Preboot support
On Monday 13 April 2009 02:19:07 phcoder wrote:
> What about this one?
- ChangeLog, loader.h and loader.c are not consistent. For example, loader.h
declares grub_loader_unregister_preboot_hook, but loader.c defines
grub_loader_remove_preboot.
- I don't understand how preboot_func and preboot_rest_func are different. At
least, not obvious. Can you elaborate on them?
- This part:
+
+ for (cur = preboots_head; cur; cur = cur->next)
+if (err = cur->preboot_func (grub_loader_noreturn))
+ {
+ for (cur = cur->prev; cur; cur = cur->prev)
+ cur->preboot_rest_func ();
+ return err;
+ }
You should not set ERR inside the "if" clause. This is against the GNU Coding
Standards. The main reason is that it is not friendly to debuggers (as you
may not "step" between the assignment and the conditional jump).
Regards,
Okuji
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Build system improvement
On Monday 13 April 2009 14:03:01 Pavel Roskin wrote: > On Sun, 2009-04-12 at 18:07 -0700, David Miller wrote: > > From: Pavel Roskin > > Date: Sun, 12 Apr 2009 17:24:49 -0400 > > > > > On Sat, 2009-04-11 at 08:29 -0700, Colin D Bennett wrote: > > >> If we could build with -Werror, then it wouldn't be so hard to find > > >> the warnings since the build would abort... > > > > > > It's also possible to redirect stderr to a file so that the build > > > doesn't stumble on the first warning. > > > > I'm iffy about this. > > I meant that "warning hunters" can use it and have a choice what > warnings to fix. I didn't suggest stderr redirection to be part of the > build system. > > > There are some hard warnings to get rid of. > > > > For example when building certain grub-* tools there is no way > > to get around the current redefinitions we get of LONG_MAX and > > friends. (one comes in via grub headers, then the stdio.h include > > gets us the system definition, we can't use ifdef guards because > > the grub headers come in and define things first) > > I would explore the possibility of introducing GRUB_LONG_MAX. GRUB > already duplicates a lot of libc definitions. Yes. It is bad and dangerous to use the same symbols as libc. I think I have written this in the wiki: http://grub.enbug.org/CodingStyle Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Nightly build script
On Monday 13 April 2009 18:46:12 phcoder wrote: > Hello, here is a first proposition of a script for nightly builds. On > IRC Yoshinori K. Okuji said that grub.enbug.org could be used to host > these files. Can this server do the builds too? If not can someone setup > build factory? I will do when I have time. Maybe this weekend. Thanks, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Design] nested partitions: Unify grub_partition and grub_disk
On Monday 13 April 2009 23:00:37 Robert Millan wrote: > On Sat, Apr 11, 2009 at 11:58:05PM +0200, phcoder wrote: > > Ping. Is it ok for me to implement it this way? > > I'd really like it if Okuji could give his impression on this one, if > possible. I don't think I am the right one to ask, because I myself don't use any BSD variant any longer. So, in short, I don't care for myself. As partition specifications are relevant to the user, it is better to ask the user. (At least when I used GNU/Hurd with BSD disk slices, I preferred a, b, c to 1, 2, 3. Something called "least surprising".) Regards, Okuji > > > phcoder wrote: > >> I forgot to speak about another question: partition naming. I see 2 > >> possibilities > >> 1) purely numeric unified naming scheme. It means that > >> (hd0,1,a) becomes (hd0,1,1) > >> On one hand mixed number-letter scheme is similar to what freebsd uses > >> but on the other hand numerical scheme is versatile and allows > >> unlimited nestedness. And I don't see why we would use a scheme > >> specific to one of many supported OSes. > >> 2) Every partition map is allowed to pick the name that it likes as > >> long as it contains no comma. In this way we would need to keep > >> partition-name parsing functions in partitition map modules. It means > >> that this code would be duplicated. But this scheme is better in the > >> cases when partition map has no numbering scheme but instead has labels > >> attached to partitions. But in this case IMO search command should be > >> used find the partition > >> > >> I personally would prefer the first way > >> > >>> Also an interesting question is how would "has_partitions" field be > >>> handled in this scheme. > >> > >> Just ignored. It's actually used only to optimise some code out based > >> on the assumption that some media has no partitions. Performance gain > >> is negligible but if this assumption doesn't hold true grub won't be > >> able to access the partitions which are really here. Famous example is > >> a cdrom. Most people would assume that cdrom has no partitions. But on > >> powerpc bootable cdroms use APM > > > > -- > > > > Regards > > Vladimir 'phcoder' Serbinenko > > > > > > ___ > > Grub-devel mailing list > > Grub-devel@gnu.org > > http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] LUA script engine for grub2
On Monday 13 April 2009 23:27:32 Robert Millan wrote: > On Tue, Apr 07, 2009 at 10:31:44PM +0800, Bean wrote: > > Hi, > > > > This patch integrate the LUA script engine to grub2. > > Hi, > > I don't have any opinion for or against using LUA, but note that we need > approval from Marco or Okuji before we can integrate external code. As long as LUA does not become the first citizen in GRUB (i.e. not essential in using GRUB), no problem. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Removing autogenerated files from svn
On Monday 13 April 2009 23:30:42 Robert Millan wrote: > On Sun, Apr 12, 2009 at 04:54:21PM -0400, Pavel Roskin wrote: > > On Sun, 2009-04-12 at 11:29 -0700, Colin D Bennett wrote: > > > phcoder wrote on Sunday 12 April 2009: > > > > Hello, we all know how annoying are these autogenerated files. We > > > > could remove it. The main argument against it is that people will not > > > > be able to compile without installing a lot of developement tools. It > > > > changes nothing for the users wanting to modify the code. So I > > > > propose to remove these files but in compensation setup a nightly > > > > build server. I'm ready to supply all necessary scripts to create a > > > > source tar.gz with autogenerated files, binary tar.gz and rescue iso > > > > for all platforms where applicable. > > > > > > Great idea. I'd love to see this happen. > > > > Me too. > > Me too. > > Okuji, can we agree on it this time? It's annoying for most people, and > release tarballs can include the autogenerated files, so the ruby > dependency is not a problem for end users. Well, it was not only about ruby, but also about autoconf. Anyway, if someone updates the INSTALL file appropriately, I don't object. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bug fix for grub-pe2elf
On Saturday 11 April 2009 21:07:51 Bean wrote: > On Sat, Apr 11, 2009 at 6:24 PM, Yoshinori K. Okuji wrote: > > On Saturday 11 April 2009 18:29:00 Bean wrote: > >> Hi, > >> > >> When symbol name is 8 or less, pe store it as short name, which is not > >> necessary null-terminated. > > > > Oh, I didn't know that. Where is it documented? > > Hi, > > Recently, I found some wired symbol not found error in modules > generated by mingw. After examining the binary image, it seems that PE > would use short name even for symbol whose length is 8, therefore no > null character at the end. grub-pe2elf assume the name is > null-terminated, which could result in extra characters in the > symbols. OK, so you've learned it from experience. :) As I don't want to agree on Microsoft's annoying conditions, I don't read the official spec, but Wikipedia admits that your interpretation is right. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix target tool check logic
On Saturday 11 April 2009 22:16:58 Pavel Roskin wrote: > Quoting "Yoshinori K. Okuji" : > > "test -n" should be avoided. Maybe this is not necessary nowadays, but my > > old lesson was to use "test x$target_alias != x" instead for portability. > > Well, "!=" was not very portable, either, maybe. > > I believe both "-n" and "!=" are found in Autoconf sources that are > turned into configure scripts. Anyway, I'll use the syntax you want. Even if this looks obsolete, I think it is better to follow the chapter "Limitations of Builtins" in the autoconf manual: `test' (strings) Posix says that `test "STRING"' succeeds if STRING is not null, but this usage is not portable to traditional platforms like Solaris 10 `/bin/sh', which mishandle strings like `!' and `-n'. Posix also says that `test ! "STRING"', `test -n "STRING"' and `test -z "STRING"' work with any string, but many shells (such as Solaris, AIX 3.2, UNICOS 10.0.0.6, Digital Unix 4, etc.) get confused if STRING looks like an operator: $ test -n = test: argument expected $ test ! -n test: argument expected Similarly, Posix says that both `test "STRING1" = "STRING2"' and `test "STRING1" != "STRING2"' work for any pairs of strings, but in practice this is not true for troublesome strings that look like operators or parentheses, or that begin with `-'. It is best to protect such strings with a leading `X', e.g., `test "XSTRING" != X' rather than `test -n "STRING"' or `test ! "STRING"'. Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split #1: auto generate handler.lst
On Saturday 11 April 2009 23:49:03 Bean wrote: > Hi, > > This patch generate handler.lst using the register functions. In > normal.mod, it reads handler.lst and register commands like: > > terminal_output.gfxterm > ... > > It also rename static function get_line in normal/main.c to > grub_file_getline. Very good. Please check it in. Thanks, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Test command
On Sunday 12 April 2009 00:11:45 phcoder wrote:
> Updated. Same changelog
>
> >> + {
> >> + update_val (grub_strcmp (args[*argn], args[*argn + 2]) == 0);
> >> + (*argn) += 3;
> >
> > I myself feel that these parentheses are redundant, but I don't know how
> > others think. For C programmers, it is well known that * has a very high
> > priority.
>
> These parenthesis are necessary if doing sth like
> (*argn)++
> since ++ and += are logically and visually similar I prefer to put the
> parenthesis
OK.
>
> > Getting tired, so I skip the same criticism from here.
>
> Actually it would have been enough to say "same applies further on in
> patch"
>
> >> + if (*argn + 1 < argc && !grub_strcmp (args[*argn], "-s"))
> >> + {
> >> + grub_file_t file;
> >> + file = grub_file_open (args[*argn + 1]);
> >> + update_val (file && grub_file_size (file));
> >
> > This is not very safe, because grub_file_size returns grub_off_t which is
> > a 64-bit unsigned int. By converting it into 32-bit signed int
> > implicitly, the result can be zero, even when the size is not zero. So it
> > is better to say explicitly, != 0.
BTW, I think you can simplify test_parse. For example, you write "if (*argn +
2 < argc ...)" many times, but it should be possible to test this condition
only once per loop.
Regards,
Okuji
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Removing autogenerated files from svn
Am Mittwoch, den 15.04.2009, 00:35 +0900 schrieb Yoshinori K. Okuji: > > Well, it was not only about ruby, but also about autoconf. Anyway, if someone > updates the INSTALL file appropriately, I don't object. > Ok, I just removed configure,config.h.in,stamp-h.in,DISTLIST,conf/*.mk, updated INSTALL and svn:ignore property. -- Felix Zielcke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] LUA script engine for grub2
Hi, Oh nice, can you confirm that there is no license conflict in porting code from lua ? On Tue, Apr 14, 2009 at 11:33 PM, Yoshinori K. Okuji wrote: > On Monday 13 April 2009 23:27:32 Robert Millan wrote: >> On Tue, Apr 07, 2009 at 10:31:44PM +0800, Bean wrote: >> > Hi, >> > >> > This patch integrate the LUA script engine to grub2. >> >> Hi, >> >> I don't have any opinion for or against using LUA, but note that we need >> approval from Marco or Okuji before we can integrate external code. > > As long as LUA does not become the first citizen in GRUB (i.e. not essential > in using GRUB), no problem. > > Regards, > Okuji > > > ___ > 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] bug fix for grub-pe2elf
Hi, ok, committed. On Tue, Apr 14, 2009 at 11:41 PM, Yoshinori K. Okuji wrote: > On Saturday 11 April 2009 21:07:51 Bean wrote: >> On Sat, Apr 11, 2009 at 6:24 PM, Yoshinori K. Okuji wrote: >> > On Saturday 11 April 2009 18:29:00 Bean wrote: >> >> Hi, >> >> >> >> When symbol name is 8 or less, pe store it as short name, which is not >> >> necessary null-terminated. >> > >> > Oh, I didn't know that. Where is it documented? >> >> Hi, >> >> Recently, I found some wired symbol not found error in modules >> generated by mingw. After examining the binary image, it seems that PE >> would use short name even for symbol whose length is 8, therefore no >> null character at the end. grub-pe2elf assume the name is >> null-terminated, which could result in extra characters in the >> symbols. > > OK, so you've learned it from experience. :) > As I don't want to agree on Microsoft's annoying conditions, I don't read the > official spec, but Wikipedia admits that your interpretation is right. > > Regards, > Okuji > > > ___ > 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
Update on xnu.mod
-- Regards Vladimir 'phcoder' Serbinenko xnu.mod Description: audio/mod ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Update on xnu.mod
Sorry this was supposed to be personal email to step21. I would never send a binary to a list phcoder wrote: -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Split #1: auto generate handler.lst
Hi, committed. On Tue, Apr 14, 2009 at 11:47 PM, Yoshinori K. Okuji wrote: > On Saturday 11 April 2009 23:49:03 Bean wrote: >> Hi, >> >> This patch generate handler.lst using the register functions. In >> normal.mod, it reads handler.lst and register commands like: >> >> terminal_output.gfxterm >> ... >> >> It also rename static function get_line in normal/main.c to >> grub_file_getline. > > Very good. Please check it in. > > Thanks, > Okuji > > > ___ > 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] FreeBSD 64-bit kernel support
What's the advantage of booting with an mfsroot? You can make a minimal fbsd system in the mfsroot that is smart enough to "init_chroot" from a SMB/NFS netmount, or from a cloop file stored a CD or http-sever (cached to a tmpfs (ramdisk)). Mine also unionfs-mounts a tmpfs to what ever root that is used so you can make changes in ram and not on the source root mount. This is also what Frenzy does - http://frenzy.org.ua/eng/ I don't know if HeX unionfs-mounts or not - http://www.rawpacket.org/projects/hex Also, will it be advantageous to me? I find it useful for executing FreeBSD rescues and where I need to pkg_add tools that are not already on the rootfs. (FreeBSD installations contained within a UFS, UFS2 &/or ZFS logical partition) I didn't think of it at first, but the mfsroot could also have all the smarts contained in it for mounting and init_chroot'ing a ZFS root. You still have to load grub and the kernel/mfsroot from a grub-supported fs, but I was very pleased to hear that phcoder is working on that! -joey ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot module in grub2 --with-platform=efi --target=i386
Hi,dear folks, unfortunately I have a tough working schedule last time. It still not tested. Hope to do it in a few weeks. phcoder, I will report results. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Kexec loading grub2
For a number of weird reasons, I would find the ability to kexec into grub2 from a running linux system useful. In looking at the current code out there, there seems to be two ways to make grub2 able to support this: 1) Add a 32-bit load segment to boot/i386/pc/lnxboot.S as described by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/x86/boot.txt (at the bottom) grub4dos (which is kexec'able) implements this in startup_32: @ http://svn.gna.org/viewcvs/grub4dos/trunk/stage2/dosstart.S?view=markup 2) Adjust the ELF images made by grub-mkimage (for coreboot) to be loaded by kexec-tools's ELF loader (or vice-versa). I figure this is the best route to go about adding kexec boot ability to grub2 since the BIOS-services-less kexec environment may be similar to coreboot's environment. Currently, loading this image: grub-mkelfimage --directory=/usr/lib/grub/i386-coreboot --prefix="/boot/grub" --output=grub2.elf --memdisk=memdisk.cpio memdisk cpio #readelf -l grub2.elf > > Elf file type is EXEC (Executable file) > Entry point 0x8200 > There are 3 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x94 0x8200 0x8200 0x06fd8 0x0e86c RWE 0x20 > GNU_STACK 0x00706c 0x 0x 0x0 0x0 RWE 0x4 > LOAD 0x00706c 0x00017000 0x00017000 0x73fb0 0x73fb0 RWE 0x4 > #file -k grub2.elf > grub2.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped like so: (using latest git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git) # kexec --type multiboot-x86 --load grub2.elf issues this error: > Base address: 8200 is not page aligned The original kexec kernel patch maintainer had these things to say about that: https://lists.linux-foundation.org/pipermail/fastboot/2005-August/008743.html http://www.mail-archive.com/fastb...@lists.linux-foundation.org/msg00249.html I noticed this line in the grub2 src: ./conf/i386-coreboot.rmk:36:kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -Wl,-N,-S,-Ttext,0x8200,-Bstatic but I'm sure there's gonna be more involved than just changing that to 0x8000. kexec_test is an example of a kexec-loadable elf: (http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools.git;a=tree;f=kexec_test;hb=HEAD) #file -k kexec-tools.git/build/lib/kexec-tools/kexec_test > kexec_test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped #readelf -l /tmp/kexec-tools/build/lib/kexec-tools/kexec > > Elf file type is EXEC (Executable file) > Entry point 0x109c4 > There are 2 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x001000 0x0001 0x0001 0x00e40 0x00e40 R E 0x1000 > LOAD 0x002000 0x00011000 0x00011000 0x0 0x0102c RW 0x1000 > > Section to Segment mapping: > Segment Sections... >00 .text >01 .bss I don't have the know-how currently to implement either route but I may be able to learn with a little guidance. I'm asking about it here so as not to repeat any work-in-progress. Thanks -joey ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] FreeBSD 64-bit kernel support
Hi Great news! Thanks for your reply! Can't wait for PHcoder to finish his work! Panarchy On Wed, Apr 15, 2009 at 5:17 AM, Joey Korkames wrote: >> What's the advantage of booting with an mfsroot? > > You can make a minimal fbsd system in the mfsroot that is smart enough to > "init_chroot" from a SMB/NFS netmount, or from a cloop file stored a CD or > http-sever (cached to a tmpfs (ramdisk)). Mine also unionfs-mounts a tmpfs > to what ever root that is used so you can make changes in ram and not on the > source root mount. > > This is also what Frenzy does - http://frenzy.org.ua/eng/ > > I don't know if HeX unionfs-mounts or not - > http://www.rawpacket.org/projects/hex > >> >> Also, will it be advantageous to me? >> > > I find it useful for executing FreeBSD rescues and where I need to pkg_add > tools that are not already on the rootfs. > >> (FreeBSD installations contained within a UFS, UFS2 &/or ZFS logical >> partition) >> > > I didn't think of it at first, but the mfsroot could also have all the > smarts contained in it for mounting and init_chroot'ing a ZFS root. > > You still have to load grub and the kernel/mfsroot from a grub-supported fs, > but I was very pleased to hear that phcoder is working on that! > > -joey > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove BSD partition number from install_drive/grub_drive in grub-install
You can checkout the code via: svn co svn://svn.savannah.gnu.org/grub/trunk/grub2 Then use the autocompile.sh script that was posted earlier to make builds of grub2 or you can wait for the nightly autobuilder to be set-up and just download its results (from wherever they will be announced). GRUB2 is not making frequent stable releases yet. -joey Chip Panarchy writes: Awesome. BTW: How do these update to GRUB2 work, I mean to the patches, once proven automatically get integrated into GRUB2 (and released to the official website)? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Fix target tool check logic
On Wed, 2009-04-15 at 00:45 +0900, Yoshinori K. Okuji wrote: > On Saturday 11 April 2009 22:16:58 Pavel Roskin wrote: > > Quoting "Yoshinori K. Okuji" : > > > "test -n" should be avoided. Maybe this is not necessary nowadays, but my > > > old lesson was to use "test x$target_alias != x" instead for portability. > > > Well, "!=" was not very portable, either, maybe. > > > > I believe both "-n" and "!=" are found in Autoconf sources that are > > turned into configure scripts. Anyway, I'll use the syntax you want. > > Even if this looks obsolete, I think it is better to follow the > chapter "Limitations of Builtins" in the autoconf manual: Thanks. The Autoconf code I was referring to didn't involve any possibility of pathological arguments. But we are dealing with user input here (target_alias comes from the command line), so you are right, it's better to err on the safe side. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
