Doing a BIOS update on recent Dell computers running linux is becoming really really easy, and is well integrated to the standard way to update software on linux distros using RPM and YUM. See this wiki page that helps to setup the dell yum repo. Do an initial invocation of bootstrap_firmware that'll enumerate the hardware of the machine that can possibly be updated through this method, pass the result of this command to yum, so the necessary firmware files will be downloaded, update the firmware, reboot, and voila! BIOS is up-to-date. No more proprietary MS-DOS executables, no more need to seek for an old bootable floppy with and even older copy of MS-DOS 6.22 on it.
[root@lxorgfr ~]# yum -y update
Loading "skip-broken" plugin
Loading "dellsysidplugin" plugin
fwupdate 100% |=========================| 1.9 kB 00:00
dell-software 100% |=========================| 1.9 kB 00:00
fedora 100% |=========================| 2.1 kB 00:00
updates 100% |=========================| 2.3 kB 00:00
bellet 100% |=========================| 2.1 kB 00:00
Excluding Packages in global exclude list
Finished
Setting up Update Process
Resolving Dependencies
---> Running transaction check
---> Package openldap.i386 0:2.3.39-3.fc8 set to be updated
---> Package control-center-filesystem.i386 1:2.20.3-2.fc8 set to be updated
---> Package yum-utils.noarch 0:1.1.11-1.fc8 set to be updated
---> Package mesa-libGLU.i386 0:7.0.2-3.fc8 set to be updated
---> Package spamassassin.i386 0:3.2.4-1.fc8 set to be updated
---> Package shared-mime-info.i386 0:0.22-4.fc8 set to be updated
---> Package yum-skip-broken.noarch 0:1.1.11-1.fc8 set to be updated
---> Package system_bios_ven_0x1028_dev_0x0211.noarch 50:a07-20 set to be updated
---> Package xterm.i386 0:232-1.fc8 set to be updated
---> Package util-linux-ng.i386 0:2.13.1-1.fc8 set to be updated
---> Package mesa-libGL.i386 0:7.0.2-3.fc8 set to be updated
[...]
[root@lxorgfr ~]# update_firmware --yes
Searching storage directory for available BIOS updates...
Checking System BIOS for OptiPlex 755 - a05
Available: system_bios(ven_0x1028_dev_0x0211) - a07
Found Update: system_bios(ven_0x1028_dev_0x0211) - a07
Found firmware which needs to be updated.
Running updates...
100% Installing system_bios(ven_0x1028_dev_0x0211) - a07
Done: Update complete. You must perform a warm reboot for the update to take effect.
[root@lxorgfr ~]# reboot
Broadcast message from root (pts/0) (Wed Feb 13 15:14:19 2008):
The system is going down for reboot NOW!
[root@lxorgfr ~]#
(et voila)
A couple of weeks ago, I finally bought some new hardware, to benefit of all the new Linux bells-and-whistles on the desktop, also of decent performances in current applications, and of virtualization-capable processors.
When I frequently read that a slow old PC is good enough to browse the web, I think this is blatantly false nowadays. My old Pentium 4, clocked at 2.4 GHz was regularly using 100% CPU at peaks, when rendering some complex web pages. I don't know exactly who is to blame. The complexity of the said web pages, the complexity of the firefox browser, the habit to put hardware intensive flash stuff everywhere [1], also the increasing use of ajax effects. Maybe a cumulative effect of all these reasons. But trust me, an old PC is just too slow to browse todays web. And I don't even speak about performance needed for gaming...
[1] even with the flashblock mozilla extension, so only selected flash are active.
What can be underlined about the hardware evolution since four years years:
My router stays up 24/7, and serves as my web browser, my mail server, and a few other public services. The machine I use for this is a Dell optiplex 755, with a Core 2 E6550 processor. I removed the pci-express video card, as this box is basically head-less, and if I really need to display output, I still can use the Intel onboard graphic card. This machine is really quiet, the processor only consumes 65 Watts. This is a good choice for a router. I'm also very satisfied by the purchase of one a the only PCI modem card, that is supported with linux, because it is a real hardware modem, and not a cheap winmodem.
My main desktop machine is a Dell precision T3400, with a Core 2 Quad Q6700 CPU. Four cores in a single socket is rather impressive, and remains me the old times, around 1996, when I installed my first Linux on a dual Pentium 90. I opted for a 30 inches flat panel screen, that advantageously replaces two 21 inches screens, with a wide resolution of 2560x1600 pixels. This kind of resolution requires a special dual-link DVI card. Initially, I had bought an nvidia quadro fx 1700. I thought this choice was a good balance between performance, and power consumption/noise (peak at 42 Watts). When I first started to play with the card, I have been quickly deceived by the amount of noise emitted by its small fan. This card occupies a single slot on the motherboard.
After some investigation, I discovered another model, also powered by nvidia, but sold to the gamers with a geforce 8600GT chip. This card made by Asus has approximately the same performance, and the same power consumption than the quadro fx 1700, but it has the great advantage to be passively cooled, with a big heat sink that occupies a second slot in the mobo. The same power, less expensive, with more silence in my room, sweet experience! OK, the GPU is clearly hotter on the passively cooled card (65 C degrees), than on the quadro fx (40 C degrees), but this temperature is still far from the 105 degrees limit, advertised by the nvidia-settings program.
Another of my goals was cable bloatedness reduction, that's been partially achieved :
10 Oct 2007 (updated 10 Oct 2007 at 14:27 UTC) »
IBM customer service
Last week, the LCD panel of my thinkpad decided to fail to light up at boot time. I contacted the IBM customer service at 10am, they quickly made a diagnostic of the problem. As the VGA output of the graphic card was still usable, the faulty hardware was certainly the LCD panel. The next day, at 11am, a technician on-site just finished to replace the dead panel.
25 hours to resolve a case of a hardware problem on a laptop. I don't need to tell that I don't regret the money that my employer put in the extra 3-years warranty, with on-site intervention. And no, I wasn't wearing this tee-shirt :-)
10 Oct 2007 (updated 10 Oct 2007 at 13:43 UTC) »
Virtualization is a hot topic. For a lot of good reasons
Virtualization on Fedora
The virtualization in Fedora has been advertised early with the shipping of Xen. Xen requires that the host runs a specific kernel, that lags behind the most recent upstream kernel version. The Xen guys at RedHat made a terrific work to port the Xen changes to current kernel releases, but this looks like such a daunting task, that they have a hard time to follow upstream kernel.
A new solution has been developed, KVM, that has an invaluable advantage to be merged upstream, and to work with an unmodified kernel, just by loading a module into the system. KVM is an api exposed to userland via the /dev/kvm device, and that has been integrated into QEMU, so QEMU commands can work unmodified with KVM.
QEMU is an older emulator, not only for x86 architectures. Coupled with a kernel module (kqemu), it can provide a nice emulation speedup, compared to a pure userland emulation. This kernel module is not yet upstream. It was proprietary code until recently. Its license is now GPL.
RedHat also developed for Fedora an interesting framework, virt-manager and libvirt, that allows to manage virtual machines, in a way that is independent of the underlying virtualization technology available on the host. It can currently handle both Xen, and KVM.
QEMU features
QEMU simulates an HDD using a single disk partition or file on the host machine. It can use a disk image format allowing embedded snapshoted states of the virtual machine. Features include compressed storage, on-demand growing disk images. It is also possible to separate the disk image in two parts : a read-only disk image in one file (typically shared among several virtual machines), and a second writable disk image, specific to each virtual machine, that use the copy-on-write principle, to only store differences with the read-only base disk image.
QEMU networking is still a bit tricky to configure, if the virtual machine must be reachable on the real network. A bridge must be created, including the real network interface, and a tuntap virtual interface. This tuntap interface must be handled by a virtual network switch emulator, like vde2. Access to this virtual ethernet switch may be granted to a given user. This user can launch, and attach many QEMU instances to this switch. Each instance with a different MAC address, so that each one obtains a distinct IP address on the real network.
QEMU virtual machines management is easy if they are configured to launch a VNC server at startup.
aironet/cisco wifi driver and wpa
The airo driver, the linux driver for aironet and cisco wireless cards, gained recently support for WPA encryption. Source code is available on www.gna.org in the airo-wpa module. This feature is now a requirement for access to all wireless networks configured by a security conscious administrator.
Matthieu Castet did an amazing work reverse engineering the windows driver with a modified ndiswrapper kernel module on linux. As a side note, luckily, we both live, Matthieu and me, in the country, where doing this reverse engineering is still legal, precisely for interoperability reason. Matthieu modified the airo driver and added the bits needed to handle a card with a WPA-aware firmware, and to talk to the wireless-extensions API with these new authentication schemes.
I still own an old pcmcia aironet 4800 card (hey Benjamin, if you read me, this is your card!), so I could test this modified driver with it. The first step is to reflash the card with a newer firmware, that supports WPA. Of course, This hardware is no longer supported by its vendor (aironet and now cisco) for a long time, and the latest released firmware is several years old. But, thanks to a nice hardware design, all 350 series cisco cards share the same 4500 radio hardware. So with luck, a recent firmware for cisco 350 cards does happily apply to my prehistoric pcmcia card.
Now the moment of truth is to test if the card and its unsupported WPA-aware firmware will associate with a WPA-enabled access point, using PSK authentication. And the answer is yes. wpa-supplicant successfully associates with my access point. I also made a test with NetworkManager, but the connection alternates up and down states, when wpa_supplicant runs in this context.
I will probably try to debug the problem a bit further, but what adds a bit of difficulty to this task, is that my pcmcia card doesn't work with ndiswrapper and the original Windows driver. So replaying the same method than Matthieu did, is not currently possible for me.
22 May 2007 (updated 22 May 2007 at 12:01 UTC) »
Fedora activity
Since a few weeks, I'm now a fedora maintainer of the FlightGear package. This is an exciting activity, that Hans de Goede convinced me to have. FlightGear is a well mature and realistic flight simulator. I spent a large amount of time, playing with it in the past months, and I appreciate this game a lot.
The reasons why I like this simulator are multiple. First, the scenery files are rich, and cover the whole earth. So it's very easy to just download the scenery of the area where you live, and to practice flying from a nearby airport. Coasts have a fine level of details, cities are mapped, and mountains are realistic. The second reason why I appreciate FlightGear is the accuracy of the simulation of environmental factors : weather can be rendered live, by querying in real-time the real weather information from various airports. This has an impact on the visibility distance, the altitude of the clouds layers, and wind and so on. The sun position also defines the scene lightning, and flying at the same location early in the morning, and late in the evening is a completely different experience. Finally, a third reason is the large variety of aircrafts, which also completely modify the fly feeling.
FlightGear is available in the Extras repository for Fedora Core 6, and will be available in Fedora 7 where Core and Extras have merged.
16 Nov 2006 (updated 31 Jan 2007 at 22:32 UTC) »
Modern computer under Linux can be sometimes paradoxal. An RTC modem on a laptop is an old and dusty piece of hardware, nobody really cares anymore, since networking function has been replaced by bluetooth, wireless, and faster gigabit devices for a long time. But modems are sometime the unreplacable way to connect to the net in some places, where a phone line and a dialup connection are the only alternative.
A usual Linux mantra is that old hardware have more chances to be supported than recent one, because it leaves more time to the kernel hackers to get their hands and the hardware, to obtains chipsets documentation, and to write and debug a driver. Except when said hardware documentation is unavailable, for miscelaneous reasons.
Winmodems are in this category. For the sake of hardware cost reduction, hardware manufacturers chose to replace plain old supported real modems components, with a standard Hayes interface through the serial port, by infamous Winmodems, more simpler DSP chipsets, often just integrated into the audio components of the laptop, but requiring a complex and closed-source DSP programming interface to handle international phone tonalities.
The situation is sad, because if you want to use a modem on a laptop today, you have to resort on old PCMCIA real-modem cards, that still work perfectly fine, because recent winmodems are just unusable. I don't want to rely on proprietary software, when I don't have to, when there's an alternative, I put some energy to help fixing some bugs in the pcmcia drivers of some old multifunctions (network + modem) pcmcia card (Linksys PCMLM56 and 3Com Megahertz 3CXEM556-B). Dominik Brodowski has been of a great help, very nice and very responsive to my bug and log reports, and I'd like to thank him publicly here. It is often said that a kernel hacker cannot own all the hardware combinations he writes drivers for, and this is indeed true. Also, a big quality of a kernel hacker is to be open to bug reports, and to guide the less-experimented people to find the cause of a bug, that they are the only one, who can generate and reproduce it. "Given enough eyeballs, all bugs are shallow" used to say ESR stated as Linus's law, this is exact, but eye-balls need to be encouraged, guided and advised towards the right place to look at.
9 Nov 2006 (updated 9 Nov 2006 at 22:36 UTC) »
I used in the past to build some custom RPM packages for the Linux distribution of my choice, Fedora Core. Building packages is not that difficult, it just requires a prepared environment, some skill to script how a software should be compiled and installed on the machine, and a relative patience, to restart the process from the beginning, when an unexpected error occurs during package generation, which can take a repeated long time when the software to be packaged is a big project. The following items are required:
The drawback of this method is that building a package uses the compilation tools of your own machine, which may introduce subtle problems (for example if the packages of your machine are not up to date, or if you use a non standard compiler by default, if you have a non-standard PATH, or even if your spec file is buggy you can potentially delete files by mistake,...).
Another typical problem with this method is that it is only possible to build packages for the distribution that is running on the build machine, and not for another one. For these reasons, it is important to have a sanitized build environment, that will be independant of the host build environment.
The Fedora project provides a complete infrastructure for building RPM packages, managing the whole chain, starting from the spec file handling, to the publication of packages and their related yum metadata on a remote server, for several Fedora Core distributions simultaneously.
Mock is a chroot-ed environment, automatically configured with a minimal set of packages, and used to build RPM packages. It relies on a set of yum repositories, and can generate build environment for several distributions in parallel. The drawback of mock is the counterpart of its force : it is slow to generate the build environment, because it installs with yum and RPM a minimal linux distribution each time a package is to be build. Hopefully this stage can be optimized :
Plague is the client-server infrastructure used to build Fedora Extras packages. It defines a set of builders, whose role is to receive a .src.rpm file, to build the package using mock locally, and to return the binary packages along with the compilation log to spot errors occuring during the compilation. The more builder you have, the better your build requests are processed. Builder can generate binaries for architectures that are compatible with their host architecture.
A plague server collects build requests, queues them, and dispatches them to the builders, it also collects generated packages, and build logs. All this information is made available via a web interface.
A plague client on the package maintainer machine is a command-line tool, that communicates with the build server, and is used to submit src.rpm packages to be compiled. In this case, src.rpm packages are _not_ the result of a previous compilation, but simply the container that includes the tarball, patches and the spec file needed to compile the program (rpmbuild -bs <specfile> is used to generate this src.rpm file). The client can process the build queue, kill pending jobs, requeue them, query the builders status for example.
The last step of this infrastructure is a CVS server, used to store spec files, and patches for each package. A directory different is created for each package, subdirectories are created to handle branches for multiple distribution versions (FC-4, FC-5, FC-6, devel, ...). Spec files and patches files are versioned in these subdirectories.
Push scripts
The extras-buildsys module of the fedora CVS repository provides some handy python scripts, that collect plague-builded packages, sign them with GnuPG, puts them in a common tree, creates the repodata information for yum, generates html pages describing them, and eventually uploads the final tree onto a remote web server.
The directory layout of packages as generated by plague is specific, because is stores each package version into a specific directory, and each architecture binaries in subdirs. These directories are processed by createrepo, because their content needs to be made available to mock too.
In the mock configuration of each builder, the following repos are needed:
Goodies : viewcvs, bonsai and lxr
Links
The Plague server : http://bellet.info/build
ViewCVS: http://bellet.info/viewcvs
Bonsai: http://bellet.info/bonsai/toplevel.cgi?treeid=extras
External links
http://fedoraproject.org/wiki/Projects/Mock
http://fedoraproject.org/wiki/Projects/Plague
http://fedoraproject.org/wiki/Infrastructure/VersionControl/Current
http://fedoraproject.org/wiki/Extras/UsingCvsFaq
The problem I was trying to resolve is the following : a laptop can connect wirelessly on one C-class network, or wiredly on another C-class network. A same DHCP server distributes leases on clients of both networks, with fixed IP addresses based on the network card hardware address. A DNS server provides two distincts names for each IP address (laptop.localnet. and laptop.wlan.localnet. for example).
This situation is cumbersome for at least two reasons:
So I decided to configure a dynamic DNS, feeded by the DHCP server, upon sollicitation from DHCP clients. The recommended DDNS style is interim, and in this scheme, two behaviours are possible : the reverse maps (IP address to hostname) are updated by the DHCP server to the DNS server in all cases, but the forward map can be updated upon request either by the DHCP client itself, or by the DHCP server.
On the security point of view, a DDNS update is possible if the DNS server and the update requester share a common static secret key (a TSIG key). If clients are allowed to update their forward map, then the TSIG key has to be spread on each client (in /etc/dhclient.conf), else only the DHCP server need to know the key (in /etc/dhcpd.conf).
The moment when forward and reverse DNS maps are updated is another important point of interest. The DNS records are not removed from the DNS server, when a machine disconnects from the network. When a machine connects to the network, both forward and reverse maps need to be updated. It is considered safe to update the reverse map without further verification, because the DHCP is in charge to ensure that the allocated IP address is not used by another machine, so updating the reverse map cannot steal someone else's identify. Updating the forward map is more delicate, because the hostname given by the DHCP client may already be in use by another machine. The DDNS protocol resolves this incertainty by inserting a supplementary TXT record in the forward map, a hash value called DHCID, based on information provided by the client, that identify it in a unique way. The DHCP server will refuse to update the forward map if the preexisting TXT record doesn't match with the newly computed one.
The problem with the default way to compute the DHCID is that it's based on the network card hardware address, so the wireless card and the wired card will generate two different DHCID, and the DHCP server will logically refuse to update the forward map, when switching from wireless to wired network, because it'll consider that two different clients try to register the same hostname. The solution to this problem is to define a unique dhcp-client-identifier string in /etc/dhclient.conf.
Another DHCP obscure behaviour tweak that caused me some trouble, due to its lack of documentation, is that the DHCP server silently discards DDNS updates concerning statically allocated IP address, except if explicity required (option update-static-lease in /etc/dhcpd.conf). The rationale of this option is that static leases should already be in the DNS, but there is a reason to distribute fixed IP addresses, even with DHCP, and even if the DDNS makes the hostname follow the updated IP address. A ssh client will warn loudly and repeatedly (man in the middle possible attack) if the association between an IP address and an hostkey changes.
With these two or three configuration tips, I have now a single DNS zone for my home network, that covers distinct physical networks, and an unified and dynamic host naming accross these networks.
17 Sep 2006 (updated 19 May 2010 at 20:55 UTC) »
[fr]: Le mois dernier, j'ai pris quelques photos du continent depuis l'île d'Oléron, plus exactement la citadelle du Château. De gauche à droite, on voit le fort Boyard, le pont de l'île de Ré derrière, la Rochelle, l'île d'Aix, le fort Enet, Fouras, l'embouchure de la Charente, le pont transbordeur de Rochefort, Brouage... Apres avoir remis les photos à l'horizontale, et les avoir fusionnées avec the Gimp, on obtient un panorama de 58720x720 pixels. Détail amusant, cette taille d'image n'est pas supportée par firefox, et le rendu est incomplet avec eog et gthumb.
