GNU bug report logs -
#32167
Kernel 'build' directory in the store is a broken symbolic link
Previous Next
Reported by: <pkill9 <at> runbox.com>
Date: Sun, 15 Jul 2018 20:09:02 UTC
Severity: normal
Done: Sarah Morgensen <iskarian <at> mgsn.dev>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32167 in the body.
You can then email your comments to 32167 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#32167
; Package
guix
.
(Sun, 15 Jul 2018 20:09:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
<pkill9 <at> runbox.com>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 15 Jul 2018 20:09:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
/run/booted-system/kernel/lib/modules/<kernel version>/build is a broken symbolic link.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32167
; Package
guix
.
(Sun, 15 Jul 2018 21:33:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 32167 <at> debbugs.gnu.org (full text, mbox):
pkill9 <at> runbox.com transcribed 94 bytes:
> /run/booted-system/kernel/lib/modules/<kernel version>/build is a broken symbolic link.
Yep. This is not a bug until it comes to what you are possibly trying to attempt,
build a software which relies on your *current* kernel sources.
For a solution I can point to the Nix package for linux, where they deal with this
within the kernel package, for firmware and more. Because I'm short on time these
days I haven't sent a patch yet but I can confirm the issues you probably ran into
as I had them many months back already.
Mark, you are mostly responsible for the linux module in Guix.
Besides my own notes, this was relevant:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/manual-config.nix#L161
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32167
; Package
guix
.
(Mon, 16 Jul 2018 17:57:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 32167 <at> debbugs.gnu.org (full text, mbox):
It would be good to keep the build directory though, since it's expected to exist, and it's easier to just download a module's source and compile it and test it.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32167
; Package
guix
.
(Mon, 16 Jul 2018 18:16:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 32167 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 16 Jul 2018 18:55:11 +0100 (BST)
<pkill9 <at> runbox.com> wrote:
> It would be good to keep the build directory though, since it's expected to exist, and it's easier to just download a module's source and compile it and test it.
I agree.
/run/booted-system/kernel/lib/modules/4.17.3-gnu is in the store anyway so it will be seen by the GC.
The fix would be in linux-libre.
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32167
; Package
guix
.
(Mon, 16 Jul 2018 22:06:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 32167 <at> debbugs.gnu.org (full text, mbox):
Danny Milosavljevic <dannym <at> scratchpost.org> writes:
> On Mon, 16 Jul 2018 18:55:11 +0100 (BST)
> <pkill9 <at> runbox.com> wrote:
>
>> It would be good to keep the build directory though, since it's
>> expected to exist, and it's easier to just download a module's
>> source and compile it and test it.
>
> I agree.
>
> /run/booted-system/kernel/lib/modules/4.17.3-gnu is in the store
> anyway so it will be seen by the GC.
>
> The fix would be in linux-libre.
If we were to preserve the kernel build directory as a store item, and
keep a link from the modules directory to the build directory, that
would greatly increase the size of the most minimal system that users
could build.
The unpacked linux-libre-4.17 source directory is 929 megabytes, and
that's before building it. So, keeping the build directory would surely
increase the closure size of the most minimal system by more than a
gigabyte. I don't think it's okay to force all Guix users to pay that
price. Some users will need to build minimal systems.
I'd like to hear more specifics about what the original poster is trying
to accomplish here. It's possible that they simply noticed the broken
links and wanted to let us know. In that case, it's probably best to
simply delete those broken symlinks.
If the intent here is to allow support for out-of-tree kernel modules,
then fixing these symlinks would not solve the problem, and it's not
clear to me that fixing them would be part of a proper solution on
GuixSD. GuixSD is not a system where you can simply compile a kernel
module manually and install it, because our module directory is
immutable. If the goal is to support building out-of-tree kernel
modules, that's a separate discussion that deserves its own "wishlist"
bug report, I think.
Thoughts?
Mark
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32167
; Package
guix
.
(Mon, 16 Jul 2018 23:11:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 32167 <at> debbugs.gnu.org (full text, mbox):
Yes I agree with you, since it is a lot of space then it's probably best to just delete the symlink.
The reasoning behind my suggestion of keeping it is mostly for convenience in compiling/testing an external kernel module, i.e. just downloading the source and then compiling it with the currently running kernel, and then loading it to test it.
Come to think of it, could the build directory be put in another output of the linux-libre package?
On Mon, 16 Jul 2018 18:03:58 -0400, Mark H Weaver <mhw <at> netris.org> wrote:
> Danny Milosavljevic <dannym <at> scratchpost.org> writes:
>
> > On Mon, 16 Jul 2018 18:55:11 +0100 (BST)
> > <pkill9 <at> runbox.com> wrote:
> >
> >> It would be good to keep the build directory though, since it's
> >> expected to exist, and it's easier to just download a module's
> >> source and compile it and test it.
> >
> > I agree.
> >
> > /run/booted-system/kernel/lib/modules/4.17.3-gnu is in the store
> > anyway so it will be seen by the GC.
> >
> > The fix would be in linux-libre.
>
> If we were to preserve the kernel build directory as a store item, and
> keep a link from the modules directory to the build directory, that
> would greatly increase the size of the most minimal system that users
> could build.
>
> The unpacked linux-libre-4.17 source directory is 929 megabytes, and
> that's before building it. So, keeping the build directory would surely
> increase the closure size of the most minimal system by more than a
> gigabyte. I don't think it's okay to force all Guix users to pay that
> price. Some users will need to build minimal systems.
>
> I'd like to hear more specifics about what the original poster is trying
> to accomplish here. It's possible that they simply noticed the broken
> links and wanted to let us know. In that case, it's probably best to
> simply delete those broken symlinks.
>
> If the intent here is to allow support for out-of-tree kernel modules,
> then fixing these symlinks would not solve the problem, and it's not
> clear to me that fixing them would be part of a proper solution on
> GuixSD. GuixSD is not a system where you can simply compile a kernel
> module manually and install it, because our module directory is
> immutable. If the goal is to support building out-of-tree kernel
> modules, that's a separate discussion that deserves its own "wishlist"
> bug report, I think.
>
> Thoughts?
>
> Mark
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32167
; Package
guix
.
(Mon, 23 Jul 2018 13:02:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 32167 <at> debbugs.gnu.org (full text, mbox):
Hi,
Mark H Weaver <mhw <at> netris.org> skribis:
> Danny Milosavljevic <dannym <at> scratchpost.org> writes:
>
>> On Mon, 16 Jul 2018 18:55:11 +0100 (BST)
>> <pkill9 <at> runbox.com> wrote:
>>
>>> It would be good to keep the build directory though, since it's
>>> expected to exist, and it's easier to just download a module's
>>> source and compile it and test it.
>>
>> I agree.
>>
>> /run/booted-system/kernel/lib/modules/4.17.3-gnu is in the store
>> anyway so it will be seen by the GC.
>>
>> The fix would be in linux-libre.
>
> If we were to preserve the kernel build directory as a store item, and
> keep a link from the modules directory to the build directory, that
> would greatly increase the size of the most minimal system that users
> could build.
Yeah, we shouldn’t do that IMO.
> If the intent here is to allow support for out-of-tree kernel modules,
> then fixing these symlinks would not solve the problem, and it's not
> clear to me that fixing them would be part of a proper solution on
> GuixSD. GuixSD is not a system where you can simply compile a kernel
> module manually and install it, because our module directory is
> immutable. If the goal is to support building out-of-tree kernel
> modules, that's a separate discussion that deserves its own "wishlist"
> bug report, I think.
I agree.
Ludo’.
Reply sent
to
Sarah Morgensen <iskarian <at> mgsn.dev>
:
You have taken responsibility.
(Sat, 25 Sep 2021 00:52:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
<pkill9 <at> runbox.com>
:
bug acknowledged by developer.
(Sat, 25 Sep 2021 00:52:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 32167-done <at> debbugs.gnu.org (full text, mbox):
Hi all,
ludo <at> gnu.org (Ludovic Courtès) writes:
> Hi,
>
> Mark H Weaver <mhw <at> netris.org> skribis:
>
>> Danny Milosavljevic <dannym <at> scratchpost.org> writes:
>>
>>> On Mon, 16 Jul 2018 18:55:11 +0100 (BST)
>>> <pkill9 <at> runbox.com> wrote:
>>>
>>>> It would be good to keep the build directory though, since it's
>>>> expected to exist, and it's easier to just download a module's
>>>> source and compile it and test it.
>>>
>>> I agree.
>>>
>>> /run/booted-system/kernel/lib/modules/4.17.3-gnu is in the store
>>> anyway so it will be seen by the GC.
>>>
>>> The fix would be in linux-libre.
>>
>> If we were to preserve the kernel build directory as a store item, and
>> keep a link from the modules directory to the build directory, that
>> would greatly increase the size of the most minimal system that users
>> could build.
>
> Yeah, we shouldn’t do that IMO.
>
>> If the intent here is to allow support for out-of-tree kernel modules,
>> then fixing these symlinks would not solve the problem, and it's not
>> clear to me that fixing them would be part of a proper solution on
>> GuixSD. GuixSD is not a system where you can simply compile a kernel
>> module manually and install it, because our module directory is
>> immutable. If the goal is to support building out-of-tree kernel
>> modules, that's a separate discussion that deserves its own "wishlist"
>> bug report, I think.
>
> I agree.
>
> Ludo’.
I am closing this old bug since the broken 'build' symlink no longer
exists (nor do any other broken symlinks, as far as I can tell).
As for building out-of-tree kernel modules, we now have
linux-module-build-system, which uses `make-linux-module-builder', which
builds the 'build' directory straight from the linux source with `make
modules_prepare'. There are some improvements to be had there, for
sure, but like mentioned above, that deserves its own wishlist item.
--
Sarah
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 23 Oct 2021 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 179 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.