josephg wrote:khayyam wrote:I don't have either, knowing I didn't need binfmt_misc, or selinux (which 'procfs' also mounts similarly).
well, it might be good to know what is installed/running that we don't need. is there anything else i can remove or turn off? i'm still understanding what belongs to core gentoo and what doesn't.
josephg ... that depends, some of these (like procfs, sysfs, etc) include a number of things (again, like cgroups, securityfs, debugfs, etc) and some of these may, or may not, be needed (ie, cgroups, which seems to be required by some recent portage FEATURES ... however, I'm not sure which portage version this involves), some of these filesystems are checked against the kernel for availability (as in the case of binfmt_misc, etc) and as they all fall under 'sysfs' they are all enabled based on that availability. So the idea of "core gentoo" may encompass a variety of things, dependent on the install. Whatever you do the next time you emerge openrc, or udev-init-scripts, those you've disabled will be enabled again, so you either need to pay attention to the fact, or simply go with whatever happens to be provided.
josephg wrote:khayyam wrote:When a user installs openrc they get all this policy enabled (whether they need it or not), they also get it re-enabled should they re-merge the package (ie, when the ncurses slot it updated), so basically, besides the buttons that can be tweaked in rc.conf, or conf.d, the user isn't deciding policy, and isn't supposed to understand what does what, interdependencies, necessity, etc.
i can probably understand about the user not deciding policy. but i certainly don't agree that users aren't supposed to understand what does what, interdependencies, necessity, etc. is this something to do with the current trend of dumbing down everything?
Well, I think it comes as part of providing "policy", for instance when re-merging the very same version of openrc due to the ncurses slot change, my rootfs failed to mount ro, figuring out a solution took way too much effort (especially as I was hampered by my thinking it couldn't possibly be related to the package itself, because it was the same package, and I spent a lot of time looking elsewhere). I still don't properly understand what happened, it turned out that 'root' was running before 'fsck' and so I needed to add 'need fsck' ... but I have no idea why that same version of openrc worked prior. Similarly, hwclock began failing at shutdown due, I assume, to some change in util-linux re /etc/adjtime, and currently "[ -e /proc/sys/kernel/hotplug ] && echo '' >/proc/sys/kernel/hotplug" hangs at shutdown, no idea why, and I've no clear idea what might have changed (as the very same stop() worked previously). It might be argued that all of this is due to my using a now depreciated version of openrc, but even if this were the case (and note fsck, root, hwclock, are all from that same version) it doesn't speak much in terms of the above "understanding". Having been reading up on the subject recently I intend to migrate to s6-rc as soon as I can find the time to do so.
NeddySeagoon wrote:It's my view that its more about providing a system that actually boots without a new user needing to set up all the dependencies in the init system.
OK, but when this goes awry, what then?
best ... khay
