SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Noticed it here also on all of my slackware64-current systems.
Was able to hit 'scroll lock' on one of 'em and grab the whole thing.
Code:
Installing package iproute2-6.5.0-x86_64-1.txz:
PACKAGE DESCRIPTION:
# iproute2 (IP routing utilities)
#
# These are tools used to administer many advanced IP routing features
# in the kernel.
#
# These utilities were written by Alexey Kuznetsov. The current
# maintainer of iproute2 is Stephen Hemminger.
#
Executing install script for iproute2-6.5.0-x86_64-1.txz.
main: line 5: [: too many arguments
cat: 'etc/iproute2/*.new': No such file or directory
Package iproute2-6.5.0-x86_64-1.txz installed.
Package iproute2-6.4.0-x86_64-1 upgraded with new package ./iproute2-6.5.0-x86_64-1.txz.
Building the newer libcgroup does fix those issues as you suggest, but it needs a bit of work vs its current libcgroup package. Here's a few I found just starting out:
- The init and conf patches need to be rebased to the newer code since they dont apply anymore.
- I haven't checked the "git" patch on the older 0.41 version, but I would suspect it would no longer be needed.
- The build needs to have --enable-systemd=no set to complete.
- The cgconfig service cannot be stopped in their provided init script now, and cgclear is removed
- The rc.cgred service fails to start out of the box since the default init script they provide only checks
for cgroup (v1) filesystems, and not cgroup2 filesystems. Can be patched locally but why is it still provided like this?
- The above point would be further complicated if the cgroup fs type is switchable between v1 and v2, requiring further patching.
Overall the package needs some work to fix up the service scripts, and introduces a few changes to catch up on. There might be some more gotchas in the box since I've just been looking at this fairly recently. (I've been hacking on it to get a little more familiar with control groups v1 and v2 in general)
I patched up the libcgroup build for 3.1.0 and have the init scripts working. I'll attach the new patches, slackbuild, and doisnt.sh to this post if anyone is interested in looking at it. The gist is the old patches that bypassed LSB functions can be dropped, since upstream added support for logging without LSB. Still have to adjust the config file path for the /etc/cgred.conf file, and I added a patch to allow the rc.cgred service to properly start with v1 or v2 cgroup mounts.
One other quirk I noticed is that the 'cpu' controller can't be utilized in v2 hierarchy, until the system is also booted with 'cgroup_no_v1=all' on the command line (along with the modified rc.S script to mount the cgroup2 fs).
Once booting with the proper kernel options and the cgroup2 fs mounted, cgroups can be managed with the libcgroup tools (e.g. cgcreate/lscgroup/etc.), managed manually (eg mkdir/cat/echo directly in the /sys/fs/cgroup dir), or automatically with a properly configured /etc/{cgconfig.conf,cgrules.conf} setup with the cgred daemon. I didn't bother testing the pam_cgroup.so module yet, and the package should probably be tested further but creating basic cgroups, adding and using controllers, and the cgrulesdaemon are working AFAICT.
A couple nitpicks:
- Documentation in the package is mostly about v1 still, so examples of commands may not be relevant when running cgroup2, requiring reading a little more online
- I tried using the '--enable-opaque-hierarchy=NAME' build option to hide the elogind cgroups, but no success. It's done with systemd in the documentation. I thought I'd try for elogind, since a multiuser system with many sessions will end up with a pile of elogind session cgroups in /sys/fs/cgroup/ or in 'lscgroup's output.
Is there any point in keeping extra/source/java/ in current? I think the java.SlackBuild only works properly for Oracle Java 7 and 8 which requires (free?) sign up with Oracle in order to access archived releases. It tries to install the Java browser plugin which hasn't been supported (since Firefox 52) or available (since Java 8u271) for a while. Oracle no longer do a 32-bit release, only x86_64 and aarch64 for Linux. There is no longer a separate JDK and JRE, just the modular JDK.
There are a bunch of alternative JDK SlackBuilds on slackbuilds.org that either repackage Oracle Java or build openjdk. AlienBob also provides openjdk{7,8,11} 32-bit and 64-bit packages.
Is there any point in keeping extra/source/java/ in current? I think the java.SlackBuild only works properly for Oracle Java 7 and 8 which requires (free?) sign up with Oracle in order to access archived releases. It tries to install the Java browser plugin which hasn't been supported (since Firefox 52) or available (since Java 8u271) for a while. Oracle no longer do a 32-bit release, only x86_64 and aarch64 for Linux. There is no longer a separate JDK and JRE, just the modular JDK.
There are a bunch of alternative JDK SlackBuilds on slackbuilds.org that either repackage Oracle Java or build openjdk. AlienBob also provides openjdk{7,8,11} 32-bit and 64-bit packages.
Also in GFS for current there is also builds-packages for flatpak, flahub, flatpak-builder gnome-builder (if you want to build your own flapaks) etc... also gui gnome-software app which working very fast and properly like flathub. So When 15.1 will be out all these will be part of SlackBuilds.org if something not exist already.
These days I m checking what deps needed to run gnome-software in a Slackware system whithout install a gnome Desktop if you dont like. I think its not hard we can have it with few deps...
As an aside I have tried in VirtualBox the demo of nixOS provided as an OVA file. The concept of installing all files of a package in a single directory is interesting, albeit unusual and not at all compliant to the FHS. To know more, read the Nix Reference Manual.
Last edited by Didier Spaier; 09-08-2023 at 11:44 AM.
Reason: Typo fix.
- I tried using the '--enable-opaque-hierarchy=NAME' build option to hide the elogind cgroups, but no success. It's done with systemd in the documentation. I thought I'd try for elogind, since a multiuser system with many sessions will end up with a pile of elogind session cgroups in /sys/fs/cgroup/ or in 'lscgroup's output.
The '--enable-opaque-hierarchy="name=elogind"' option only seems to work under cgroup-v1 hierarchy to disable seeing elogind in the 'lscgroup' output. Seems pretty useless otherwise, since you can still see the cgroup under the mounted cgroup filesystem at '/sys/fs/cgroup', and it all shows up in lscgroup if using cgroup-v2.
Otherwise the last thing I'll say is to summarize that with a patch like this to rc.S:
Will allow a newer libcgroup package, and allow for freely switching between cgroup v1 or v2 with boot options. The default would be to use v1 the same as it ever was (enabled, but doing nothing). To switch to v2 would use boot options "cgroup=v2 cgroup_no_v1=all", which sets up a cgroup2 fs instead (and also defaults to do nothing beyond that). Perhaps a better rc.S patch would be to overload the cgroup_no_v1=all option so it does the "cgroup=v2" option's job of mounting a cgroup2 fs in rc.S, and also prevents mounting controllers under v1, which causes them to be unavailable in v2 (which is why the option is set when using v2). However, the linked patch also works, though with two options needed to be set.
The newer libcgroup tools are compatible with either version, although due to the essentially inverted hierarchys between them, the commands are entered differently depending if cgroup v1 or v2 is in use. The cgred daemon works for either v1 or v2 (with the patch), although the config file syntax is different between the two versions, and the examples are v1 based. Still its fairly easy to make a config with cgsnapshot for either version.
It would be nice to have an option to use either cgroup type, since its currently limited to v1 by the rc.S script and age of libcgroup tools. The linked patches can do so, although I'll defer to Pat's final decision as always. All I'm trying to do here is see how that might work moving forward.
I'll show myself out now and stop bringing up cgroup/libcgroup now
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
