* bug#32167: Kernel 'build' directory in the store is a broken symbolic link @ 2018-07-15 20:07 pkill9 2018-07-15 21:32 ` Nils Gillmann 2018-07-16 17:55 ` pkill9 0 siblings, 2 replies; 8+ messages in thread From: pkill9 @ 2018-07-15 20:07 UTC (permalink / raw) To: 32167 /run/booted-system/kernel/lib/modules/<kernel version>/build is a broken symbolic link. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#32167: Kernel 'build' directory in the store is a broken symbolic link 2018-07-15 20:07 bug#32167: Kernel 'build' directory in the store is a broken symbolic link pkill9 @ 2018-07-15 21:32 ` Nils Gillmann 2018-07-16 17:55 ` pkill9 1 sibling, 0 replies; 8+ messages in thread From: Nils Gillmann @ 2018-07-15 21:32 UTC (permalink / raw) To: pkill9; +Cc: 32167 pkill9@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#32167: Kernel 'build' directory in the store is a broken symbolic link 2018-07-15 20:07 bug#32167: Kernel 'build' directory in the store is a broken symbolic link pkill9 2018-07-15 21:32 ` Nils Gillmann @ 2018-07-16 17:55 ` pkill9 2018-07-16 18:15 ` Danny Milosavljevic 1 sibling, 1 reply; 8+ messages in thread From: pkill9 @ 2018-07-16 17:55 UTC (permalink / raw) To: 32167 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#32167: Kernel 'build' directory in the store is a broken symbolic link 2018-07-16 17:55 ` pkill9 @ 2018-07-16 18:15 ` Danny Milosavljevic 2018-07-16 22:03 ` Mark H Weaver 0 siblings, 1 reply; 8+ messages in thread From: Danny Milosavljevic @ 2018-07-16 18:15 UTC (permalink / raw) To: pkill9; +Cc: 32167 [-- Attachment #1: Type: text/plain, Size: 390 bytes --] On Mon, 16 Jul 2018 18:55:11 +0100 (BST) <pkill9@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. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#32167: Kernel 'build' directory in the store is a broken symbolic link 2018-07-16 18:15 ` Danny Milosavljevic @ 2018-07-16 22:03 ` Mark H Weaver 2018-07-16 23:10 ` pkill9 2018-07-23 13:00 ` Ludovic Courtès 0 siblings, 2 replies; 8+ messages in thread From: Mark H Weaver @ 2018-07-16 22:03 UTC (permalink / raw) To: Danny Milosavljevic; +Cc: 32167, pkill9 Danny Milosavljevic <dannym@scratchpost.org> writes: > On Mon, 16 Jul 2018 18:55:11 +0100 (BST) > <pkill9@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#32167: Kernel 'build' directory in the store is a broken symbolic link 2018-07-16 22:03 ` Mark H Weaver @ 2018-07-16 23:10 ` pkill9 2018-07-23 13:00 ` Ludovic Courtès 1 sibling, 0 replies; 8+ messages in thread From: pkill9 @ 2018-07-16 23:10 UTC (permalink / raw) To: Mark H Weaver; +Cc: 32167, pkill9 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@netris.org> wrote: > Danny Milosavljevic <dannym@scratchpost.org> writes: > > > On Mon, 16 Jul 2018 18:55:11 +0100 (BST) > > <pkill9@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#32167: Kernel 'build' directory in the store is a broken symbolic link 2018-07-16 22:03 ` Mark H Weaver 2018-07-16 23:10 ` pkill9 @ 2018-07-23 13:00 ` Ludovic Courtès 2021-09-25 0:51 ` Sarah Morgensen 1 sibling, 1 reply; 8+ messages in thread From: Ludovic Courtès @ 2018-07-23 13:00 UTC (permalink / raw) To: Mark H Weaver; +Cc: 32167, pkill9 Hi, Mark H Weaver <mhw@netris.org> skribis: > Danny Milosavljevic <dannym@scratchpost.org> writes: > >> On Mon, 16 Jul 2018 18:55:11 +0100 (BST) >> <pkill9@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’. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#32167: Kernel 'build' directory in the store is a broken symbolic link 2018-07-23 13:00 ` Ludovic Courtès @ 2021-09-25 0:51 ` Sarah Morgensen 0 siblings, 0 replies; 8+ messages in thread From: Sarah Morgensen @ 2021-09-25 0:51 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 32167-done, pkill9 Hi all, ludo@gnu.org (Ludovic Courtès) writes: > Hi, > > Mark H Weaver <mhw@netris.org> skribis: > >> Danny Milosavljevic <dannym@scratchpost.org> writes: >> >>> On Mon, 16 Jul 2018 18:55:11 +0100 (BST) >>> <pkill9@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-25 0:52 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-07-15 20:07 bug#32167: Kernel 'build' directory in the store is a broken symbolic link pkill9 2018-07-15 21:32 ` Nils Gillmann 2018-07-16 17:55 ` pkill9 2018-07-16 18:15 ` Danny Milosavljevic 2018-07-16 22:03 ` Mark H Weaver 2018-07-16 23:10 ` pkill9 2018-07-23 13:00 ` Ludovic Courtès 2021-09-25 0:51 ` Sarah Morgensen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).