Possible Bug in 11.0 rc.S Script?

Woodsman · 10-27-2006, 03:28 PM

In my testing of 11.0 I have run into issues with hotplug that I never experienced before with Slackware. I think I have discovered the cause of my problems and I think the problem is a bug in the rc.S script. I would appreciate some of you more knowledgeable Slackers responding.

Background: I always have run the 2.4 kernel and never have tried or tested the 2.6 kernel. I use old hardware and although I have two 1.1 USB ports on my boxes, I do not use any USB devices. Even my mice and keyboard are PS2 or AT. Thus, I never had any need for hotplug and I always have disabled the rc.hotplug script (not executable). I experienced no issues or problems with this configuration until updating to 11.0. Since then dhcpcd has driven me nuts. I discovered that the only way to stop the nonsense was to pass the nohotplug parameter to the kernel at boot-up. This work-around sufficed but bothered me. What changed from 10.2 to 11.0?

I believe the problem is the rc.S script. Many of you are running 2.6 kernels and as written the script's hotplug test will not affect you. Similarly, of the remaining Slackers running 2.4, I suspect many have rc.hotplug enabled (executable). And again, the new 11.0 rc.S script will not affect you. I imagine only a few Slackers are like me who simply do not run hotplug and never have. Therefore I think this new bug passed unnoticed by just about everybody. But us folks running 2.4 who previously always ignored hotplug experience the 11.0 rc.S differently.

Unlike the 10.2 script, the 11.0 rc.S script uses a kernel version test in deciding whether to run hotplug. In 10.2, if rc.hotplug was not executable then that was the final test and the rc.S script disabled hotplug. But in the 11.0 rc.S, the script now additionally checks the kernel version before deciding what to do with a non-executable rc.hotplug. Based upon the comments embedded within the hotplug section of the 11.0 rc.S script, I believe the intent is that with 2.4 kernels, hotplug should be disabled if rc.hotplug is not executable but the executable status of rc.hotplug should be ignored with 2.6 kernels. Yet the script test does not honor the executable status of rc.hotplug with 2.4 kernels because of a single ! negation parameter.

The stock 11.0 rc.S hotplug test looks this:

Code:

if [ -w /proc/sys/kernel/hotplug ]; then
  # Kernel command line option 'nohotplug' given, so we will shut off
  # hotplugging even if it is not a good idea. Sometimes it *is* a
  # good idea, especially when you're trying to figure out which
  # kernel module is crashing the machine and needs to be added to
  # your /etc/modprobe.d/blacklist (2.6+ kernels) and/or your
  # /etc/hotplug/blacklist (2.4.x kernels).
  if grep -wq nohotplug /proc/cmdline ; then
    echo "/dev/null" > /proc/sys/kernel/hotplug
  elif [ ! -x /etc/rc.d/rc.hotplug ]; then
    # Ignore /etc/rc.d/rc.hotplug on kernels newer than 2.4.x:
    if [ ! "$(uname -r | cut -f 1,2 -d .)" = "2.4" ]; then
      # We must be running a 2.4.x kernel, so turn off hotplug:
      echo "/dev/null" > /proc/sys/kernel/hotplug
    fi
  fi
fi

That uname -r test with the ! negation is the problem. The ! negation should not be there. By removing that negation parameter the script now runs correctly on my box and honors the executable condition of my rc.hotplug.

With this modification I also no longer have to pass the nohotplug parameter to the kernel at boot-up and dhcpcd now behaves itself.

Comments please and should PV be notified?

P.S. I'm not interested in discussions about the philosophy of hotplug, etc. I just want to fix this awful problem with hotplug and dhcpcd, which I believe is caused by the rc.S script. Thanks.

Alien Bob · 10-27-2006, 05:19 PM

I'm kind of sorry for being loaded with Trappist beer at the moment, but I think Woodsman you've found a bug in rc.S.
You can email your story to volkerdi at slackware dot com - sure, don't hesitate.

Eric

Franklin · 10-27-2006, 05:31 PM

Quote:

Originally Posted by Alien Bob

I'm kind of sorry for being loaded with Trappist beer at the moment.

<snip>

Eric

Never apologize for good taste.

danieldk · 10-28-2006, 02:13 AM

This check

Code:

if [ ! "$(uname -r | cut -f 1,2 -d .)" = "2.4" ]; then
# We must be running a 2.4.x kernel, so turn off hotplug:
  echo "/dev/null" > /proc/sys/kernel/hotplug
fi

is OK, because the condition is true on 2.6 kernels, and it will echo /dev/null to /proc/sys/kernel/hotplug. Removing the exclamation mark may solve your problem, but will skip echo-ing null to that file on 2.6 kernels, which is wrong.

From my quick view it seems that another condition needs to be added that checks the executable permissions on rc.hotplug. Something like:

Code:

if [ (! "$(uname -r | cut -f 1,2 -d .)" = "2.4") || (! -x /etc/rc.d/rc.hotplug) ]; then
# We must be running a 2.4.x kernel, so turn off hotplug:
  echo "/dev/null" > /proc/sys/kernel/hotplug
fi

This makes more sense, because it will empty /proc/sys/kernel/hotplug when you have 1. a 2.6 kernel, or 2. no executable bit set for rc.hotplug.

acummings · 10-28-2006, 02:26 AM

You said "updated to 11."

In so doing, did you do anything to bring rc.hotplug.new

It's a long shot and I don't know that much about it.

But I went on the www to the Slackware-current changelog. And in my web browser I searched for rc.hotplug which turned up 5 hits.

--
Alan.

stabu · 10-28-2006, 10:37 AM

Quote:

I discovered that the only way to stop the nonsense was to pass the nohotplug parameter to the kernel at boot-up. This work-around sufficed but bothered me. What changed from 10.2 to 11.0?

It would appear to be a change in policy, i.e.

Code:

# Kernel command line option 'nohotplug' given, so we will shut off
# hotplugging even if it is not a good idea. Sometimes it *is* a
# good idea

It may be bothering because kernel command line options do seem a bit brute-force-ish, but are they really? The way they are global in their scope maybe. Anyhow, PV is pretty close to condoning them here.

It's more or less the comment that has me:

Code:

# We must be running a 2.4.x kernel, so turn off hotplug:

Because the ifstatement tests for the absence of a 2.4, so it would read better if it said "We must be running a 2.6.X kernel ...". That is, IF the comment is directly related to the ifstatement above it. It's a nested "if", so it may not be.

Earlier on in the nested if, the exectuability of rc.hotplug is already tested for, so this line would not have been reached if that script was executable: it seems superfluous to test it a second time.

Overall, it seems to me that this part of the rc.S is really only concerned about the hotplug and 2.6 kernel. Woodsman's requirement to not run it while on a 2.4 kernel would appear to be a special requirement, not a general one, so it may have no place in a conformist, admittedly new, rc.S. I also ran hotplug for ages while on 2.4., though I also dropped it later.

danieldk · 10-29-2006, 05:32 AM

Yeah, sorry, I didn't really read anything else than the context. The whole check seems a bit strange to me, because it seems to me that you'll always want to erase the value of /proc/sys/kernel/hotplug if rc.hotplug is not executable, or when it is executable, still erase it when running a 2.6 kernel. So, something like this seems more logical to me:

Code:

if [ -w /proc/sys/kernel/hotplug ]; then
  # Kernel command line option 'nohotplug' given, so we will shut off
  # hotplugging even if it is not a good idea.  Sometimes it *is* a
  # good idea, especially when you're trying to figure out which
  # kernel module is crashing the machine and needs to be added to
  # your /etc/modprobe.d/blacklist (2.6+ kernels) and/or your
  # /etc/hotplug/blacklist (2.4.x kernels).
  if grep -wq nohotplug /proc/cmdline ; then
    echo "/dev/null" > /proc/sys/kernel/hotplug
  elif [ (! -x /etc/rc.d/rc.hotplug) || (! "$(uname -r | cut -f 1,2 -d .)" = "2.4")]; then
    echo "/dev/null" > /proc/sys/kernel/hotplug
  fi
fi

Of course this may be incorrect. I don't have Slack 11 on any machine, so I haven't looked how hotplug/udev works in 11.