No smooth transition in Debian

Bugreport 638019 appears to be very straight forward, until the code finally hit Debian Testing last weekend. A simple relocation of a FIFO-buffer from /dev to /run caused direct trouble for machines with systemd and a normal shutdown wasn’t possible anymore. Both bugs 657979 and 657990 are a results of the modification. Seeing the overview of effected files and made me go back to the previous working release of source package sysvinit with the following commands

$ cd `xdg-user-dir DOWNLOAD`
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/bootlogd_2.88dsf-18_amd64.deb
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/initscripts_2.88dsf-18_amd64.deb
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysv-rc_2.88dsf-18_all.deb
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysvinit-utils_2.88dsf-18_amd64.deb
$ wget http://snapshot.debian.org/archive/debian/20111223T034013Z/pool/main/s/sysvinit/sysvinit_2.88dsf-18_amd64.deb
$ dpkg -i bootlogd_2.88dsf-18_amd64.deb initscripts_2.88dsf-18_amd64.deb sysvinit_2.88dsf-18_amd64.deb sysvinit-utils_2.88dsf-18_amd64.deb sysv-rc_2.88dsf-18_all.deb

And as there is no solution for now except a dependency change for systemd the package are being placed on hold like the last time they broke systemd.

$ echo "bootlogd hold" | sudo dpkg --set-selections
$ echo "initscripts hold" | sudo dpkg --set-selections
$ echo "sysvinit hold" | sudo dpkg --set-selections
$ echo "sysvinit-utils hold" | sudo dpkg --set-selections
$ echo "sysv-rc hold" | sudo dpkg --set-selections

It sounds strange for Linux-people, but I really wished I had an alternative boot environment like Solaris has. Maybe this is the reason for me to invest more time in read-write within BtrFS.

Debian Wheezy and GNOME 3.2

The migration of GNOME toward version 3.0 in Debian earlier this year wasn’t very successful in the beginning, but a lot of bugs where solved during the summer. GNOME 3.0 made it into Wheezy during the release of 3.2 and maybe for the better. Now only a few months after the release of GNOME 3.2 almost all packages have been uploaded to experimental or unstable, and most of them even already migrated to testing.

But what brings GNOME 3.2? A lot of people are unhappy and some of these points are valid and need to be fixed. Others can be discussed if they are true. One thing that changed in 3.2 is how GNOME interacts with your address book and your instant messaging accounts. Connections to instant messaging networks are automatically being started when you log in. This also reflects in the search screen when you type in a friends name and you direct see his connection status.

GNOME Online Accounts is another example of making things simpler for the user. Currently it only works for Google, but I really hope current proposals with querying the right SRV-records in DNS are also going to be part of GNOME in a future release. For now GNOME Online Accounts setups up multiple Google services up like Mail, Calendar, Chat, Documents and Contacts with a single authentication token. Different services don’t have to maintain and store the credentials in GNOME Keyring or in still in there own way. Hopefully there will come a solution for Liferea which still stores te users password plain-text in the configuration file.

Other third-party applications like Simple Scan, Shotwell and Deja-Dup are slowly making there way into becoming part of GNOME. I can’t wait to see what is going to happen with the GNOME 3.4 release as both Epiphany and Evolution are going to have some major work done to them. A switch to Webkit 2 and ending the usage of GtkHTML in Evolution. Hopefully after this Epiphany can replace Firefox completely on my desktop.

It is good to see the progress GNOME is making into becoming an interface for cloud services by simplifying the configuration for users, but also separating data from applications more and more. I can’t wait to see how GNOME Document is going to evolve, but two other things still open is a good solution for RSS-feeds and chat-logs as Empathy is still storing them on disk and isn’t able to use logs stored by Google for example.

In the end I’m happy with GNOME 3.2 in Debian Testing right now and Debian on my workstation is back to it’s weekly testing upgrade schedule as most parts are working. I even think that I will continue to do this during the 3.4 release as most of the GNOME dust has settled. Maybe I make an exception for both AbiWord and Gnumeric when they switch to GTK3 and hopefully also better OpenDocument support.

The hunt for /etc/.pwd.lock

After upgrade Debian to kernel 3.0.0, I saw a hidden file called .pwd.lock in /etc which I didn’t noticed before. Checking other machines gave the same result as shown below, but both without a matching Debian-package or manpage.

$ ls -l /etc/.pwd.lock
-rw-------. 1 root root 0 feb 27  2009 /etc/.pwd.lock
$ ls -l --time=atime /etc/.pwd.lock
-rw-------. 1 root root 0 apr 10  2010 /etc/.pwd.lock
$ ls -l --time=ctime /etc/.pwd.lock
-rw-------. 1 root root 0 aug 14  2010 /etc/.pwd.lock

As time match at least the installation date of the machine and exists on other machines it appears to be a valid file, but with what purpose? After reading the Linux Programmer’s Manual two functions called lckpwdf and ulckpwdf where candidates for using this file. Checking the source code at Sourceware confirmed that both lckpwdf and ulckpwdf are using the file. And reading the manpage about these functions also confirms it’s purpose, a lock file the commands like passwd.

The lckpwdf() function is intended to protect against multiple simulta‐
neous accesses of the shadow password database. It tries to acquire a
lock, and returns 0 on success, or -1 on failure (lock not obtained
within 15 seconds). The ulckpwdf() function releases the lock again.
Note that there is no protection against direct access of the shadow
password file. Only programs that use lckpwdf() will notice the lock.
 
These were the functions that formed the original shadow API. They are
widely available.

This is another example why open source matters. You can get the evidence when you want and/or need instead of trusting some manual to explain things. Verification will become more important as systems get more complex. It was/is also a big advantage when OpenSolaris was created with it’s web accessible source repository.

Transitie naar /run

In een vorige posting gaf ik al een hint naar de transitie naar /run en voor ongeveer een week geleden zijn de packages geüpload naar Debian Unstable. Maar wat brengt deze transitie? Eigenlijk het gebruik van tmpfs voor oa /var/run, /var/lock en /tmp, maar ook uiteindelijk /etc/mtab te verhuizen naar /proc/mounts.

Na het upgraden van alle sysvinit-packages en een paar kleine aanpassingen aan /etc/default/rcS zag df er als volgend eruit.

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg00-root  19G  9.3G  8.2G  54% /
tmpfs                 5.0M     0  5.0M   0% /lib/init/rw
tmpfs                 788M  744K  788M   1% /run
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                 1.6G  152K  1.6G   1% /tmp
udev                   10M  4.0K   10M   1% /dev
tmpfs                 1.6G  516K  1.6G   1% /run/shm
/dev/sda1             236M   47M  178M  21% /boot
/dev/mapper/vg00-home 854G  707G  104G  88% /home
/dev/sr0              6.6G  6.6G     0 100% /media/cdrom0

Nu worden /var/run en /var/lock ook met een symlink omgeleid naar /run en hiermee komt ook een einde eigenlijk dat packages directories kunnen aanmaken in /var/run bijvoorbeeld of een directory bestaat.

$ ls -ld /var/run /var/lock /tmp
drwxrwxrwt. 11 root root 280 mei 25 01:15 /tmp
lrwxrwxrwx.  1 root root   9 mei 23 22:51 /var/lock -> /run/lock
lrwxrwxrwx.  1 root root   4 mei 23 22:51 /var/run -> /run

Hiermee is eigenlijk de weg vrijgemaakt om de transitie van SysV init-style naar systemd v25 te beginnen, maar eerst is het wachten totdat alle packages Debian Testing bereiken zodat er enige vastigheid is. Met systemd v25 alleen nog in experimental kan dat nog wel even duren, maar aan de andere kant de freeze periode voor Wheezy is voorlopig nog niet gestart.

GNOME 3.0 op Wheezy

GNOME 3.0 op mijn Wheezy workstation is niet meer helaas door stabiliteits problemen. In iedergeval niet totdat GNOME 3.0 in Debian Testing is geland en hoe snel het daar komt blijft nog even de vraag. Afgelopen weekend werd er wel gesproken op IRC om de transitie van experimental naar unstable voor te bereiden. Zeker nu 3.0.1 al enige tijd beschikbaar is en 3.0.2 voor de laatste week van mei op de planning staat.

Nu terug op mix van GNOME 2.30 en 2.32 wordt wel langzaam duidelijk dat ik GNOME 3.0 toch een beetje mis. Er zijn nog voldoende dingen die niet af zijn of verbetering behoeven, maar het idee van interactie met je systeem, je data en je communicatie spreekt me wel aan. Hopelijk komt die transitie snel, maar of deze soepel zal verlopen? Zeker gezien problemen met GCC 4.6, Glibc 2.13 en de transitie naar /run. Ik kan al wel vast zeggen dat de testen met systemd als vervanger voor de traditionale init en SysV-scripts zeer goed zijn bevallen.