Mandriva 2010 has a vastly improved install script. The install provided a choice between KDE and Gnome desktops. I went with Gnome, as KDE and older machines have a stormy relationship. After the initial boot, there were several problems.
The most serious problem was that the ath5k module failed to connect to my WiFi network. When I ran the command ‘dmesg | less,’ I found the clue to the problem. Following is the snippet that tells the story:
cfg80211: Calling CRDA to update world regulatory domain cfg80211: World regulatory domain updated: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) ath5k 0000:03:00.0: enabling device (0000 -> 0002) ath5k 0000:03:00.0: PCI INT A -> Link[LNKD] -> GSI 10 (level, low) -> IRQ 10 ath5k 0000:03:00.0: registered as 'phy0'ath: EEPROM regdomain: 0x10 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: CO ath: Regpair used: 0x10
The issue is that each country could have different regulations regarding WiFi frequencies and power. The purpose of the cfg80211 module is to obtain the frequency map based on CRDA (Central Regulatory Domain Agent), which it than passes to the ath5k module. During the boot process, the kernel does not know the correct value for alpha2. There are two user-space programs that can alter the configuration of these driver modules, which operate in kernel-space: the ‘iw’ command, and the ‘wpa_supplicant’ daemon. The real problem is that the ‘wpa_supplicant’ daemon is not running, as it was not installed during the initial install.
When Mandriva boots, there is this long pause in the boot cycle. It turns out that rc.sysinit uses a scsi_wait_scan module to introduce a delay. I find the use of a kernel module a rather strange solution.
I found the delay by pressing ESC to get out of the boot splash. There were two other messages immediately following that are a clue to why the system boots without a swap partition. I was hoping to find a clue in /var/log/boot.log, but it was empty. I checked /var/log/messages and no clues. The /proc/swaps file is empty, which confirms the lack of a swap partition. By comparing /dev/disk/by-uuid and /etc/fstab, I found that the problem was the UUID for the swap partition had changed. Another install could have altered the UUID for the swap partition. Had there been a boot log, it would have saved me a lot of time.
I finally connected the machine to a hard-wired network. I downloaded wpa_supplicant and iwconfig, and a few other packages. It took awhile, as the Gnome panel crashed during the configuration of eth0. I had problems connecting to some of the repositories on the first round, but worked on the second. After rebooting with the WiFi card, I am back to being on the wireless network.
I do not like the package manager. Every time I executed a search, the package manager downloaded files for every repository. Finding the three references to iwconfig took five minutes. I can tell that this package manager is going to test my patience.
In my opinion, Mandriva 2010 needs some serious work. I would never recommend it to anyone, who didn’t have a good understanding of system diagnostics. Of the seven distributions that I installed on this cycle of updates, this was the most difficult.


4 comments ↓
[...] Here is the original: Mandriva 2010 – A Review — Low Cost Computing [...]
[...] Mandriva 2010 – A Review [...]
The problem with the empty boot.log seems to be quite general judging by Google. It may be that something was changed at kernel level. Anyway in Mandriva 2009+ the boot log can now be found at:
/var/log/prcsys.log
Due to a disk crash, I no longer have Mandriva installed on any machine. One of these days, I will install and test the latest version. Thanks, for the info on the boot.log file. The problem is that the kernel cannot directly write to a user space disk file. It needs the help of a user application to extract the log data from the kmsg buffer.
Leave a Comment