Booting over the network to install the system

Do you still have CD/DVD players installed on your boxes? Well, I mostly don’t; why would I anyway?

Actually, apart from system installation or access to the rescue mode of the system installation, there’s nothing you cannot do without and nothing is not best to do without (nothing is slower and noisier on  nowadays computers). But that’s not even really true anymore, now most mainboards include an ethernet card capable of network booting even if hidden behind confusing names like NVDIA Boot Agent for instance.

Usually, it supports the Preboot Execution Environment (PXE) which combines DHCP and TFTP. That’s nice because it’s then easy with GNU/Linux to ran DHCP and TFTP servers. So here comes my PXE setup, using ISC DHCPD and TFTPD-HPA, both shipped by Debian.

As described in the README, on the server (you have a home server, right? *plonk*), put this PXE directory somewhere clever, like /srv/pxe for instance (yes, that’s what I did; but you can put it in /opt/my/too/long/path/i/cannot/remember if you really really want).

Run the gnulinux/update.sh script to get kernels and initrds. By default, it fetches debian and ubuntu stuff. If it went well, you should have several *-linux and *-initrd.gz files in gnulinux/ plus a generated config file named default inside pxelinux.cfg/
You may add a symlink to this script inside /etc/cron.monthly so you keep stuff up-to-date.

Then, you must install a “Trivial FTP Daemon” on you local server which will, in the context of PXE (Preboot Execution Environment), serve these files you just got:

apt-get install tftpd-hpa
update-rc.d tftpd-hpa defaults

Edit /etc/default/tftpd-hpa, especially TFTP_DIRECTORY setting (you know, /opt/my/what/the/…).

Finally, you must update your DHCP Daemon so it advertises we’re running PXE (filename and next-server options). With ISC dhcpd, in /etc/dhcp/dhcpd.conf, for my subnet, I have now:

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.100 192.168.1.200;

  # PXE / boot on lan
  filename "pxelinux.0";
  next-server 192.168.1.1;
}

Obviously, you wont forget to do:

invoke-rc.d isc-dhcp-server restart
invoke-rc.d tftpd-hpa start

That’s all. Now on your client, go in the BIOS, look for “boot on lan” and whatever crap it may be called (it varies greatly), activate it. Then boot. It’ll do some DHCP magic to find the path to the PXE and the menu should be printed on your screen at some point.

We can actually do plenty of things with this simple stuff. We could, for instance, use it to boot diskless terminals on a specifically designed distro.

Next Step towards GNUStep within KDE

Back in the days I started using GNU/Linux, the only user-friendly desktop environment available was KDE 1. So I started using KDE 1. Afterwards, considering license issue of Qt (that was no Libre Software at that time) KDE was depending on, considering progress being made by the GNOME project, I switched to GNOME 1.

Then, my brother Philippe advised me to give a try to WindowMaker. I did. At first, I was puzzled. But finally, I adopted this desktop environment inspired by NextStep. The main point is to kick the taskbar and the big start menu and, instead, going through apps with the right or middle click on the desk and having each important app to get a dock, which one could be used to launch the app or show the app if already launched.

Years afterwards, WindowMaker seemed to make no longer any progress and I wanted a modern desktop environment. Which means I wanted a desktop environment in which every piece of software is neatly integrated, where configuring new features is easy – while toying with both WPrefs and wmakerconf was not. And Qt was freed. So I get back to KDE. GNOME was longer an option, as I do not trust GNOME leaders like Miguel De Icaza to make the right decisions (the Nautilus and Eazel story was revealing enough for me: trying to behave corporatish, they chose the worse software to be the GNOME file manager, but they did while it wasn’t even coded, they only trusted a newly founded company made by people with no experience in Libre Software to do the right and good thing) and it was no surprise to me when HelixCode/Ximian/whatever-crap-it-is-renamed started to sell proprietary software under the denomination commercial software after implementing .NET, I expected nothing more from people talking about Open Source mumbo-jumbo ESR style, instead of Free Sofware, while they were getting popular just because of their involvment in a GNU project. KDE is powerful, rock-solid. But it is also über-conventional. They know what is working good in MS Windows, they clone it, improve it and release it. Moreover, KDE tries to address a broad audience, so KDE is made to seem familiar even to people having no clue about GNU/Linux. Moving back to KDE meant loosing the interesting design of WindowMaker.

Then, I had the opportunity to look at an Apple Macbook Pro. The dock, for good reasons, reminded me of WindowMaker. And finally, I found Daisy. It is a clone of Mac OS X dock, it works like the WindowMaker dock. But it is a plasmoid for KDE. It’s only just clumsier to set up (no easy drag and drop), prone to bugs (sometimes, a click on the dock app launcher start two instance). But it works. And I trashed once more the taskbar I definitely do not like.

KDE with Daisy, WindowMaker/Mac Os X style!

There is no Debian package, so I went to Ubuntu plasma-widget-daisy page. There, I downloaded the source tarball and the debian part (which contains the debian folder necessary to built the package). I extracted them all in a temporary directory. Then:

1/ I edited the debian/changelog file to add a new entry.

2/ I edited “Build-Depends:” in the debian/control file to depends on the pkg-kde-tools version that comes with my system (Debian unstable).

3/ I installed necessary dependancies to build the package – as the package was not in debian trunk, I made the guess that it had the same deps than the similar package plasma-widget-ktorrent:

# apt-get build-dep plasma-widget-ktorrent

4/ I rebuilt it:

$ dpkg-buildpackage -r fakeroot plasma-widget-daisy

5/ Then I installed the package.

You can fetch my plasma-widget-daisy_0.0.4.22a-0ubuntu2-fordebian1_amd64.deb package built against debian sid (unstable) for an amd64 architecture.

I also posted a RFP (request for packaging) against wnpp in debian BTS (bug tracking system).