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.
Can we please enable SUNRPC_DEBUG (CONFIG_SUNRPC_DEBUG=y) in the kernel options (Under menuconfig -- File Systems -> Network File System -> RPC: Enable dprintk debugging)?
This allows people to debug NFS connections (both server and client) using the rpcdebug program. I found today that I was lacking this feature in the kernel when I tried to debug a client connection issue.
NOTE: This does also enable CONFIG_NFS_DEBUG.
I have it enabled here (for a short period of time) without any known issues.
Code:
diff --git a/.config b/.config
index 2eb22ac..560b8b6 100644
--- a/.config
+++ b/.config
@@ -9307,6 +9307,7 @@ CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
CONFIG_NFS_V4_SECURITY_LABEL=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
+CONFIG_NFS_DEBUG=y
# CONFIG_NFS_DISABLE_UDP_SUPPORT is not set
# CONFIG_NFS_V4_2_READ_PLUS is not set
CONFIG_NFSD=m
@@ -9332,7 +9333,7 @@ CONFIG_SUNRPC_BACKCHANNEL=y
CONFIG_SUNRPC_SWAP=y
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES is not set
-# CONFIG_SUNRPC_DEBUG is not set
+CONFIG_SUNRPC_DEBUG=y
CONFIG_SUNRPC_XPRT_RDMA=m
CONFIG_CEPH_FS=m
CONFIG_CEPH_FSCACHE=y
Can we please enable SUNRPC_DEBUG (CONFIG_SUNRPC_DEBUG=y) in the kernel options (Under menuconfig -- File Systems -> Network File System -> RPC: Enable dprintk debugging)?
edit:
We all have to keep in mind that 15.0 is almost under the tree 🎅🏽🎄
The choice may be forced, unless Pat can track down some backports for those 4 security issues or is happy to live with the local privilege escalations. As is usual, the timing sucks.
I started a thread a few months ago about this, but it didn't garner much attention, so I thought I'd mention it here.
Looking at the mkinitrd script, we find this:
Code:
# If $WAIT is not set, assume we need only one second
# to have all devices done
# (unless we find that value is already set in the initrd-tree):
if [ -z "$WAIT" -a -z "$(cat $SOURCE_TREE/wait-for-root)" ]; then
WAIT=1
# ARM devices need even more time:
case "$( uname -m )" in
arm*) WAIT=4;;
esac
fi
if [ ! -z "$WAIT" ]; then
echo $WAIT > $SOURCE_TREE/wait-for-root
fi
When extracting the skeleton initrd-tree, rootdev and rootfs are empty files (0 bytes,) but wait-for-root contains a "1". Thus, testing "-z $(cat $SOURCE_TREE/wait-for-root)" always fails, so the body of that block is never entered.
The only way I can see for the ARM-test to actually run would be to run mkinitrd once to extract the skeleton initrd-tree, manually empty/null the wait-for-root file, and then run mkinitrd again without the "-c" option.
Making wait-for-root an empty file in the skeleton tree--like rootfs, etc.--would allow mkinitrd to set the value to 1 or 4 every time it is invoked with "-c".
For myself, I went a little further and did away with the $(uname -m) test altogether as outlined in this post. (Kindly disregard the posts above and below that one.)
The choice may be forced, unless Pat can track down some backports for those 4 security issues or is happy to live with the local privilege escalations. As is usual, the timing sucks.
Do you mean those 4 CVE mentioned here? These are fixed in -current
Distribution: slackware, slackware from scratch, LFS, slackware [arm], linux Mint...
Posts: 1,564
Rep:
libcaca0.99beta20
Code:
libcaca v0.99.beta20 Latest
@samhocevar samhocevar released this 19 Oct 2021
· 3 commits to main since this release
v0.99.beta20
373c88b
IPv6 support in cacaserver
fixed a bug from 2004 that caused PDF documentation generation to fail
memory allocation functions are now more robust
numerous fixes for memory leaks and invalid memory accesses:
CVE-2021-30498
CVE-2021-30499
CVE-2021-3410
CVE-2018-20546
CVE-2018-20547
CVE-2018-20545
CVE-2018-20548
CVE-2018-20549
Some code changes would be required in xorg-server, xinit, and various login
managers to make rootless X work out of the box or to fall back in cases
where elogind isn't supported, and those changes aren't appropriate here in
the RC stage, but you can try it without recompiling:
chmod 755 /usr/libexec/Xorg*
Thanks to LuckyCyborg.
I have read the aforecited message in the ChangeLog, and I am thinking whether it would be appropriate to make a (sticky) thread dedicated to "requests for -current after 15.0"? Because in this thread "long-term" changes are interspersed amid "immediate" changes.
I would have asked for that "X without root privileges" feature be there, as well as, perhaps, rc.kexec (discussed in a separate thread), and libcgroup-v2 (which is being developed quite quickly, so I hope it should be available for 15.1).
I have read the aforecited message in the ChangeLog, and I am thinking whether it would be appropriate to make a (sticky) thread dedicated to "requests for -current after 15.0"? Because in this thread "long-term" changes are interspersed amid "immediate" changes.
I would have asked for that "X without root privileges" feature be there, as well as, perhaps, rc.kexec (discussed in a separate thread), and libcgroup-v2 (which is being developed quite quickly, so I hope it should be available for 15.1).
I also for one vote for this; if however it is not feasible to implement this now(by default) - I do absolutely would want rootless-Xserver for 15.1
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)
