As is often the case, I usually expand my Android phones to full Debian distributions using Sven-Ola’s Debian Kit. Since Sven does not appear to support the kit anymore, it sometimes takes quite a bit of tweaking to make it work. Recently, I put Debian on a phone with PacMan Rom which was equivalent to Android 4.4.4. One of the many problems which I ran into involved LSB tags and overrides.

Note: LSB stands for Linux Standard Base. “The Linux Standard Base (LSB) is a joint project by several Linux distributions under the organizational structure of the Linux Foundation to standardize the software system structure, including the filesystem hierarchy used in the GNU/Linux operating system.” –Wikipedia. Essentially, LSB is a movement amongst Linux to set some standards that should be common between all distributions.

The PacMan Rom creator needed to fix a few things that happen during startup. They did this by creating some scripts for insserv to utilize and make the system perform/work as it ought to. The particular problem was this: with these scripts in place, I would be alerted every time I tried to install something new that there was an error. Sometimes this error would make insserv so angry that it could not continue to do what I originally told it to do, like install something from the repositories through scripts. That is not acceptable when it causes a failure, and rather annoying when it creates all of the warnings.

The warnings look like this:

……………………
insserv: warning: script ’90userinit’ missing LSB tags and overrides
insserv: warning: script ’81setrenice’ missing LSB tags and overrides
……………………<more>……………………..
insserv: warning: script ’81cron’ missing LSB tags and overrides
insserv: warning: script ’80check’ missing LSB tags and overrides
……………………

A cursory reading of the Debian wiki page for LSB tags told me to either add the tags or place copies of the files in the /etc/insserv/overrides/ directory. Since the original scripts make the PacMan Rom work, I really didn’t want to edit them. So I decided to fix this by putting copies of each script into the overrides directory.

# cp /etc/init.d/90userinit /etc/insserv/overrides/
# cp /etc/init.d/81setrenice /etc/insserv/overrides/
……………………<more>……………………..
# cp /etc/init.d/81cron /etc/insserv/overrides/
# cp /etc/init.d/80check /etc/insserv/overrides/

Well, that ought to do it. Or so I thought. Physically putting them in the overrides folder does not make them overridden. As I came to learn, you need to tell insserv to look for each individual overridden file.

# insserv -o 90userinit
# insserv -o 81setrenice
…..<more>…..
# insserv -o 81cron
# insserv -o 80check

Wow, now I’m done right? Wrong! As it turns out, what I didn’t understand, and what I don’t feel was reasonably clear in the wiki page was: putting something into the override folder and telling insserv that it is overridden doesn’t actually make it null and void and cause it to ignore the files or errors. Doing all of this simply tells insserv to use the override file instead of the original. Of course, all of my overridden files were copies of the original, and had the same problems and caused the same errors. So I needed to perform a few more steps to make this work.

Ultimately, it would have been shorter to add the LSB tags to the original scripts, but I was still concerned that changing them in any way might hinder their function, so I didn’t want to touch them. However, I now had overridden copies that were available to be edited to my hearts content. So I simply stole the tags from another script.

# head -17 /etc/init.d/cron >> /etc/insserv/overrides/90userinit
# head -17 /etc/init.d/cron >> /etc/insserv/overrides/81setrenice
……………………<more>……………………..
# head -17 /etc/init.d/cron >> /etc/insserv/overrides/81cron
# head -17 /etc/init.d/cron >> /etc/insserv/overrides/80check

I then opened each file, went to the last 17 lines, and edited the runlevels and name listed in the LSB tags. A quick check with insserv -n revealed that I no longer had any errors popping up! Finally that nuisance was gone and I could focus on the real problems.
Linux – keep it simple.

Leave a Reply

Your email address will not be published. Required fields are marked *