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
Great suggestion, I know I'll find it very useful, and wouldve in the past few months if I knew it existed.
I appreciate that the Slackware installation media provides a complete system that can be installed without an internet connection.
Also, it allows you to select an ftp or http mirror with the packages to install, but it is always the same packages and version that are in the original ISO. At the end of the installation we must carry out slackpkg upgrade-all, which in the case of Slackware 14.2 practically implies the reinstallation of each of the packages again.
My request is the following:
An option could be implemented in the Slackware Installer, eg. "Upgrade on the fly", which, by selecting the /patches/PACKAGES.TXT file from a mirror, implements the following logic:
If a package in PACKAGES.TXT has its counterpart in /patches/PACKAGES.TXT then the one that exists in /patches/PACKAGES.TXT is installed
With this, the installation will be up to date after a reboot. It is something that I have missed and I find it interesting to implement, but maybe this does not make sense, could you explain it then?
Last edited by emidevices; 12-17-2021 at 02:48 AM.
I appreciate that the Slackware installation media provides a complete system that can be installed without an internet connection.
Also, it allows you to select an ftp or http mirror with the packages to install, but it is always the same packages and version that are in the original ISO. At the end of the installation we must carry out slackpkg upgrade-all, which in the case of Slackware 14.2 practically implies the reinstallation of each of the packages again.
My request is the following:
An option could be implemented in the Slackware Installer, eg. "Upgrade on the fly", which, by selecting the /patches/PACKAGES.TXT file from a mirror, implements the following logic:
If a package in PACKAGES.TXT has its counterpart in /patches/PACKAGES.TXT then the one that exists in /patches/PACKAGES.TXT is installed
With this, the installation will be up to date after a reboot. It is something that I have missed and I find it interesting to implement, but maybe this does not make sense, could you explain it then?
Hi,
This has already been discussed (I haven't found where)
4.3 The SOURCE option:
[...]
The network installation function is mainly intended to facilitate
installation on multiple machines in a local network. Please do not use it to
bog down Slackware mirror sites.
4.3 The SOURCE option:
[...]
The network installation function is mainly intended to facilitate
installation on multiple machines in a local network. Please do not use it to
bog down Slackware mirror sites.
Yes, BUT someone can make a full mirror of Slackware 15.0 tree in a local server, then to use it to mass install into computers from local network. I.e. a company or a school which have to do few hundred of installs.
However, there we will hit on the old and known issue of having official support for only one repository on the Slackware tools, and /patches counts a second standalone repository. So, I do not think this will happen.
Yes, BUT someone can make a full mirror of Slackware 15.0 tree in a local server, then to use it to mass install into computers from local network. I.e. a company or a school which have to do few hundred of installs.
However, there we will hit on the old and known issue of having official support for only one repository on the Slackware tools, and /patches counts a second standalone repository. So, I do not think this will happen.
For me, doing the upgrade during or after the install is the same. it just depends on when you want to waste time
However, after the installation, it allows you to use slackware and run the upgrades at the same time
The difference is that you don't have to worry about the network configuration during the installation
It mentions kernels no more provided since a very long time like gensmp and speakup.s.
It says:
Quote:
If setup is not successful in accessing the CD-ROM drive, you'll need to figure out why before you can go on. The most common reason for this is that you used a kernel that doesn't support the CD-ROM drive
This is no more an issue since a long time.
Quote:
Then create a smaller primary DOS partition, leaving enough space to install Linux. Preferably this should be more than 9GB.
Good luck to install a recent Slackware in 9GB (at least a full installation).
It doesn't even mention elilo, just referring to README_UEFI.TXT for partitioning UEFI systems.
It mentions only DOS partition tables. Good luck to find a recent machine without a GPT for its primary drive.
These are just a few examples. But maybe it is planned to update it on occasion of the release of Slackware 15, so this is just an observation, not a complaint.
Last edited by Didier Spaier; 12-17-2021 at 03:35 AM.
Reason: Added line about DOS and GPT.
For me, doing the upgrade during or after the install is the same. it just depends on when you want to waste time
However, after the installation, it allows you to use slackware and run the upgrades at the same time
The difference is that you don't have to worry about the network configuration during the installation
Doing the updrade during the install, which could be from a local mirror, would already leave you an up to date system, although it took a little longer during the installation, it would be faster than installing everything, restarting and updating everything, I think.
The network installation function is mainly intended to facilitate
installation on multiple machines in a local network. Please do not use it to
bog down Slackware mirror sites.
It might be a good idea to ship a monthly patches ISO which could then be distributed by P2P.
If the mirror bandwidth's become a problem, that'd be the most obvious fix.
I'm curious to know how many times (per month, week or day! ?) people here are doing fresh install and don't want to waste their time doing upgrades after it
I'm curious to know how many times (per month, week or day! ?) people here are doing fresh install and don't want to waste their time doing upgrades after it
Funny, but you'd have to see the stats of every public mirror and consider the private mirrors as well.
It's not something which can be done reliably, if at all. What is reliable is that majority of mirror trafic should traditionally be generated by /patches/
So having snapshots would reduce that traffic considerably.
It might be a good idea to ship a monthly patches ISO which could then be distributed by P2P.
If the mirror bandwidth's become a problem, that'd be the most obvious fix.
Yes, periodically updating the ISO install image with the newest packages would also be an option.
Although it would imply downloading it, burning it or transferring it to USB before installing, and you may not have free media at that time.
The original ISO, with the option "On the fly upgrade" in the setup, would do a better job.
I'm curious to know how many times (per month, week or day! ?) people here are doing fresh install and don't want to waste their time doing upgrades after it
Just as example, the school (where my younger kid learns) has around 100 computers.
Now imagine that their admin have to install Slackware on them, on a single weekend.
Mission impossible? That's what I will say too, and that's probably also a reason WHY the Slackware will not become more "mainstream" even on schools, not talking about companies.
People says that Slackware requires too much time for maintenance, according with the today standards. I wonder why?
Last edited by LuckyCyborg; 12-17-2021 at 05:39 AM.
Yes, periodically updating the ISO install image with the newest packages would also be an option.
Although it would imply downloading it, burning it or transferring it to USB before installing, and you may not have free media at that time.
The original ISO, with the option "On the fly upgrade" in the setup, would do a better job.
Snapshot can be signed and md5/sha* could be calculated, remastered ISO cannot be signed upstream and you'd have a checksum mismatch.
So this is neither ideal or secure enough, even though it's possible.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
