fbcondecor failed to work because, I think, of a missing patch in klibc. Reproducible: Always When emerging media-gfx/splashutils-1.5.2.1, I get following message: * The kernel tree against which dev-libs/klibc was built was not patched * with a compatible version of fbcondecor. Splashutils will be compiled * without fbcondecor support (i.e. verbose mode will not work). Then, when I start fbcondecor, the following happens: fbcondecor | * Setting framebuffer console images ... fbcondecor |/etc/init.d/fbcondecor: line 43: /sbin/fbcondecor_ctl: No such file or directory fbcondecor |/etc/init.d/fbcondecor: line 43: /sbin/fbcondecor_ctl: No such file or directory fbcondecor |/etc/init.d/fbcondecor: line 15: /sbin/fbcondecor_ctl: No such file or directory fbcondecor | * Failed to set background image on tty2 fbcondecor | * ERROR: fbcondecor failed to start I have the latest klibc available for ~amd64: klibc-1.5.7-r2 My emerge --info: Portage 2.1.3.19 (default-linux/amd64/2007.0, gcc-4.2.2, glibc-2.7-r0, 2.6.23-tuxonice x86_64) ================================================================= System uname: 2.6.23-tuxonice x86_64 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Timestamp of tree: Sat, 17 Nov 2007 22:16:01 +0000 app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r6, 2.5.1-r3 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0_rc6 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r1 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=nocona -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.modulix.net/gentoo/ http://gentoo.mneisen.org/ " MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/xeffects" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl acpi alsa amd64 berkdb bitmap-fonts caps cli cracklib crypt dbus doc dri emacs examples fortran gdbm gpm gtk hal iconv isdnlog jpeg latex lm_sensors midi mmx mudflap ncurses nls nptl nptlonly nvidia opengl openmp pam pcre perl png pppd python qt readline reflection session spl sse sse2 ssl tcpd tetex threads truetype truetype-fonts type1-fonts unicode v4l v4l2 xinerama xorg xv xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="vmware nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Recompile klibc against uvesafb-enabled kernel and try again.
(In reply to comment #1) > Recompile klibc against uvesafb-enabled kernel and try again. > Well problem is still there. Here is what I did: I activated uvesafb and removed the vesafb from my kernel then emerged v86d, and updated my grub.conf. Finally, I rebooted in this new kernel and checked that uvesafb was running: dmesg said: [ 10.503337] uvesafb: NVIDIA Corporation, G86 Board - thurman0, Chip Rev , OEM: NVIDIA, VBE v3.0 [ 10.595440] uvesafb: VBIOS/hardware doesn't support DDC transfers [ 10.595442] uvesafb: no monitor limits have been set, default refresh rate will be used [ 10.595538] uvesafb: scrolling: redraw [ 11.080259] uvesafb: framebuffer at 0xfb000000, mapped to 0xffffc20004100000, using 8000k, total 14336k [ 11.080261] fb0: VESA VGA frame buffer device and there was a v86d process running. So I assume that uvesafb is correctly installed. Then I reemerged klibc and after that splashutils; but I'm still getting the same message during the emerge step, and the fbcondecor_ctl is still absent.
The problem is caused by the fact that the latest klibc ebuild uses a vanilla kernel tree, not the one installed in /usr/src/linux. We'll have to figure out a way to avoid breaking splashutils. We can either ship the header files along with splashutils or patch the klibc kernel tree with fbcondecor. Robin, what do you think?
spock: is the fbcondecor stuff going into the upstream kernel soon? I want to narrow down the size of the external kernel stuff used by klibc ultimately, which is hard per the previous bugs (at least until upstream klibc starts to package their own kernel headers). If they are likely to change, I think it would be best if you included them with splashutils, esp so that you don't depend on the headers in the upstream klibc if/when they finally ship.
(In reply to comment #4) > spock: is the fbcondecor stuff going into the upstream kernel soon? I want to It is extremely unlikely. > narrow down the size of the external kernel stuff used by klibc ultimately, > which is hard per the previous bugs (at least until upstream klibc starts to > package their own kernel headers). If they are likely to change, I think it > would be best if you included them with splashutils, esp so that you don't > depend on the headers in the upstream klibc if/when they finally ship. The headers are unlikely to change and I hope we'll be able to phase out fbcondecor altogether at some point. I guess shipping the headers with splashutils is in fact the best solution here. I'll thus close this bug when I release a new, fixed version of splashutils.
Fixed in media-gfx/splashutils-1.5.3. Please note that as of 1.5.3, support for the fbcondecor patch is controlled by the 'fbcondecor' USE flag.
