A recent upgrade in Arch Linux caused my Thunar file manager to lose its auto-mounting capabilities.
Now granted, auto-mounting of removable media (floppy, ZIP, CD/DVD, USB, etc.) on my system is purely a convenience. It’s not a necessity. I have no fear of the command line, so mounting manually can always be achieved. It’s the principle of the thing, dammit. What used to work should continue to work. Unfortunately, as we all know, thanks to updates of one sort or another (in any operating system), this doesn’t always hold true.
After doing some reading and research into the causes of Thunar’s apparent crippling, I became aggravated with Arch because recent updates have been plaguing me with breakage. Now, let’s be honest here… it’s not really Arch’s fault. Arch is a rolling-release distribution. Things change rapidly. The developers keep the base system closer to the bleeding edge that most periodic-release distributions. Anyone who uses Arch knows these things.
I run Slackware as my primary operating system on all my machines (except for an old Dell Latitude 610 running Bodhi Linux). Arch is my secondary (backup) operating system on my main system. I used to use Debian for this purpose, but as much as I love Debian, it is just too sluggish about getting current versions of apps in its repos. Now don’t all you Debian folks start throwing rubber chickens at me. I understand that Debian’s legendary stability is due to the fact that its stable repos contain only tried and truly long-term tested versions of applications. That is how it should be with Debian (I run Sid as a tester on my system, by the way).
So, back the Arch situation…
In the process of trying to find out what I needed to do to fix the auto-mounting issue, I ran across some information here and there about systemd. What is systemd, you might ask.
systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit.
I noticed that Arch’s core repo shifted udev from its stand-alone status to a sub-app of the systemd-tools application.
2012-06-01 – Dave Reisner
systemd and udev have been merged upstream. We will still ship them in separate packages. However, in order to keep things simple, udev will now be part of a package called systemd-tools. This package contains several other standalone tools which can be used without systemd. The astute reader will note that this also means the entirety of systemd is available in the core repository.
Please replace udev with systemd-tools when prompted. If you upgrade the linux package at the same time, you may see an error during initramfs creation that the udev hook is not found. After the upgrade completes, please rerun ‘mkinitcpio -p linux’ to ensure that a bootable image is created for the newly installed kernel.
Seeing this made me wonder if Arch was going to transition to systemd over initscripts sometime soon. To be honest, as some of the folks at Scot’s Newsletter Forums/Bruno’s All Things Linux can attest to, I actually became a bit peeved… pissed off, you might even say. All’s well, though. Ignorance is a great stimulant for fear and loathing. Knowledge paves the way for understanding and acceptance.
A little research was in order, so I spent the next few days after this initial rant about systemd learning what I could about it. Eventually, I decided to convert my Arch to systemd 100%, eschewing initscripts entirely. How did that go? Relatively well, actually. Read more about how I did it and how things turned out HERE, if you’re interested. I even managed to solve my auto-mount issues along the way.
systemd is available in many distributions already. I do believe that it has a good chance of replacing the standard initscripts method of services in GNU/Linux in the near future. If you’re a tinkerer, go give it a try on some test partition on one of your systems. I wouldn’t recommend converting 100% to systemd on your main operating system, though; not unless you really know what you’re doing. It wouldn’t hurt to learn the fundamentals of systemd. I believe it’ll be around for a while.
*Sorry for the raw links. I’m being lazy today.