blino's website

Free software developer and more

So, some weeks ago, we have switched to modular IDE in the cooker kernel.

The spadework was mostly done for tmb kernels, since mkinitrd was already able to cope with modular IDE. Though, it's quite a premiere for our DrakX installer.

Last week, Pixel added some support in our bootloader-config utility that is called in kernel post-install. Now, it automatically adds an ide-controller alias (actually, an install directive) in /etc/modprobe.conf if needed. Titi also made the installer automatically load the IDE modules on the fly.

Nice, but it turns out it's not enough, and both of Pixel and Titi left on vacations... And now I have the QA team (excuse me, I meant "Enabling" team) on my back, especially my dear Damien /o\

After all, it shouldn't be that difficult. Arnaud mentionned that we have to load the ide-disk module (of course, we really want to use the disks), it should be a piece of cake. Ok, so make the ide-disk module included in drakx-installer-images, then make the stage1 part load the ide-disk module (in the rare case the installer uses ISO images or mirror tree from disk), and finally make the installer load the ide-disk module when probing IDE controllers.

That's it, I'm done. It's about minor modifications, don't even bother test them, just submit! No?

Grmpf, it does not build. Our init-like part of the stage1 installer used a minilibc (borrowed from Redhat a long time ago), which made use of _syscallX() macros, allowing to wrap system calls. But these have been hidden from user view in upstream kernel, and then completely removed, userspace applications having to use the syscall() function.

But it's quite different when you're buidling a libc... And RedHat|Fedora's Anaconda does not use minilibc anymore. Ok, I don't want to reinvent the wheel, some other minimal libc such as uClibc and dietlibc have an implementation of the syscall() function (commit of _syscallX() removal in uClibc).

And since we already use dietlibc in the plain stage1, that was the way to go. Even if we are losing 6K in the resulting binary, poor of us ;-) Then we just need to link with libcompat.a to use the syscall() function:

-static inline _syscall3(int, syslog, int, type, char *, bufp, int, len);
-static inline _syscall3(int, reboot, int, magic, int, magic2, int, flag);
+#include <sys/syscall.h>
+#define syslog(...) syscall(__NR_syslog, __VA_ARGS__)
+#define reboot(...) syscall(__NR_reboot, __VA_ARGS__)

I also used the occasion to update our dietlibc package to 0.30. It didn't build out of the box, because of a small typo (patch from ALT Linux, seriously?).

Finally, a day and a half after the initial rants, IDE disks can be used in the Cooker installer \o/

(and I don't mention the other projects I'm working on, neither the other installer build problems caused by new kernel headers, new glibc, new whatever, current buildsystem, whatever...)

Oh, and that was the "trivial" part, I expect migration to libata PATA drivers to be a lot more fun!



This week, one of the most critical bug left in our 2007 Spring release candidate was about the fglrx proprietary driver for ATI cards. It made the screen turn black when resetting an Xsession, making the system unusable locally (#29550).

Worse, during the first boot of a Mandriva One after installation, it made the first X session unusable...

To workaround this, we used the same workaround that had to be used in Mandriva 2007.1 for repeat logins with AIGLX, which is to restart the X server instead of resetting it. I've patched our DrakX libs so that harddrake and XFdrake set the correct options in kdm and gdm configuration files when the fglrx driver is used.

Maybe the 8.35.5 release of the fglrx driver would solve that, the changelog shows a bugfix for a similar issue, but we were to close from release to switched to a new fglrx driver.

Too bad we still need proprietary drivers for high-end ATI cards :-/



In 2006.0 and previous releases, the CPU frequency modules were detected using the cpufreq service. This was quite bad to do this in a service, since it performs detection and computes modules list at each boot, while it can be a one-time process (such as in the lm_sensors service).

So, I've written a cpufreq.pm module in DrakX, based on the initscript. It allows to detect required modules, and to write them in a /etc/modprobe.preload.d/cpufreq file.

It is used by harddrake and the installer. The plan is to drop modules detection from the cpufreq service, and maybe to remove this service, if nobody uses the syfs cpufreq initialization part.



drakx failes to detect USB keys in cooker, because block devices are now named differently in sysfs (using block:<device> naming).

This was fixed for some USB sysfs fields, but the fix wasn't general enough. I've extended it to handle more sysfs fields, such as usb_vendor/id, and to fix our detect_devices::isKeyUsb() function.

USB key are now correctly detected, this should allow the draklive copy wizard to process normally in the next cooker live snapshot.



A bug in my laptop support patch made harddrake reconfigure laptop related services at each boot on desktop systems (#23072).

For example, it disabled the cpufreq service at each boot, while it should only be done when switching from laptop to desktop (to enforce distribution policy), and not at each boot.

It's now fixed in cooker and 2006.0 SVN.



drakx previously failed to guess the correct driver for multi-function PCMCIA device cards. It used to fallback on the first driver matching the device modalias, which may be wrong.

To prevent misdetection, it doesn't fallback on the driver resolved by the modalias if the module is loaded (else, it would already be binded).



Previously, the lspcidrake command was not fully usable during the install, it didn't even support the verbose option (-v).

Now, it has a standalone lspcidrake-compliant output and allow verbose listing (with vendor/device IDs).



Now that the pcmcia initscript is dead, we have to preload the PCMCIA controller module using another way.

Previously, I wrote an udev rule to load yenta-socket at coldplug for devices supporting it, but other controllers were not handled.

Since /etc/rc.modules now also loads modules from /etc/modprobe.preload.d/, I've made the harddrake::autoconf module drop a pcmcia file there, that contains the name of the PCMCIA controler module.

This is now used in the installer and harddrake.

This also made me notice the yenta-socket preload rule was broken in the pcmciautils package, it lead to general PCI hotplugging /o\



I've cleaned up a bit the synaptics-related code in DrakX (installer + mousedrake). We now don't specify any synaptics driver options for classical synaptics touchpads, but we let the driver do it.

Though, we still have some specific options for ALPS touchpads. Maybe they should be set directly bythe synaptics driver instead.



blosxom Optimised for standards.
Olivier Blin (2005)