Replacing sysv-rc by OpenRC on Debian

I won’t comment once again systemd, I think my mind set on the topic and future will tell if I was right or wrong. Still, dislike for the humongous scope self-assigned by systemd does not equate to consider that sysv-rc cannot be improved, it does not mean being stuck with sysv-rc for life.

Good thing is OpenRC is still being developed (latest release: 7 days ago) and, being portable over BSDs, is very unlikely to follow systemd path. Switching Debian 8.8 from sysv-rc over openrc (assuming you already got rid of systemd) is just a matter of installing it:

apt-get install openrc

for file in /etc/rc0.d/K*; do s=`basename $(readlink "$file")` ; /etc/init.d/$s stop; done

Then after reboot, removing sysv-rc:

apt-get --purge remove sysv-rc

rm -rf /etc/rc*.d /etc/rc.local

You might want then to edit /etc/rc.conf (for instance for LXC containers rc_sys=”lxc” option), check status with rc-status, check services according to runlevels in /etc/runlevels.

Update: also works with Debian 9.0 just released. But do not bother removing /etc/rc*.d, they now belong to package init-system-helpers, a package that “contains helper tools that are necessary for switching between the various init systems that Debian contains (e. g. sysvinit or systemd)”, essential on which other packages depends on (like cron). I actually asked for init-system-helpers not to force people to have in /etc directories that makes sense only for systemd or sysv-rc but, so far, got no real reply, but a WONTFIX closure – apparently the fact that update-rc.d would require /etc/rc*.d is the main issue, while update-rc.d handles perfectly the fact that /etc/runlevels may or may not exists.

For more details about OpenRC, I suggest to read Debian’s Debate initsystem openrc listing pros and cons.

 

Running Debian GNU with kFreeBSD

As you could have guess considering my latest update to my iPXE setup, I’m currently giving a try to Debian GNU along with FreeBSD kernel – Debian GNU/kFreeBSD.

The hardware I’m giving this try with is neither simple nor complicated: it’s old but it’s also laptop; a Dell Latitude C640 with a P4 mobile CPU and 1GB RAM.

The install was made over network. There’s nothing overly complicated but to avoid wasting time, it’s always good to properly RTFM. For instance, I learned too late that kFreeBSD does not handle / partition set on a logical one. I did not understood exactly how come, but I had to get my / partition on ufs (ext2 for /home was ok though). I did not even got into ZFS, as it looks like it’s not recommended with a simple i686 CPU. It took me a while and find no way to get my NFS4 partitions mounted as usual from /etc/fstab, or even with mount, I had to add a dirty call to /sbin/mount_nfs -o nfsv4 gate:/all /path in /etc/rc.local. And when it came to Xorg, I found the mouse to be sometimes working, sometimes not, plenty of overly complicated and confusing info on the web, to finally come up with a working /etc/X11/xorg.conf containing only  Section “ServerFlags”  Option “AutoAddDevices” “False” EndSection (on three lines).

These are some little inconveniencies that you would not expect with a recent GNU/Linux system install, that the debian-installer does not prevent you in any way to hit/create. I’m not even sure that I found the best fixes for them. It feels a bit like installing RedHat 5.2 🙂 with is more than what I actually expected.

So far I did not encountered any issue to get anything working but the suspend/sleep and general energy management looks much less reliable (with xfce4). On a side note, the fact that only OSS is available with kFreeBSD pushed me to update my wakey.pl script, I expect it to run on any BSD now.

Booting over the network to install the system (improved, with iPXE instead of PXE)

A few month ago, I provided my setup using pxelinux, isc-dhcpd and tftdp-hpa in order to make possible boot on lan. I improved this setup to chainload iPXE instead. I’m not interested in overwrite ROMs of ethernet devices I have so I still use PXE but only in order to get to iPXE that is way more powerful, as it allows direct access over http and much more.

The README in the my PXE directory explains the whole (quite short actually) install from scratch process. If you had the previous version running, note that the DHCPD configuration and update script changed (and the case of subdirectories changed too).

Modifying preinst and postinst scripts before installing a package with dpkg

Ever found yourself in the situation where you’d like to ignore or edit a postinst or preinst script of a Debian package?

As Debian froze Wheezy I decided it would be a good time for me to upgrade my home server, to help catching bugs and because it’s Sandy Bridge based not well supported regarding its sensors by Squeeze’s kernel. Unfortunately, I had weird stuff regarding EGLIBC, namely I had the 2.13 version installed from scratch, unknown to the dpkg database, while dpkg only knew about the cleanly installed 2.11. So the upgrade failed with:

A copy of the C library was found in an unexpected directory:
  '/lib/x86_64-linux-gnu/libc-2.13.so'
It is not safe to upgrade the C library in this situation;
please remove that copy of the C library or get it out of
'/lib/x86_64-linux-gnu' and try again.

dpkg : erreur de traitement de libc6_2.13-33_amd64.deb (--install) :
 le sous-processus nouveau script pre-installation a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
 libc6_2.13-33_amd64.deb

Nasty. EGLIBC/GLIBC is a major piece of the system, you cannot simple “remove” it or “get it out” and expect the system to continue to work. Moreover, in this specific case, these files we’re not truly an issue: they were about to be replaced during the upgrade process. But dpkg does not provide any mean to ignore configure scripts (and will probably never do). So one easy workaround is to uncompressed, edit, rebuild and install the package as follows:

aptitude download libc6
dpkg-deb --extract libc6_2.13-33_amd64.deb libc
dpkg-deb --control libc6_2.13-33_amd64.deb libc/DEBIAN

Then we can edit libc/DEBIAN/preinst (I commented out the exit 1 after the safety warning)

dpkg-deb --build libc
dpkg -i libc.deb

Yes, it’s fast 🙂

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.

Package: amarok 2.4beta1 for Debian testing

Amarok is a nice music player for KDE. Inspired by iTunes interface, it features a clever random mode, provides Wikipedia/lyrics/photos pages for the currently played song, handles mtp devices and works with lastfm so you can have online stats of what you listen to and find people that listen to the same crap too. That’s definitely a nice software. But, unfortunately, it’s quite buggy.

This morning, Amarok would not start, no matter what. Well, it’s started once I erased .kde/share/config/amarok and .kde/share/apps/amarok. Then, shortly afterwards, it failed to start once more. I’m not quite frankly prepared to remove my Amarok config twice per day. So I decided I would just give a shot to a more recent version and the first beta for 2.4 around seemed a good pick.

Here’s amarok 2.4beta1 (2.3.90) packages for Debian testing amd64.

It was built with amarok Debian experimental directory (a new entry added in debian/changelog, usr/share/doc/kde/HTML/* removed from debian/amarok-common.install, usr/lib/strigi* removed from debian/amarok.install, usr/lib/kde4/*.so and usr/lib/*.so* added to debian/amarok.install, target override_dh_shlibdeps: added to debian/rules and all patches removed from debian/patches/series) and amarok official latest source package (renamed amarok_2.3.90.orig.tar.bz2) using the command dpkg-buildpackage -rfakeroot inside the amarok-2.3.90 directory (source tarball decompressed) containing also the debian directory.