Updating Slackware — 5
I found more issues while testing the upcoming Slackware 15.
I saw stderr messages about my
/etc/host.conf file. I have the following options in the file:
nospoof on spoofalert on spoof warn
Searching the web indicates the spoof options are not supported in the glibc resolver libraries. The Slackware 14.2 man page indicated the options were introduced in glibc 2.0.7 but never implemented. The Slackware Current man page indicated support for the options was removed after glibc 2.24. The glibc change log confirms the
host.conf spoof code was removed 2016-12-27. Based on that information, whether using an older
host.conf file or updating to Current from 14.2, those options never were useful. The options are irrelevant in 14.2 but creates stderr spew in Current.
Yeah, I haven’t touched my
host.conf file in many years.
Despite the icon theme selected, in my testing the Xfce power manager systray icon is flat, likely defaulting to one of the “contrast” theme icons.
I saw repeated messages of
file /var/lib/alsa/asound.state lock error: No such file or directory. Both the directory and file existed.
0755 permissions and
alsactl -L in
rc.alsaavoids the errors.
speaker-test functioned fine.
Booting with rc.alsa not executable (
chmod -x) also worked.
The only cure I have found is using the
When booting directly to runlevel 1 I saw another oddball message:
Current bug: netlink error: failed to retrieve link setting/No such device. The network controller card is a Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet using the
ethtool produced the spew. I did not find any clues online or in the logs. The spew did not appear when booting to runlevel 3.
While networking usually is not used in runlevel 1, I never have seen this behavior. I discovered the bug because my
rc.local[_shutdown] scripts use
ethtool to ensure wake-on-lan (WOL) is enabled. I resolved the problem by modifying my scripts to send
ethtool stderr to
A weird bug appeared again when booting directly to runlevel 1. I would randomly see one to three blank lines with the
rc.font stdout spew (launched from
The bug did not appear when booting to runlevel 3.
Normally when booting to runlevel 3 I saw the following:
Setting the console font: Loading 256-char 11x22 font from file /usr/share/kbd/consolefonts/ter-122n.psf.gz Loading Unicode mapping table...
When booting directly to init 1 there would be one to three blank lines between the two “Loading” messages.
I could not replicate the bug when running
rc.font manually in runlevel 1. My solution was to move launching
rc.keymap to the end of
When using bash history the search term was highlighted, which never happened before. This new behavior is caused by changes in the
readline command. I removed the highlighting by editing
set enable-bracketed-paste off.
fc-cache was not working correctly.
/usr/local/share/fonts/OTF: skipping, looped directory detected /usr/local/share/fonts/ttf: skipping, looped directory detected
I resolved that in
/etc/fonts/local.conf by removing
/usr/local/share/fonts and creating two lines, one for each subdirectory:
Another annoyance was testing a fresh install of Current. When using the
mount command I saw a significant output spew about cgroup file systems. Digging into this I found the default behavior of
/etc/mtabin the Slackware installer was changed to a sym link to
/proc/mounts. I found some comments in
rc.S that this is the new default, but the snippet of code still supported using
/etc/mtab as a file. Removing the symlink and replacing with
touch /etc/mtab eliminated the useless cgroup spew.
On the T400 laptop I was seeing
kernel: intel_powerclamp: No package C-state available. My solution was to add
blacklist intel_powerclamp module to
With the change to using PAM, I was seeing message-of-the-day (MOTD) spew when logging in. The old
/etc/login.defs supported not displaying that text. The only solution I found when using PAM is using
The journey continues.