/etc/rc.local not running at boot

[xenopeek]

I have hdparm parameters/sbin/hdparm -a1024 -B 254 -A 1 -M 254 -K 1 -P 255 -c 3 -q /dev/sda
and rmmod ums_realtek to prevent write errors but it appears that rc.local is not being run.
I am running LMDE 1204 with repositories set to Testing.
Any ideas?

[eanfrid]

Did you verify your hdparm parameters by running your options on a command-line ? These are quite weird unless it is a very old PATA drive. On a recent SATA drive, most of them are either useless or incompatible.

[herbie643]

The parameters work perfectly on my Toshiba with a SATA drive. I execute it at the root prompt and all params are accepted.
When I had one of them messed up before, running Nadia, I could see it on my console at shutdown.
It worked under Nadia but not LMDE.

[eanfrid]

Unless you manually disabled it, /etc/rc.local is always run at start.

[herbie643]

I checked the properties on the file and it is set to Execute. How could you disable it?

[eanfrid]

Since Debian 6.x, services startup/shutdown configuration and ordering is managed by insserv. However IMO you should better still use update-rc.d to correctly manage the boot sequence. LMDE is based on Debian 7, so...

Code: Select all

sudo insserv -s|grep rc.local

should output something like

Code: Select all

S:08:2 3 4 5:rc.local

meaning Start (or Kill):order 08:at runlevel 2345:/etc/init.d/script_name

A simple line like

Code: Select all

update-rc.d script_name enable|disable

will activate or inactivate a service.

Check insserv and update-rc.d manpages for further info.

[herbie643]

My output is as follows per your posting:

root@l355-toshiba:/home/xxxx# sudo insserv -s|grep rc.local
S:24:2 3 4 5:rc.local
root@l355-toshiba:/home/xxxx# update-rc.d /etc/rc.local enable
update-rc.d: using dependency based boot sequencing
update-rc.d: error: cannot find a LSB script for /etc/rc.local

Changed the following in case /etc was not required and got:

root@l355-toshiba:/home/xxxx# update-rc.d rc.local enable
update-rc.d: using dependency based boot sequencing

I will reboot and see if that works. To be honest I am totally clueless as to what that means but will research...

[eanfrid]

Code: Select all

S:24:2 3 4 5:rc.local

Means that it was already active at boot time, as usual in Debian.

[herbie643]

root@l355-toshiba:/home/xxxx# update-rc.d rc.local enable
update-rc.d: using dependency based boot sequencing

Rebooted and that didn't fix the problem.

I read the man page on update-rc.d and saw that you may use 'defaults' so I tried that.
I reported back the following:

root@l355-toshiba:/home/xxxx# update-rc.d rc.local defaults
update-rc.d: using dependency based boot sequencing
update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match rc.local Default-Stop values (none)

But that didn't work either.

[eanfrid]

The "stop" option of rc.local does nothing hence the message you got. Did you try to run manually "sudo /etc/rc.local" in a console after reboot to check errors ? Can you paste here a copy of your /etc/rc.local ?

[herbie643]

root@l355-toshiba:/home/merlin# sudo /etc/rc.local
mount: cgroup already mounted or /dev/cgroup/cpu busy
mount: according to mtab, cgroup is already mounted on /dev/cgroup/cpu


Here is my rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent
rfkill block bluetooth
/sbin/hdparm -a1024 -B 254 -A 1 -M 254 -K 1 -P 255 -c 3 -q /dev/sda
rmmod ums_realtek
exit 0

[eanfrid]

Why do you load bluetooth and ums-realtek modules on boot if you immediately disable or remove them ? If you don't want them loaded at all, rather add a myblacklist.conf file in /etc/modprobe.d

[herbie643]

While I have been using Linux for a fairly long time I am not astute at blacklists. I have BootUpManager set to not load Bluetooth so perhaps my rfkill is a bit redundant. I will check into the blacklist options.

Now if I or you could just figure out why my rc.local doesn't load that would be great. I am at a loss as it has always worked on prior installations of Ubunutu, Linux Mint.
Thanks for you input on the unnecessary actions in rc.local. I will see what I can.

[herbie643]

I found part of the problem.

Part 1:
mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user

the mkdir's were failing do the rc.local execution exited.
I have no idea why the directories couldn't be created but they weren't so I created them myself and did the following:
#mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
#mkdir -m 0777 /dev/cgroup/cpu/user

I rebooted and still no hdparm's being set.
I commented the mount line and ran it from the command line and hdparm's are being set.

Part 2:
I created a myblacklist.conf but I am not sure that it is working:

blacklist ums_realtek
blacklist bluetooth

I would assume not since the ums_realtek is still loaded. I must be missing something.

I have to say this though, "You are one patient person to put up with all this."
Many thanks.

[eanfrid]

Seems like we are close to solve your troubles So "ums_realtek" is probably not the right module name. What gives "lsmod|grep realtek", for example ?

I overlooked your cgroups stuff. Indeed there is a package named "cgroup-bin" dedicated to cgroups management, which IMO does at system level all that you try to make manually... Check if this package is installed.

In the worst case you will end up with only these lines in rc.local if you don't find which driver to blacklist:

Code: Select all

#!/bin/sh -e
/sbin/hdparm -a1024 -B 254 -A 1 -M 254 -K 1 -P 255 -c 3 -q /dev/sda
rmmod ums_realtek
exit 0

[herbie643]

snd_hda_codec_realtek 56220 1
snd_hda_codec 101836 2 snd_hda_codec_realtek,snd_hda_intel
snd 54566 21 snd_hda_codec_realtek,snd_pcm_oss,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_oss,snd_seq_device,snd_mixer_oss

I checked and cgroup was not installed.

Also, any thoughts on the bluetooth blacklist item?

[eanfrid]

I don't see any realtek card reader driver loaded there, only sound drivers

Regarding bluetooth, you can check with "lsmod|grep blue" but the "blacklist bluetooth" line should already have done the job. If not, you will simply have to uninstall all the bluetooth-oriented packages you can remove safely (ie. some of them cannot be removed since they are required by your DE).

[herbie643]

I was reading up on the cgroup implementation. Here I thought is was for speed up only (about a year or so ago I read about this speedup thingy) and are they still required?

[eanfrid]

Yes monthes ago (edit: more than 2 years ago indeed) there was a display speed hack using cgroups. It is no more required because it has been integrated in the kernel since a while

[herbie643]

So basically the cgroup stuff was messing up the execution of rc.local. Whoda thunk....