On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote:
> Hello *,
> some time ago I filed a RFS [1] for DKMS [2]
So, what's the final status of this thread?
Should I continue working on the package? Should I drop it?
I wouldn't want to drop it -- if there's no consensus or, at least, someone
w
Le lundi 15 septembre 2008 à 07:54 +0200, Yves-Alexis Perez a écrit :
> On dim, 2008-09-14 at 22:36 +0100, Ben Hutchings wrote:
> > (DKMS actually moves the old version out of the way and
> > moves the new version into its place. I think we might want to modify
> > that behaviour in Debian, perhap
On Fri, 2008-09-12 at 10:02 +, Tzafrir Cohen wrote:
> That may be true for an out-of-tree modules. However, let's recall that
> Fedora ships with Latest kernel and Debian (Stable) doesn't. Hence
> Debian should be more concerened with backporting.
Right now Debian d
On dim, 2008-09-14 at 09:15 +0200, Josselin Mouette wrote:
> Le samedi 13 septembre 2008 à 07:08 +, Tzafrir Cohen a écrit :
> > And as I mentioned before, the problem with those generated debs is
> that
> > you can not install two of them on your system if you have two
>
Le samedi 13 septembre 2008 à 07:08 +, Tzafrir Cohen a écrit :
> And as I mentioned before, the problem with those generated debs is that
> you can not install two of them on your system if you have two different
> kernel variants.
Then it is a bug in the Debian dkms package, and
On Sat, Sep 13, 2008 at 09:32:41PM -0500, Gunnar Wolf wrote:
> Tzafrir Cohen dijo [Sat, Sep 13, 2008 at 07:08:05AM +]:
> > > > - Having files *vital* to the system not tracked by dpkg is
> > > > counter-productive. At the very least it thwarts the most basic and
> > > > obvious way of integrit
So, DKMS is being run after the installation of a kernel. Am I right?
Yes.
Btw, is all this documented anywhere?
I guess it isn't.
Kindly,
David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Tzafrir Cohen dijo [Sat, Sep 13, 2008 at 07:08:05AM +]:
> > > - Having files *vital* to the system not tracked by dpkg is
> > > counter-productive. At the very least it thwarts the most basic and
> > > obvious way of integrity protection.
> >
> > Dpkg is not tripwire. If you think you can re
OoO En cette matinée ensoleillée du samedi 13 septembre 2008, vers
09:08, Tzafrir Cohen <[EMAIL PROTECTED]> disait :
> Do not assume everybody maintaining the system know of dkms (or of m-a
> or such). Knowledge of debsums or equivalent should be assumed from
> anybody maintaining a Debian s
On sam, 2008-09-13 at 06:21 +, Tzafrir Cohen wrote:
> Can you do that if you generate modules for both 2.6.26-1-686 and
> 2.6.26-1-vserver-686 ?
Will tell you on monday.
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
On sam, 2008-09-13 at 00:21 +0200, José Luis Tallón wrote:
> > No. You only need dkms.
> >
> Hmm... How does dkms build the modules for a build kernel, then?
> Surely a compiler and linker must be needed, right?
You build the module on the build host, then put it on a .deb pa
exceptional; it is for desktops and
> laptops with non-free graphics and wifi. In most cases you don’t care of
> having distributable packages.
Dell developed dkms for Linux servers it ships. Many servers ship with
disk controllers, network controllers and such that are not yet
supported i
On Fri, Sep 12, 2008 at 11:28:49PM +0200, Yves-Alexis Perez wrote:
> On ven, 2008-09-12 at 13:55 +0200, Raphael Hertzog wrote:
> > > Why? I think this is the only sane way to go for drivers that we
> > won’t
> > > ship binary packages for.
> >
> > Why? What's wrong with dynamically generating .deb
ceptional; it is for desktops and
laptops with non-free graphics and wifi. In most cases you don’t care of
having distributable packages.
> When the rebuild is triggered by booting with a new kernel, dpkg is not
> active and can be invoked to *register* the new modules, hence realizing
&g
stalled normally, under
/lib/modules/${KVERS} and tracked by dpkg.
One idea which comes to mind (without further thinking) is to merge both
approaches: dkms could become a "subsystem" of module-assistant in Debian:
As presented above, installing kernel-headers and/or booting a kernel
for whic
arget host.
>>
>
> No. You only need dkms.
>
Hmm... How does dkms build the modules for a build kernel, then?
Surely a compiler and linker must be needed, right?
J.L.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On ven, 2008-09-12 at 11:32 +, Tzafrir Cohen wrote:
> This is a major bug IMHO. It means that at least for i386
> dkms-generated
> debs cannot be put in repositories. Thus you require a build
> environment
> on the target host.
No. You only need dkms.
--
Yves-Alexis
signature.asc
Descripti
On ven, 2008-09-12 at 13:55 +0200, Raphael Hertzog wrote:
> > Why? I think this is the only sane way to go for drivers that we
> won’t
> > ship binary packages for.
>
> Why? What's wrong with dynamically generating .deb of those modules
> and
> installing them?
That's exactly what “dkms mkdeb” do
Tzafrir Cohen wrote:
> Upon initial inspection of the dkms script, it seems to generate
> deb packages whose name does not not include $KVERS . But I didn't test
> it.
>
This is correct, because you don't want to have multiple DKMS packages
installed to support many
it is possible to achieve that and how much perverted it would
be, but I really don’t think this is the good way to go.
> > As long as the .ko files are correctly removed when you remove the
> > kernel image – which is feasible with a trigger – there is nothing wrong
> > with it.
supplementary package installation.
> As long as the .ko files are correctly removed when you remove the
> kernel image – which is feasible with a trigger – there is nothing wrong
> with it.
If you remove dkms, and remove kernel afterwards, you will keep cruft for
the eternity. Handling
; > installed on the system. dpkg does not like this. Hence kernel modules
> > > deb packages have the name $BASE-$KVERS (e.g: lirc-modules-2.6.26-1-686),
> > > whereas rpm packages of kernel modules tend to encode $KVERS in the
> > > Version field alone.
> >
&g
On Fri, Sep 12, 2008 at 01:18:04PM +0200, David Paleino wrote:
> On Fri, 12 Sep 2008 11:12:59 +, Tzafrir Cohen wrote:
> > Another issue: with rpm it is OK to have several packages of the same name
> > installed on the system. dpkg does not like this. Hence kernel modules
> &
s should be the norm. Having many files under /lib that
> cannot be tracked by debsums is not something I like.
>
> [..]
>
> Another issue: with rpm it is OK to have several packages of the same name
> installed on the system. dpkg does not like this. Hence kernel modules
> deb
t you install it, it builds modules for your running kernel. As soon as
> you install a new kernel, it will build modules for that kernel too. Any old
> kernels that you have, modules will be built as soon as you boot into the
> kernel.
> Compare this to module-assistant. You have to in
gt; http://fedoraproject.org/wiki/Packaging/KernelModules
> http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal
That may be true for an out-of-tree modules. However, let's recall that
Fedora ships with Latest kernel and Debian (Stable) doesn't. Hence
Debian should be more concerened with back
o for drivers that we won’t
> ship binary packages for.
That's why I originally proposed the "DKMS way", i.e.:
dkms add [..]
dkms remove [..]
dkms status [..]
...
> As long as the .ko files are correctly removed when you remove the
> kernel image – which is feasible with a t
rectly removed when you remove the
kernel image – which is feasible with a trigger – there is nothing wrong
with it.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-
@debian-kernel: please see the full thread at
<http://lists.debian.org/debian-devel/2008/09/msg00229.html>
On Fri, 12 Sep 2008 10:00:00 +0200, Raphael Hertzog wrote:
> Hi,
Hi Raphael,
> On Thu, 11 Sep 2008, David Paleino wrote:
> > Hello *,
> > some time ago I fil
an developers (and users) think about
> this framework: it's useless if no package uses it :)
Indeed, that's why it's important to have the kernel team involved and
Daniel in particular as he currently takes care of
linux-modules-{extra,contrib}
Cheers,
--
Raphaël Hertzog
Le best-se
ad". We all agree here, no? But, what the
case of non-free drivers, for example?
> http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal
The main point:
"There is no justification for shipping kernel modules as separate packages
within Fedora, in either source (dkms payload) or
On Thu, 11 Sep 2008 22:29:44 -0400, Filipus Klutiero wrote:
> > This is achieved through the installation of a script in:
> >
> > /etc/kernel/header_postinst.d/
> > /etc/kernel/postinst.d/
> > /etc/kernel/prerm.d/
> >
> > A quick search with apt-file didn
On Fri, Sep 12, 2008 at 02:51:00PM +0800, Paul Wise wrote:
> On Thu, Sep 11, 2008 at 4:00 PM, David Paleino <[EMAIL PROTECTED]> wrote:
>
> > some time ago I filed a RFS [1] for DKMS [2], and Daniel Baumann
> > asked
> > me what advantages it had over module-assistant.
> > After some talking with
On Thu, Sep 11, 2008 at 12:24:08PM -0500, Mario Limonciello wrote:
> As I understand, the dpkg maintainer (Michael Vogt)
Do you mean "apt maintainer"? TTBOMK, Michael has never been involved with
dpkg maintenance; so is this implementation going to be in dpkg, or apt?
Cheers,
--
Steve Langasek
On Thu, Sep 11, 2008 at 4:00 PM, David Paleino <[EMAIL PROTECTED]> wrote:
> some time ago I filed a RFS [1] for DKMS [2], and Daniel Baumann
> asked
> me what advantages it had over module-assistant.
> After some talking with upstream, here I have the answer.
Only down side I worry about is tha
On Thu, 11 Sep 2008, David Paleino wrote:
> On Thu, 11 Sep 2008 19:50:35 +0200, David Paleino wrote:
>
> > On Thu, 11 Sep 2008 19:43:39 +0200, Josselin Mouette wrote:
> > > You’d run into the same issue as module-assistant has: a package being
> > > installed cannot launch installation of other pa
On jeu, 2008-09-11 at 10:00 +0200, David Paleino wrote:
> This mail is being sent to see what Debian developers (and users)
> think about
> this framework: it's useless if no package uses it :)
I currently use DKMS at work on some servers which run Debian. All other
run RHEL, and have fully update
On jeu, 2008-09-11 at 18:02 +, Tzafrir Cohen wrote:
>
> Do you actually have a working build system? Must you have a build
> system on every host?
I have one on a testbed yes. I have a box which has dkms,
build-essential and headers installed. I import the driver source
tarball, run dkms mkde
On jeu, 2008-09-11 at 21:32 +0100, Ben Hutchings wrote:
> Note, we would also need to ensure that alien does a good job
> with DKMS RPMs.
dkms can build deb packages. They need dkms to be installed too (so you
need it installed on all your servers, not just on the build machine),
but it works fine
This is achieved through the installation of a script in:
/etc/kernel/header_postinst.d/
/etc/kernel/postinst.d/
/etc/kernel/prerm.d/
A quick search with apt-file didn't return any result.
Is this approach supported by Debian?
/etc/kernel/header_postinst.d/ isn't supported.
I rem
On Thu, 2008-09-11 at 10:00 +0200, David Paleino wrote:
> *Other*
>
> 5) Interoperability with different distributions. DKMS tarballs can be used on
> RHEL, SuSE, Ubuntu, or Debian. If there are different kernels, patches can be
> included in the DKMS tarball to enable support on d
rint a message suggesting what to do next
> >
> > From your reply, I understand that b1) wouldn't be possible to achieve. Why?
> > Can't triggers start external programs?
>
> Triggers are run from within dpkg, and cannot launch new APT/dpkg
> processes. And in all
Le jeudi 11 septembre 2008 à 21:44 +0200, David Paleino a écrit :
> On Thu, 11 Sep 2008 20:24:53 +0200, Josselin Mouette wrote:
> > You cannot install packages in a triggered script, or in whatever way
> > that will be determined from within a package itself.
>
> Is there any particular reason for
an alternative, i'd suggest:
>
> - building the modules as part of the upgrade process using dpkg triggers or
> some other clever mechanism to determine when it needs to be done
Ok, this is what I was trying to suggest :)
> - storing the modules in a nested subdirectory
On Thu, 11 Sep 2008 20:24:53 +0200, Josselin Mouette wrote:
> Le jeudi 11 septembre 2008 à 20:02 +0200, David Paleino a écrit :
> > apt-get is able to determine the architecture he's running on, right?
> > Anyways, dkms is a shells script, it could use dpkg-architecture to get the
> > right string
-init-tools so that these
directories were included in the search path for modprobe.
note that this is non-conflicting with rolling the modules into a .deb
package too, but i think is the only clean way to build/install kernel
modules if you are already within the package installation process.
sean
signature.asc
Description: Digital signature
gt; > trick at least for the default kernel. (Depending on just
> > > linux-headers-2.6 is not enough, since linux-headers-2.6.xx-y-$subarch
> > > provides it).
> >
> > I think you meant:
> >
> > depend on linux-headers-2.6.26-1-all
> >
>
> > > One of the issues I’m wondering about is: how do you ensure you always
> > > > > have the kernel headers for the installed kernels?
> > > >
> > > > Some kind of check inside DKMS? In the end, that's a Bash script, and
> >
dkms?
Just install build-essential (and what else is needed) alongside with
the proper linux-headers-* package.
> What is the name of the generated deb package? Can two packages of
> different kernel architectures liv in the same system? 2.6.26-1-486 and
> 2.6.26-1-686 .
DKMS *does* *not* generat
always
> > > > have the kernel headers for the installed kernels?
> > >
> > > Some kind of check inside DKMS? In the end, that's a Bash script, and the
> > > Debian maintainer (i.e. me, in this case) could just maintain a patch for
> > > this (or
On Thu, 11 Sep 2008 17:52:39 +, Tzafrir Cohen wrote:
> On Thu, Sep 11, 2008 at 07:43:39PM +0200, Josselin Mouette wrote:
> > Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit :
> > > > One of the issues I’m wondering about is: how do you ensure you always
&g
On Thu, 11 Sep 2008 19:50:35 +0200, David Paleino wrote:
> On Thu, 11 Sep 2008 19:43:39 +0200, Josselin Mouette wrote:
> > You’d run into the same issue as module-assistant has: a package being
> > installed cannot launch installation of other packages.
>
> Uhm, right.
> I believe there could be
Le jeudi 11 septembre 2008 à 17:29 +0200, David Paleino a écrit :
> > > 1) It includes a kernel postinstall hook. This means that, the moment
> > > kernel
> > > headers get installed, your modules are automatically rebuilt.
> >
> > Seems just as easy
On Thu, Sep 11, 2008 at 07:43:39PM +0200, Josselin Mouette wrote:
> Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit :
> > > One of the issues I’m wondering about is: how do you ensure you always
> > > have the kernel headers for the installed kernels?
> &
On Thu, 11 Sep 2008 19:43:39 +0200, Josselin Mouette wrote:
> Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit :
> > > One of the issues I’m wondering about is: how do you ensure you always
> > > have the kernel headers for the installed kernels?
> >
&g
Le jeudi 11 septembre 2008 à 19:23 +0200, David Paleino a écrit :
> > One of the issues I’m wondering about is: how do you ensure you always
> > have the kernel headers for the installed kernels?
>
> Some kind of check inside DKMS? In the end, that's a Bash script, and
Hi Josselin:
As I understand, the dpkg maintainer (Michael Vogt) is implementing the
idea of package groups that have sticky dependencies. This should mean
that when a package gets installed, it will need to register with the
package group. When a kernel with a new ABI is available, it won'
On Thu, 11 Sep 2008 19:17:17 +0200, Josselin Mouette wrote:
> Le jeudi 11 septembre 2008 à 17:29 +0200, David Paleino a écrit :
> > > > 1) It includes a kernel postinstall hook. This means that, the moment
> > > > kernel headers get installed, your module
Hi David:
I'll add on the Ubuntu kernel team here to get some comments on this
postinstall hook functionality and it's origins.
Regards
David Paleino wrote:
> On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote:
>
>
>> If you have AUTOINSTALL set to yes in a D
Hi Cohen:
Keep in mind, if there is a new kernel that gets installed, this will
build the driver for that kernel, but nothing will be activated until
you reboot. That choice is your own. Due to the kernel postinstall
service, you won't even need to build the modules during the next boot
eve
> some effort should be made to make a "central repository" (like for
> autopackage, and for other similar "cross-vendor" projects) where to store
> "vanilla" tarballs. Mario, do you know of any "central source" currently
> available?
>
The origina
On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote:
> If you have AUTOINSTALL set to yes in a DKMS control file:
>
> 1) It includes a kernel postinstall hook. This means that, the moment kernel
> headers get installed, your modules are automatically rebuilt.
This is achieved
;
> > I believe this is a bug in the zaptel init scripts... shouldn't they check
> > whether they can be unloaded? Is there a --force option? But this is another
> > story :)
>
> Maybe it's possible (I'm not exactly sure. I think it's possible, at
>
can be unloaded? Is there a --force option? But this is another
> story :)
Maybe it's possible (I'm not exactly sure. I think it's possible, at
least in most cases). But do I want this? Do I want to shut down my PBX
because of the Ubuntu kernel upgrade of the month?
Which is why I
compatibility.
That's why I'm trying to introduce DKMS!
> Some comments:
>
> On Thu, Sep 11, 2008 at 10:00:38AM +0200, David Paleino wrote:
>
> > 1) It includes a kernel postinstall hook. This means that, the moment kernel
> > headers get installed, your modul
Hi,
I have experince mostly with the out-of-tree module Zaptel.
I'm personally happy with m-a. It works resonably well for me. Though I
appreciate the goal of cross-vendor compatibility.
Some comments:
On Thu, Sep 11, 2008 at 10:00:38AM +0200, David Paleino wrote:
> 1) It includes
to yes in a DKMS control file:
1) It includes a kernel postinstall hook. This means that, the moment kernel
headers get installed, your modules are automatically rebuilt.
2) It includes a boot time service to add modules for a running kernel provided
headers are available.
*Usability & Ma
g Lang: C
Description : source for RT2860 wireless adapter kernel module
RT2860 is a wireless adapter found particularly in the ASUS EeePC model
901 and above. The package contains the source of a Linux kernel module
for it.
There may be some licensing problems and this is why I CC debian
Processing commands for [EMAIL PROTECTED]:
> severity 496967 important
Bug#496967: general: System completely blocks any input
Severity set to `important' from `grave'
> tags 496967 +unreproducible
Bug#496967: general: System completely blocks any input
There were no tags set.
Tags added: unrepro
On Wed, 2008-07-16 at 22:29 +0200, Mike Hommey wrote:
> I'm wondering... do we have binary packages for all kernel modules we have
> (free) -source packages for so that such kernel modules don't need to be
> built by users ?
No, but *most* of them are built by linux-modules
It looks like the search you tried is just broken.
The search tool works but it is rather dumb and the instructions are misleading.
_i386 will only find packages with _i386 in the filename. So it will NOT find
arch all packages like module-assistant. There does not seem
to be a way to search fo
Zitat von "brian m. carlson" <[EMAIL PROTECTED]>:
On Wed, Jul 16, 2008 at 09:53:24PM +0200, richs wrote:
I think that including headers, m-a and build essential would be a
good move for the developers. Other distros have out-of-the-box
non-free and proprietary apps/drivers/codecs, I woul
On Thursday 17 July 2008, richs wrote:
> I can assure you that on an http download i386 iso, m-a is not.
> http://atterer.net/jigdo/jigdo-search.php?q=module-assistant+_i386
You really need to check your facts better. If you use the links I
provided and just search the pages:
http://atterer.net/
Le Wed, Jul 16, 2008 at 08:21:14PM +, brian m. carlson a écrit :
>
> Non-free (and contrib) packages are not part of Debian and are therefore
> not shipped on Debian CDs or DVDs. I understand your frustration with
> not being able to use your wireless card out of the box; I have the same
> pr
iso, m-a is not.
http://atterer.net/jigdo/jigdo-search.php?q=module-assistant+_i386
And on Lenny the latest kernel headers weren't available either.
richs
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.6 (GNU/Linux)
mQGiBEhcyNURBADXeYTKqnBw/SLabReVFBgIxwjo9IYvORx6uxETHDvuyo7
richs wrote:
> Hi, basically I am requesting module-assistant, build-essential and the
> kernel headers for the default kernel on the first iso.
I really don't have a clue what you're going on about then.
If you check these pages, you'll see that all three package you name _
t of Debian.
>
> Even if the packages you request were available on the first CD, you
> still don't have the drivers that you would need to compile, since those
> are in non-free or contrib and thus aren't on the CDs. Your best
> chances of getting a working system out of t
mpile, since those
are in non-free or contrib and thus aren't on the CDs. Your best
chances of getting a working system out of the box are if Free drivers
without firmware are included into the kernel. If this is a serious
concern, I would recommend carefully selecting the hardware you buy f
Hi, basically I am requesting module-assistant, build-essential and the
kernel headers for the default kernel on the first iso. These are basic
tools that are necessary to be able to install non-free, proprietary
packages such as madwifi, nvidia-drivers etc.
My main point is the wireless
Hi,
[EMAIL PROTECTED] wrote:
> They are free, do not take up space, but
> without them (on a wireless only computer) you hit a vicious circle;
> Needing internet to be able to get internet.
Avoiding the free vs. non-free firmware issue, most of these packages
are available on Debian CDs/DVDs, jus
I would like to ask why essential packages are not included on the first Debian
download cd/iso. I use Nvidia and Atheros wireless, but the packages
module-assistant, build essential, kernel headers, wireless-tools etc, are
needed for most other graphic, network driver and firmware
Frank Lichtenheld wrote:
> I traced the error back to a change in kernel 2.6.25: Apparently vfat
> file system can now become case sensitive in some cases
> ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> filesystem will be case sensitive!")
> - k
On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
> While testing some updates to my gtkpod/libgpod packages I noticed that
> I couldn't actually play any songs anymore from my iPod. Which worked
> fine some weeks ago.
> I traced the error back to a change
ymore from my iPod. Which worked
> > fine some weeks ago.
> >
> > I traced the error back to a change in kernel 2.6.25: Apparently vfat
> > file system can now become case sensitive in some cases
> > ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
&
On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
> Hi.
>
> While testing some updates to my gtkpod/libgpod packages I noticed that
> I couldn't actually play any songs anymore from my iPod. Which worked
> fine some weeks ago.
>
> I traced the error
Hi.
While testing some updates to my gtkpod/libgpod packages I noticed that
I couldn't actually play any songs anymore from my iPod. Which worked
fine some weeks ago.
I traced the error back to a change in kernel 2.6.25: Apparently vfat
file system can now become case sensitive in some
ere and also in /lib/modules/$(uname
-r)/kernel/drivers/net, the one in updates takes precedence? Even for
initrd rebuilding?
--
Ernesto Hernández-Novich - Linux 2.6.18 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't use
roaches had failed. This was a bit ugly but at least
> it works: Etch stock Xen kernel, network bridge functional, management
> firmware not needed.
Sadly, there's no documented way to disable IPMI on the IBM x3655
servers :-/
--
Ernesto Hernández-Novich - Linux 2.6.18 i686 - Unix: Liv
On Wed, Jun 18, 2008 at 10:14:33AM -0430, Ernesto Hernandez-Novich wrote:
> Is there a document or package I could follow as an example?
Put the modules into /lib/modules/$(uname -r)/updates.
Bastian
--
Another dream that failed. There's nothing sadder.
-- Kirk, "This side of P
ere able to work around this issue by disabling the IPMI management
portion of the firmware via a DOS tool as described on
<http://mywiki.ncsa.uiuc.edu/wiki/Dell_PE1950_NIC_Firmware_Workaround>
when all other approaches had failed. This was a bit ugly but at least
it works: Etch stock Xen kernel
On Wed Jun 18, 2008 at 10:41:13 -0430, Ernesto Hernandez-Novich wrote:
> Been there, done that, doesnt't work for these machines. The problem has
> to do with the interaction of the card with IBM's IPMI controller, and
> requires the latest Broadcom drivers.
What you want to do is install the E
On Wed, 2008-06-18 at 16:01 +0100, Stephen Gran wrote:
> 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708
> Gigabit Ethernet (rev 12)
>
> /etc/network/interfaces:
> post-up ethtool -K eth0 tx off
>
> Fixes it here.
Been there, done that, doesnt't work for these machines. Th
This one time, at band camp, Ernesto Hernandez-Novich said:
> I'm currently having issues with a Broadcom Netxtreme II 5708 card when
> used with Xen on Debian Etch. Basically, using kernel 2.6.18 it works,
> but as soon as either a bridge or a routed network under Xen is
>
I'm currently having issues with a Broadcom Netxtreme II 5708 card when
used with Xen on Debian Etch. Basically, using kernel 2.6.18 it works,
but as soon as either a bridge or a routed network under Xen is
started, it stops receiven packages. The servers (cause they are many)
must remain
ectory `/usr/src/linux-headers-2.6.18-4-686'
>
>
>
>
>
> Actually, Red.ko had made but can not load the module due to the
> unknown symbol (tasklist_lock).
>
>
>
> What’s the problem?? I can see the symbol is exported in the
> linux-header-2.6.18-4-686/include/linux/sched.
unknown symbol
(tasklist_lock).
What’s the problem?? I can see the symbol is exported in the
linux-header-2.6.18-4-686/include/linux/sched.h.
I couldn’t understand why it is shown “undefined”??
Also during searching about this problem, I read this - for linux kernel
2.6.18, the symbol does NOT
: http://open-mesh.net/batman
* License : GPL
Programming Lang: C
Description : Source for the batman-advanced kernel module.
This package provides the source code for the batman-adv-source kernel modules.
The batman-adv-source package is also required in order to make use of thes
Package: wnpp
Severity: wishlist
Owner: Bertrand Marc <[EMAIL PROTECTED]>
* Package name: fglrx-kernel-modules
Version : 1:8-4-1
Upstream Author : ATI/AMD
* URL : http://ati.amd.com/support/drivers/linux/linux-radeon.html
* License : restricted
Descr
Processing commands for [EMAIL PROTECTED]:
> # Automatically generated email from bts, devscripts version 2.10.20
> reassign 275635 kernel
Bug#275635: How to increase the Threads Size in debian...
Bug reassigned from package `general' to `kernel'.
>
End of message, stopp
Your message dated Fri, 4 Apr 2008 01:23:56 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#268709: Architecture names should have a "${kernel}-"
prefix
has caused the Debian Bug report #268709,
regarding Architecture names should have a "${kernel}-&qu
701 - 800 of 2851 matches
Mail list logo
