Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
* Felix Zielcke [Sun, 10 Aug 2008 01:01:25 +0200]: The new upload for lenny will build-depend on the old version, so hopefully all buildds will then use the lenny version to build the packages. They won't. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
* Felix Zielcke [Sun, 10 Aug 2008 14:22:05 +0200]: Luckly we only need that unifont for amd64 and i386. It isn't a problem for us to upload a binary for both. That is normally frowned upon, but I'm ok if you do that for now, since rebuilds on testing will produce valid packages in any case. But if we build depend on that older version which works for us and the buildds won't use it, then this sounds to me it doestn't get build at all, because then the build depency can't be satisfied? That's correct. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
Am Sonntag, den 10.08.2008, 13:10 +0100 schrieb Adeodato Simó: * Felix Zielcke [Sun, 10 Aug 2008 01:01:25 +0200]: The new upload for lenny will build-depend on the old version, so hopefully all buildds will then use the lenny version to build the packages. They won't. Ok, thanks for your reply. I'm still so new to that `Co-maintaining a Debian package' thing :) Luckly we only need that unifont for amd64 and i386. It isn't a problem for us to upload a binary for both. But if we build depend on that older version which works for us and the buildds won't use it, then this sounds to me it doestn't get build at all, because then the build depency can't be satisfied? I just want to clarify this if we have in the future again such a problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
Am Sonntag, den 10.08.2008, 14:23 +0100 schrieb Adeodato Simó: * Felix Zielcke [Sun, 10 Aug 2008 14:22:05 +0200]: Luckly we only need that unifont for amd64 and i386. It isn't a problem for us to upload a binary for both. That is normally frowned upon, but I'm ok if you do that for now, since rebuilds on testing will produce valid packages in any case. But if we build depend on that older version which works for us and the buildds won't use it, then this sounds to me it doestn't get build at all, because then the build depency can't be satisfied? That's correct. Thanks again that you clarify this for me. Robert probable already knows these things already anyway :) As I wrote that `hopefully buillds use lenny version' I even forgot that he already said we just upload binaries for amd64 and i386 which has the font. Luckly there's now a new unifont-bin which includes it again. I forgot even -proposed-updates. So the buildds are just using the enviroment the packages was uploaded for. There has to be a reason why stable|testing -proposed-updates does exist :) This really makes sense to me now so thanks again to you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
Package: grub-pc
Version: 1.96+20080724-6
Severity: normal
The update-grub script evaluates `font_path` in order to determine
whether GRUB_FONT_PATH can be set to its output. However font_path
doesn't seem to be excutable... Therefore, although $GRUB_TERMINAL
originally came with the nice gfxterm setting, it gets reverted to
console, and there's no longer graphical menu, :(...
It was working nice to me before, not sure what happened...
Javier.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/hda7 / ext3 rw,errors=remount-ro,data=ordered 0 0
/dev/hda5 /boot ext3 rw,errors=continue,data=ordered 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/hda
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/update-grub using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
terminal console
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###
### BEGIN /etc/grub.d/10_linux ###
set root=(hd0,5)
search --fs-uuid --set 82bf8be6-d811-47f4-85f3-953dbf39db1f
menuentry Debian GNU/Linux, linux 2.6.26-1-686 {
linux /vmlinuz-2.6.26-1-686
root=UUID=9cb9b166-e657-43b4-9b0b-acfdecf09510 ro vga=0x318 resume=/dev/hda6
initrd /initrd.img-2.6.26-1-686
}
menuentry Debian GNU/Linux, linux 2.6.26-1-686 (single-user mode) {
linux /vmlinuz-2.6.26-1-686
root=UUID=9cb9b166-e657-43b4-9b0b-acfdecf09510 ro single vga=0x318
initrd /initrd.img-2.6.26-1-686
}
menuentry Debian GNU/Linux, linux 2.6.25-2-686 {
linux /vmlinuz-2.6.25-2-686
root=UUID=9cb9b166-e657-43b4-9b0b-acfdecf09510 ro vga=0x318 resume=/dev/hda6
initrd /initrd.img-2.6.25-2-686
}
menuentry Debian GNU/Linux, linux 2.6.25-2-686 (single-user mode) {
linux /vmlinuz-2.6.25-2-686
root=UUID=9cb9b166-e657-43b4-9b0b-acfdecf09510 ro single vga=0x318
initrd /initrd.img-2.6.25-2-686
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###
*** END /boot/grub/grub.cfg
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages grub-pc depends on:
ii debconf [debconf-2.0]1.5.23 Debian configuration management sy
ii grub-common 1.96+20080724-6 GRand Unified Bootloader, version
ii libc62.7-13 GNU C Library: Shared libraries
ii liblzo2-22.03-1 data compression library
ii libncurses5 5.6+20080804-1 shared libraries for terminal hand
grub-pc recommends no packages.
Versions of packages grub-pc suggests:
pn desktop-base none (no description available)
pn os-prober none (no description available)
-- debconf information:
grub-pc/linux_cmdline: fillme
grub-pc/chainload_from_menu.lst: true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
On Sat, Aug 09, 2008 at 10:49:12AM -0600, Familia Vasquez-Vivas wrote: Package: grub-pc Version: 1.96+20080724-6 Severity: normal The update-grub script evaluates `font_path` in order to determine whether GRUB_FONT_PATH can be set to its output. However font_path doesn't seem to be excutable... Therefore, although $GRUB_TERMINAL originally came with the nice gfxterm setting, it gets reverted to console, and there's no longer graphical menu, :(... It was working nice to me before, not sure what happened... font_path is a shell function, declared in update-grub_lib. Please describe the symptoms of your problem before jumping into conclussions. What is it exactly that you observed? -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
On Sat, Aug 9, 2008 at 1:04 PM, Robert Millan [EMAIL PROTECTED] wrote:
On Sat, Aug 09, 2008 at 10:49:12AM -0600, Familia Vasquez-Vivas wrote:
Package: grub-pc
Version: 1.96+20080724-6
Severity: normal
The update-grub script evaluates `font_path` in order to determine
whether GRUB_FONT_PATH can be set to its output. However font_path
doesn't seem to be excutable... Therefore, although $GRUB_TERMINAL
originally came with the nice gfxterm setting, it gets reverted to
console, and there's no longer graphical menu, :(...
It was working nice to me before, not sure what happened...
font_path is a shell function, declared in update-grub_lib. Please describe
the symptoms of your problem before jumping into conclussions.
What is it exactly that you observed?
update-grub works just fine, except that I no longer get in grub.cfg
the gfxterm stuff (so I no longer get splash image menu). This
happens only in all my i686 boxes, not in the amd64 one... I modified
update-grub several times to identify where the problem was (with my
own debug hooks)... Just before case ${GRUB_TERMINAL} in I included
' echo \${GRUB_TERMINAL} - ${GRUB_TERMINAL} ', and I got
gfxterm. I did exactly the same after that piece of code and I got
console... So I thought that was the issue. To my surprise, this
doesn't seem the case for amd64.
I'm sorry for jumping into conclusions too soon, but after this little
debug I thought that was the issue...
So I'll try a bit further and see if there's a difference in
update-grub that's causing i686 version not to provide me with the
nice graphical menu, :)...
--
Robert Millan
Thanks,
--
Javier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
On Sat, Aug 9, 2008 at 2:31 PM, Javier Vasquez [EMAIL PROTECTED] wrote:
On Sat, Aug 9, 2008 at 1:04 PM, Robert Millan [EMAIL PROTECTED] wrote:
On Sat, Aug 09, 2008 at 10:49:12AM -0600, Familia Vasquez-Vivas wrote:
Package: grub-pc
Version: 1.96+20080724-6
Severity: normal
The update-grub script evaluates `font_path` in order to determine
whether GRUB_FONT_PATH can be set to its output. However font_path
doesn't seem to be excutable... Therefore, although $GRUB_TERMINAL
originally came with the nice gfxterm setting, it gets reverted to
console, and there's no longer graphical menu, :(...
It was working nice to me before, not sure what happened...
font_path is a shell function, declared in update-grub_lib. Please describe
the symptoms of your problem before jumping into conclussions.
What is it exactly that you observed?
update-grub works just fine, except that I no longer get in grub.cfg
the gfxterm stuff (so I no longer get splash image menu). This
happens only in all my i686 boxes, not in the amd64 one... I modified
update-grub several times to identify where the problem was (with my
own debug hooks)... Just before case ${GRUB_TERMINAL} in I included
' echo \${GRUB_TERMINAL} - ${GRUB_TERMINAL} ', and I got
gfxterm. I did exactly the same after that piece of code and I got
console... So I thought that was the issue. To my surprise, this
doesn't seem the case for amd64.
I'm sorry for jumping into conclusions too soon, but after this little
debug I thought that was the issue...
So I'll try a bit further and see if there's a difference in
update-grub that's causing i686 version not to provide me with the
nice graphical menu, :)...
--
Robert Millan
Thanks,
--
Javier
Actually I think my conclusions are not that wrong... With the
following modifications to update-grub:
echo \${GRUB_TERMINAL} before evaluating font_path == ${GRUB_TERMINAL}
case ${GRUB_TERMINAL} in
gfxterm)
echo Next line is output of \`font_path\`:
echo `font_path`
if path=`font_path` ; then
GRUB_FONT_PATH=${path}
else
# fallback to console
GRUB_TERMINAL=console
fi
;;
esac
echo \${GRUB_TERMINAL} after evaluating font_path == ${GRUB_TERMINAL}
I get:
# update-grub
${GRUB_TERMINAL} before evaluating font_path == gfxterm
Next line is output of `font_path`:
${GRUB_TERMINAL} after evaluating font_path == console
Updating /boot/grub/grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.26-1-686
Found initrd image: /boot/initrd.img-2.6.26-1-686
Found linux image: /boot/vmlinuz-2.6.25-2-686
Found initrd image: /boot/initrd.img-2.6.25-2-686
done
So you can actually that it's font_path returning NOTHING the
problem... I thought because NOT being executable, but it might be
something else, but actually font_path returning nothings is causing
the problem. Again this affects all i686 boxes, but not the only
amd64 I have. For the amd64 I get with the same modifications:
# update-grub
${GRUB_TERMINAL} before evaluating font_path == gfxterm
Next line includes `font_path` output:
/usr/share/grub/ascii.pff
${GRUB_TERMINAL} after evaluating font_path == gfxterm
Updating /boot/grub/grub.cfg ...
Found Debian background: debian-blueish-wallpaper-640x480.tga
Found linux image: /boot/vmlinuz-2.6.26-1-amd64
Found initrd image: /boot/initrd.img-2.6.26-1-amd64
Found linux image: /boot/vmlinuz-2.6.25-2-amd64
Found initrd image: /boot/initrd.img-2.6.25-2-amd64
done
And there's a difference in here, since for i686:
# ls /usr/share/grub/
#
So the /usr/share/grub directory is empty, while for amd64 I get:
# ls /usr/share/grub/
ascii.pff unicode.pff
So this might be the problem then... I think this is the further I
can go, it might be that the i686 debian package just didn't include
the /usr/share/grub stuff, and that'd be pretty much it, :)
I hope that's the problem, maybe a quick one to fix...
--
Javier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
tag 494460 pending retitle 494460 i386 builds are missing fonts thanks Am Samstag, den 09.08.2008, 16:44 -0600 schrieb Javier Vasquez: And there's a difference in here, since for i686: # ls /usr/share/grub/ # See 494473 The reason is that the unifont-bin package doestn't provide anymore the file we use to generate the fonts for GRUB. The new upload for lenny will build-depend on the old version, so hopefully all buildds will then use the lenny version to build the packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
On Sat, Aug 9, 2008 at 5:01 PM, Felix Zielcke [EMAIL PROTECTED] wrote: tag 494460 pending retitle 494460 i386 builds are missing fonts thanks Am Samstag, den 09.08.2008, 16:44 -0600 schrieb Javier Vasquez: And there's a difference in here, since for i686: # ls /usr/share/grub/ # See 494473 The reason is that the unifont-bin package doestn't provide anymore the file we use to generate the fonts for GRUB. The new upload for lenny will build-depend on the old version, so hopefully all buildds will then use the lenny version to build the packages. OK, however neither of my boxes (amd64 nor i686) have unifont nor unifont-bin installed (they are not dependencies for grub-pc or grub-common). BTW, on the amd64, I don't have /usr/share/unifont path, as a result that I don't have unifont/unifont-bin installed, and I still have for amd64: % ls /usr/share/grub/ ascii.pff unicode.pff Both the i386 and the amd64 packages seem to have the same versions: http://packages.debian.org/sid/grub-pc Package: grub-pc (1.96+20080724-6) http://packages.debian.org/sid/grub-common amd64 1.96+20080724-6 i386 1.96+20080724-6 So the reason might just be that things are done differently for these 2 architectures, and the bug is i386 exclusive, :)... I'm mentioning this out of my ignorance, since I still don't get how things still work for one architecture and not the other, given that both have the same versions, and both are not depending upon unifont* which I don't have installed in any architecture... So my only guess is that they do things very different then, :). So the clue is then to wait for a new update which would fix things then, I guess? Thanks, -- Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494460: grub-pc: update-grub unable to generate a graphical gfxterm menu
Am Samstag, den 09.08.2008, 17:38 -0600 schrieb Javier Vasquez: So the reason might just be that things are done differently for these 2 architectures, and the bug is i386 exclusive, :)... I'm mentioning this out of my ignorance, since I still don't get how things still work for one architecture and not the other, given that both have the same versions, and both are not depending upon unifont* which I don't have installed in any architecture... So my only guess is that they do things very different then, :). Binary packages are only uploaded for one archicteture, in our case AMD64. For the other architectures buildds are used to create them for us. It's a *build* depency and that's why it's not listed on the binary grub-pc or grub-common package. Robert used the old version of unifont-bin to create the 24-6 upload, whereas the i386 buildd had already used the new one. But this is not the topic of this report so if you still have questions to that better ask on debian-user list or some other place. So the clue is then to wait for a new update which would fix things then, I guess? Yes and that's why this bug is now tagged pending. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
