Recompiling the with the stock config breaks framebuffer?

[Dan Alderman]

apt-get install linux-source-2.6.8.1 kernel-package.
cd /usr/src
tar xvfj linux-source-2.6.8.1.tar.bz2
ln -s linux-2.6.8.1 linux
cd linux
cp /boot/config-2.6.8.1-2-386 .config
make-kpkg clean ; make-kpkg --append-to-version=alps --initrd kernel_image

... go for a swim ...

dpkg -i ../kernel-image-2.6.8.1alps_10.00.Custom_i386.deb

reboot

I get the following error from hald when it starts, I do not get this from the
pre installed kernel.

[E] hald.c:199 drop_privileges() : drop_privileges: could not install
capabilities; your kernel lacks capability support, therefore some
features will not be available

I also found that framebuufer ceased to work, appending vga=0x318 results in a
blank screen.

D.

[Matt Zimmerman (mdz)]

You should get that message from hal with the stock kernel as well (I do), but
it doesn't break hal. It's only a warning. (Martin, can we just suppress it?
What functionality is lost without capabilities?)

I'll defer to Herbert on the framebuffer issue, though I would not expect that
to be different from the stock kernel either

[Martin Pitt (pitti)]

(In reply to comment #1)
> You should get that message from hal with the stock kernel as well (I do)

That's odd. I also use the stock kernel (linux-image-2.6.8.1-2-k7) and
capabilities work for me:

$ /sbin/getpcaps `pidof hald`
Capabilities for `5940': = cap_net_admin+ep

The 'capability' and 'commoncap' modules are loaded automatically for me. Aren't
they loaded on your system?

> , but it doesn't break hal. It's only a warning. (Martin, can we just
suppress it?
> What functionality is lost without capabilities?)

CAP_NET_ADMIN is used for detecting the "link" flag of ethernet cards, i. e. if
a cable is plugged in. Since we don't use this flag, it does not really hurt if
hald cannot get this capability.

Currently hal is the only piece of software known to me which actually makes use
of capabilities (gnupg does not need them any more), so this should not break
anything too badly.

We don't really need to suppress this warning. The current versions do not
output anything to syslog any more, to actually see these messages you have to
start hald with --daemon=no in a terminal.

[Matt Zimmerman (mdz)]

Hmm, I was seeing that message previously, but looking now, the module seems to
be autoloaded fine and I don't see any error from hal. It was probably running
an earlier stock kernel before, but I don't think anything changed in this area...

[Martin Pitt (pitti)]

(In reply to comment #2)
> We don't really need to suppress this warning. The current versions do not
> output anything to syslog any more, to actually see these messages you have to
> start hald with --daemon=no in a terminal.

Sorry, I just unloaded the modules manually and saw that this error message
really is displayed. IMHO it does not look so bad and it revealed a flaw in the
module loading, so I would like to ask again whether we should really suppress
the message (which is no big deal; in fact it was me who introduced it).

[Herbert Xu (herbert-gondor)]

(In reply to comment #0)
> I also found that framebuufer ceased to work, appending vga=0x318 results in a
> blank screen.

You need to compile vesafb into the kernel. Building it as a module only works
if you load it. The stock kernels do so by providing a post-install script to
kernel-package.

[Dan Alderman (danalderman)]

I recompiled again so I could get my trackpad working, and still get the same
error, but have been ignoring on your advice. However, when upgrading today I
got these errors from apt:

Errors were encountered while processing:
 hal
 gnome-volume-manager
localepurge: Disk space freed in /usr/share/locale: 31476K
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ack! Something bad happened while installing packages. Trying to recover:
Setting up hal (0.2.98-1ubuntu4) ...
 * Restarting system message bus...
 * Stopping Hardware Abstraction Layer... [ ok ]
 * Starting Hardware Abstraction Layer...
 *:17:27.088 [E] hald.c:301: drop_privileges: could not install capabilit[fail]
run-parts: /etc/dbus-1/event.d/hal exited with return code 1
invoke-rc.d: initscript dbus-1, action "restart" failed.
dpkg: error processing hal (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of gnome-volume-manager:
 gnome-volume-manager depends on hal (>= 0.2.92); however:
  Package hal is not configured yet.
dpkg: error processing gnome-volume-manager (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 hal
 gnome-volume-manager
Press return to continue.

Should I worry about this?

D.

[Dan Alderman (danalderman)]

OK, I rebooted with the stock and did a apt-get -f install to fix things. I get
this error on boot from dbus-1

scutter:/home/dan# /etc/init.d/dbus-1 restart
 * Restarting system message bus...
 * Stopping Hardware Abstraction Layer... [ ok ]
 * Starting Hardware Abstraction Layer...
 *:40:17.476 [E] hald.c:301: drop_privileges: could not install capabilit[fail]
run-parts: /etc/dbus-1/event.d/hal exited with return code 1

This is with my recompiled kernel as stated above, I don't get it with the stock
one. Please let me know if you need any more information

D.

[Dan Alderman (danalderman)]

(In reply to comment #5)
> (In reply to comment #0)
> > I also found that framebuufer ceased to work, appending vga=0x318 results in a
> > blank screen.
>
> You need to compile vesafb into the kernel. Building it as a module only works
> if you load it. The stock kernels do so by providing a post-install script to
> kernel-package.

I have got en entry in /etc/mkinitrd/modules as follows

vesafb

But I still get a blank screen. I tried again as suggested and put the vesafb
into the kernel and that worked. Is this expected behaviour?

D.

[Herbert Xu (herbert-gondor)]

(In reply to comment #8)
> I have got en entry in /etc/mkinitrd/modules as follows
>
> vesafb

Did you rebuild the initrd image after putting it in? Is the vesafb entry in the
initrd image itself?

[Dan Alderman (danalderman)]

(In reply to comment #9)
> (In reply to comment #8)
> > I have got en entry in /etc/mkinitrd/modules as follows
> >
> > vesafb
>
> Did you rebuild the initrd image after putting it in? Is the vesafb entry in the
> initrd image itself?
>

No, I thought it was handled by the scripts, I shall build again and try by
recreating it manually.

Thanks,

D.

[Dan Alderman (danalderman)]

(In reply to comment #2)
> (In reply to comment #1)
> > You should get that message from hal with the stock kernel as well (I do)
>
> That's odd. I also use the stock kernel (linux-image-2.6.8.1-2-k7) and
> capabilities work for me:
>
> $ /sbin/getpcaps `pidof hald`
> Capabilities for `5940': = cap_net_admin+ep
>
> The 'capability' and 'commoncap' modules are loaded automatically for me. Aren't
> they loaded on your system?

They are when I use the stock kernel, they are not when I use the kernel that I
recompiled using the config from /boot for the stock kernel. Am I missing
something from the compile process (as stated in the original report) or is this
a bug?

Thanks,

Dan.

>
> > , but it doesn't break hal. It's only a warning. (Martin, can we just
> suppress it?
> > What functionality is lost without capabilities?)
>
> CAP_NET_ADMIN is used for detecting the "link" flag of ethernet cards, i. e. if
> a cable is plugged in. Since we don't use this flag, it does not really hurt if
> hald cannot get this capability.
>
> Currently hal is the only piece of software known to me which actually makes use
> of capabilities (gnupg does not need them any more), so this should not break
> anything too badly.
>
> We don't really need to suppress this warning. The current versions do not
> output anything to syslog any more, to actually see these messages you have to
> start hald with --daemon=no in a terminal.
>

[Dan Alderman (danalderman)]

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > I have got en entry in /etc/mkinitrd/modules as follows
> > >
> > > vesafb
> >
> > Did you rebuild the initrd image after putting it in? Is the vesafb entry in the
> > initrd image itself?
> >
>

OK, I rebuilt the kernel again with the latest source from the repository and
the current kernel config. I then remade the initrd using mkinitrd after
rebooting with the new kernel and the vesafb entry in /etc/mkinitrd/modules. I
still get a blank screen on reboot with vga=0x318 appended to the kernel options.

Searching the initrd for vesafb...

scutter:/home/dan# strings /boot/initrd.img-2.6.8.1alps | grep vesa
vesafb.ko

It would seem that unless it is actually compiled into the kernel it doesn't work?

Dan.
> No, I thought it was handled by the scripts, I shall build again and try by
> recreating it manually.
>
> Thanks,
>
> D.

[Herbert Xu (herbert-gondor)]

> > The 'capability' and 'commoncap' modules are loaded automatically for me. Aren't
> > they loaded on your system?
>
> They are when I use the stock kernel, they are not when I use the kernel that I
> recompiled using the config from /boot for the stock kernel. Am I missing
> something from the compile process (as stated in the original report) or is this
> a bug?

kernel-package has no support for installing modules by default. The stock
kernel image source uses mechanisms outside kernel-package to do so.

If you're building your own kernel images, you should not try to modularise
things that are necessary for *your* system. If you do choose to build them as
modules, then it is up to you to load them.

[Herbert Xu (herbert-gondor)]

> OK, I rebuilt the kernel again with the latest source from the repository and
> the current kernel config. I then remade the initrd using mkinitrd after
> rebooting with the new kernel and the vesafb entry in /etc/mkinitrd/modules. I
> still get a blank screen on reboot with vga=0x318 appended to the kernel
options.

Load fbcon as well and it should work.

[Dan Alderman (danalderman)]

(In reply to comment #14)
> > OK, I rebuilt the kernel again with the latest source from the repository and
> > the current kernel config. I then remade the initrd using mkinitrd after
> > rebooting with the new kernel and the vesafb entry in /etc/mkinitrd/modules. I
> > still get a blank screen on reboot with vga=0x318 appended to the kernel
> options.
>
> Load fbcon as well and it should work.

Works fine, thanks :-)

So the question now is why I have to force loading of the commoncap and
capability modules when I use my own built kernel via /etc/modules, whereas the
stock kernels don't require this. If I omit it dbus-1 fails to start.

Thanks,

Dan.

[Herbert Xu (herbert-gondor)]

(In reply to comment #15)
> So the question now is why I have to force loading of the commoncap and
> capability modules when I use my own built kernel via /etc/modules, whereas the
> stock kernels don't require this. If I omit it dbus-1 fails to start.

Please see my explanation in #13.

[Martin Pitt (pitti)]

Hi Dan!

(In reply to comment #0)
> I get the following error from hald when it starts, I do not get this from the
> pre installed kernel.
>
> [E] hald.c:199 drop_privileges() : drop_privileges: could not install
> capabilities; your kernel lacks capability support, therefore some
> features will not be available

Just for the records, the most recent hal package only spits out a warning, but
will just run without extended capabilities instead of exiting.

[Herbert Xu (herbert-gondor)]

Dan, do you have any remaining issues with this bug?

[Dan Alderman (danalderman)]

(In reply to comment #18)
> Dan, do you have any remaining issues with this bug?

Nope, think this one is all done now. Thanks Mr Xu.

[Herbert Xu (herbert-gondor)]

Thanks.

[Matt Zimmerman (mdz)]

*** Bug 9746 has been marked as a duplicate of this bug. ***