Ask Klaus

Dear Klaus, this is my second year (approx) trying to come to terms with an alternative to XP and the learning curve that we must all accept with anything new.

My Mac was a little easier to learn, but not without its difficulties, but I destroyed Linux Mint (down to black screen) trying to come to grips with how to make what I understood in Microsoft work with Linux, so I knew that this Linux was a very different challenge! It is clear to me that I have a long way to go with the Linux learning curve. So, there is knowledge in what I have done so far, but I have made many mistakes, so please view me accordingly.

I am reasonable proficient in loading a new OS on my 32-bit laptop, until suddenly it seemed that my WiFi access and wired connection were mysteriously removed in the attempt to install two OSs: Ubuntu and Mint (and I do know about checking the third-party software box during installation to get the drivers). However, I was shocked when loading Knoppix to discover that both wired and WiFi had been found, so why not on the other two?

The excitement of getting my old laptop working with my newly discovered Linux is rapidly fading after having my WiFi wiped, each time worse than the other, and all requiring external help.

Is it possible that Knoppix has a repair, tutorial, and/or a first aid for such occasions?

Kind regards,

Cy O'Hara

Hello Cy, there are surely different perspectives on what is "new" and what is "alternative." The Unix system, on which GNU/Linux is designed, is older and more "traditional" than Windows XP, so it all comes down to what you are used to working with personally that you want to replace.

Of course it's easier to move from one version of the same operating system and applications to the next version, with the possible exception of a disruptive design decision by the operating system's manufacturer. The truth is, Windows and Linux work differently from the user's perspective, concerning application software versus drivers. Windows somewhat hides the technical concepts, whereas GNU/Linux often assumes that you know about things like the relation between kernel, drivers/modules, system services, and userspace before you attempt to change things.

For example, upgrading the kernel without upgrading the hardware-related modules, and vice versa, will almost certainly lead to a dysfunctional system. Also – picking up on your WiFi problem – installing a different driver for your WLAN chipset that does not match the installed kernel and deactivating the old WiFi module during installation will disable WiFi completely until the wrong WiFi driver gets removed. Hardware drivers are, in most cases, not just a "program," but a major system component that can have large side effects.

Upgrading system services, like udev or systemd, may enhance or decrease the system's ability to detect and configure hardware automatically. On Windows, if a mandatory update renders a hardware component unusable, the only way to fix the problem is often a reinstallation or downgrade. Naturally, your expectations on Linux might be better than that, and it's true, with the necessary understanding of how the Linux system works and operates, you can repair and optimize many things on your own. However, that requires some experience, and experimenting with a Live system like Knoppix to check out what happens if you change this or that could give you an insight into Linux internals over time.

Especially if you want to repair an installed OS, not just reinstall a program, you need some knowledge about the technical background (and this is the same in Linux and Windows), and I recommend that you NOT trust any "automatic repair tools" that yield other promises on the package. ;-)

Having said that, I'll take a much simplified look at how Linux handles access to hardware like your WiFi adapter from the top down – from an application like the browser to the hardware drivers included in the kernel.

Figure 1 shows the flow of operation when controlling the WiFi adapter with a program like the graphical Network Manager application (nm-applet) shown in Figure 2.

Figure 1: Layers of operation in a Linux system.

Figure 2: Network Manager.

The GUI is the application, which talks to a service (network-manager), which uses system libraries to access a kernel interface. The kernel then uses a dynamic component, the WiFi-adapter-specific module (loaded on demand by another system service, the udev hardware manager), that knows how to translate between network traffic and the hardware registers of the WiFi card. Again, even though this might look complicated, it's less complex than Windows' internal procedures of handling hardware access; yet, the picture isn't complete, because firmware (a very tiny operating system that is being uploaded to the WiFi adapter by udev) is missing from the scheme.

This process makes sure that no application can lock or disable hardware by itself, because all access has to go through the kernel. The kernel manages the hardware component and puts all requests to the card in a queue, preventing chaos by random parallel accesses.

The sudden failure of a WiFi adapter can have different grounds. On the hardware level, the chip can be destroyed by static electricity or overheating (modern hardware should be robust enough to survive, though).

The chip-specific firmware file could be missing from the system; in this case, you should see a message in the system log (command dmesg) as soon as the adapter has been detected that says a firmware file has not been found. If you upgrade the system, it could happen that new WiFi card firmware is installed that is not working with your specific adapter. In that case, you would need to downgrade the firmware software package.

To check whether the WiFi adapter is detected at all, use the iwconfig command. Listing 1 shows that a WiFi adapter has been detected, but its power is set to zero.

Interfaces for the adapter at the kernel and library levels might not match. For example, the kill switch, which is used to disable the (software-controlled) WiFi adapter antenna, might not be supported by the kernel, libraries, or system software.

Check with the rfkill command to see the operation state of your wireless hardware. (Install the rfkill package with

sudo apt-get install rfkill

if your system lacks the command.)

Listing 2 shows the rfkill output. This notebook does not have a physical switch, but rather a "software" switch for disabling the WiFi antenna (Soft blocked: yes). The software switch is controlled by a keyboard combination, which is quite common. If the network-manager GUI fails to enable the WiFi card, you could try to unblock the card with the following:

sudo rfkill unblock all

in the terminal, which will basically unset all kill switches, enabling all wireless adapters (including WiFi and Bluetooth, if present). Now rfkill list should show all "blocked" items set to no, and the WiFi adapter becomes operational.

In some cases, however, the adapter cannot be powered either from the OS or with a hardware switch unless a proprietary (and possibly Windows-only) driver is installed. If this is the case, I'd recommend buying a USB WiFi adapter that just works and disabling the internal WiFi adapter completely.

On the next layer, WiFi with password-protected WPA encryption also requires the wpa_supplicant daemon to control access point association and encryption handshake.

Finally, the application layer (the GUI that controls wpa_supplicant system service WiFi parameters like SSID and the WPA password) will connect to the access point and call the DHCP client to obtain a valid host IP and Internet gateway route.

This piece of the puzzle also can go wrong if the access point is configured for a non-standard authentication mechanism, the WiFi hardware (MAC) address is restricted, or no more IP addresses are available for a client.

By knowing about these relationships between applications, services, libraries, and kernel (hardware) support for the WiFi adapter, you might be able to find the problem on the hard-disk-installed distributions.

Btw, the screen staying black when booting a distribution from disk, even while the hard disk LED may still be flickering, sounds like mismatched kernel modules for the graphics drivers (i.e., maybe a failed kernel upgrade or a wrong option in the bootloader keeps the graphics modules from loading correctly). If the kernel boots from hard disk and the kernel plus modules installed inside the distribution on disk do not match perfectly, most hardware will simply not work, which could also be an explanation.

Check the bootloader configuration file (depends on the distro); if different kernel versions are specified, try something other than the default.

By looking up the active kernel modules in Knoppix (lsmod), you can find the (hopefully) correct modules matching your hardware and recheck the installed system using the same command. If lsmod shows no results, the kernel modules started by the bootloader do not match those installed on the system.

To fix your problem, you need the distro's recovery procedure or installation medium to reinstall the kernel and matching kernel modules again and set the correct entry in the bootloader.