Debian Bug report logs - #586725
dkms attempts to install modules in wrong order

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jan Muszynski <debianbugs@jancm.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dkms attempts to install modules in wrong order

Date: Mon, 21 Jun 2010 19:59:36 -0400

[Message part 1 (text/plain, inline)]

Package: dkms
Version: 2.1.1.2-3
Severity: normal
Tags: patch

This shows up, on my system, when trying to build the modules for virtualbox (PUEL). There are 3 modules, and they need to be built in a specific order (the others depend on the first to build correctly). If dkms processes the modules in sorted sequence everything is fine. Otherwise I have to manually get the modules to build. Here's an example of what I mean:

'find "$dkms_tree" -maxdepth 1 -mindepth 1 -type d' returns, on my system:
/var/lib/dkms/vboxnetadp
/var/lib/dkms/vboxnetflt
/var/lib/dkms/nvidia
/var/lib/dkms/vboxdrv

The 2 vboxnet modules dpend on the vboxdrv module in order to compile correctly, so this ends up failing. After patching the autoinstaller to pipe the results through a sort the order becomes:
/var/lib/dkms/nvidia
/var/lib/dkms/vboxdrv
/var/lib/dkms/vboxnetadp
/var/lib/dkms/vboxnetflt

And this works just fine. Patch attached. Need anything else please let me know.
TIA
-jcm

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.34-02.i386vanilla (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dkms depends on:
ii  build-essential              11.5        Informational list of build-essent
ii  dpkg-dev                     1.15.7.2    Debian package development tools
ii  gcc                          4:4.4.4-2   The GNU C compiler
ii  make                         3.81-8      An utility for Directing compilati
ii  module-init-tools            3.12~pre2-3 tools for managing Linux kernel mo

Versions of packages dkms recommends:
ii  fakeroot                    1.14.4-1     Gives a fake root environment
ii  linux-headers-2.6.32-5-686  2.6.32-15    Header files for Linux 2.6.32-5-68
ii  linux-headers-2.6.34-0.dmz. 2.6.34-43    Header files for Linux 2.6.34-0.dm
ii  linux-headers-2.6.34-02.i38 2010.163.jcm Header files related to Linux kern
ii  linux-image-2.6.32-5-686 [l 2.6.32-15    Linux 2.6.32 for modern PCs
ii  linux-image-2.6.34-0.dmz.12 2.6.34-43    Linux 2.6.34 for modern PCs
ii  linux-image-2.6.34-02.i386v 2010.163.jcm Linux kernel binary image for vers
ii  lsb-release                 3.2-23.1     Linux Standard Base version report
ii  menu                        2.1.43       generates programs menu for all me
ii  patch                       2.6-2        Apply a diff file to an original
ii  sudo                        1.7.2p7-1    Provide limited super user privile

dkms suggests no packages.

-- Configuration Files:
/etc/kernel/prerm.d/dkms changed [not included]

-- no debconf information

[dkms_autoinstaller.patch (text/plain, attachment)]

Message #10 received at 586725@bugs.debian.org (full text, mbox, reply):

From: Giuseppe Iuculano <giuseppe@iuculano.it>

To: Jan Muszynski <debianbugs@jancm.org>, 586725@bugs.debian.org, DKMS maintainers <pkg-dkms-maint@lists.alioth.debian.org>

Subject: Re: [Pkg-dkms-maint] Bug#586725: dkms attempts to install modules in wrong order

Date: Sat, 17 Jul 2010 12:52:48 +0200

[Message part 1 (text/plain, inline)]

On 06/22/2010 01:59 AM, Jan Muszynski wrote:
> This shows up, on my system, when trying to build the modules for virtualbox (PUEL). There are 3 modules, and they need to be built in a specific order (the others depend on the first to build correctly). If dkms processes the modules in sorted sequence everything is fine. Otherwise I have to manually get the modules to build. Here's an example of what I mean:

Ok, you are proposing to use 'sort', but this fixes a specific issue,
the alphabetical order doesn't necessarily matches the build order.

Cheers,
Giuseppe.

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 586725@bugs.debian.org (full text, mbox, reply):

From: Jan Muszynski <debianbugs@jancm.org>

To: Giuseppe Iuculano <giuseppe@iuculano.it>

Cc: 586725@bugs.debian.org, DKMS maintainers <pkg-dkms-maint@lists.alioth.debian.org>

Subject: Re: [Pkg-dkms-maint] Bug#586725: dkms attempts to install modules in wrong order

Date: Sat, 17 Jul 2010 14:02:59 -0400

On Sat, Jul 17, 2010 at 6:52 AM, Giuseppe Iuculano <giuseppe@iuculano.it> wrote:
> On 06/22/2010 01:59 AM, Jan Muszynski wrote:
>> This shows up, on my system, when trying to build the modules for virtualbox (PUEL). There are 3 modules, and they need to be built in a specific order (the others depend on the first to build correctly). If dkms processes the modules in sorted sequence everything is fine. Otherwise I have to manually get the modules to build. Here's an example of what I mean:
>
> Ok, you are proposing to use 'sort', but this fixes a specific issue,
> the alphabetical order doesn't necessarily matches the build order.
>
> Cheers,
> Giuseppe.

I suspect (although can't prove) that any modules that have
dependencies (as in this case) wll use alpha order, and name modules
accordingly. Otherwise what would they use to determine the compile
order?

In most cases it's a one module build so it doesn't matter. This is
restricted to multiple module compiles, that also have dependencies on
each other, so the universe is (relatively) small.

If you can show me a multi-module driver set that has dependencies
that depend on an order other than an alpha sort I'll be happy to drop
the bug and reconsider another method. But logically I think an alpha
sort is the only thing that makes sense and that anyone building a
dkms package that builds such modules will assume they go in sorted
order.

Message #18 received at 586725-done@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <michael.s.gilbert@gmail.com>

To: 586725-done@bugs.debian.org, 567460-done@bugs.debian.org

Cc: control@bugs.debian.org

Subject: re: dkms attempts to install modules in wrong order

Date: Tue, 17 Aug 2010 23:00:28 -0400

forcemerge 586725 567460
thanks

this must have been a virtualbox issue.  as of at least 3.2.8 they now
only have one dkms directory, and i assume they've set that up in a way
that installs modules in the correct order:

$ ls /var/lib/dkms
dkms_dbversion	virtualbox-ose

if this hasn't fixed the problem, please reopen the bug.

thanks,
mike

Message #23 received at 586725@bugs.debian.org (full text, mbox, reply):

From: Jan Muszynski <debianbugs@jancm.org>

To: 586725@bugs.debian.org

Subject: Re: Bug#586725 closed by Michael Gilbert <michael.s.gilbert@gmail.com> (re: dkms attempts to install modules in wrong order)

Date: Fri, 20 Aug 2010 20:50:01 -0700

What you show is virtualbox-ose. Compare to PUEL. And no, you can't
say it's a bug in the PUEL implementation. Note that when you run
/etc/init.d/vboxdrv setup it:
1) Does use dkms if it's available
2) Explicitly processes the drivers in order
Anyway:

ls /var/lib/dkms
dkms_dbversion  nvidia  vboxdrv  vboxnetadp  vboxnetflt

apt-show-versions -a virtualbox-3.2
virtualbox-3.2 3.2.8-64453~Debian~lenny install ok installed
virtualbox-3.2 3.2.8-64453~Debian~lenny lenny download.virtualbox.org
No testing version
No unstable version
virtualbox-3.2/lenny uptodate 3.2.8-64453~Debian~lenny


The issue that I originally filed this on obviously isn't critical.
For my own purposes I can easily correct this. The general issue
remains though. What order should the various dkms modules get
compiled in? I think the only logical order is sorted alpha, since if
there are modules with inter-related dependencies that would be what
they logically would use. For other, standalone, modules the order
doesn't matter so it's no harm no foul.

Bottom line it's a simple change and I don't see how it could possibly
hurt anything, so I'm unable to understand the resistance/reluctance
to implement it.



On Tue, Aug 17, 2010 at 8:03 PM, Debian Bug Tracking System
<owner@bugs.debian.org> wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the dkms package:
>
> #567460: dkms attempts to install modules in wrong order
>
> It has been closed by Michael Gilbert <michael.s.gilbert@gmail.com>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Michael Gilbert <michael.s.gilbert@gmail.com> by
> replying to this email.
>
>
> --
> 567460: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567460
> Debian Bug Tracking System
> Contact owner@bugs.debian.org with problems
>
>
> ---------- Forwarded message ----------
> From: Michael Gilbert <michael.s.gilbert@gmail.com>
> To: 586725-done@bugs.debian.org, 567460-done@bugs.debian.org
> Date: Tue, 17 Aug 2010 23:00:28 -0400
> Subject: re: dkms attempts to install modules in wrong order
> forcemerge 586725 567460
> thanks
>
> this must have been a virtualbox issue.  as of at least 3.2.8 they now
> only have one dkms directory, and i assume they've set that up in a way
> that installs modules in the correct order:
>
> $ ls /var/lib/dkms
> dkms_dbversion  virtualbox-ose
>
> if this hasn't fixed the problem, please reopen the bug.
>
> thanks,
> mike
>
>
>
> ---------- Forwarded message ----------
> From: Jan Muszynski <debianbugs@jancm.org>
> To: Debian Bug Tracking System <submit@bugs.debian.org>
> Date: Mon, 21 Jun 2010 19:59:36 -0400
> Subject: dkms attempts to install modules in wrong order
> Package: dkms
> Version: 2.1.1.2-3
> Severity: normal
> Tags: patch
>
> This shows up, on my system, when trying to build the modules for virtualbox (PUEL). There are 3 modules, and they need to be built in a specific order (the others depend on the first to build correctly). If dkms processes the modules in sorted sequence everything is fine. Otherwise I have to manually get the modules to build. Here's an example of what I mean:
>
> 'find "$dkms_tree" -maxdepth 1 -mindepth 1 -type d' returns, on my system:
> /var/lib/dkms/vboxnetadp
> /var/lib/dkms/vboxnetflt
> /var/lib/dkms/nvidia
> /var/lib/dkms/vboxdrv
>
> The 2 vboxnet modules dpend on the vboxdrv module in order to compile correctly, so this ends up failing. After patching the autoinstaller to pipe the results through a sort the order becomes:
> /var/lib/dkms/nvidia
> /var/lib/dkms/vboxdrv
> /var/lib/dkms/vboxnetadp
> /var/lib/dkms/vboxnetflt
>
> And this works just fine. Patch attached. Need anything else please let me know.
> TIA
> -jcm
>
> -- System Information:
> Debian Release: squeeze/sid
>  APT prefers testing
>  APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
>
> Kernel: Linux 2.6.34-02.i386vanilla (PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages dkms depends on:
> ii  build-essential              11.5        Informational list of build-essent
> ii  dpkg-dev                     1.15.7.2    Debian package development tools
> ii  gcc                          4:4.4.4-2   The GNU C compiler
> ii  make                         3.81-8      An utility for Directing compilati
> ii  module-init-tools            3.12~pre2-3 tools for managing Linux kernel mo
>
> Versions of packages dkms recommends:
> ii  fakeroot                    1.14.4-1     Gives a fake root environment
> ii  linux-headers-2.6.32-5-686  2.6.32-15    Header files for Linux 2.6.32-5-68
> ii  linux-headers-2.6.34-0.dmz. 2.6.34-43    Header files for Linux 2.6.34-0.dm
> ii  linux-headers-2.6.34-02.i38 2010.163.jcm Header files related to Linux kern
> ii  linux-image-2.6.32-5-686 [l 2.6.32-15    Linux 2.6.32 for modern PCs
> ii  linux-image-2.6.34-0.dmz.12 2.6.34-43    Linux 2.6.34 for modern PCs
> ii  linux-image-2.6.34-02.i386v 2010.163.jcm Linux kernel binary image for vers
> ii  lsb-release                 3.2-23.1     Linux Standard Base version report
> ii  menu                        2.1.43       generates programs menu for all me
> ii  patch                       2.6-2        Apply a diff file to an original
> ii  sudo                        1.7.2p7-1    Provide limited super user privile
>
> dkms suggests no packages.
>
> -- Configuration Files:
> /etc/kernel/prerm.d/dkms changed [not included]
>
> -- no debconf information
>
>

Message #28 received at 586725@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <michael.s.gilbert@gmail.com>

To: 586725@bugs.debian.org, 586725-submitter@bugs.debian.org

Subject: Re: [Pkg-dkms-maint] Bug#586725: closed by Michael Gilbert <michael.s.gilbert@gmail.com> (re: dkms attempts to install modules in wrong order)

Date: Mon, 23 Aug 2010 23:15:34 -0400

On Fri, 20 Aug 2010 20:50:01 -0700 Jan Muszynski wrote:

> What you show is virtualbox-ose. Compare to PUEL. And no, you can't
> say it's a bug in the PUEL implementation. Note that when you run
> /etc/init.d/vboxdrv setup it:
> 1) Does use dkms if it's available
> 2) Explicitly processes the drivers in order
> Anyway:
> 
> ls /var/lib/dkms
> dkms_dbversion  nvidia  vboxdrv  vboxnetadp  vboxnetflt
> 
> apt-show-versions -a virtualbox-3.2
> virtualbox-3.2 3.2.8-64453~Debian~lenny install ok installed
> virtualbox-3.2 3.2.8-64453~Debian~lenny lenny download.virtualbox.org
> No testing version
> No unstable version
> virtualbox-3.2/lenny uptodate 3.2.8-64453~Debian~lenny
> 
> 
> The issue that I originally filed this on obviously isn't critical.
> For my own purposes I can easily correct this. The general issue
> remains though. What order should the various dkms modules get
> compiled in? I think the only logical order is sorted alpha, since if
> there are modules with inter-related dependencies that would be what
> they logically would use. For other, standalone, modules the order
> doesn't matter so it's no harm no foul.
> 
> Bottom line it's a simple change and I don't see how it could possibly
> hurt anything, so I'm unable to understand the resistance/reluctance
> to implement it.

yes, your suggested change is simple; however, it doesn't generalize
since module names won't necessarily be alphabetical. 

however, the core problem here is that the PUEL (Personal Use Evaluation
License) version of virtualbox is not provided by debian, and thus we
can't directly support it.  for the bugs you find in that, you need to
submit reports to the upstream bug system directly.

thanks,
mike

Message #36 received at 586725-quiet@bugs.debian.org (full text, mbox, reply):

From: Jan Muszynski <gmail@jancm.org>

To: Michael Gilbert <michael.s.gilbert@gmail.com>, 586725-quiet@bugs.debian.org

Subject: Re: Bug#586725: [Pkg-dkms-maint] Bug#586725: closed by Michael Gilbert <michael.s.gilbert@gmail.com> (re: dkms attempts to install modules in wrong order)

Date: Tue, 24 Aug 2010 20:07:03 -0700

On Mon, Aug 23, 2010 at 8:15 PM, Michael Gilbert
<michael.s.gilbert@gmail.com> wrote:
> On Fri, 20 Aug 2010 20:50:01 -0700 Jan Muszynski wrote:
>
>> What you show is virtualbox-ose. Compare to PUEL. And no, you can't
>> say it's a bug in the PUEL implementation. Note that when you run
>> /etc/init.d/vboxdrv setup it:
>> 1) Does use dkms if it's available
>> 2) Explicitly processes the drivers in order
>> Anyway:
>>
>> ls /var/lib/dkms
>> dkms_dbversion  nvidia  vboxdrv  vboxnetadp  vboxnetflt
>>
>> apt-show-versions -a virtualbox-3.2
>> virtualbox-3.2 3.2.8-64453~Debian~lenny install ok installed
>> virtualbox-3.2 3.2.8-64453~Debian~lenny lenny download.virtualbox.org
>> No testing version
>> No unstable version
>> virtualbox-3.2/lenny uptodate 3.2.8-64453~Debian~lenny
>>
>>
>> The issue that I originally filed this on obviously isn't critical.
>> For my own purposes I can easily correct this. The general issue
>> remains though. What order should the various dkms modules get
>> compiled in? I think the only logical order is sorted alpha, since if
>> there are modules with inter-related dependencies that would be what
>> they logically would use. For other, standalone, modules the order
>> doesn't matter so it's no harm no foul.
>>
>> Bottom line it's a simple change and I don't see how it could possibly
>> hurt anything, so I'm unable to understand the resistance/reluctance
>> to implement it.
>
> yes, your suggested change is simple; however, it doesn't generalize
> since module names won't necessarily be alphabetical.
>
> however, the core problem here is that the PUEL (Personal Use Evaluation
> License) version of virtualbox is not provided by debian, and thus we
> can't directly support it.  for the bugs you find in that, you need to
> submit reports to the upstream bug system directly.

1) I don't think you can classify this as a "bug" in PUEL :)
2) I'm not asking you to "directly support it". The support is a side effect.

All that aside answer me this question, because it's not obvious to
me. What order does the find command return the listing in? It's
consistent so there's some order to it, but I can't determine what it
is.

I get (for the above directory):

dkms$ find  . -maxdepth 1 -mindepth 1 -type d -a -not -name original_module
./vboxnetadp
./vboxnetflt
./nvidia
./vboxdrv

It's not time based:
drwxr-xr-x  3 root root 4096 Aug 24 11:17 nvidia
drwxr-xr-x  3 root root 4096 Aug 24 11:20 vboxdrv
drwxr-xr-x  3 root root 4096 Aug 24 11:20 vboxnetadp
drwxr-xr-x  3 root root 4096 Aug 24 11:20 vboxnetflt


As far as module name not necessarily being alpha then what other
order could be used for a system where one module depends on another
(that would make logical sense). For cases where there's no dependency
then obviously the order doesn't matter. However tell me what order
find uses and I'll deal with the issue from that direction.

thanks
-jan

Message #41 received at 586725@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <michael.s.gilbert@gmail.com>

To: 586725@bugs.debian.org, 586725-submitter@bugs.debian.org

Subject: Re: Bug#586725: [Pkg-dkms-maint] Bug#586725: closed by Michael Gilbert <michael.s.gilbert@gmail.com> (re: dkms attempts to install modules in wrong order)

Date: Tue, 24 Aug 2010 23:51:03 -0400

On Tue, 24 Aug 2010 20:07:03 -0700 Jan Muszynski wrote:

> On Mon, Aug 23, 2010 at 8:15 PM, Michael Gilbert
> <michael.s.gilbert@gmail.com> wrote:
> > On Fri, 20 Aug 2010 20:50:01 -0700 Jan Muszynski wrote:
> >
> >> What you show is virtualbox-ose. Compare to PUEL. And no, you can't
> >> say it's a bug in the PUEL implementation. Note that when you run
> >> /etc/init.d/vboxdrv setup it:
> >> 1) Does use dkms if it's available
> >> 2) Explicitly processes the drivers in order
> >> Anyway:
> >>
> >> ls /var/lib/dkms
> >> dkms_dbversion  nvidia  vboxdrv  vboxnetadp  vboxnetflt
> >>
> >> apt-show-versions -a virtualbox-3.2
> >> virtualbox-3.2 3.2.8-64453~Debian~lenny install ok installed
> >> virtualbox-3.2 3.2.8-64453~Debian~lenny lenny download.virtualbox.org
> >> No testing version
> >> No unstable version
> >> virtualbox-3.2/lenny uptodate 3.2.8-64453~Debian~lenny
> >>
> >>
> >> The issue that I originally filed this on obviously isn't critical.
> >> For my own purposes I can easily correct this. The general issue
> >> remains though. What order should the various dkms modules get
> >> compiled in? I think the only logical order is sorted alpha, since if
> >> there are modules with inter-related dependencies that would be what
> >> they logically would use. For other, standalone, modules the order
> >> doesn't matter so it's no harm no foul.
> >>
> >> Bottom line it's a simple change and I don't see how it could possibly
> >> hurt anything, so I'm unable to understand the resistance/reluctance
> >> to implement it.
> >
> > yes, your suggested change is simple; however, it doesn't generalize
> > since module names won't necessarily be alphabetical.
> >
> > however, the core problem here is that the PUEL (Personal Use Evaluation
> > License) version of virtualbox is not provided by debian, and thus we
> > can't directly support it.  for the bugs you find in that, you need to
> > submit reports to the upstream bug system directly.
> 
> 1) I don't think you can classify this as a "bug" in PUEL :)

it's a bug in PUEL since it expects dkms to behave in a way that isn't
necessarily guaranteed. this problem has already been solved in the
debian-supported virtualbox-ose package. you should suggest to PUEL
upstream to adopt the existing fix.

> 2) I'm not asking you to "directly support it". The support is a side effect.

we can't possibly anticipate/handle all cases of bad behavior in dkms
using tools (especially for proprietary variants). the bad behavior
itself should be fixed directly in the offending application.

> All that aside answer me this question, because it's not obvious to
> me. What order does the find command return the listing in? It's
> consistent so there's some order to it, but I can't determine what it
> is.
> 
> I get (for the above directory):
> 
> dkms$ find  . -maxdepth 1 -mindepth 1 -type d -a -not -name original_module
> ./vboxnetadp
> ./vboxnetflt
> ./nvidia
> ./vboxdrv
> 
> It's not time based:
> drwxr-xr-x  3 root root 4096 Aug 24 11:17 nvidia
> drwxr-xr-x  3 root root 4096 Aug 24 11:20 vboxdrv
> drwxr-xr-x  3 root root 4096 Aug 24 11:20 vboxnetadp
> drwxr-xr-x  3 root root 4096 Aug 24 11:20 vboxnetflt

find is highly optimized, and its output order is highly dependent on
the layout of low-level file system structures.  there is no guarantee
of any particular order.

mike

Message #53 received at 586725@bugs.debian.org (full text, mbox, reply):

From: denk@post.com

To: 586725@bugs.debian.org

Subject: Fixed with VirtualBox 3.2.10 PUEL

Date: Mon, 11 Oct 2010 16:21:01 -0400

Hi, 
 
the problem is fixed with the new release 3.2.10 as of the three single
dkms modules have been merged into only one! 
 
denk 

Send a report that this bug log contains spam.