The programs provided by packages in the modutils virtual are not strictly required for a working system, as many users choose to build their kernels without modules. Furthermore, most packages explicitly depend on virtual/modutils when they need support for loading modules, including virtual/udev[kmod] (kmod is default-on here), and anything inheriting the linux-mod eclass on Linux kernels. I informally discussed this with ssuominen on IRC, and he seemed to agree that this was a good idea. Some changes that would likely need to be made if this is approved would be adjusting busybox[mdev] to pull in virtual/modutils, as well as adjusting some of OpenRC's included initscripts to not complain if modprobe is missing (this was discussed in bug 342313, but I don't believe any progress was actually made). Some other packages' initscripts would need adjusting too, including fuse (only other package I have installed on my system that uses modprobe). Grepping for 'modprobe' in the files dir of each package in the tree would list plenty others.
this can only work as long as our default stage3 continues to ship with module support in it by default. catering to the uncommon case (people who build w/modules turned off) should not be done to the detriment of the overwhelming common case.
(In reply to comment #1) > this can only work as long as our default stage3 continues to ship with > module support in it by default. catering to the uncommon case (people who > build w/modules turned off) should not be done to the detriment of the > overwhelming common case. Certainly. virtual/dev-manager is also in @system, and should stay there. The default satisfier is virtual/udev, which has +kmod in IUSE, which subsequently pulls in sys-fs/udev[kmod], which deps on sys-apps/kmod. Some systems that don't need modules also don't need a dev-manager (example: Xen domU; devtmpfs is pre-populated with everything needed), and so they can satisfy virtual/dev-manager by adding sys-fs/static-dev to package.provided and be done with it.
*** Bug 478462 has been marked as a duplicate of this bug. ***
Until virtual/modutils is removed from system, could someone please make sure that * static-nodes does not emit an error message during every system startup when booting a mod-less kernel * or at least a warning output is added to the kmod ebuild saying that static-nodes should be *removed* from the runlevels for mod-less kernels? Currently, static-nodes gets installed and runlevel-added automatically, and for the average gentoo administrator/user, it is * neither obvious that static-nodes is related to and installed by kmod, * nor obvious that the error message is caused by having modules disabled, * nor obvious how critical that error message is and if it causes damage, * nor obvious whether it is safe to just remove static-nodes from the runlevels or if this will make the system less functional or unbootable.
(I will say in advance that this entire response is probably going to sound like elitism, but Gentoo requires a certain level of skill in working with Linux systems, and nobody here will deny that. Developers will only hold your hand so far, after which you're on your own, which is one of the benefits (in my mind) of Gentoo over other distros.) (In reply to Klaus Kusche from comment #6) > Until virtual/modutils is removed from system, > could someone please make sure that > > * static-nodes does not emit an error message during every system startup > when booting a mod-less kernel Why? It's a valid error message, which if you actually read, becomes clear that it's because you don't have modules turned on. > * or at least a warning output is added to the kmod ebuild saying > that static-nodes should be *removed* from the runlevels for mod-less > kernels? Again, why? You chose to disable module loading in your kernel build, you should understand that things that depend on module loading may not work, and apply appropriate adjustments for your systems to compensate. When I updated to kmod-14-r1, I noticed that its warning output was longer than usual, and saw that it was suggesting that I add static-nodes to my boot runlevel. I then looked at the static-nodes initscript, and saw that it executed kmod static-nodes, and copied the execution and ran it by hand to see what it did. When I saw the error message it spat out (see below), I realized that it was meant for systems with module loading enabled, and that I could safely leave it out. > Currently, static-nodes gets installed and runlevel-added automatically, From the ebuild, this only occurs the first time that kmod is installed, which only occurs in a stage3 build, or when upgrading a system from module-init-tools (which, according to robbat2's most recent automated addition and removal email, was removed from the tree by ssuominen on the 23rd, and so everybody should have been transitioned by now.) > and for the average gentoo administrator/user, it is > > * neither obvious that static-nodes is related to and installed by kmod, Sure it is: # equery belongs /etc/init.d/static-nodes * Searching for /etc/init.d/static-nodes ... sys-apps/kmod-14-r1 (/etc/init.d/static-nodes) Alternately: # $EDITOR /etc/init.d/static-nodes Line 16: kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf > * nor obvious that the error message is caused by having modules disabled, Sure it is: # kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf Error: could not open /lib/modules/3.7.10-gentoo/modules.devname - No such file or directory /lib/modules/$(uname -r)/modules.devname is created by depmod, typically as part of `make modules_install` during the kernel build; the modules_install target throws an error if you try to run it when you've disabled module loading. > * nor obvious how critical that error message is and if it causes damage, > > * nor obvious whether it is safe to just remove static-nodes from the > runlevels > or if this will make the system less functional or unbootable. I'll answer both of these points at once: You disabled module loading support, so you should be able to figure this out for yourself. It's expected that you know what you're doing if you disable one of the core features of the Linux kernel, as the overwhelming majority does not do this.
(In reply to dwfreed from comment #7) > (I will say in advance that this entire response is probably going to sound > like elitism, but Gentoo requires a certain level of skill in working with > Linux systems, and nobody here will deny that. Developers will only hold > your hand so far, after which you're on your own, which is one of the > benefits (in my mind) of Gentoo over other distros.) I enjoy that benefit, too. I'm focussed on unix / linux for >25 years (privately owned one of the first AT & T SysV Unix licenses in Austria), both professionally and privately, and primarily use gentoo for >11 years. I teach at a technical school and a university, among others operating systems and software engineering. So I have that level of skills, and the problem was no real problem for me. However, I have been in software quality assurance for half of my business life, most of the time even head of QA in a mid-sized company. So I try to look at things not with my background, but with the average user's background: "Will that make the user happy?" And I have 16 year old pupils which try to make their first linux contact with gentoo (we use it in school). In general, I think * we should not make gentoo more "eleet" than necessary: If it's easy to help the average (or less than average) user or avoid him getting in trouble or confused, we should do so (and an emerge notice is "easy"). After all, we welcome newcomers and should make their life comfortable. * Gentoo is the primary choice for flexible linux systems, and flexibility is the primary reason for choosing gentoo, so we should cover as many possible configurations as possible. And I don't think a static kernel is that rare: It is one of the most important recommendations for all secure systems, it is the natural choice for small or embedded systems or non-intel platforms, and it is the way we do it in our labs to make first manual linux kernel build, installation and booting exercises as simple as possible. > > * nor obvious that the error message is caused by having modules disabled, > > Sure it is: > > # kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf > Error: could not open /lib/modules/3.7.10-gentoo/modules.devname - No such > file or directory If you look at the problem from a less-than-experienced point of view, then it is not obvious that /lib/modules/... is related to kernel modules if someone *never* used a kernel *with* modules. > > * nor obvious how critical that error message is and if it causes damage, > > > > * nor obvious whether it is safe to just remove static-nodes from the > > runlevels > > or if this will make the system less functional or unbootable. > > I'll answer both of these points at once: You disabled module loading > support, so you should be able to figure this out for yourself. It's > expected that you know what you're doing if you disable one of the core > features of the Linux kernel, as the overwhelming majority does not do this. 1. Again, wrong point of view: Not: I have a running system with mod's and kmod, and now I disable kernel mods and have to clean things up - that would be ok. But: I've had a perfectly working system with a mod-less kernel for 10 years, and now some upgrade silently messed up my boot without giving any hint. 2. I don't think that it is easy to judge how critical that error is and if it's ok to just remove static-nodes: First, kmod static-nodes is quite new and less than perfectly documented, and secondly, the only thing the static-nodes script does is saving that information into some tmpfile. Without brute-force grepping, it is impossible to tell which init-scripts or programs rely on that tmpfile, even in the non-mod case, or if this tmpfile is required only for the mod case (after all, static device nodes are also needed for a non-mod kernel boot).
nothing is going to change until bug 393445 is addressed
(In reply to SpanKY from comment #9) > nothing is going to change until bug 393445 is addressed As I mentioned in comment #2, virtual/modutils is pulled in by sys-fs/udev, which is the default satisfier of virtual/udev, which is, in turn, the default satisfier for virtual/dev-manager, which I believe should stay in @system. So unless you also plan to remove virtual/dev-manager from @system for some reason, I don't see how bug 393445 is a blocker of this bug.
(In reply to dwfreed from comment #10) implicit dependency trees like that is irrelevant. we don't rely on flaky connections in place of the right answer.
