grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

I wonder why nobody on this list noticed this yet.
Jordi reported this already on Debian a while ago [0]

It fails with `No suitable backend could be found for gfxterm.'
The problem is that gfxterm is used when nothing is explicitly specified
and the fonts were compiled, but the fails because vbe.mod only gets
compiled for i386-pc whereas gfxterm.mod gets compiled for every arches.

I suggest as Jordi to just change the `exit 1' to ´exit 0' and telling
the user that it falls back to native terminal:

diff --git a/util/grub.d/00_header.in b/util/grub.d/00_header.in
index d8fa416..7c6ea39 100644
--- a/util/grub.d/00_header.in
+++ b/util/grub.d/00_header.in
@@ -83,7 +83,7 @@ case x${GRUB_TERMINAL_OUTPUT} in
       fi
     done
     if ! [ "${video_backend}" ] ; then
-      echo "No suitable backend could be found for gfxterm." >&2 ; exit 1
+      echo "No suitable backend could be found for gfxterm, falling back to native terminal." >&2 ; exit 0
     fi
 
     cat << EOF


[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520846
-- 
Felix Zielcke

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Pavel Roskin]

On Wed, 2009-06-03 at 11:43 +0200, Felix Zielcke wrote:
> I wonder why nobody on this list noticed this yet.
> Jordi reported this already on Debian a while ago [0]
> 
> It fails with `No suitable backend could be found for gfxterm.'
> The problem is that gfxterm is used when nothing is explicitly specified
> and the fonts were compiled, but the fails because vbe.mod only gets
> compiled for i386-pc whereas gfxterm.mod gets compiled for every arches.

It looks like a conflict between grub-mkconfig and 00_header.
grub-mkconfig sets GRUB_TERMINAL_OUTPUT to gfxterm because gfxterm.mod
is present, but 00_header refuses to use it because vbe.mod is absent.

Or maybe Debian sets GRUB_TERMINAL_OUTPUT to gfxterm somewhere.

> I suggest as Jordi to just change the `exit 1' to ´exit 0' and telling
> the user that it falls back to native terminal:

I believe it's a wrong fix, as it would not prevent adding the gfxterm
code to grub.cfg.

I believe the fix belongs to grub-mkconfig (if it's not a Debian
specific issue).  Setting defaults in grub-mkconfig should be done very
carefully, as the numbered scripts treat those defaults as explicit
requests by the user.

-- 
Regards,
Pavel Roskin

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

Am Mittwoch, den 03.06.2009, 16:55 -0400 schrieb Pavel Roskin:
> On Wed, 2009-06-03 at 11:43 +0200, Felix Zielcke wrote:
> > I wonder why nobody on this list noticed this yet.
> > Jordi reported this already on Debian a while ago [0]
> > 
> > It fails with `No suitable backend could be found for gfxterm.'
> > The problem is that gfxterm is used when nothing is explicitly specified
> > and the fonts were compiled, but the fails because vbe.mod only gets
> > compiled for i386-pc whereas gfxterm.mod gets compiled for every arches.
> 
> It looks like a conflict between grub-mkconfig and 00_header.
> grub-mkconfig sets GRUB_TERMINAL_OUTPUT to gfxterm because gfxterm.mod
> is present, but 00_header refuses to use it because vbe.mod is absent.
> 
> Or maybe Debian sets GRUB_TERMINAL_OUTPUT to gfxterm somewhere.

No, by default we don't set GRUB_TERMINAL_OUTPUT at all.

> > I suggest as Jordi to just change the `exit 1' to ´exit 0' and telling
> > the user that it falls back to native terminal:
> 
> I believe it's a wrong fix, as it would not prevent adding the gfxterm
> code to grub.cfg.

Yes it won't. It would only prevent it from completely failing if
gfxterm isn't avaible.

> I believe the fix belongs to grub-mkconfig (if it's not a Debian
> specific issue).  Setting defaults in grub-mkconfig should be done very
> carefully, as the numbered scripts treat those defaults as explicit
> requests by the user.

So you would prefer something like the attached patch?
Though then we'll need to tell people to explicit enable gfxterm.

-- 
Felix Zielcke

[-- Attachment #2: mkconfig-gfxterm.patch --]
[-- Type: text/x-patch, Size: 754 bytes --]

2009-06-03  Felix Zielcke  <fzielcke@z-51.de>

	    * util/grub-mkconfig.in: Don't use gfxterm by default if not
	    explicit specified by the user.

diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index ff92590..8f84074 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -137,13 +137,7 @@ if [ "x${GRUB_TERMINAL}" != "x" ] ; then
 fi
 
 case x${GRUB_TERMINAL_OUTPUT} in
-  x)
-    # If this platform supports gfxterm, try to use it.
-    if test -e ${grub_prefix}/gfxterm.mod ; then
-      GRUB_TERMINAL_OUTPUT=gfxterm
-    fi
-  ;;
-  xconsole | xserial | xofconsole | xgfxterm) ;;
+  x | xconsole | xserial | xofconsole | xgfxterm) ;;
   *) echo "Invalid output terminal \"${GRUB_TERMINAL_OUTPUT}\"" >&2 ; exit 1 ;;
 esac
 

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

Am Donnerstag, den 04.06.2009, 00:11 +0200 schrieb Felix Zielcke:
> Am Mittwoch, den 03.06.2009, 16:55 -0400 schrieb Pavel Roskin:
> > On Wed, 2009-06-03 at 11:43 +0200, Felix Zielcke wrote:
> > > I wonder why nobody on this list noticed this yet.
> > > Jordi reported this already on Debian a while ago [0]
> > > 
> > > It fails with `No suitable backend could be found for gfxterm.'
> > > The problem is that gfxterm is used when nothing is explicitly specified
> > > and the fonts were compiled, but the fails because vbe.mod only gets
> > > compiled for i386-pc whereas gfxterm.mod gets compiled for every arches.
> > 
> > It looks like a conflict between grub-mkconfig and 00_header.
> > grub-mkconfig sets GRUB_TERMINAL_OUTPUT to gfxterm because gfxterm.mod
> > is present, but 00_header refuses to use it because vbe.mod is absent.
> > 
> > Or maybe Debian sets GRUB_TERMINAL_OUTPUT to gfxterm somewhere.
> 
> No, by default we don't set GRUB_TERMINAL_OUTPUT at all.
> 
> > > I suggest as Jordi to just change the `exit 1' to ´exit 0' and telling
> > > the user that it falls back to native terminal:
> > 
> > I believe it's a wrong fix, as it would not prevent adding the gfxterm
> > code to grub.cfg.
> 
> Yes it won't. It would only prevent it from completely failing if
> gfxterm isn't avaible.
> 
> > I believe the fix belongs to grub-mkconfig (if it's not a Debian
> > specific issue).  Setting defaults in grub-mkconfig should be done very
> > carefully, as the numbered scripts treat those defaults as explicit
> > requests by the user.
> 
> So you would prefer something like the attached patch?
> Though then we'll need to tell people to explicit enable gfxterm.

Pavel? Seems like you missed my mail.
-- 
Felix Zielcke

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Vladimir 'phcoder' Serbinenko]

On Thu, Jun 4, 2009 at 12:11 AM, Felix Zielcke<fzielcke@z-51.de> wrote:
> Am Mittwoch, den 03.06.2009, 16:55 -0400 schrieb Pavel Roskin:
>> On Wed, 2009-06-03 at 11:43 +0200, Felix Zielcke wrote:
>> > I wonder why nobody on this list noticed this yet.
>> > Jordi reported this already on Debian a while ago [0]
>> >
>> > It fails with `No suitable backend could be found for gfxterm.'
>> > The problem is that gfxterm is used when nothing is explicitly specified
>> > and the fonts were compiled, but the fails because vbe.mod only gets
>> > compiled for i386-pc whereas gfxterm.mod gets compiled for every arches.
>>
>> It looks like a conflict between grub-mkconfig and 00_header.
>> grub-mkconfig sets GRUB_TERMINAL_OUTPUT to gfxterm because gfxterm.mod
>> is present, but 00_header refuses to use it because vbe.mod is absent.
>>
>> Or maybe Debian sets GRUB_TERMINAL_OUTPUT to gfxterm somewhere.
>
> No, by default we don't set GRUB_TERMINAL_OUTPUT at all.
The correct solution would be to check the presence of graphical
backend and base the default on it. Or even better is to make the
default depend on platform. It would solve the situations in which
video backend is available but known to cause problems
>
>> > I suggest as Jordi to just change the `exit 1' to ´exit 0' and telling
>> > the user that it falls back to native terminal:
>>
>> I believe it's a wrong fix, as it would not prevent adding the gfxterm
>> code to grub.cfg.
>
> Yes it won't. It would only prevent it from completely failing if
> gfxterm isn't avaible.
>
>> I believe the fix belongs to grub-mkconfig (if it's not a Debian
>> specific issue).  Setting defaults in grub-mkconfig should be done very
>> carefully, as the numbered scripts treat those defaults as explicit
>> requests by the user.
>
> So you would prefer something like the attached patch?
> Though then we'll need to tell people to explicit enable gfxterm.
>
> --
> Felix Zielcke
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Pavel Roskin]

Quoting Felix Zielcke <fzielcke@z-51.de>:

>> So you would prefer something like the attached patch?
>> Though then we'll need to tell people to explicit enable gfxterm.
>
> Pavel? Seems like you missed my mail.

No, it's still in my INBOX.  The patch looks reasonable, but I didn't  
have a chance to test it yet.

-- 
Regards,
Pavel Roskin

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

Am Donnerstag, den 11.06.2009, 18:09 +0200 schrieb Vladimir 'phcoder'
Serbinenko:
> On Thu, Jun 4, 2009 at 12:11 AM, Felix Zielcke<fzielcke@z-51.de> wrote:
> > Am Mittwoch, den 03.06.2009, 16:55 -0400 schrieb Pavel Roskin:
> >> On Wed, 2009-06-03 at 11:43 +0200, Felix Zielcke wrote:
> >> > I wonder why nobody on this list noticed this yet.
> >> > Jordi reported this already on Debian a while ago [0]
> >> >
> >> > It fails with `No suitable backend could be found for gfxterm.'
> >> > The problem is that gfxterm is used when nothing is explicitly specified
> >> > and the fonts were compiled, but the fails because vbe.mod only gets
> >> > compiled for i386-pc whereas gfxterm.mod gets compiled for every arches.
> >>
> >> It looks like a conflict between grub-mkconfig and 00_header.
> >> grub-mkconfig sets GRUB_TERMINAL_OUTPUT to gfxterm because gfxterm.mod
> >> is present, but 00_header refuses to use it because vbe.mod is absent.
> >>
> >> Or maybe Debian sets GRUB_TERMINAL_OUTPUT to gfxterm somewhere.
> >
> > No, by default we don't set GRUB_TERMINAL_OUTPUT at all.
> The correct solution would be to check the presence of graphical
> backend and base the default on it. Or even better is to make the
> default depend on platform. It would solve the situations in which
> video backend is available but known to cause problems

Pavel already wanted that gfxterm isn't anymore the default but didn't
replied yet to my other mail about it.

> >
> >> > I suggest as Jordi to just change the `exit 1' to ´exit 0' and telling
> >> > the user that it falls back to native terminal:
> >>
> >> I believe it's a wrong fix, as it would not prevent adding the gfxterm
> >> code to grub.cfg.
> >
> > Yes it won't. It would only prevent it from completely failing if
> > gfxterm isn't avaible.
> >
> >> I believe the fix belongs to grub-mkconfig (if it's not a Debian
> >> specific issue).  Setting defaults in grub-mkconfig should be done very
> >> carefully, as the numbered scripts treat those defaults as explicit
> >> requests by the user.
> >
> > So you would prefer something like the attached patch?
> > Though then we'll need to tell people to explicit enable gfxterm.
> >
> > --
> > Felix Zielcke
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> 
> 
> 


-- 
Felix Zielcke

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

Am Donnerstag, den 11.06.2009, 21:09 -0400 schrieb Pavel Roskin:
> Quoting Felix Zielcke <fzielcke@z-51.de>:
> 
> >> So you would prefer something like the attached patch?
> >> Though then we'll need to tell people to explicit enable gfxterm.
> >
> > Pavel? Seems like you missed my mail.
> 
> No, it's still in my INBOX.  The patch looks reasonable, but I didn't  
> have a chance to test it yet.
> 

So what do we do know with this?
If we're going to make gfxterm not the default then I think it would be
good to have this changed before 1.97 is released.

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Pavel Roskin]

On Wed, 2009-07-22 at 13:04 +0200, Felix Zielcke wrote:
> Am Donnerstag, den 11.06.2009, 18:09 +0200 schrieb Vladimir 'phcoder'
> Serbinenko:
> > The correct solution would be to check the presence of graphical
> > backend and base the default on it. Or even better is to make the
> > default depend on platform. It would solve the situations in which
> > video backend is available but known to cause problems
> 
> Pavel already wanted that gfxterm isn't anymore the default but didn't
> replied yet to my other mail about it.

I'm sorry, I'm very busy these days.  I don't know what message you are
talking about, but I still have a lot of mail to read.

I don't insist on changing the default, as long as GRUB behaves
correctly.  I have verified that setting GRUB_TERMINAL_OUTPUT=console
in /usr/local/etc/default/grub would disable gfxterm, and that should be
OK.

The only problem I see right now is that it's not documented in the
textinfo documentation, so that users won't be able to figure it out
without reading the code.

-- 
Regards,
Pavel Roskin

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Vladimir 'phcoder' Serbinenko]

>
> I'm sorry, I'm very busy these days.  I don't know what message you are
> talking about, but I still have a lot of mail to read.
>
> I don't insist on changing the default, as long as GRUB behaves
> correctly.  I have verified that setting GRUB_TERMINAL_OUTPUT=console
> in /usr/local/etc/default/grub would disable gfxterm, and that should be
> OK.
Why not to change default to use console? I understand that distros
may want background image or other beatiful stuff but IMO mainstream
should remain simple and reliable and in this case using gfxterm at
least on some console is less reliable than old and proven console
approach. I'm ok with providing an option to choose gfxterm but I
don't see why it would be default in mainstream
>
> The only problem I see right now is that it's not documented in the
> textinfo documentation, so that users won't be able to figure it out
> without reading the code.
>
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> 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

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Pavel Roskin]

On Fri, 2009-08-14 at 08:44 +0200, Felix Zielcke wrote:
> Am Donnerstag, den 11.06.2009, 21:09 -0400 schrieb Pavel Roskin:
> > Quoting Felix Zielcke <fzielcke@z-51.de>:
> > 
> > >> So you would prefer something like the attached patch?
> > >> Though then we'll need to tell people to explicit enable gfxterm.
> > >
> > > Pavel? Seems like you missed my mail.
> > 
> > No, it's still in my INBOX.  The patch looks reasonable, but I didn't  
> > have a chance to test it yet.
> > 
> 
> So what do we do know with this?
> If we're going to make gfxterm not the default then I think it would be
> good to have this changed before 1.97 is released.

You are right.

I have applied your patch, as there were no objections.  Sorry that it
took so long.

-- 
Regards,
Pavel Roskin

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

Am Dienstag, den 18.08.2009, 13:58 -0400 schrieb Pavel Roskin:
> On Fri, 2009-08-14 at 08:44 +0200, Felix Zielcke wrote:
> > Am Donnerstag, den 11.06.2009, 21:09 -0400 schrieb Pavel Roskin:
> > > Quoting Felix Zielcke <fzielcke@z-51.de>:
> > > 
> > > >> So you would prefer something like the attached patch?
> > > >> Though then we'll need to tell people to explicit enable gfxterm.
> > > >
> > > > Pavel? Seems like you missed my mail.
> > > 
> > > No, it's still in my INBOX.  The patch looks reasonable, but I didn't  
> > > have a chance to test it yet.
> > > 
> > 
> > So what do we do know with this?
> > If we're going to make gfxterm not the default then I think it would be
> > good to have this changed before 1.97 is released.
> 
> You are right.
> 
> I have applied your patch, as there were no objections.  Sorry that it
> took so long.
> 

No problem. Thanks for directly commiting it.
Now I only need to talk with Robert how we deal with this change in
Debian now, so we don't get many complaints :)

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Pavel Roskin]

On Tue, 2009-08-18 at 19:53 +0200, Vladimir 'phcoder' Serbinenko wrote:
> >
> > I'm sorry, I'm very busy these days.  I don't know what message you are
> > talking about, but I still have a lot of mail to read.
> >
> > I don't insist on changing the default, as long as GRUB behaves
> > correctly.  I have verified that setting GRUB_TERMINAL_OUTPUT=console
> > in /usr/local/etc/default/grub would disable gfxterm, and that should be
> > OK.
> Why not to change default to use console? I understand that distros
> may want background image or other beatiful stuff but IMO mainstream
> should remain simple and reliable and in this case using gfxterm at
> least on some console is less reliable than old and proven console
> approach. I'm ok with providing an option to choose gfxterm but I
> don't see why it would be default in mainstream

Done.  Sorry, I posted my reply before I found the message Felix was
referring to.

-- 
Regards,
Pavel Roskin

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Michal Suchanek]

2009/8/18 Felix Zielcke <fzielcke@z-51.de>:
> Am Dienstag, den 18.08.2009, 13:58 -0400 schrieb Pavel Roskin:
>> On Fri, 2009-08-14 at 08:44 +0200, Felix Zielcke wrote:
>> > Am Donnerstag, den 11.06.2009, 21:09 -0400 schrieb Pavel Roskin:
>> > > Quoting Felix Zielcke <fzielcke@z-51.de>:
>> > >
>> > > >> So you would prefer something like the attached patch?
>> > > >> Though then we'll need to tell people to explicit enable gfxterm.
>> > > >
>> > > > Pavel? Seems like you missed my mail.
>> > >
>> > > No, it's still in my INBOX.  The patch looks reasonable, but I didn't
>> > > have a chance to test it yet.
>> > >
>> >
>> > So what do we do know with this?
>> > If we're going to make gfxterm not the default then I think it would be
>> > good to have this changed before 1.97 is released.
>>
>> You are right.
>>
>> I have applied your patch, as there were no objections.  Sorry that it
>> took so long.
>>
>
> No problem. Thanks for directly commiting it.
> Now I only need to talk with Robert how we deal with this change in
> Debian now, so we don't get many complaints :)

Just add the option into the defaults file on i386 and amd64.

Should be easy to check and fix up when building the package.

The package upgrade should offer the option to update the config. At
worst the users will see console only if they refuse the update.

Thanks

Michal

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Robert Millan]

On Tue, Aug 18, 2009 at 07:53:30PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >
> > I'm sorry, I'm very busy these days.  I don't know what message you are
> > talking about, but I still have a lot of mail to read.
> >
> > I don't insist on changing the default, as long as GRUB behaves
> > correctly.  I have verified that setting GRUB_TERMINAL_OUTPUT=console
> > in /usr/local/etc/default/grub would disable gfxterm, and that should be
> > OK.
> Why not to change default to use console? I understand that distros
> may want background image or other beatiful stuff but IMO mainstream
> should remain simple and reliable and in this case using gfxterm at
> least on some console is less reliable than old and proven console
> approach. I'm ok with providing an option to choose gfxterm but I
> don't see why it would be default in mainstream

The eye candy is nice but not so important.  For me, gfxterm should be
default on platforms where it's available, because it implements UTF-8,
which is necessary to support l10n.

-- 
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."

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Pavel Roskin]

On Wed, 2009-08-19 at 17:18 +0200, Robert Millan wrote:

> The eye candy is nice but not so important.  For me, gfxterm should be
> default on platforms where it's available, because it implements UTF-8,
> which is necessary to support l10n.

Fine with me.   Just please don't rely on existence of modules.

-- 
Regards,
Pavel Roskin

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Vladimir 'phcoder' Serbinenko]

On Fri, Aug 21, 2009 at 12:18 AM, Pavel Roskin<proski@gnu.org> wrote:
> On Wed, 2009-08-19 at 17:18 +0200, Robert Millan wrote:
>
>> The eye candy is nice but not so important.  For me, gfxterm should be
>> default on platforms where it's available, because it implements UTF-8,
>> which is necessary to support l10n.
>
> Fine with me.   Just please don't rely on existence of modules.
gfxterm is currently slow and may account for sluggish user experience
(just type lsmod in qemu with grub-mkrescue image in gfxterm mode). I
have few patches to optimise it a bit. (like faster font blitting)
>
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> 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

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Michal Suchanek]

2009/8/21 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
> On Fri, Aug 21, 2009 at 12:18 AM, Pavel Roskin<proski@gnu.org> wrote:
>> On Wed, 2009-08-19 at 17:18 +0200, Robert Millan wrote:
>>
>>> The eye candy is nice but not so important.  For me, gfxterm should be
>>> default on platforms where it's available, because it implements UTF-8,
>>> which is necessary to support l10n.
>>
>> Fine with me.   Just please don't rely on existence of modules.
> gfxterm is currently slow and may account for sluggish user experience
> (just type lsmod in qemu with grub-mkrescue image in gfxterm mode). I
> have few patches to optimise it a bit. (like faster font blitting)

Slow performance in qemu should not be deciding factor for features
that are enabled in release binaries.

However, displaying some logo in graphics mode so that people realize
they are in fact seeing graphics might help.

Thanks

Michal

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Am Donnerstag, den 20.08.2009, 18:18 -0400 schrieb Pavel Roskin:
> On Wed, 2009-08-19 at 17:18 +0200, Robert Millan wrote:
> 
> > The eye candy is nice but not so important.  For me, gfxterm should be
> > default on platforms where it's available, because it implements UTF-8,
> > which is necessary to support l10n.
> 
> Fine with me.   Just please don't rely on existence of modules.
> 

Here's now a patch which moves the check for vbe.mod from 00_header to
grub-mkconfig and enables gfxterm if it's found.

-- 
Felix Zielcke
Proud Debian Maintainer

[-- Attachment #2: gfxterm.patch --]
[-- Type: text/x-patch, Size: 2510 bytes --]

2009-08-23  Felix Zielcke  <fzielcke@z-51.de>

	* util/grub.d/00_header.in: Move check for the video backend of
	gfxterm from here ...
	* util/grub-mkconfig.in: ... to here.  Enable gfxterm if there's
	a suitable video backend.

Index: util/grub.d/00_header.in
===================================================================
--- util/grub.d/00_header.in	(revision 2508)
+++ util/grub.d/00_header.in	(working copy)
@@ -73,23 +73,11 @@ case x${GRUB_TERMINAL_OUTPUT} in
     # Make the font accessible
     prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_FONT_PATH}`
 
-    # Pick a video backend
-    video_backend=
-    for i in vbe ; do
-      if test -e ${grub_prefix}/$i.mod ; then
-        video_backend=$i
-        break
-      fi
-    done
-    if ! [ "${video_backend}" ] ; then
-      echo "No suitable backend could be found for gfxterm." >&2 ; exit 1
-    fi
-
     cat << EOF
 if loadfont `make_system_path_relative_to_its_root ${GRUB_FONT_PATH}` ; then
   set gfxmode=${GRUB_GFXMODE}
   insmod gfxterm
-  insmod ${video_backend}
+  insmod ${GRUB_VIDEO_BACKEND}
   if terminal_output gfxterm ; then true ; else
     # For backward compatibility with versions of terminal.mod that don't
     # understand terminal_output
Index: util/grub-mkconfig.in
===================================================================
--- util/grub-mkconfig.in	(revision 2508)
+++ util/grub-mkconfig.in	(working copy)
@@ -141,7 +141,24 @@ if [ "x${GRUB_TERMINAL}" != "x" ] ; then
 fi
 
 case x${GRUB_TERMINAL_OUTPUT} in
-  x | xconsole | xserial | xofconsole | xgfxterm) ;;
+  x | xgfxterm)
+    # If this platform supports gfxterm, try to use it.
+    if test -e ${grub_prefix}/gfxterm.mod ; then
+      GRUB_VIDEO_BACKEND=
+      for i in vbe ; do
+        if test -e ${grub_prefix}/$i.mod ; then
+          GRUB_VIDEO_BACKEND=$i
+          break
+        fi
+      done
+      if [ -n "${GRUB_VIDEO_BACKEND}" ] ; then
+        GRUB_TERMINAL_OUTPUT=gfxterm
+      elif [ "${GRUB_TERMINAL_OUTPUT}" = "gfxterm" ] ; then
+        echo "No suitable backend could be found for gfxterm." >&2 ; exit 1
+      fi
+    fi
+  ;;
+  xconsole | xserial | xofconsole) ;;
   *) echo "Invalid output terminal \"${GRUB_TERMINAL_OUTPUT}\"" >&2 ; exit 1 ;;
 esac
 
@@ -190,7 +207,8 @@ export GRUB_DEVICE \
   GRUB_DEVICE_BOOT_UUID \
   GRUB_FS \
   GRUB_FONT_PATH \
-  GRUB_PRELOAD_MODULES
+  GRUB_PRELOAD_MODULES \
+  GRUB_VIDEO_BACKEND
 
 # These are optional, user-defined variables.
 export GRUB_DEFAULT \

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Robert Millan]

On Sun, Aug 23, 2009 at 10:22:49AM +0200, Felix Zielcke wrote:
> Am Donnerstag, den 20.08.2009, 18:18 -0400 schrieb Pavel Roskin:
> > On Wed, 2009-08-19 at 17:18 +0200, Robert Millan wrote:
> > 
> > > The eye candy is nice but not so important.  For me, gfxterm should be
> > > default on platforms where it's available, because it implements UTF-8,
> > > which is necessary to support l10n.
> > 
> > Fine with me.   Just please don't rely on existence of modules.
> > 
> 
> Here's now a patch which moves the check for vbe.mod from 00_header to
> grub-mkconfig and enables gfxterm if it's found.

Just a min, I think Pavel's concern about reliing on existence of modules was
resolved with this commit:

2009-08-21  Pavel Roskin  <proski@gnu.org>

        * Makefile.in (install-local): When checking if a file is in the
        build directory, use "test -e" to detect symlinks.

        * Makefile.in (install-local): Remove all files in
        $(DESTDIR)$(pkglibdir) before installing new files there.

Pavel, if you could confirm that you're ok with checking for module
existance, maybe Felix' patch can be made simpler.

-- 
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."

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Robert Millan]

On Sun, Aug 23, 2009 at 01:03:21PM +0200, Robert Millan wrote:
> On Sun, Aug 23, 2009 at 10:22:49AM +0200, Felix Zielcke wrote:
> > Am Donnerstag, den 20.08.2009, 18:18 -0400 schrieb Pavel Roskin:
> > > 
> > > Fine with me.   Just please don't rely on existence of modules.
> > 
> > Here's now a patch which moves the check for vbe.mod from 00_header to
> > grub-mkconfig and enables gfxterm if it's found.
> 
> Just a min, I think Pavel's concern about reliing on existence of modules was
> resolved with this commit:
> 
> 2009-08-21  Pavel Roskin  <proski@gnu.org>
> 
>         * Makefile.in (install-local): When checking if a file is in the
>         build directory, use "test -e" to detect symlinks.
> 
>         * Makefile.in (install-local): Remove all files in
>         $(DESTDIR)$(pkglibdir) before installing new files there.
> 
> Pavel, if you could confirm that you're ok with checking for module
> existance, maybe Felix' patch can be made simpler.

I checked Felix' patch, which checks for module existance, and I
believe that there's currently no problem with it.  This is based on
private conversation with Pavel, which led to the commit I'm quoting
in this mail (see above).

Felix, please go ahead and commit it.  I don't think there's anything
wrong, but if there is we can still fix it afterwards.

-- 
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."

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

Am Dienstag, den 25.08.2009, 21:35 +0200 schrieb Robert Millan:
> On Sun, Aug 23, 2009 at 01:03:21PM +0200, Robert Millan wrote:
> > On Sun, Aug 23, 2009 at 10:22:49AM +0200, Felix Zielcke wrote:
> > > Am Donnerstag, den 20.08.2009, 18:18 -0400 schrieb Pavel Roskin:
> > > > 
> > > > Fine with me.   Just please don't rely on existence of modules.
> > > 
> > > Here's now a patch which moves the check for vbe.mod from 00_header to
> > > grub-mkconfig and enables gfxterm if it's found.
> > 
> > Just a min, I think Pavel's concern about reliing on existence of modules was
> > resolved with this commit:
> > 
> > 2009-08-21  Pavel Roskin  <proski@gnu.org>
> > 
> >         * Makefile.in (install-local): When checking if a file is in the
> >         build directory, use "test -e" to detect symlinks.
> > 
> >         * Makefile.in (install-local): Remove all files in
> >         $(DESTDIR)$(pkglibdir) before installing new files there.
> > 
> > Pavel, if you could confirm that you're ok with checking for module
> > existance, maybe Felix' patch can be made simpler.
> 
> I checked Felix' patch, which checks for module existance, and I
> believe that there's currently no problem with it.  This is based on
> private conversation with Pavel, which led to the commit I'm quoting
> in this mail (see above).
> 
> Felix, please go ahead and commit it.  I don't think there's anything
> wrong, but if there is we can still fix it afterwards.
> 

Commited. I don't have either an idea how to do it differently.

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Pavel Roskin]

On Sun, 2009-08-23 at 13:03 +0200, Robert Millan wrote:

> Pavel, if you could confirm that you're ok with checking for module
> existance, maybe Felix' patch can be made simpler.

Generally, I would prefer not to rely on the existence of modules, as
it's a poor substitute for the knowledge whether they are actually
functional on the target hardware.

But if that's the simplest approach and it solves the original problem
with all architectures other than i386-pc, then I'm fine with it.

-- 
Regards,
Pavel Roskin

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Robert Millan]

On Fri, Sep 11, 2009 at 05:54:19PM -0400, Pavel Roskin wrote:
> On Sun, 2009-08-23 at 13:03 +0200, Robert Millan wrote:
> 
> > Pavel, if you could confirm that you're ok with checking for module
> > existance, maybe Felix' patch can be made simpler.
> 
> Generally, I would prefer not to rely on the existence of modules, as
> it's a poor substitute for the knowledge whether they are actually
> functional on the target hardware.

I suppose we could put that knowledge into *.rmk files (i.e. stop building
gfxterm on platforms that don't have video backends).  But it's a bit
annoying since it forces us to maintain duplicate declarations for 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."

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Felix Zielcke]

Am Samstag, den 12.09.2009, 14:58 +0200 schrieb Robert Millan:
> On Fri, Sep 11, 2009 at 05:54:19PM -0400, Pavel Roskin wrote:
> > On Sun, 2009-08-23 at 13:03 +0200, Robert Millan wrote:
> > 
> > > Pavel, if you could confirm that you're ok with checking for module
> > > existance, maybe Felix' patch can be made simpler.
> > 
> > Generally, I would prefer not to rely on the existence of modules, as
> > it's a poor substitute for the knowledge whether they are actually
> > functional on the target hardware.
> 
> I suppose we could put that knowledge into *.rmk files (i.e. stop building
> gfxterm on platforms that don't have video backends).  But it's a bit
> annoying since it forces us to maintain duplicate declarations for it.
> 

And we'd need to define a fixed video backend for every target, else we
still have to check if there's a suitable one.
I don't see why that would be better then the current method.
And I doubt we can check inside the OS if the avaible video backends
actually work on the machine of the user.

-- 
Felix Zielcke
Proud Debian Maintainer

Re: grub-mkconfig fails on every non i386-pc because of gfxterm/vbe

[Michal Suchanek]

Hello

2009/9/12 Felix Zielcke <fzielcke@z-51.de>:
> Am Samstag, den 12.09.2009, 14:58 +0200 schrieb Robert Millan:
>> On Fri, Sep 11, 2009 at 05:54:19PM -0400, Pavel Roskin wrote:
>> > On Sun, 2009-08-23 at 13:03 +0200, Robert Millan wrote:
>> >
>> > > Pavel, if you could confirm that you're ok with checking for module
>> > > existance, maybe Felix' patch can be made simpler.
>> >
>> > Generally, I would prefer not to rely on the existence of modules, as
>> > it's a poor substitute for the knowledge whether they are actually
>> > functional on the target hardware.
>>
>> I suppose we could put that knowledge into *.rmk files (i.e. stop building
>> gfxterm on platforms that don't have video backends).  But it's a bit
>> annoying since it forces us to maintain duplicate declarations for it.
>>
>
> And we'd need to define a fixed video backend for every target, else we
> still have to check if there's a suitable one.
> I don't see why that would be better then the current method.
> And I doubt we can check inside the OS if the avaible video backends
> actually work on the machine of the user.
>

Perhaps the terminal_output command should fail if the terminal does
not work so we can do something like

for vd in <future video drivers> vbe vga ; do #assuming vga is fixed
 insmod $vd && break
done

for to in gfxterm console ; do
 terminal_output $to && break
done

Also why does gfxterm failing really matter? Shouldn't grub just
continue with console?

Thanks

Michal