FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-31-2010, 04:51 PM
Petter Reinholdtsen
 
Default Automatically installing hardware specific packages

For a long time, I have wished the Debian installer would
automatically install the right packages on the servers I have. If it
detect a RAID controller using the cpqarray kernel module, the
cpqarrayd package should be installed. If a RAID controller using the
mptscsih kernel module is detected, the mpt-status package should be
installed. If a i810 compatible video card is detected, the i810switch
package should be installed.

I wrote a draft implementation a few years ago using the discover v2
package, but never found time to integrate it into the installer.
But, since a few days ago, I found time to do this integration. The
daily d-i images install discover automatically and run the required
commands as root to install hardware specific packages automatically
during installation. The command is

aptitude install discover; discover-pkginstall

This will look up USB and PCI IDs found on the machine in the database
provided by the discover-data package, and install any hardware
specific packages detected (after presenting a debconf question which
is hidden at the normal debconf priority).

To get this working out of the box, the discover-data package need to
be updated with mappings from PCI and USB IDs to Debian package names.
I've added a few, but I am sure there are mappings missing.

If you know of some package that should be installed automatically
when some PCI or USB devices are detected, please report them to BTS
and the discover-data package, to get the mappings into Debian before
Squeeze is released.

Are there better ways to do this? Anyone willing to work on it?

Fedora 13 provides PackageKit to install hardware specific packages
after installation. Perhaps we should extend the discover system to
listen to DBus events and install hardware packages also after
installation? Or port PackageKit to Debian and use it instead?

Anyway, a draft system is in d-i at the moment, and I welcome help
with updating the hardware mappings to get more packages installed
automatically by d-i.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2fly6f0ypze.fsf@login2.uio.no">http://lists.debian.org/2fly6f0ypze.fsf@login2.uio.no
 
Old 06-16-2010, 07:33 PM
Petter Reinholdtsen
 
Default Automatically installing hardware specific packages

[Petter Reinholdtsen]
> Are there better ways to do this? Anyone willing to work on it?

One alternative would be to move the information out of the
discover-data package, and into the Packages file instead, similar to
how Iceweasel[1] and Moonlight[2] might find their plugins and codec
packages, and store USB and PCI ids there.

[1] https://wiki.ubuntu.com/FlashExperienceIntrepid
[2] http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight

The idea I got was to add headers like this to the package supporting
specific hardware, and use this information to look up the USB and PCI
ids present in the machine:

Xb-Hardware-Bus-PCI: 1af4:1002
Xb-Hardware-Bus-USB: 1d6b:0001

This way the build system for the X video card packages could extract
the list of PCI devices supported by the driver and include it in the
control file of the package, and the RAID controller packages could
list the supported hardware ids too. It would get rid of the central
hardware->package directory, and probably scale better than the
discover-pkginstall approach.

A problem with this approach is that some packages support a lot of
PCI ids, and another is that some packages support ranges of ids or
classes of devices. Not sure how that is best represented in a
Packages file.

> Fedora 13 provides PackageKit to install hardware specific packages
> after installation. Perhaps we should extend the discover system to
> listen to DBus events and install hardware packages also after
> installation? Or port PackageKit to Debian and use it instead?

Anyone know how this work?

> Anyway, a draft system is in d-i at the moment, and I welcome help
> with updating the hardware mappings to get more packages installed
> automatically by d-i.

I got a bunch of updates, and these are now in the discover-data
package in unstable and testing, but I am sure there are more hardware
specific packages out there, and very much welcome more mappings.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2fl7hlywz4v.fsf@login2.uio.no">http://lists.debian.org/2fl7hlywz4v.fsf@login2.uio.no
 
Old 06-16-2010, 08:13 PM
Julien Cristau
 
Default Automatically installing hardware specific packages

On Wed, Jun 16, 2010 at 21:33:52 +0200, Petter Reinholdtsen wrote:

> The idea I got was to add headers like this to the package supporting
> specific hardware, and use this information to look up the USB and PCI
> ids present in the machine:
>
> Xb-Hardware-Bus-PCI: 1af4:1002
> Xb-Hardware-Bus-USB: 1d6b:0001
>
> This way the build system for the X video card packages could extract
> the list of PCI devices supported by the driver and include it in the
> control file of the package
>
We did something like that in lenny (not in the Packages file, but same
basic idea), to get X to choose the right driver. It turns out it's a
pain to maintain, and doesn't really work all that well. We should just
install xserver-xorg-video-all.

Maybe for other cases it's different, I don't know.

Cheers,
Julien
 
Old 06-16-2010, 08:23 PM
Bjrn Mork
 
Default Automatically installing hardware specific packages

Petter Reinholdtsen <pere@hungry.com> writes:
> [Petter Reinholdtsen]
>> Are there better ways to do this? Anyone willing to work on it?
>
> One alternative would be to move the information out of the
> discover-data package, and into the Packages file instead, similar to
> how Iceweasel[1] and Moonlight[2] might find their plugins and codec
> packages, and store USB and PCI ids there.
>
> [1] https://wiki.ubuntu.com/FlashExperienceIntrepid
> [2] http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight
>
> The idea I got was to add headers like this to the package supporting
> specific hardware, and use this information to look up the USB and PCI
> ids present in the machine:
>
> Xb-Hardware-Bus-PCI: 1af4:1002
> Xb-Hardware-Bus-USB: 1d6b:0001

And subdevice ids and class ids and more buses and ...

> This way the build system for the X video card packages could extract
> the list of PCI devices supported by the driver and include it in the
> control file of the package, and the RAID controller packages could
> list the supported hardware ids too. It would get rid of the central
> hardware->package directory, and probably scale better than the
> discover-pkginstall approach.
>
> A problem with this approach is that some packages support a lot of
> PCI ids, and another is that some packages support ranges of ids or
> classes of devices. Not sure how that is best represented in a
> Packages file.

Why not reuse the module alias syntax for the hardware application
database as well? It allows for a number of different bus
configurations, not only pci and usb, with class matches where
appropriate. And it is a well known syntax. And it buys you easy
direct matching against /sys/devices/.../modalias



Bjrn


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ocfavi9k.fsf@nemi.mork.no">http://lists.debian.org/87ocfavi9k.fsf@nemi.mork.no
 
Old 06-16-2010, 08:23 PM
Petter Reinholdtsen
 
Default Automatically installing hardware specific packages

[Julien Cristau]
> We did something like that in lenny (not in the Packages file, but
> same basic idea), to get X to choose the right driver. It turns out
> it's a pain to maintain, and doesn't really work all that well.

Why was it a pain to maintain?

I can imagine it is a pain if there is no automatic way to extract the
supported ids from the source code (like it is/was with X). But if it
is possible to extract it automatically like is done with kernel
modules, I believe it should not be too hard.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100616202354.GI15182@login2.uio.no">http://lists.debian.org/20100616202354.GI15182@login2.uio.no
 
Old 06-16-2010, 09:09 PM
Josselin Mouette
 
Default Automatically installing hardware specific packages

Le mercredi 16 juin 2010 * 21:33 +0200, Petter Reinholdtsen a écrit :
> > Fedora 13 provides PackageKit to install hardware specific packages
> > after installation. Perhaps we should extend the discover system to
> > listen to DBus events and install hardware packages also after
> > installation? Or port PackageKit to Debian and use it instead?
>
> Anyone know how this work?

PackageKit is not suitable for Debian, but Ubuntu reimplemented the same
D-Bus interface on top of aptdaemon (session-installer). It has recently
entered unstable.

This interface is able to install packages given their name - if it’s
only for that, you can also use aptdaemon directly, the only advantage
is that it’s the same as Fedora’s.

In all cases this implies writing a session daemon that listens to
events when hardware is plugged, and asks the user for conformation
before installing hardware-specific packages. I don’t know whether the
stuff from Fedora can be re-used.

Cheers,
--
.'`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`- […] I will see what I can do for you.” -- Jörg Schilling
 
Old 06-16-2010, 09:11 PM
Julien Cristau
 
Default Automatically installing hardware specific packages

On Wed, Jun 16, 2010 at 22:23:54 +0200, Petter Reinholdtsen wrote:

> [Julien Cristau]
> > We did something like that in lenny (not in the Packages file, but
> > same basic idea), to get X to choose the right driver. It turns out
> > it's a pain to maintain, and doesn't really work all that well.
>
> Why was it a pain to maintain?
>
> I can imagine it is a pain if there is no automatic way to extract the
> supported ids from the source code (like it is/was with X). But if it
> is possible to extract it automatically like is done with kernel
> modules, I believe it should not be too hard.
>
The pci ids were extracted from the source code with awk or sed or
whatever. They were also wrong, because things like matching for a
range of chips [0] or looking for the actual chip id in mmio space
[1] weren't taken into account.

[0] http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_driver.c#n798
[1] http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_driver.c#n717

Cheers,
Julien
 
Old 06-17-2010, 12:23 AM
Ben Hutchings
 
Default Automatically installing hardware specific packages

On Wed, 2010-06-16 at 21:33 +0200, Petter Reinholdtsen wrote:
> [Petter Reinholdtsen]
> > Are there better ways to do this? Anyone willing to work on it?
>
> One alternative would be to move the information out of the
> discover-data package, and into the Packages file instead, similar to
> how Iceweasel[1] and Moonlight[2] might find their plugins and codec
> packages, and store USB and PCI ids there.
>
> [1] https://wiki.ubuntu.com/FlashExperienceIntrepid
> [2] http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight
>
> The idea I got was to add headers like this to the package supporting
> specific hardware, and use this information to look up the USB and PCI
> ids present in the machine:
>
> Xb-Hardware-Bus-PCI: 1af4:1002
> Xb-Hardware-Bus-USB: 1d6b:0001
>
> This way the build system for the X video card packages could extract
> the list of PCI devices supported by the driver and include it in the
> control file of the package, and the RAID controller packages could
> list the supported hardware ids too. It would get rid of the central
> hardware->package directory, and probably scale better than the
> discover-pkginstall approach.
[...]

This probably makes some sense for userland drivers that bind to
specific PCI and USB devices, and for any OOT kernel drivers. For
applications and userland drivers that depend on specific kernel drivers
it would make more sense for the package to specify the kernel driver(s)
and for the package manager to look at which drivers have been loaded
and bound to devices.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 06-22-2010, 11:17 AM
Sebastian Heinlein
 
Default Automatically installing hardware specific packages

On Wed, Jun 16, 2010 at 11:09:32PM +0200, Josselin Mouette wrote:
> Le mercredi 16 juin 2010 * 21:33 +0200, Petter Reinholdtsen a écrit :
> > > Fedora 13 provides PackageKit to install hardware specific packages
> > > after installation. Perhaps we should extend the discover system to
> > > listen to DBus events and install hardware packages also after
> > > installation? Or port PackageKit to Debian and use it instead?
> >
> > Anyone know how this work?

Basically PackageKit is just a common interface and a daemon to handle
transactions. The work is done by backends. The PackageKit daemon just
receives the request for a driver and routes it to the backend.

But you also need some client tools: The always running gpk-update-icon
and the DBus activated gpk-service tools from gnome-packagekit. Both run
in the user session and listen to the session D-Bus. The tools provide the
end user dialogs and guide the user through the installation process:

AFAIK there are currently 3 ways to install drivers/firmware:

* gpk-update-icon which is part of gnome-packagekit monitors
/dev/.udev/firmware-missing
* gpk-update-icon listens to the DeviceAdded signal of hal
* gpk-service provides a InstallPrinterDriver method. I think that it
called by the cups management application

The above clients call the WhatProvides method of the
system PackageKit daemon to query the corresponding packages.
Which is implemented differently by each backend.

I haven't looked at the details of the yum backend which is used by
Fedora. The apt and aptcc backend don't provide any firmware/driver
query capabilities.

Furthermore there is a small tool in packgekit which rebinds devices to
tigger the loading of a recently installed firmware.

> PackageKit is not suitable for Debian, but Ubuntu reimplemented the same
> D-Bus interface on top of aptdaemon (session-installer). It has recently
> entered unstable.

Actually aptdaemon and sessioninstaller are not implemented by "Ubuntu",
but I get a lot of support and patches from Michael Vogt and Matthew
Paul Thomas.

Canonical's software-center is "just" the main user. I started to work
on the projects since I was a little bit frustrated about the design
limits of PackageKit. The packagekit daemon wants to keep things
simple and provide a complete backend for a basic package manager
- including search operations.

In contrast aptdaemon only handles the core methods which require root
privileges - but making use of advanced features (e.g. debconf support,
config file handling and since recently plugins and future cache
calculation). The system DBus interface of aptdaemon is not compatible
with the one of PackageKit.

The search and query operations should be handled by the client
applications since a modern package management GUI needs a lot of
distro specific information, see software-center compared to
gpk-application or kpackagekit.

> This interface is able to install packages given their name - if it’s
> only for that, you can also use aptdaemon directly, the only advantage
> is that it’s the same as Fedora’s.

Sessioninstaller implements the session DBus interface of PackageKit which is
provided by gnome-packagekit and kpackagekit, but uses synaptic or aptdaemon
for the installation. The interfaces should stay compatible in the
future, since third party software is supposed to call the session interface to
install software, plugins, fonts, printer drivers or gstreamer resources.
The system interface should only be called by fully blown package managers.

Sessioninstaller currently supports installing by file name (requires
apt-file), by gstreamer resources and by mime type handler (requires
app-install-data). Printer drivers and fonts are not supported, since
there isn't yet any corresponding infrastructure in Debian or Ubuntu.

If you want to extend the interface we could discuss this on the
PackageKit list. Richard is generally open to improvements.

> In all cases this implies writing a session daemon that listens to
> events when hardware is plugged, and asks the user for conformation
> before installing hardware-specific packages. I don’t know whether the
> stuff from Fedora can be re-used.

I remember vaguely the hermes project of Guadalinex - an Ubuntu
derivate of the Spanish administration. It provided nearly the
same functionality. But it was some years back when I looked at the
code.

Finally there is also jockey of Ubuntu. But I am not familiar
with it.

Cheers,

Sebastian
 
Old 06-24-2010, 08:51 AM
Petter Reinholdtsen
 
Default Automatically installing hardware specific packages

[Sebastian Heinlein]
> Basically PackageKit is just a common interface and a daemon to handle
> transactions. The work is done by backends. The PackageKit daemon just
> receives the request for a driver and routes it to the backend.
>
> But you also need some client tools: The always running gpk-update-icon
> and the DBus activated gpk-service tools from gnome-packagekit. Both run
> in the user session and listen to the session D-Bus. The tools provide the
> end user dialogs and guide the user through the installation process:

Would you be interested in testing in Debian Edu/Squeeze a setup using
the packagekit interface to dynamically install hardware specific
packages when they are discovered? If we get it working there in time
for Squeeze, we can try to get it integrated into the normal Debian
desktop too.

If so, please join us on #debian-edu (irc.debian.org) to discuss how.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2fl4ogsvmnq.fsf@login1.uio.no">http://lists.debian.org/2fl4ogsvmnq.fsf@login1.uio.no
 

Thread Tools




All times are GMT. The time now is 06:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org