Re: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
Am Samstag, den 08.08.2009, 02:35 -0400 schrieb Pavel Roskin: > On Sat, 2009-08-08 at 08:04 +0200, Felix Zielcke wrote: > > > > I think it would be more natural to let the user specify the full path > > > to the file. Setting LANG=C seems unneeded in this case. After all, > > > it's the user's choice, and we cannot examine the font file to check > > > which characters it has. > > > > Ok here's a new one. > > Looks good to me. > Ok commited with style changed. -- Felix Zielcke Proud Debian Maintainer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
On Sat, 2009-08-08 at 08:04 +0200, Felix Zielcke wrote: > > I think it would be more natural to let the user specify the full path > > to the file. Setting LANG=C seems unneeded in this case. After all, > > it's the user's choice, and we cannot examine the font file to check > > which characters it has. > > Ok here's a new one. Looks good to me. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting iso image having syslinux
On Sat, 8 Aug 2009 13:25:34 +1000 Peter Cros wrote: > Some comments about live iso booting and grub2 loopback - > > After grub boots the live iso kernel and initrd, they need to loop > mount the iso again to access the live files. Otherwise the initrd > would need rebuild, or some way found to pass the loop mount from > grub. > > I have been trying some available live iso's (there are others out > there). I am using grub.efi, not using syslinux.. > > These live isos do loop mount the iso, and run - > ununtu, grml, slax. > > These don't - > fedora, debian, gparted. > > In all cases, grub loopback mounting of the iso and booting the > kernel and initrd works. > I don't know if it is a coincident but your timing to share these info is directly connected with my problem. I am presently trying to collect some live iso in my usb stick and like to call those by grub2. gparted is one of them. I have in mind to use gparted iso but you have already mentioned that it can't be. Is there any other work around within grub to cope with these type of iso ? Thanks for sharing ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
Am Samstag, den 08.08.2009, 01:49 -0400 schrieb Pavel Roskin:
> On Sat, 2009-08-08 at 07:36 +0200, Felix Zielcke wrote:
>
> > > Could you please explain what I should do to keep using ascii.pf2? I
> > > checked the script, but don't see any variable controlling that. "make
> > > install" would install both unicode.pf2 and ascii.pf2, so unicode.pf2
> > > would always be preferred.
> >
> > With the old code ascii.pf2 would be always preferred.
> > There wasn't either a way to specify it.
>
> I see. Maybe that's what we should have fixed first.
>
> > > If changing the default, it's a good style to provide an easy way for
> > > users to keep the old setting, and I just don't see it, short or
> > > removing /usr/src/unifont.bdf and /usr/local/share/grub/unicode.pf2 so
> > > that they are never reinstalled or detected by GRUB.
> >
> > Here's now a patch which allows users to specifiy the used font with
> > GRUB_FONT=ascii
>
> First of all, I hope that the patch you will actually commit will use
> sane formatting. Diffs that ignore spacing changes are OK for review,
> but not for applying as is.
Yes.
> I think it would be more natural to let the user specify the full path
> to the file. Setting LANG=C seems unneeded in this case. After all,
> it's the user's choice, and we cannot examine the font file to check
> which characters it has.
Ok here's a new one.
--
Felix Zielcke
Proud Debian Maintainer
2009-08-08 Felix Zielcke
* util/grub-mkconfig.in: Allow the user to specify the used font
with GRUB_FONT.
Index: util/grub-mkconfig.in
===
--- util/grub-mkconfig.in (revision 2482)
+++ util/grub-mkconfig.in (working copy)
@@ -154,6 +154,14 @@ esac
# check for terminals that require fonts
case ${GRUB_TERMINAL_OUTPUT} in
gfxterm)
+if [ -n "$GRUB_FONT" ] ; then
+ if is_path_readable_by_grub ${GRUB_FONT} > /dev/null ; then
+GRUB_FONT_PATH=${GRUB_FONT}
+ else
+ echo "No such font or not readable by grub: ${GRUB_FONT}" >&2
+ exit 1
+ fi
+else
for dir in ${pkgdatadir} /boot/grub /usr/share/grub ; do
for basename in unicode unifont ascii; do
path="${dir}/${basename}.pf2"
@@ -169,6 +177,7 @@ case ${GRUB_TERMINAL_OUTPUT} in
break 2
done
done
+fi
if [ -z "${GRUB_FONT_PATH}" ] ; then
# fallback to the native terminal for this platform
unset GRUB_TERMINAL_OUTPUT
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to call dban fron grub ?
On Fri, 07 Aug 2009 19:35:09 +0200 Felix Zielcke wrote: [..] > > > > Does anyone of you have the luck to call dban from grub2 ? > > > > > > Try with the old linux loader with linux16 and initrd16 [..] WORKING !! it is working :-) you are a hero. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
On Sat, 2009-08-08 at 07:36 +0200, Felix Zielcke wrote: > > Could you please explain what I should do to keep using ascii.pf2? I > > checked the script, but don't see any variable controlling that. "make > > install" would install both unicode.pf2 and ascii.pf2, so unicode.pf2 > > would always be preferred. > > With the old code ascii.pf2 would be always preferred. > There wasn't either a way to specify it. I see. Maybe that's what we should have fixed first. > > If changing the default, it's a good style to provide an easy way for > > users to keep the old setting, and I just don't see it, short or > > removing /usr/src/unifont.bdf and /usr/local/share/grub/unicode.pf2 so > > that they are never reinstalled or detected by GRUB. > > Here's now a patch which allows users to specifiy the used font with > GRUB_FONT=ascii First of all, I hope that the patch you will actually commit will use sane formatting. Diffs that ignore spacing changes are OK for review, but not for applying as is. I think it would be more natural to let the user specify the full path to the file. Setting LANG=C seems unneeded in this case. After all, it's the user's choice, and we cannot examine the font file to check which characters it has. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
Am Samstag, den 08.08.2009, 07:36 +0200 schrieb Felix Zielcke: > Am Samstag, den 08.08.2009, 01:12 -0400 schrieb Pavel Roskin: > > On Fri, 2009-08-07 at 14:57 +0200, Felix Zielcke wrote: > > > > > I commited it now with an ack from Robert on IRC. > > > > Sorry, I'm commenting after it has been committed. Anyway, please note > > that having an approval doesn't absolve you from testing the code on > > your own. Reviews are not testing. There was a warning introduced by > > your change, and there was a syntax error after "ascii". Also, the > > formatting of the moved code should have been changed to use the same > > indentation as the target file. I have fixed all that. > > Sorry. > > > Could you please explain what I should do to keep using ascii.pf2? I > > checked the script, but don't see any variable controlling that. "make > > install" would install both unicode.pf2 and ascii.pf2, so unicode.pf2 > > would always be preferred. > > With the old code ascii.pf2 would be always preferred. > There wasn't either a way to specify it. > > > If changing the default, it's a good style to provide an easy way for > > users to keep the old setting, and I just don't see it, short or > > removing /usr/src/unifont.bdf and /usr/local/share/grub/unicode.pf2 so > > that they are never reinstalled or detected by GRUB. > > Here's now a patch which allows users to specifiy the used font with > GRUB_FONT=ascii > Oh I forgot to mention that I left the indent changes with intent out, so it's more readable. -- Felix Zielcke Proud Debian Maintainer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] make 10_linux' test_gt() a bit more generic
On Fri, 2009-08-07 at 14:05 +0200, Robert Millan wrote: > > Committed. Also moved those functions to grub-mkconfig_lib.in. When comparing vmlinuz-2.6.31-rc4-wl and vmlinuz-2.6.31-rc5-wl, version_test_gt() ends up comparing "wl" and "wl". Using the "g" modifier leads to the replacement being applied continuously until the last minus is consumed. The use of "g" wasn't warranted before, but it didn't have such effect. I'm committing the fix. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
Am Samstag, den 08.08.2009, 01:12 -0400 schrieb Pavel Roskin:
> On Fri, 2009-08-07 at 14:57 +0200, Felix Zielcke wrote:
>
> > I commited it now with an ack from Robert on IRC.
>
> Sorry, I'm commenting after it has been committed. Anyway, please note
> that having an approval doesn't absolve you from testing the code on
> your own. Reviews are not testing. There was a warning introduced by
> your change, and there was a syntax error after "ascii". Also, the
> formatting of the moved code should have been changed to use the same
> indentation as the target file. I have fixed all that.
Sorry.
> Could you please explain what I should do to keep using ascii.pf2? I
> checked the script, but don't see any variable controlling that. "make
> install" would install both unicode.pf2 and ascii.pf2, so unicode.pf2
> would always be preferred.
With the old code ascii.pf2 would be always preferred.
There wasn't either a way to specify it.
> If changing the default, it's a good style to provide an easy way for
> users to keep the old setting, and I just don't see it, short or
> removing /usr/src/unifont.bdf and /usr/local/share/grub/unicode.pf2 so
> that they are never reinstalled or detected by GRUB.
Here's now a patch which allows users to specifiy the used font with
GRUB_FONT=ascii
--
Felix Zielcke
Proud Debian Maintainer
2009-08-08 Felix Zielcke
* util/grub-mkconfig.in: Allow the user to specify the used font
with GRUB_FONT.
diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index 7756b49..55135f8 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -155,6 +155,19 @@ esac
case ${GRUB_TERMINAL_OUTPUT} in
gfxterm)
for dir in ${pkgdatadir} /boot/grub /usr/share/grub ; do
+ if [ -n "$GRUB_FONT" ] ; then
+path="${dir}/${GRUB_FONT}.pf2"
+if is_path_readable_by_grub ${path} > /dev/null ; then
+ GRUB_FONT_PATH=${path}
+ if [ "${GRUB_FONT}" = "ascii" ]
+ export LANG=C
+ fi
+ break
+ else
+ echo "No such font ${GRUB_FONT}.pf2" >&2
+ exit 1
+ fi
+ else
for basename in unicode unifont ascii; do
path="${dir}/${basename}.pf2"
if is_path_readable_by_grub ${path} > /dev/null ; then
@@ -168,6 +181,7 @@ case ${GRUB_TERMINAL_OUTPUT} in
fi
break 2
done
+fi
done
if [ -z "${GRUB_FONT_PATH}" ] ; then
# fallback to the native terminal for this platform
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] use UUID to map system devices to grub devices
Am Freitag, den 07.08.2009, 21:22 +0200 schrieb Robert Millan: > On Fri, Aug 07, 2009 at 04:29:00PM +0200, Felix Zielcke wrote: > > Am Freitag, den 07.08.2009, 13:27 +0200 schrieb Robert Millan: > > > On Wed, Aug 05, 2009 at 08:18:29AM +0200, Felix Zielcke wrote: > > > > Am Dienstag, den 04.08.2009, 23:19 +0200 schrieb Robert Millan: > > > > > On Fri, Jul 31, 2009 at 06:26:51PM +0200, Felix Zielcke wrote: > > > > > > > > > > > > If we'd do an arbitrary mapping then `grub-probe -t drive' would > > > > > > show > > > > > > the wrong grub device. > > > > > > But except from this I think that would be okay. > > > > > > > > > > We can never garantee that `grub-probe -t drive' will show the > > > > > "right" drive, > > > > > at least on i386-pc, because we don't know how is BIOS going to order > > > > > them. > > > > > > > > Yes drive not, but the partition. > > > > > > It's true, but we don't really make the distinction. UUID search will > > > find > > > a filesystem, which is in a partition (usually), and doesn't rely on > > > partitions > > > being reliable. > > > > > > That's fortunate! It means we don't have to commit to partition numbers > > > being > > > reliable, even if they are right now. > > > > > > Because of this (unless I missed something), at the end of the day the > > > unreliability issue you described doesn't translate into any real problem > > > for us. It just adds more to a problem we already solved. > > > > > > > Unfortunately we don't have UUID support on every filesystem we support > > > > like JFS. But I think it's not that commonly used. > > > > > > Adding UUID support to new filesystems is very easy. I did the first ones > > > with just 5-10 minutes of research and a few lines of coding. > > > > > > Would you like to do JFS ? > > > > I did it now for JFS. > > > > I tried it now out with dos_part set to p + 2 with my find_by_uuid patch > > and now I get a `no such partition' error on my dmraid device. > > So we can't use an arbitary mapping in grub_util_biosdisk_get_grub_dev > > Why not? well then we would need to change the partition table parsing code to use the same arbitary mapping for GRUB_UTIL && LINUX then grub_util_biosdisk_get_grub_dev and I think that's not really a proper solution. -- Felix Zielcke Proud Debian Maintainer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
On Fri, 2009-08-07 at 14:57 +0200, Felix Zielcke wrote: > I commited it now with an ack from Robert on IRC. Sorry, I'm commenting after it has been committed. Anyway, please note that having an approval doesn't absolve you from testing the code on your own. Reviews are not testing. There was a warning introduced by your change, and there was a syntax error after "ascii". Also, the formatting of the moved code should have been changed to use the same indentation as the target file. I have fixed all that. Could you please explain what I should do to keep using ascii.pf2? I checked the script, but don't see any variable controlling that. "make install" would install both unicode.pf2 and ascii.pf2, so unicode.pf2 would always be preferred. If changing the default, it's a good style to provide an easy way for users to keep the old setting, and I just don't see it, short or removing /usr/src/unifont.bdf and /usr/local/share/grub/unicode.pf2 so that they are never reinstalled or detected by GRUB. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Solving the grub-pe2elf problem
On Fri, 2009-08-07 at 15:46 +0200, Robert Millan wrote: > Other maintainers, is it burdensome to any of you to include these binaries > in official builds? I suppose it's not, since mingw32 packages are widely > available, but it doesn't hurt to ask :-) I would prefer not to do a binary build at this stage. Especially Windows users are at risk of messing things up if the entry barrier is lowered too much. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Solving the grub-pe2elf problem
On Fri, 2009-08-07 at 22:39 +0200, Robert Millan wrote: > I don't understand this. Why is a requirement to install GNU binutils > unreasonable, whereas a requirement to install objconv is not? Installing binutils can break the existing toolchain. Installing objconv should not. It's a good idea, as it would unify Apple and Cygwin support to some degree. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/2] Relocator framework
On Fri, 2009-08-07 at 14:01 +0200, Vladimir 'phcoder' Serbinenko wrote: > Apple's compiler is based GCC but binutils aren't and they pose the > most of problems. Actualy the most problematic bit was that I didn't > know that unless you prefix variable with L_ apple's assembler treats > it as global. Adding L_ in this code solves problem. Yves proposed to > add a LOCAL(x) macro to symbol.h this way the assembler code is also > more readable. I also did further adjustments in this patch to > decrease the number of ifdefs but had no time to test it and so > couldn't submit it I would prefer if you don't commit any patches that introduce any more preprocessor conditionals for the Apple compiler or assembler. It would make it hard to debug problems reported by others, as different compilers would produce different binaries. If we are using some feature that is just nice but not needed (such as binary & in lnxboot.S to set the image size to 1024), it would be better to avoid using that feature for all compilers rather than for the compilers that don't support it. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting iso image having syslinux
Some comments about live iso booting and grub2 loopback - After grub boots the live iso kernel and initrd, they need to loop mount the iso again to access the live files. Otherwise the initrd would need rebuild, or some way found to pass the loop mount from grub. I have been trying some available live iso's (there are others out there). I am using grub.efi, not using syslinux.. These live isos do loop mount the iso, and run - ununtu, grml, slax. These don't - fedora, debian, gparted. In all cases, grub loopback mounting of the iso and booting the kernel and initrd works. On Fri, Aug 7, 2009 at 9:57 PM, J.Bakshi wrote: > > > > Are you using vga= ? I fixed a bug recently (in SVN) that may cause this > > behaviour. > > > > Then I have to reinstall grub from my sqeeeze box to the usb-stick > again to see the effect. > > > ___ > 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: [PATCH] ntldr support
2009/8/7 Robert Millan : > On Fri, Aug 07, 2009 at 01:17:30PM +0200, Michal Suchanek wrote: >> >> ntldr is a boot loader like any other and it needs its configuration >> and support files to work. Without them it fails (not sure how) but >> that is not unexpected. > > I tend to agree, but in this particular case, it's conceivable that Microsoft > didn't expect anyone to do this, and therefore neglected to provide a graceful > response. > > Could anyone test it and report how this behaves? > > -- > 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." > I tried putting the ntldr binary on an empty fat32 disk and loading with the grub ntldr command. The system just reboots. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Solving the grub-pe2elf problem
On Fri, Aug 07, 2009 at 04:06:11PM +0200, Vladimir 'phcoder' Serbinenko wrote: > On Fri, Aug 7, 2009 at 4:01 PM, Vladimir 'phcoder' > Serbinenko wrote: > > On Fri, Aug 7, 2009 at 3:46 PM, Robert Millan wrote: > >> > >> Hi, > >> > >> I thought of a possible solution to the grub-pe2elf problem. It seems that > >> it is burdensome to produce ELF binaries on Windows, but building PE > >> binaries > >> or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 > >> toolchain > >> which is available on most distributions). > >> > If you see pe2elf as being too much of a burden we may switch to > objconv: http://www.agner.org/optimize/. It's already used in > conjunction with Apple Mach-O toolchain. It's not a GNU project but is > licensed under GPL. I don't understand this. Why is a requirement to install GNU binutils unreasonable, whereas a requirement to install objconv is not? -- 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: [PATCH] use UUID to map system devices to grub devices
On Fri, Aug 07, 2009 at 04:29:00PM +0200, Felix Zielcke wrote: > Am Freitag, den 07.08.2009, 13:27 +0200 schrieb Robert Millan: > > On Wed, Aug 05, 2009 at 08:18:29AM +0200, Felix Zielcke wrote: > > > Am Dienstag, den 04.08.2009, 23:19 +0200 schrieb Robert Millan: > > > > On Fri, Jul 31, 2009 at 06:26:51PM +0200, Felix Zielcke wrote: > > > > > > > > > > If we'd do an arbitrary mapping then `grub-probe -t drive' would show > > > > > the wrong grub device. > > > > > But except from this I think that would be okay. > > > > > > > > We can never garantee that `grub-probe -t drive' will show the "right" > > > > drive, > > > > at least on i386-pc, because we don't know how is BIOS going to order > > > > them. > > > > > > Yes drive not, but the partition. > > > > It's true, but we don't really make the distinction. UUID search will find > > a filesystem, which is in a partition (usually), and doesn't rely on > > partitions > > being reliable. > > > > That's fortunate! It means we don't have to commit to partition numbers > > being > > reliable, even if they are right now. > > > > Because of this (unless I missed something), at the end of the day the > > unreliability issue you described doesn't translate into any real problem > > for us. It just adds more to a problem we already solved. > > > > > Unfortunately we don't have UUID support on every filesystem we support > > > like JFS. But I think it's not that commonly used. > > > > Adding UUID support to new filesystems is very easy. I did the first ones > > with just 5-10 minutes of research and a few lines of coding. > > > > Would you like to do JFS ? > > I did it now for JFS. > > I tried it now out with dos_part set to p + 2 with my find_by_uuid patch > and now I get a `no such partition' error on my dmraid device. > So we can't use an arbitary mapping in grub_util_biosdisk_get_grub_dev Why not? -- 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: How to call dban fron grub ?
Am Freitag, den 07.08.2009, 22:47 +0530 schrieb J. Bakshi:
> Hello developers,
>
> I think ( please correct me if I am wrong ) I need not say more about dban
> (Darik's Boot And Nuke); a HDD data eraser.
> dban is shipped with syslinux to fit into both Cd and USB stick. What I am
> trying to achieve is to call dban by grub2.
> As per the syslinux.cfg; calling dban with shell is done by
>
> `` syslinux.cfg
>
> LABEL shell
> KERNEL kernel.bzi
> APPEND initrd=initrd.gz root=/dev/ram0 init=/rc nuke="exec ash"
> `
>
> dban comes as floppy image as dban_1_0_7_i386.ima which has the kernel and
> initrd image ( I have also confirmed by mount it through loopback device and
> get the same ). To call it from grub with loopback I have done as below [
> Note: I have put dban_1_0_7_i386.ima in reiserfs partition (hd0,2) ]
>
> ``
> menuentry "dban"
> {
> loopback loop (hd0,2)/dban_1_0_7_i386.ima
> linux (loop)/kernel.bzi nuke="exec ash"
> initrd (loop)/initrd.gz
> }
>
>
> Grub calls dban successfully but immediately computer restarts. It happens
> again and again whenever I call dban. Also checked by
>
> linux (loop)/kernel.bzi root=/dev/ram0 init=(loop)/dban_1_0_7_i386.ima/rc
> nuke="exec ash"
>
> but no luck.
>
> Does anyone of you have the luck to call dban from grub2 ?
>
>
Try with the old linux loader with linux16 and initrd16
--
Felix Zielcke
Proud Debian Maintainer
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB manual
Hi, I've just reviewed the WIP manual in docs/grub.texi, and removed a lot of information that is specific to GRUB Legacy (sometimes entire sections). The remaining text was still written with GRUB Legacy in mind, and is certainly full of inaccuracies related to that. If you spot one of those, there's no need to send a patch for review, please shot on sight (but please make sure you write accurate ChangeLog entries and update copyright year). The manual is still not ready for prime use, as some key sections are missing. If someone's interested in adding them, I recommend that the GRUB Legacy manual is checked, as it will surely contain a lot of reusable text. If you wish to document new things, please feel free to propose changes, or to include documentation blurbs in patches that add new functionality to GRUB. Also, perhaps it'd be a good idea to build/install the manual in our build system, with a disclaimer indicating it's not complete or so. This would help us gather attention to it and maybe some help, but it can also be too confusing for users. Thoughts? -- 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: Solving the grub-pe2elf problem
Hi, You could also check out my new object format at http://github.com/bean123/grub, lib branch. It supports conversion of pe/elf/mach-o object file to a grub specific format, so that you can use native build tool in Linux/OSX/Windows, no need for linker and converter. It also reduce compile time by half and generate module file much smaller that the current format. On Sat, Aug 8, 2009 at 12:20 AM, Christian Franke wrote: > Vladimir 'phcoder' Serbinenko wrote: >> >> If you see pe2elf as being too much of a burden we may switch to >> objconv: http://www.agner.org/optimize/. It's already used in >> conjunction with Apple Mach-O toolchain. It's not a GNU project but is >> licensed under GPL. >> > > Thanks for the hint, I will try objconv it soon. > > -- > Regards, > Christian Franke > > > > ___ > 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
How to call dban fron grub ?
Hello developers,
I think ( please correct me if I am wrong ) I need not say more about dban
(Darik's Boot And Nuke); a HDD data eraser.
dban is shipped with syslinux to fit into both Cd and USB stick. What I am
trying to achieve is to call dban by grub2.
As per the syslinux.cfg; calling dban with shell is done by
`` syslinux.cfg
LABEL shell
KERNEL kernel.bzi
APPEND initrd=initrd.gz root=/dev/ram0 init=/rc nuke="exec ash"
`
dban comes as floppy image as dban_1_0_7_i386.ima which has the kernel and
initrd image ( I have also confirmed by mount it through loopback device and
get the same ). To call it from grub with loopback I have done as below [ Note:
I have put dban_1_0_7_i386.ima in reiserfs partition (hd0,2) ]
``
menuentry "dban"
{
loopback loop (hd0,2)/dban_1_0_7_i386.ima
linux (loop)/kernel.bzi nuke="exec ash"
initrd (loop)/initrd.gz
}
Grub calls dban successfully but immediately computer restarts. It happens
again and again whenever I call dban. Also checked by
linux (loop)/kernel.bzi root=/dev/ram0 init=(loop)/dban_1_0_7_i386.ima/rc
nuke="exec ash"
but no luck.
Does anyone of you have the luck to call dban from grub2 ?
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] New object format
Hi, Update: Support 64-bit mach-o object files, now you can build i386-pc, i386-efi and x86_64-efi in OSX. Use PIC in x86_64-efi. Relocation R_X86_64_32S would cause problem in machine with 2G or more memory, the only way to get rid of it is to use large memory model, or use PIC. Large model is only available in gcc-4.3 or later, and the generated image is quite large as all address is 8 bytes long. PIC is always enabled in mingw-w64 and apple's gcc, it just need a little work to support PIC in elf platform. Now all system uses PIC instead of large memory model. As with this version, it's possible to build i386-pc, i386-efi and x86_64-efi in Linux/OSX/Windows, using the native build tool, no cross compiler. Only gcc and as is needed to generated object file *.o from source code, linker (ld) and converter (objcopy, objconv, grub-pe2elf, grub-macho2img) are not needed as the conversion is handled by grub-mkrawimage and grub-mkmod. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 2/2] RFT: Remove ABS macro from boot/i386/pc/boot.S
On Sat, Jul 18, 2009 at 9:16 PM, Robert Millan wrote: > On Sat, Jul 18, 2009 at 08:34:41PM +0200, Vladimir 'phcoder' Serbinenko wrote: >> Haiku can be compiled and can use either gcc 4.x or gcc2.95. The main >> reason for them to keep gcc 2.95 possibility is the binary >> compatibility with BeOS. As François Revol explained me on IRC C++ ABI >> changed from gcc2 to gcc3 and as BeOS and Haiku heavily rely on C++ >> it's impossible to launch BeOS apps under Haiku if it was compiled >> with gcc4. > > Ok, but this doesn't seem to be related to GRUB, since we don't need to > link its utils with any proprietary code. Can't they compile runtime > libraries intended for BeOS compatibility using gcc2 and use gcc4 for > GRUB (and, well, just about everything else)? > gcc2 even the one updated by haiku has bugs. I don't think we should go long way just to support it. Hence I withdraw my request for holding this patch back because of it > -- > 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 > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Solving the grub-pe2elf problem
Vladimir 'phcoder' Serbinenko wrote: If you see pe2elf as being too much of a burden we may switch to objconv: http://www.agner.org/optimize/. It's already used in conjunction with Apple Mach-O toolchain. It's not a GNU project but is licensed under GPL. Thanks for the hint, I will try objconv it soon. -- Regards, Christian Franke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Solving the grub-pe2elf problem
Robert Millan wrote: I thought of a possible solution to the grub-pe2elf problem. It seems that it is burdensome to produce ELF binaries on Windows, but building PE binaries or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain which is available on most distributions). If building GRUB with "./configure --host=i586-mingw32msvc" works, we could include win32 binaries in the upcoming 1.97 release. Other GNU projects do this as well. Then we could drop support for toolchains that lack ELF. Which binaries would you like to include? - kernel.img and modules, and/or - the grub-*.exe files (Note: mingw32 .exe != cygwin .exe).? The problem with the PE->ELF conversion affects build of the *.mod files, not the build of the *.exe. The linker script is necessary for kernel.img. Christian and Bean, are you interested in implementing this? No. Then building a Cygwin package would rely on the existence of (tested or untested?) binaries in the a release tarball. Building packages from SVN snapshots would no longer be possible. I really don't want to spent my open-source-time with such kind of feature removal :-) -- Regards, Christian Franke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] use UUID to map system devices to grub devices
Am Freitag, den 07.08.2009, 13:27 +0200 schrieb Robert Millan: > On Wed, Aug 05, 2009 at 08:18:29AM +0200, Felix Zielcke wrote: > > Am Dienstag, den 04.08.2009, 23:19 +0200 schrieb Robert Millan: > > > On Fri, Jul 31, 2009 at 06:26:51PM +0200, Felix Zielcke wrote: > > > > > > > > If we'd do an arbitrary mapping then `grub-probe -t drive' would show > > > > the wrong grub device. > > > > But except from this I think that would be okay. > > > > > > We can never garantee that `grub-probe -t drive' will show the "right" > > > drive, > > > at least on i386-pc, because we don't know how is BIOS going to order > > > them. > > > > Yes drive not, but the partition. > > It's true, but we don't really make the distinction. UUID search will find > a filesystem, which is in a partition (usually), and doesn't rely on > partitions > being reliable. > > That's fortunate! It means we don't have to commit to partition numbers being > reliable, even if they are right now. > > Because of this (unless I missed something), at the end of the day the > unreliability issue you described doesn't translate into any real problem > for us. It just adds more to a problem we already solved. > > > Unfortunately we don't have UUID support on every filesystem we support > > like JFS. But I think it's not that commonly used. > > Adding UUID support to new filesystems is very easy. I did the first ones > with just 5-10 minutes of research and a few lines of coding. > > Would you like to do JFS ? I did it now for JFS. I tried it now out with dos_part set to p + 2 with my find_by_uuid patch and now I get a `no such partition' error on my dmraid device. So we can't use an arbitary mapping in grub_util_biosdisk_get_grub_dev -- Felix Zielcke Proud Debian Maintainer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Solving the grub-pe2elf problem
On Fri, Aug 7, 2009 at 4:01 PM, Vladimir 'phcoder' Serbinenko wrote: > On Fri, Aug 7, 2009 at 3:46 PM, Robert Millan wrote: >> >> Hi, >> >> I thought of a possible solution to the grub-pe2elf problem. It seems that >> it is burdensome to produce ELF binaries on Windows, but building PE binaries >> or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain >> which is available on most distributions). >> If you see pe2elf as being too much of a burden we may switch to objconv: http://www.agner.org/optimize/. It's already used in conjunction with Apple Mach-O toolchain. It's not a GNU project but is licensed under GPL. > -- > Regards > Vladimir 'phcoder' Serbinenko > > Personal git repository: http://repo.or.cz/w/grub2/phcoder.git > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Solving the grub-pe2elf problem
On Fri, Aug 7, 2009 at 3:46 PM, Robert Millan wrote: > > Hi, > > I thought of a possible solution to the grub-pe2elf problem. It seems that > it is burdensome to produce ELF binaries on Windows, but building PE binaries > or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain > which is available on most distributions). > > If building GRUB with "./configure --host=i586-mingw32msvc" works, we could > include win32 binaries in the upcoming 1.97 release. Other GNU projects do > this as well. Then we could drop support for toolchains that lack ELF. > I don't think that dropping useful features just for the sake of code to look nice is a good thing. End users wouldn't care if you supply binaries with or without compilable sources. But you don't let them to exercise freedom. You can argue that you don't restrict their freedom it's true but many people may need to taste freedom on a small thing before changing to (w)holly free system. And this approach attracts developpers. When I was speaking with developpers around Darwin they specifically wanted to compile grub with toolchain they already have. It's why I bothered at all to make grub compilable with Apple toolchain (I'm personally fine with compiling it from Linux or FreeBSD). I'm aware of few coders on different skill levels who are now "tasting" grub and who wouldn't have if I haven't done it > It probably doesn't currently build this way, because win32 won't have all > the functions we need, but this can be fixed by importing them from Gnulib, > the GNU compatibility library. > > Christian and Bean, are you interested in implementing this? > > Other maintainers, is it burdensome to any of you to include these binaries > in official builds? I suppose it's not, since mingw32 packages are widely > available, but it doesn't hurt to ask :-) > > -- > 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 > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Solving the grub-pe2elf problem
Hi, I thought of a possible solution to the grub-pe2elf problem. It seems that it is burdensome to produce ELF binaries on Windows, but building PE binaries or even PE/win32 executables on GNU/Linux is not (thanks to Mingw32 toolchain which is available on most distributions). If building GRUB with "./configure --host=i586-mingw32msvc" works, we could include win32 binaries in the upcoming 1.97 release. Other GNU projects do this as well. Then we could drop support for toolchains that lack ELF. It probably doesn't currently build this way, because win32 won't have all the functions we need, but this can be fixed by importing them from Gnulib, the GNU compatibility library. Christian and Bean, are you interested in implementing this? Other maintainers, is it burdensome to any of you to include these binaries in official builds? I suppose it's not, since mingw32 packages are widely available, but it doesn't hurt to ask :-) -- 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: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
Am Freitag, den 07.08.2009, 14:02 +0200 schrieb Felix Zielcke:
> Am Freitag, den 07.08.2009, 13:39 +0200 schrieb Robert Millan:
> > On Thu, Aug 06, 2009 at 11:39:11AM +0200, Felix Zielcke wrote:
> > > +for dir in ${pkgdatadir} /boot/grub /usr/share/grub ; do
> > > + for basename in unicode unifont ascii; do
> > > + path="${dir}/${basename}.pf2"
> > > +if is_path_readable_by_grub ${path} > /dev/null ; then
> > > + GRUB_FONT_PATH=${path}
> > > + else
> > > + continue
> > > + fi
> > > + if [ "${basename}" = "ascii"] ; then
> > > + # make sure all our children behave in conformance with ascii..
> > > + export LANG=C
> > > + fi
> > > + break 2
> > > + done
> > > +done
> > > + if [ -z "${GRUB_FONT_PATH}" ] ; then
> > > +# fallback to the native terminal for this platform
> > > +unset GRUB_TERMINAL_OUTPUT
> > > + fi
> > > fi
> > >;;
> > > -esac
> > > -
> > > -# does our terminal support utf-8 ?
> > > -case ${GRUB_TERMINAL_OUTPUT} in
> > > - gfxterm) ;;
> > >*)
> > > # make sure all our children behave in conformance with ascii..
> > > export LANG=C
> > > - ;;
> > > esac
> >
> > It seems that "export LANG=C" is issued twice?
> >
> Once if gfxterm gets used and once like before for all other output
> terminals.
I commited it now with an ack from Robert on IRC.
--
Felix Zielcke
Proud Debian Maintainer
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] fix FreeBSD.vfs.root.mountfrom
Committed.
On Tue, Aug 04, 2009 at 09:13:51PM +0200, Robert Millan wrote:
> On Tue, Aug 04, 2009 at 08:42:25PM +0200, Robert Millan wrote:
> >
> > FreeBSD.vfs.root.mountfrom expects an absolute path, not just device name.
>
> Actually, both work, but the former is what their loader uses, and it's
> simpler for us to handle, so let's juse use that.
>
> Also, the default setting on FreeBSD is to mount / as writable, for which
> we need vfs.root.mountfrom.options=rw.
>
> See new patch.
>
> --
> 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."
> 2009-08-04 Robert Millan
>
> * util/grub.d/10_freebsd.in: Use an absolute device path for
> `vfs.root.mountfrom'. Set `vfs.root.mountfrom.options=rw'.
>
> Index: util/grub.d/10_freebsd.in
> ===
> --- util/grub.d/10_freebsd.in (revision 2466)
> +++ util/grub.d/10_freebsd.in (working copy)
> @@ -50,8 +50,6 @@ if [ "x$kfreebsd" != "x" ] ; then
> devices_rel_dirname=`make_system_path_relative_to_its_root
> $devices_dirname`
>fi
>
> - root_device=`basename ${GRUB_DEVICE}`
> -
># For "ufs" it's the same. Do we care about the others?
>kfreebsd_fs=${GRUB_FS}
>
> @@ -69,7 +67,8 @@ EOF
> EOF
>fi
>cat << EOF
> - set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${root_device}
> + set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${GRUB_DEVICE}
> + set FreeBSD.vfs.root.mountfrom.options=rw
> }
> EOF
> fi
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
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: [PATCH] make 10_linux' test_gt() a bit more generic
Committed. Also moved those functions to grub-mkconfig_lib.in.
On Tue, Aug 04, 2009 at 09:19:40PM +0200, Robert Millan wrote:
>
> This makes 10_linux' test_gt() a bit more generic so that it can be
> moved (along with a few other functions) to grub-mkconfig_lib, where
> it'll be usable by 10_freebsd.
>
> This will allow handling multiple kernel versions in 10_freebsd, like
> 10_linux does.
>
> --
> 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."
> 2009-08-04 Robert Millan
>
> * util/grub.d/10_linux.in (test_gt): Strip any basename prefix,
> not just "vmlinu[zx]".
>
> Index: util/grub.d/10_linux.in
> ===
> --- util/grub.d/10_linux.in (revision 2466)
> +++ util/grub.d/10_linux.in (working copy)
> @@ -67,8 +67,8 @@ test_numeric ()
>
> test_gt ()
> {
> - local a=`echo $1 | sed -e "s/vmlinu[zx]-//g"`
> - local b=`echo $2 | sed -e "s/vmlinu[zx]-//g"`
> + local a=`echo $1 | sed -e "s/[^-]*-//g"`
> + local b=`echo $2 | sed -e "s/[^-]*-//g"`
>local cmp=gt
>if [ "x$b" = "x" ] ; then
> return 0
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
--
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: Three question about grub2
"J.Bakshi" writes: > Coming back with one more question in mind. ( already searched bot no > luck yet ). "echo" can dispaly message. Is there ( by any luck ) any > command to display message from a file ? cat -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Reimplement 10_freebsd.in using 10_linux.in
This patch reimplements 10_freebsd.in using 10_linux.in as a base, with
the kFreeBSD-specific parts of 10_freebsd.in.
The new version brings in support for multiple kernel versions (the reason
for the rewrite) and also handling of acpi.ko.
It is diffed against 10_linux.in, since the old code structure is no longer
used.
--
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."
--- util/grub.d/10_linux.in 2009-08-07 14:04:34.0 +0200
+++ util/grub.d/10_freebsd.in 2009-08-07 14:09:05.0 +0200
@@ -21,82 +21,79 @@
libd...@libdir@
. ${libdir}/grub/grub-mkconfig_lib
-if [ "x${GRUB_DISTRIBUTOR}" = "x" ] ; then
- OS=GNU/Linux
-else
- OS="${GRUB_DISTRIBUTOR} GNU/Linux"
-fi
-
-# loop-AES arranges things so that /dev/loop/X can be our root device, but
-# the initrds that Linux uses don't like that.
-case ${GRUB_DEVICE} in
- /dev/loop/*|/dev/loop[0-9])
-GRUB_DEVICE=`losetup ${GRUB_DEVICE} | sed -e "s/^[^(]*(\([^)]\+\)).*/\1/"`
- ;;
+case "${GRUB_DISTRIBUTOR}" in
+ Debian) OS="${GRUB_DISTRIBUTOR} GNU/kFreeBSD" ;;
+ *) OS="FreeBSD" ;;
esac
-if [ "x${GRUB_DEVICE_UUID}" = "x" ] || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ] \
-|| ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" ; then
- LINUX_ROOT_DEVICE=${GRUB_DEVICE}
-else
- LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
-fi
-
-linux_entry ()
+kfreebsd_entry ()
{
cat << EOF
menuentry "$1" {
EOF
prepare_grub_to_access_device ${GRUB_DEVICE_BOOT} | sed -e "s/^/\t/"
cat << EOF
- linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro $2
+ freebsd ${rel_dirname}/${basename}
+EOF
+
+ if test -n "${devices}" ; then
+cat << EOF
+ freebsd_loadenv ${devices_rel_dirname}/${devices_basename}
EOF
- if test -n "${initrd}" ; then
+ fi
+
+ if test -n "${acpi_ko}" ; then
cat << EOF
- initrd ${rel_dirname}/${initrd}
+ freebsd_module_elf ${acpi_ko_rel_dirname}/${acpi_ko_basename}
EOF
fi
+
cat << EOF
+ set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${GRUB_DEVICE}
+ set FreeBSD.vfs.root.mountfrom.options=rw
}
EOF
}
-list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
+list=`for i in /boot/kfreebsd-* /boot/kernel/kernel ; do
if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
done`
while [ "x$list" != "x" ] ; do
- linux=`version_find_latest $list`
- echo "Found linux image: $linux" >&2
- basename=`basename $linux`
- dirname=`dirname $linux`
+ kfreebsd=`version_find_latest $list`
+ echo "Found kernel of FreeBSD: $kfreebsd" >&2
+ basename=`basename $kfreebsd`
+ dirname=`dirname $kfreebsd`
rel_dirname=`make_system_path_relative_to_its_root $dirname`
- version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
+
+ if [ x"$devices" != "x" ] ; then
+devices_basename=`basename $devices`
+devices_dirname=`dirname $devices`
+devices_rel_dirname=`make_system_path_relative_to_its_root $devices_dirname`
+ fi
+
+ # For "ufs" it's the same. Do we care about the others?
+ kfreebsd_fs=${GRUB_FS}
+
+ version=`echo $basename | sed -e "s,^[^0-9]*-,,g;s/\.gz$//g"`
alt_version=`echo $version | sed -e "s,\.old$,,g"`
- linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
- initrd=
- for i in "initrd.img-${version}" "initrd-${version}.img" \
- "initrd-${version}" "initrd.img-${alt_version}" \
- "initrd-${alt_version}.img" "initrd-${alt_version}"; do
-if test -e "${dirname}/${i}" ; then
- initrd="$i"
+ acpi_ko=
+ for i in "/lib/modules/${version}/acpi.ko" "/lib/modules/${alt_version}/acpi.ko" \
+ "/boot/kernel/acpi.ko"; do
+if test -e "$i" ; then
+ acpi_ko="$i"
break
fi
done
- if test -n "${initrd}" ; then
-echo "Found initrd image: ${dirname}/${initrd}" >&2
- else
-# "UUID=" magic is parsed by initrds. Since there's no initrd, it can't work here.
-linux_root_device_thisversion=${GRUB_DEVICE}
+ if test -n "${acpi_ko}" ; then
+echo "Found ACPI module: ${acpi_ko}" >&2
+acpi_ko_basename=`basename ${acpi_ko}`
+acpi_ko_dirname=`dirname ${acpi_ko}`
+acpi_ko_rel_dirname=`make_system_path_relative_to_its_root $acpi_ko_dirname`
fi
- linux_entry "${OS}, Linux ${version}" \
- "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
- if [ "x${GRUB_DISABLE_LINUX_RECOVERY}" != "xtrue" ]; then
-linux_entry "${OS}, Linux ${version} (recovery mode)" \
- "single ${GRUB_CMDLINE_LINUX}"
- fi
+ kfreebsd_entry "${OS}, kFreeBSD ${version}"
- list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
+ list=`echo $list | tr ' ' '\n' | grep -vx $kfreebsd | tr '\n' ' '`
done
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
Am Freitag, den 07.08.2009, 13:39 +0200 schrieb Robert Millan:
> On Thu, Aug 06, 2009 at 11:39:11AM +0200, Felix Zielcke wrote:
> > +for dir in ${pkgdatadir} /boot/grub /usr/share/grub ; do
> > + for basename in unicode unifont ascii; do
> > + path="${dir}/${basename}.pf2"
> > +if is_path_readable_by_grub ${path} > /dev/null ; then
> > + GRUB_FONT_PATH=${path}
> > + else
> > + continue
> > + fi
> > + if [ "${basename}" = "ascii"] ; then
> > + # make sure all our children behave in conformance with ascii..
> > + export LANG=C
> > + fi
> > + break 2
> > + done
> > +done
> > + if [ -z "${GRUB_FONT_PATH}" ] ; then
> > +# fallback to the native terminal for this platform
> > +unset GRUB_TERMINAL_OUTPUT
> > + fi
> > fi
> >;;
> > -esac
> > -
> > -# does our terminal support utf-8 ?
> > -case ${GRUB_TERMINAL_OUTPUT} in
> > - gfxterm) ;;
> >*)
> > # make sure all our children behave in conformance with ascii..
> > export LANG=C
> > - ;;
> > esac
>
> It seems that "export LANG=C" is issued twice?
>
Once if gfxterm gets used and once like before for all other output
terminals.
--
Felix Zielcke
Proud Debian Maintainer
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/2] Relocator framework
On Fri, Aug 7, 2009 at 1:16 PM, Marco Gerards wrote: > Robert Millan writes: > > [...] > >>> Apple linker can't handle 64-bit differences >> >> This seems like a bug. Can GNU binutils be used on MacOS to resolve this? >> >> If it's workable, I'd rather make binutils a build requirement than adding >> more of this (the other APPLE_CC ifdefs will probably need some review too, >> but there's no hurry about that). > > Agreed. GRUB is a GNU project and we can depend on GNU programs. > Especially since we use some GNU extensions. > Apple's compiler is based GCC but binutils aren't and they pose the most of problems. Actualy the most problematic bit was that I didn't know that unless you prefix variable with L_ apple's assembler treats it as global. Adding L_ in this code solves problem. Yves proposed to add a LOCAL(x) macro to symbol.h this way the assembler code is also more readable. I also did further adjustments in this patch to decrease the number of ifdefs but had no time to test it and so couldn't submit it > -- > Marco > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting iso image having syslinux
> > Are you using vga= ? I fixed a bug recently (in SVN) that may cause this > behaviour. > Then I have to reinstall grub from my sqeeeze box to the usb-stick again to see the effect. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Three question about grub2
On Fri, Aug 7, 2009 at 2:48 PM, J.Bakshi wrote: > On Fri, Aug 7, 2009 at 2:26 PM, Felix Zielcke wrote: >> Am Freitag, den 07.08.2009, 14:19 +0530 schrieb J.Bakshi: >>> Hello list, [snip..] >>> 2] In syslinux.cfg we use "TEXT" to display message. How to do the >>> same in grub2 ? >> >> echo command. > Many many thanks. Now memtest86+ is booting without any problem. > Thanks for the other tips. > Wish you a nice time. > [snip./] Coming back with one more question in mind. ( already searched bot no luck yet ). "echo" can dispaly message. Is there ( by any luck ) any command to display message from a file ? Thanks ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting iso image having syslinux
On Fri, Aug 7, 2009 at 5:06 PM, Robert Millan wrote: > On Thu, Aug 06, 2009 at 02:12:58PM +0530, J.Bakshi wrote: >> Hello list, >> >> GRUB2 has a cool feature to boot .iso image. It is really a cool >> option as we can simply put the .iso and test it without making a cd. >> Some of the .iso has syslinux inbuilt. Like live .iso of gparted and >> dban. How can we manage those .iso ? We need to call the syslinux.cfg >> in those distros to get the boot option ( ex- dban ). Could any one >> kindly focus on this issue ? > > There's no proper standard for what you want to do, so a homegrown > approach is the only option. > > Try putting grub.cfg in /, then use "configfile" command on it. > > -- > Robert Millan Thanks , I'll definately give it a try and come back with the feedback. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ntldr support
On Fri, Aug 07, 2009 at 01:17:30PM +0200, Michal Suchanek wrote: > > ntldr is a boot loader like any other and it needs its configuration > and support files to work. Without them it fails (not sure how) but > that is not unexpected. I tend to agree, but in this particular case, it's conceivable that Microsoft didn't expect anyone to do this, and therefore neglected to provide a graceful response. Could anyone test it and report how this behaves? -- 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: bootmgr support
On Thu, Aug 06, 2009 at 06:57:43PM +0200, Yves Blusseau wrote: > Hi all, > > it will be great to have bootmgr support because we can boot directly > windows recovery environement image files (wim). > > We don't need a bootblock, only a valid boot/BCD file so it's possible > to put several WIM files in the same partition like we do with iso > files. Hi, bootmgr uses the same boot protocol as ntldr, check my recent patch for NTLDR load, from a few days ago. -- 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: [PATCH] move functionality of font_path() directly to util/grub-mkconfig.in and prefer unicode.pf2 over ascii.pf2
On Thu, Aug 06, 2009 at 11:39:11AM +0200, Felix Zielcke wrote:
> +for dir in ${pkgdatadir} /boot/grub /usr/share/grub ; do
> + for basename in unicode unifont ascii; do
> + path="${dir}/${basename}.pf2"
> +if is_path_readable_by_grub ${path} > /dev/null ; then
> + GRUB_FONT_PATH=${path}
> + else
> + continue
> + fi
> + if [ "${basename}" = "ascii"] ; then
> + # make sure all our children behave in conformance with ascii..
> + export LANG=C
> + fi
> + break 2
> + done
> +done
> + if [ -z "${GRUB_FONT_PATH}" ] ; then
> +# fallback to the native terminal for this platform
> +unset GRUB_TERMINAL_OUTPUT
> + fi
> fi
>;;
> -esac
> -
> -# does our terminal support utf-8 ?
> -case ${GRUB_TERMINAL_OUTPUT} in
> - gfxterm) ;;
>*)
> # make sure all our children behave in conformance with ascii..
> export LANG=C
> - ;;
> esac
It seems that "export LANG=C" is issued twice?
--
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: booting iso image having syslinux
On Thu, Aug 06, 2009 at 05:18:22PM +0530, J.Bakshi wrote: > Thanks for your kind guidance. > The kernel path is correct. But after getting your response, I have > downloaded the iso again and overwrite the existing one in usb-stick. > Also check the md5sum and it is correct. And something *NEW* has > happend this time. No more error like before ( invalid magic number ) > . Though not sucees yet. Now grub display "Linux-bzimage" and just > stick there. No further progress. Are you using vga= ? I fixed a bug recently (in SVN) that may cause this behaviour. -- 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: booting iso image having syslinux
On Thu, Aug 06, 2009 at 02:12:58PM +0530, J.Bakshi wrote: > Hello list, > > GRUB2 has a cool feature to boot .iso image. It is really a cool > option as we can simply put the .iso and test it without making a cd. > Some of the .iso has syslinux inbuilt. Like live .iso of gparted and > dban. How can we manage those .iso ? We need to call the syslinux.cfg > in those distros to get the boot option ( ex- dban ). Could any one > kindly focus on this issue ? There's no proper standard for what you want to do, so a homegrown approach is the only option. Try putting grub.cfg in /, then use "configfile" command on it. -- 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: New maintainers
On Thu, Aug 06, 2009 at 12:09:46AM +0100, Carles Pina i Estany wrote: > > Hi, > > Ops, of course this had to be private. I'm going to translate. :-) > > felicitats Robert! > > congrats Robert! Gràcies / Thanks ;-) > > Aviat tornaré a posar-me amb el tema del gettext, segurament a partir > > de finals de la setmana vinent > > Soon I will catch again the gettext topic, probably after end of next > week > > I add now: > Hopefully this third attempt will succeed. Some weeks ago I started but > then phcoder went to holidays and after that I have been extra-busy :-( Great! I look forward to it. -- 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: i386/pc/grub-setup.c question
On Wed, Aug 05, 2009 at 01:41:10AM -0700, Seth Goldberg wrote: > Has the blocklist (--force) code path been tested? We don't test it much. If you test it and find problems, feedback is welcome of course (I think Felix already addressed your concern), but we recommend that you avoid reliing on it. There are other sort of problems you may find with blocklists that we can't really provide a solution for. -- 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: [PATCH] use UUID to map system devices to grub devices
On Wed, Aug 05, 2009 at 08:18:29AM +0200, Felix Zielcke wrote: > Am Dienstag, den 04.08.2009, 23:19 +0200 schrieb Robert Millan: > > On Fri, Jul 31, 2009 at 06:26:51PM +0200, Felix Zielcke wrote: > > > > > > If we'd do an arbitrary mapping then `grub-probe -t drive' would show > > > the wrong grub device. > > > But except from this I think that would be okay. > > > > We can never garantee that `grub-probe -t drive' will show the "right" > > drive, > > at least on i386-pc, because we don't know how is BIOS going to order them. > > Yes drive not, but the partition. It's true, but we don't really make the distinction. UUID search will find a filesystem, which is in a partition (usually), and doesn't rely on partitions being reliable. That's fortunate! It means we don't have to commit to partition numbers being reliable, even if they are right now. Because of this (unless I missed something), at the end of the day the unreliability issue you described doesn't translate into any real problem for us. It just adds more to a problem we already solved. > Unfortunately we don't have UUID support on every filesystem we support > like JFS. But I think it's not that commonly used. Adding UUID support to new filesystems is very easy. I did the first ones with just 5-10 minutes of research and a few lines of coding. Would you like to do JFS ? -- 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: [PATCH] ntldr support
2009/8/7 Robert Millan : > On Wed, Aug 05, 2009 at 07:35:32AM +0200, Christian Franke wrote: >> Vladimir 'phcoder' Serbinenko wrote: >>> On Tue, Aug 4, 2009 at 9:27 PM, Robert Millan<...> wrote: >>> After thinking a bit about this, I don't think we want this command in its current form. The problem is it is misleading. It leads the user to think it can load ntldr as a standalone file, but in fact it is reading the PBR behind the scenes. >>> I don't think it's of any problem since ntldr uses this PBR only as >>> superblock to identify the partition. As such I would rather consider >>> this loading as a special case of passing $root, just the form of it >>> is a bit weird >>> >>> >> >> Agree. >> >> A 'ntldr' or 'chainloader --ntldr' command is not mandatory. But it is >> 'nice to have' because it allows to boot even if the boot code (6 >> sectors) in the area behind the PBR is not present for whatever reason. >> See my previsions mail with the test case. > > Ok. Should we settle with 'ntldr' or 'chainloader --ntldr'? In either case, > we should try making them share the code (with ifdef trick if necessary), but > I'm not completely sure. Will users be confused if they put ntldr in an > unrelated partition and try to boot their Windows using it? If ntldr may > hang or crash because of it, then I would go for 'chainloader --ntldr' and > if it fails with a nice error then 'ntldr'. > > Thoughts? > ntldr is a boot loader like any other and it needs its configuration and support files to work. Without them it fails (not sure how) but that is not unexpected. The Microsoft code for loading ntldr is broken wrt disk geometry so replacing the MS loader with a grub chainloader option might allow booting a disk taken from a system where the BIOS interprets the disk geometry differently. This needs some testing, though. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/2] Relocator framework
Robert Millan writes: [...] >> Apple linker can't handle 64-bit differences > > This seems like a bug. Can GNU binutils be used on MacOS to resolve this? > > If it's workable, I'd rather make binutils a build requirement than adding > more of this (the other APPLE_CC ifdefs will probably need some review too, > but there's no hurry about that). Agreed. GRUB is a GNU project and we can depend on GNU programs. Especially since we use some GNU extensions. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: VBE info request bit per Multiboot Specification 1
On Tue, Aug 04, 2009 at 04:49:57PM -0700, Jan Setje-Eilers wrote: > > >> On Tue, Aug 04, 2009 at 01:37:19PM -0400, Francis Shim wrote: >>> Hi, >>> >>> In the Multiboot specifications (version 1), there is a flag that >>> the OS Image can set to request that the boot loader provide VBE >>> information to the OS kernel upon boot up via the Multiboot >>> Information structure. Legacy GRUB (GRUB1) deos not support this >>> feature without a patch that is circulating around in OS >>> development websites; >> >> Hi, >> >> It's not implemented. But since you mention that a patched GRUB >> Legacy supports it, I assume there are a number of OSes that >> implement it. > > FWIW, we've got a prototype VESA console for Solaris that uses that > structure to avoid additional mode switches. In fact, was just looking > into what this looked like in GRUB 2 when someone pointed this thread > out to me. > > If the structure is built up compatibly, things should just work. That's very nice. I assume it follows the Multiboot spec? (in theory, that should suffice, but that's just theory ;-)). >> Can you provide us with a test case? This would make an >> implementation of the GRUB side much easier. >> >> Btw, would you like to work on this? It's not difficult, as we >> already support something analogous in the Linux loader. > > Unless there's another preferred interface (or someone beats us to it). > we'll likely end up filling in. Considering the VBE code that's already > there this is fairly trivial. Very well! -- 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: [PATCH 2/2] Use relocator framework for multiboot1
On Wed, Aug 05, 2009 at 12:20:35PM +0200, Vladimir 'phcoder' Serbinenko wrote: > On Tue, Aug 4, 2009 at 10:56 PM, Robert Millan wrote: > > On Mon, Aug 03, 2009 at 02:10:18PM +0200, Vladimir 'phcoder' Serbinenko > > wrote: > >> +#define GRUB_MULTIBOOT_STACK_SIZE 4096 > >> [...] > >> +#define stack_addr(x) ((void *) ((x) + code_size + > >> cmdline_length + boot_loader_name_length + sizeof (struct > >> grub_multiboot_info) + mmap_length + GRUB_MULTIBOOT_STACK_SIZE)) > > > > What's this stack used for? > Only to set %esp to something that can be used by OS for small things > before they setup their own stack. By multiboot specification OS is > required to setup its stack itself but I suppose many OSes may have > done a mistake of having few push'es before real stack setup Did you find code that has this problem? Note it's much simpler for them to solve it on their side by allocating a stack in their BSS. -- 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: [PATCH 1/2] Relocator framework
On Wed, Aug 05, 2009 at 12:18:17PM +0200, Vladimir 'phcoder' Serbinenko wrote: > >> +#ifdef __x86_64__ > >> +extern grub_uint64_t grub_relocator32_backward_src; > >> +#else > >> +extern grub_uint32_t grub_relocator32_backward_src; > >> +#endif > > > > You could make this a pointer, or grub_uintptr_t > > (the latter we don't yet have, it seems like a good excuse to > > add it if a pointer is not suitable :-)). > grub_addr_t would actually do the job. Ah yes, of course. > > Are you sure moving to movsl is a good idea? Maybe the payload size is not > > 4-aligned. > > > On AFAIK x86 movsl works on unaligned addresses too. I'll recheck But maybe there's some corner case in which we would overwrite something if we copy 3 bytes more than necessary? I didn't check if this would be possible. > >> +#ifdef APPLE_CC > >> + add $(cont0 - base), %eax > >> +#else > >> + add $(cont0 - base), %rax > >> +#endif > > > > What's the issue at hand? Apple assembler [1] can't add an inmediate to > > %rax ? > > > Apple linker can't handle 64-bit differences This seems like a bug. Can GNU binutils be used on MacOS to resolve this? If it's workable, I'd rather make binutils a build requirement than adding more of this (the other APPLE_CC ifdefs will probably need some review too, but there's no hurry about that). -- 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: [PATCH] ntldr support
On Wed, Aug 05, 2009 at 07:35:32AM +0200, Christian Franke wrote: > Vladimir 'phcoder' Serbinenko wrote: >> On Tue, Aug 4, 2009 at 9:27 PM, Robert Millan<...> wrote: >> >>> After thinking a bit about this, I don't think we want this command in >>> its current form. >>> >>> The problem is it is misleading. It leads the user to think it can load >>> ntldr as a standalone file, but in fact it is reading the PBR behind the >>> scenes. >>> >>> >> I don't think it's of any problem since ntldr uses this PBR only as >> superblock to identify the partition. As such I would rather consider >> this loading as a special case of passing $root, just the form of it >> is a bit weird >> >> > > Agree. > > A 'ntldr' or 'chainloader --ntldr' command is not mandatory. But it is > 'nice to have' because it allows to boot even if the boot code (6 > sectors) in the area behind the PBR is not present for whatever reason. > See my previsions mail with the test case. Ok. Should we settle with 'ntldr' or 'chainloader --ntldr'? In either case, we should try making them share the code (with ifdef trick if necessary), but I'm not completely sure. Will users be confused if they put ntldr in an unrelated partition and try to boot their Windows using it? If ntldr may hang or crash because of it, then I would go for 'chainloader --ntldr' and if it fails with a nice error then 'ntldr'. Thoughts? -- 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: [PATCH] multiboot on EFI
On Wed, Aug 05, 2009 at 12:33:56PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> static grub_err_t
> >> grub_multiboot_boot (void)
> >> {
> >> +#ifdef GRUB_MACHINE_EFI
> >> + if (! grub_efi_finish_boot_services ())
> >> + grub_fatal ("cannot exit boot services");
> >> +#endif
> >
> > grub_fatal() terminates GRUB. I suggest you just error out instead, so that
> > user can try other things.
> >
> It's how it's done in efi/linux.c and according to EFI spec it can't
> fail in this code. But I agree with you that both instances should be
> changed
What does the spec say? If after grub_efi_finish_boot_services() exits with
error EFI is inoperative, we wouldn't be able to print this message.
OTOH, sometimes specs are overzealous about what implementations can and can't
do. If this requirement is gratuitous, we don't have to follow it.
> >> - grub_loader_set (grub_multiboot_boot, grub_multiboot_unload, 1);
> >> + grub_loader_set (grub_multiboot_boot, grub_multiboot_unload, 0);
> >
> > This breaks text-mode payloads when they're loaded from gfxterm.
> >
> Ok I will make it use the modesetting as linux.c does. text-mode only
> payloads are broken on EFI anyway
I was concerned with text-mode payloads on BIOS, coreboot, etc. When you pass
0, grub_machine_fini()/grub_console_fini() is not reached, so GRUB won't switch
to text mode when loading them.
(Btw this API is so awkward because of the way it has evolved. I think it'd be
a good idea to simply call grub_console_fini() from loaders when they have to)
> since AFAIK no real EFI machine has
> VGA console available
Does Tianocore/QEMU have VGA? I assume it is not forbidden to provide it
in EFI systems, as it can be found in e.g. coreboot.
> unless we find a way to load one without loading
> BIOS emulation. Bean may know more.
VGA doesn't need BIOS calls. BIOS provides disk and keyboard, which the
VGA ROM doesn't need, so the VGA ROM can be run standalone. This
is already done by coreboot, and by GRUB in the i386-qemu port (it
can be done by switching to real mode and call $0xc000, $0x3).
--
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: Three question about grub2
On Fri, Aug 7, 2009 at 2:26 PM, Felix Zielcke wrote:
> Am Freitag, den 07.08.2009, 14:19 +0530 schrieb J.Bakshi:
>> Hello list,
>>
>> I am collecting some toolkits in my usb-stick powered with grub2. I
>> installed grub2 in this stick from my debian squeeze box. During grub
>> configuration some question has developed in my mind and I might be
>> permitted to ask those in this list.
>>
>> 1] I am trying to boot the latest memtest86+ (v2.11) with grub2 as
>>
>> `
>> menuentry "memtest86+-2.11"
>> {
>> set root=(hd0,2)
>> linux /memtest86+-2.11.bin
>> }
>> ```
>>
>> but grub reports
>>
>>
>> zImage doesn't suppoert 32-bit boot (try with linux16)
>> ```
>>
>> I did some googling with this error but haven't found any solution.
>> What does it mean and how can I fix it ?
>
> grub tells you.
> Use linux16 /memtest86+-2.11.bin
>
>> 2] In syslinux.cfg we use "TEXT" to display message. How to do the
>> same in grub2 ?
>
> echo command.
>
>> 3] I have seen some distro has keyboard interactive feature in GRUB.
>> Like "press F2" for help etc. There should be a file with the required
>> messages to display. But how to bind it with F2 key within grub
>> configuration to make it work ?
>
> Official grub2 doestn't have such a feature.
> I don't know if Colin Bennet implemented this with his theme support or
> if the screenshots there just show how it could be displayed if there
> were such a feature.
>
>> I will be very grateful if someone kindly explain these. Also like to
>> know if any good doc is available.
>
> All avaible documentation is in the official wiki http://grub.enbug.org
>
Many many thanks. Now memtest86+ is booting without any problem.
Thanks for the other tips.
Wish you a nice time.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Three question about grub2
Am Freitag, den 07.08.2009, 14:19 +0530 schrieb J.Bakshi:
> Hello list,
>
> I am collecting some toolkits in my usb-stick powered with grub2. I
> installed grub2 in this stick from my debian squeeze box. During grub
> configuration some question has developed in my mind and I might be
> permitted to ask those in this list.
>
> 1] I am trying to boot the latest memtest86+ (v2.11) with grub2 as
>
> `
> menuentry "memtest86+-2.11"
> {
> set root=(hd0,2)
> linux /memtest86+-2.11.bin
> }
> ```
>
> but grub reports
>
>
> zImage doesn't suppoert 32-bit boot (try with linux16)
> ```
>
> I did some googling with this error but haven't found any solution.
> What does it mean and how can I fix it ?
grub tells you.
Use linux16 /memtest86+-2.11.bin
> 2] In syslinux.cfg we use "TEXT" to display message. How to do the
> same in grub2 ?
echo command.
> 3] I have seen some distro has keyboard interactive feature in GRUB.
> Like "press F2" for help etc. There should be a file with the required
> messages to display. But how to bind it with F2 key within grub
> configuration to make it work ?
Official grub2 doestn't have such a feature.
I don't know if Colin Bennet implemented this with his theme support or
if the screenshots there just show how it could be displayed if there
were such a feature.
> I will be very grateful if someone kindly explain these. Also like to
> know if any good doc is available.
All avaible documentation is in the official wiki http://grub.enbug.org
--
Felix Zielcke
Proud Debian Maintainer
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Three question about grub2
Hello list,
I am collecting some toolkits in my usb-stick powered with grub2. I
installed grub2 in this stick from my debian squeeze box. During grub
configuration some question has developed in my mind and I might be
permitted to ask those in this list.
1] I am trying to boot the latest memtest86+ (v2.11) with grub2 as
`
menuentry "memtest86+-2.11"
{
set root=(hd0,2)
linux /memtest86+-2.11.bin
}
```
but grub reports
zImage doesn't suppoert 32-bit boot (try with linux16)
```
I did some googling with this error but haven't found any solution.
What does it mean and how can I fix it ?
2] In syslinux.cfg we use "TEXT" to display message. How to do the
same in grub2 ?
3] I have seen some distro has keyboard interactive feature in GRUB.
Like "press F2" for help etc. There should be a file with the required
messages to display. But how to bind it with F2 key within grub
configuration to make it work ?
I will be very grateful if someone kindly explain these. Also like to
know if any good doc is available.
Thanks
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
