A few words about Debian on the Asus C90s and a visual aid for runlevels for newbies

In Debian Lenny, almost everything works out of the box on my laptop. But there are a few annoying little things about which I will discuss.

To begin with, there is a bug that interferes with the normal work with wi-fi on Asus C90s laptops (it is possible that on some others) with the Intel PRO / Wireless 3945ABG card. The bottom line is that through the interfaces the waffle works, but if it is not mentioned in this file, or the connection did not occur, then wi-fi falls off completely, and you can’t pick it up using normal methods. Unable to use network-manager, wicd connects unstable, greatly complicates the work.
I found information on the problem with rather great difficulty, and this post is an attempt to help my comrades in misfortune.

So, we have the dmesg which is chopped off when loading Wi-Fi, dmesg

iwl3945: Radio disabled by HW RF Kill switch

Alt + F2 does not work, there are no hard switches on the laptop.
')

Decision

It turned out to be simple:

$ echo 1> / sys / devices / platform / asus-laptop / wlan

After that, the adapter immediately turned on, as indicated by a lit LED. But how to make this crutch work as an automaton?

The waffle fell off at boot time, therefore, I decided, I had to dig up the scripts being run by init . A simple script was written that made echo and a five-second sleep , which by running the command

$ update-rc.d myscript start XX abc d. stop yy def.

was placed after the scripts launched by the system checked for lice.

About runlevels

A few words about the procedure for booting the system, since I began to explain in such detail. There are seven so-called. "Run levels" (runlevels). Zero corresponds to a system shutdown, the sixth to a reboot, the first to a single-user mode. According to the official wiki , Debian makes no distinction between the other five. Each mode corresponds to a set of scripts launched at the entrance to the mode and at the exit from it. Links to scripts are stored in /etc/rcX.d, where X is the level number. (The scripts themselves run in /etc/init.d/)
The link to the script, starting with S, starts at the entrance, with K - at the exit. A two-digit number after S or K indicates the launch priority: first, the scripts with the lowest priority are run. The update-rc.d command mentioned above allows you to assign these links to the script correctly, or delete them. In the syntax of this command I mentioned, we give our myscript script priority XX when running in runlevel a, b, c and d, and priority YY when stopping in runlevel d, e and f. You can remove the program from autorun like this:

$ update-rc.d -f myscript remove

Well, now back to practical application. The sh-script that made sleep 5 , being crammed before and after different scripts launched by the system when loading, showed that the LED of the wireless adapter goes out exactly after the launch of acpi-support . Since his launch priority was 99, we had to change it to 98 with the team

$ update-rc.d acpi-support start 98 2 3 4 5. stop 20 1.

Priority 20 when stopping in runlevel 1 I saved. Now it remains only to rewrite my script so that it will raise wi-fi:

#! /bin/sh<br># /etc/init.d/mywififix<br><br>touch /var/lock/mywififix<br>case "$1" in<br> start)<br> echo 1 > /sys/devices/platform/asus-laptop/wlan <br> ;;<br> stop)<br> echo 0 > /sys/devices/platform/asus-laptop/wlan <br> ;;<br> *) echo "Usage: /etc/init.d/mywifiscript {start|stop}"<br> exit 1<br> ;;<br>esac<br><br>exit 0

and execute

$ update-rc.d mywififix defaults 99 99

to put it in autoload. I will note another syntax in which only priority is passed to the script, and the parameters of the runners are taken as default (start at 2, 3, 4 and 5, stop at 0, 1 and 6 runners).
After the introduction of such a crutch, the wafer stopped falling, the network-manager began to be perceived normally, and the LED went out for a split second when it was loaded.

The solution of the problem with the Intel card was found after many hours of googling and one system reinstallation (one comrade stated that it helped him, and I just moved to the new hard drive, at the same time I tried the boxed Debian offered to the user, but about that another time ).
There were IRC-logs , in which a certain tvakah offered the solution of the problem mentioned at the very beginning, for which he thanks a lot and honors him. Although he wrote to Bagtrack about his discovery, the solution did not pop up in Google (or was not noticed), and there were plenty of unsolved questions and questions on the forums. Habr is regularly indexed by Google, so I hope that my post will help at least someone.

If someone is interested, then I think periodically to write reviews of various Linux software, making some kind of “debian’s notes” from my personal blog. I myself periodically had questions like “which program is better to do this,” I spent almost free traffic and precious time on Google and comparing programs aimed at solving the same tasks or setting something up for myself or my hardware, so my knowledge can save someone something.