Debian Bug report logs - #629245
kernel-package: linux-headers packages do not contain symlinks in /lib/modules/<version>

Toggle useless messages

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

From: Kevin Mitchell <kevmitch@math.sfu.ca>

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

Subject: kernel-package: linux-headers packages do not contain symlinks in /lib/modules/<version>

Date: Sat, 04 Jun 2011 13:13:06 -0700

Package: kernel-package
Version: 12.036+nmu1
Severity: normal

Both kernel_image and kernel_header targets are made with

make-kpkg --rootcmd=fakeroot --append-to-version=.03 kernel_image kernel_headers

However, the resulting
linux-headers-3.0.0-rc1.03+_3.0.0-rc1.03+-10.00.Custom_amd64.deb package
does not contain symlinks which are presetnt in stock Debian headers
packages:

/lib/modules/3.0.0-rc1.03+/source -> /usr/src/linux-headers-3.0.0-rc1.03+/
/lib/modules/3.0.0-rc1.03+/build  -> /usr/src/linux-headers-3.0.0-rc1.03+/

Instead, the linux-image-3.0.0-rc1.03+_3.0.0-rc1.03+-10.00.Custom_amd64.deb package contains 
/lib/modules/3.0.0-rc1.03+/source -> <host build dir>
/lib/modules/3.0.0-rc1.03+/build -> <host build dir>

As a reuslt if both the image and headers packages are deployed to a
different machine, or the original build dir is moved or modified,
building modules against the compiled kernel fails. The workaround is to
manually redirect the symlinks to the headers directory.



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-rc1.02+ (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kernel-package depends on:
ii  binutils              2.21.51.20110523-1 The GNU assembler, linker and bina
ii  build-essential       11.5               Informational list of build-essent
ii  debianutils           4.0.1              Miscellaneous utilities specific t
ii  file                  5.04-5+b1          Determines file type using "magic"
ii  gettext               0.18.1.1-3         GNU Internationalization utilities
ii  make                  3.81-8.1           An utility for Directing compilati
ii  module-init-tools     3.16-1             tools for managing Linux kernel mo
ii  po-debconf            1.0.16+nmu1        tool for managing templates file t
ii  util-linux            2.17.2-9.1         Miscellaneous system utilities

Versions of packages kernel-package recommends:
ii  cpio                          2.11-7     GNU cpio -- a program to manage ar

Versions of packages kernel-package suggests:
pn  btrfs-tools                   <none>     (no description available)
ii  bzip2                         1.0.5-6    high-quality block-sorting file co
pn  docbook-utils                 <none>     (no description available)
ii  e2fsprogs                     1.41.12-4  ext2/ext3/ext4 file system utiliti
pn  grub | grub2                  <none>     (no description available)
ii  initramfs-tools [linux-initra 0.99       tools for generating an initramfs
pn  jfsutils                      <none>     (no description available)
pn  libncurses-dev                <none>     (no description available)
pn  linux-source | kernel-source  <none>     (no description available)
pn  mcelog                        <none>     (no description available)
pn  oprofile                      <none>     (no description available)
pn  pcmciautils                   <none>     (no description available)
pn  ppp                           <none>     (no description available)
ii  procps                        1:3.2.8-10 /proc file system utilities
pn  quota                         <none>     (no description available)
pn  reiserfsprogs                 <none>     (no description available)
pn  squashfs-tools                <none>     (no description available)
ii  udev                          170-1      /dev/ and hotplug management daemo
pn  xfsprogs                      <none>     (no description available)
pn  xmlto                         <none>     (no description available)

-- no debconf information

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

From: Adam Borowski <kilobyte@angband.pl>

To: 629245@bugs.debian.org

Subject: the symlinks are there, pointing to a wrong place

Date: Sat, 16 Mar 2013 03:23:09 +0100

ls -al /lib/modules/3.8.2-x32
[...]
lrwxrwxrwx 1 root root     36 Sep 27 04:09 build -> /home/kilobyte/tmp/kernel/linux-source-3.8
lrwxrwxrwx 1 root root     37 Sep 27 04:09 source -> /home/kilobyte/tmp/kernel/linux-source-3.8

... which may initially work, before you clean up the directory you compiled
in.  Obviously, if the package is copied to another machine, chances for it
ever working are rather low.

Please fix, this breaks dkms among others.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ

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

From: David Nielson <naptastic@gmail.com>

To: 629245@bugs.debian.org

Subject: I believe I'm being affected by this bug.

Date: Thu, 06 Jun 2013 22:44:26 -0500

On one VirtualBox instance, I compiled linux-image and linux-headers 
packages. They install just fine on that machine. I copied them to 
another VirtualBox machine set up basically the same, and it would not 
install successfully. It says it can't be installed because it depends 
on itself, and it's not installed. (lol)

[root]@[debserver][22:40:26][~]# dpkg -i 
linux-headers-3.9.4-debserver_3.9.4-debserver-10.00.Custom_amd64.deb

Selecting previously unselected package linux-headers-3.9.4-debserver.
(Reading database ... 58155 files and directories currently installed.)
Unpacking linux-headers-3.9.4-debserver (from 
linux-headers-3.9.4-debserver_3.9.4-debserver-10.00.Custom_amd64.deb) ...
Setting up linux-headers-3.9.4-debserver (3.9.4-debserver-10.00.Custom) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.9.4-debserver 
/boot/vmlinuz-3.9.4-debserver
Error! Your kernel headers for kernel 3.9.4-debserver cannot be found.
Please install the linux-headers-3.9.4-debserver package,
or use the --kernelsourcedir option to tell DKMS where it's located

Questions:

- Can you provide more information about the workaround?

- Is there any way I (as a non-coder) can accelerate this bug getting fixed?

Thanks,

David Nielson

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

From: Manoj Srivastava <srivasta@acm.org>

To: Kevin Mitchell <kevmitch@math.sfu.ca>

Cc: 629245-done@bugs.debian.org

Subject: Re: Bug#629245: kernel-package: linux-headers packages do not contain symlinks in /lib/modules/<version>

Date: Mon, 05 May 2014 02:06:04 -0700

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

On Sat, Jun 04 2011, Kevin Mitchell wrote:

> Package: kernel-package
> Version: 12.036+nmu1
> Severity: normal
>
> Both kernel_image and kernel_header targets are made with
>
> make-kpkg --rootcmd=fakeroot --append-to-version=.03 kernel_image kernel_headers
>
> However, the resulting
> linux-headers-3.0.0-rc1.03+_3.0.0-rc1.03+-10.00.Custom_amd64.deb package
> does not contain symlinks which are presetnt in stock Debian headers
> packages:

> /lib/modules/3.0.0-rc1.03+/source -> /usr/src/linux-headers-3.0.0-rc1.03+/
> /lib/modules/3.0.0-rc1.03+/build  -> /usr/src/linux-headers-3.0.0-rc1.03+/

> Instead, the linux-image-3.0.0-rc1.03+_3.0.0-rc1.03+-10.00.Custom_amd64.deb package contains 
> /lib/modules/3.0.0-rc1.03+/source -> <host build dir>
> /lib/modules/3.0.0-rc1.03+/build -> <host build dir>
>
> As a reuslt if both the image and headers packages are deployed to a
> different machine, or the original build dir is moved or modified,
> building modules against the compiled kernel fails. The workaround is to
> manually redirect the symlinks to the headers directory.

        This is actually supposed to work. If you look at the postinst
 scripts.  From man kernel-img.conf(5)
--8<---------------cut here---------------start------------->8---
 relink_build_link
        This option manipulates the build link created by recent
        kernels. If the link is a dangling link, and if a the
        corresponding kernel headers appear to have been installed on
        the system, a new symlink shall be created to point to them. The
        default is to relink the build link (YES).

 force_build_link
        This option manipulates the build link created by recent
        kernels. If the link is a dangling link, a new symlink shall be
        created to point to kernel headers data in /usr/src, whether
        they have been installed or not. The default is unset, we don't
        create potentially dangling symlinks by default.

 relink_src_link
        This option manipulates the source link created by recent
        kernels. If the link is a dangling link it is deleted at install
        time. The default is to relink (delete) the source link (YES).
--8<---------------cut here---------------end--------------->8---


        manoj


-- 
Carmel, New York, has an ordinance forbidding men to wear coats and
trousers that don't match.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

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

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

From: Manoj Srivastava <srivasta@acm.org>

To: Adam Borowski <kilobyte@angband.pl>

Cc: 629245@bugs.debian.org

Subject: Re: Bug#629245: the symlinks are there, pointing to a wrong place

Date: Mon, 05 May 2014 02:07:30 -0700

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

On Sat, Mar 16 2013, Adam Borowski wrote:

> ls -al /lib/modules/3.8.2-x32
> [...]
> lrwxrwxrwx 1 root root     36 Sep 27 04:09 build -> /home/kilobyte/tmp/kernel/linux-source-3.8
> lrwxrwxrwx 1 root root     37 Sep 27 04:09 source -> /home/kilobyte/tmp/kernel/linux-source-3.8

> ... which may initially work, before you clean up the directory you compiled
> in.  Obviously, if the package is copied to another machine, chances for it
> ever working are rather low.

        Actually, not so: The postinst should take care of all this.

> Please fix, this breaks dkms among others.

        The dkms issue might be something else. Do you have full logs
 for that?

        manoj
-- 
"The cure for boredom is curiosity. There is no cure for curiosity."
-Ellen Parr
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

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

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

From: Adam Borowski <kilobyte@angband.pl>

To: 629245@bugs.debian.org

Subject: Re: Bug#629245: the symlinks are there, pointing to a wrong place

Date: Tue, 6 May 2014 00:33:00 +0200

On Mon, May 05, 2014 at 02:07:30AM -0700, Manoj Srivastava wrote:
> On Sat, Mar 16 2013, Adam Borowski wrote:
> 
> > ls -al /lib/modules/3.8.2-x32
> > lrwxrwxrwx 1 root root     36 Sep 27 04:09 build -> /home/kilobyte/tmp/kernel/linux-source-3.8
> > lrwxrwxrwx 1 root root     37 Sep 27 04:09 source -> /home/kilobyte/tmp/kernel/linux-source-3.8
> 
> Actually, not so: The postinst should take care of all this.

The symlinks still point to the build dir as of a week ago, with
kernel-package 12.036+nmu3.  Can't test 13.00* as those versions fail
building the kernel for me due to an unrelated bug (just reported).

> > Please fix, this breaks dkms among others.
> 
> The dkms issue might be something else. Do you have full logs for that?

I don't have kernel build logs due to #747142, DKMS output is:

Loading new virtualbox-4.3.10 DKMS files...
Building only for 3.14.2-x32
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.

If I restore the source to that directory, all works ok.

Should I downgrade kernel-package to produce a full log?

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?

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

From: Manoj Srivastava <srivasta@acm.org>

To: Adam Borowski <kilobyte@angband.pl>

Cc: 629245@bugs.debian.org

Subject: Re: Bug#629245: the symlinks are there, pointing to a wrong place

Date: Tue, 06 May 2014 07:30:58 -0700

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

On Tue, May 06 2014, Adam Borowski wrote:

> On Mon, May 05, 2014 at 02:07:30AM -0700, Manoj Srivastava wrote:
>> On Sat, Mar 16 2013, Adam Borowski wrote:
>> 
>> > ls -al /lib/modules/3.8.2-x32
>> > lrwxrwxrwx 1 root root     36 Sep 27 04:09 build -> /home/kilobyte/tmp/kernel/linux-source-3.8
>> > lrwxrwxrwx 1 root root     37 Sep 27 04:09 source -> /home/kilobyte/tmp/kernel/linux-source-3.8
>> 
>> Actually, not so: The postinst should take care of all this.
>
> The symlinks still point to the build dir as of a week ago, with
> kernel-package 12.036+nmu3.  Can't test 13.00* as those versions fail
> building the kernel for me due to an unrelated bug (just reported).

        If this is not your build machine, are the symlinks dangling?
 The image package postinst is supposed to remove them.

        If it is your build machine, then this is the current behaviour
 to leave the links pointing to your build directory. This can of course
 be overridden by adding your own postint file to the postinst.d
 drectory. 

>> > Please fix, this breaks dkms among others.
>> 
>> The dkms issue might be something else. Do you have full logs for that?
>
> I don't have kernel build logs due to #747142, DKMS output is:

> Loading new virtualbox-4.3.10 DKMS files...
> Building only for 3.14.2-x32
> Module build for the currently running kernel was skipped since the
> kernel source for this kernel does not seem to be installed.

> If I restore the source to that directory, all works ok.
>
> Should I downgrade kernel-package to produce a full log?

        No, I think I would much rather figure out why the new version
 is not working for you. I have been unable to reproduce the problems,
 and these are the kernels I have built:

6112 /usr/local/src/kernel/linux-image-2.6.39-glaurung_2.6.39-glaurung-10.00.Custom_amd64.deb
5840 /usr/local/src/kernel/linux-image-3.15.0-rc4-00200-g2080cee_3.15.0-rc4-00200-g2080cee-10.00.Custom_amd64.deb
5828 /usr/local/src/kernel/linux-image-3.15.0-rc4_3.15.0-rc4-10.00.Custom_amd64.deb
5664 /usr/local/src/kernel/linux-image-3.15.0-rc4-dbg_3.15.0-rc4-10.00.Custom_amd64.deb


        manoj
-- 
I attribute my success to intelligence, guts, determination, honesty,
ambition, and having enough money to buy people with those qualities.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

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

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

From: Adam Borowski <kilobyte@angband.pl>

To: 629245@bugs.debian.org

Subject: Re: Bug#629245: the symlinks are there, pointing to a wrong place

Date: Sat, 10 May 2014 03:20:01 +0200

On Tue, May 06, 2014 at 07:30:58AM -0700, Manoj Srivastava wrote:
> On Tue, May 06 2014, Adam Borowski wrote:
> 
> > On Mon, May 05, 2014 at 02:07:30AM -0700, Manoj Srivastava wrote:
> >> On Sat, Mar 16 2013, Adam Borowski wrote:
> >> 
> >> > ls -al /lib/modules/3.8.2-x32
> >> > lrwxrwxrwx 1 root root     36 Sep 27 04:09 build -> /home/kilobyte/tmp/kernel/linux-source-3.8
> >> > lrwxrwxrwx 1 root root     37 Sep 27 04:09 source -> /home/kilobyte/tmp/kernel/linux-source-3.8
> 
>         If this is not your build machine, are the symlinks dangling?
>  The image package postinst is supposed to remove them.

On machines other than the build one, the "source" symlink has been removed,
the "build" one correctly goes to /usr/src/linux-headers-3.14.3-x32

>         If it is your build machine, then this is the current behaviour
>  to leave the links pointing to your build directory. This can of course
>  be overridden by adding your own postint file to the postinst.d
>  drectory. 

On the build machine, both "source" and "build" point to the directory the
kernel happened to be built in, in my case in a directory owned by an user
other than root.  This leads to failures:

* if I delete the unpacked sources, dkms fails to find installed
  linux-headers-XXX.  This is likely when using packaged linux-source which
  embeds its version number in its top directory's name.

* if I checkout some other version, dkms will build against the currently
  unpacked tree rather than installed linux-headers-XXX.  This is likely
  when building from git.


-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?

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

From: Manoj Srivastava <srivasta@acm.org>

To: Adam Borowski <kilobyte@angband.pl>

Cc: 629245@bugs.debian.org

Subject: Re: Bug#629245: the symlinks are there, pointing to a wrong place

Date: Fri, 09 May 2014 23:38:39 -0700

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

On Sat, May 10 2014, Adam Borowski wrote:

> On Tue, May 06, 2014 at 07:30:58AM -0700, Manoj Srivastava wrote:
>> On Tue, May 06 2014, Adam Borowski wrote:
>> 
>> > On Mon, May 05, 2014 at 02:07:30AM -0700, Manoj Srivastava wrote:
>> >> On Sat, Mar 16 2013, Adam Borowski wrote:
>> >> 
>> >> > ls -al /lib/modules/3.8.2-x32
>> >> > lrwxrwxrwx 1 root root     36 Sep 27 04:09 build -> /home/kilobyte/tmp/kernel/linux-source-3.8
>> >> > lrwxrwxrwx 1 root root     37 Sep 27 04:09 source -> /home/kilobyte/tmp/kernel/linux-source-3.8
>> 
>>         If this is not your build machine, are the symlinks dangling?
>>  The image package postinst is supposed to remove them.
>
> On machines other than the build one, the "source" symlink has been removed,
> the "build" one correctly goes to /usr/src/linux-headers-3.14.3-x32

        OK, so that is working correctly, am I right?


>>         If it is your build machine, then this is the current behaviour
>>  to leave the links pointing to your build directory. This can of course
>>  be overridden by adding your own postint file to the postinst.d
>>  drectory. 

> On the build machine, both "source" and "build" point to the directory the
> kernel happened to be built in, in my case in a directory owned by an user
> other than root.

        This is what I would expect, yes

>            This leads to failures:

> * if I delete the unpacked sources, dkms fails to find installed
>   linux-headers-XXX.  This is likely when using packaged linux-source which
>   embeds its version number in its top directory's name.

        Perhaps it prefers the source link, which is now dangling? I
 suppose is you  delete the source directory where the build is you
 currently need to also delete the source link. Yuck. I tend to keep a
 shallow clone source directories of active kernels around, but that is
 not something that can be reasonably required.

> * if I checkout some other version, dkms will build against the currently
>   unpacked tree rather than installed linux-headers-XXX.  This is likely
>   when building from git.

        I am guessing the source link continues to point to the git
 tree.

        What behaviour would youlike to see on the machine where you
 build sources? not install the links pointing to the current build
 tree? I personally find that convenient, since I just build and install
 image packages, and leave sources lying aroung.

        Perhaps another kernel-img.conf option to just delete the
 symlinks?  We already have:
--8<---------------cut here---------------start------------->8---

 relink_build_link
        This option manipulates the build link created by recent
        kernels. If the link is a dangling link, and if a the
        corresponding kernel headers appear to have been installed on
        the system, a new symlink shall be created to point to them. The
        default is to relink the build link (YES).

 force_build_link
        This option manipulates the build link created by recent
        kernels. If the link is a dangling link, a new symlink shall be
        created to point to kernel headers data in /usr/src, whether
        they have been installed or not. The default is unset, we don't
        create potentially dangling symlinks by default.

 relink_src_link
        This option manipulates the source link created by recent
        kernels. If the link is a dangling link it is deleted at install
        time. The default is to relink (delete) the source link (YES).
--8<---------------cut here---------------end--------------->8---

        manoj
-- 
I never made a mistake in my life.  I thought I did once, but I was
wrong. Lucy Van Pelt
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

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

Send a report that this bug log contains spam.