In post 19 (Creating an Arch Live-CD) I blogged about building a simple Live-CD on Arch Linux. It was the summary of my first attempts relating to that topic. In the meantime I created another ISO and published it as a first preview of my “Desktop Demo DVD” project in post 21 (The Desktop Demo DVD).
This new entry will describe how my “DDD” was built (and thus how you add things like a graphical login manager and add users to a live medium).
First I create a new virtual machine to keep things clean and tidy and then build and install the archiso tool. Next is building AUR packages edelib and ede as well as creating a custom repo for them. (I won’t repeat it in detail here. You can look up both things in post #19 if you wish).
Just like in my previous building attempt, it’s necessary to create a new directory and copy over the “releng” dir from archiso. After that the various steps at configuring the iso can be taken.
The first thing to do is adding the right packages to the file packages.i686. Since we want a graphical environment, it’s a good idea to have xorg-server installed (we’re going to use a graphical login manager this time, so we can do without
Since the system is meant to run on about every hardware, X11 needs the proper graphic drivers. You may want to look for all xf86-video-* packages and add them. The only issue with that was that the openchrome and unichrome drivers were conflicting, but later (and older) one has been removed from the “extra” repository recently. Whatever you do, be sure to leave xf86-video-vesa in there – that’s the fallback driver that will work on most machines even if none of the others does (which is pretty rare however). Also it might be a good idea to add xf86-input-evdev just to make sure, you can use e.g. your keyboard in X. Adding virtualbox-guest-modules, too, will let X.org use the appropriate driver if running inside a VirtualBox VM.
Next I added the desktop environments that I wanted to be available. I chose mate (remember to add the additional repos for it and ede!), xfce4, lxde and e-svn as well as libxpm (needed by ede) and the packages edelib and ede. Finally the display manager lxdm is added as well.
Thanks to systemd, much of the wiki page about archiso is outdated and no longer of any use. This is the case e.g. when it comes to starting the display manager automatically after booting. It suggests using an inittab and we could actually do so and use a sysVinit compatibility package as well. However it was already announced that this would be dropped in the forseeable future so it’s best to do things the proper way right from the beginning.
LXDM comes with its own service file for usage with systemd. So the default command to configure the system for starting it after booting is systemctl enable lxdm.service. However this will of course not work in our case: First we don’t even have LXDM installed on building system and second – even if we had – enabling it there would not affect the live system. However for that reason there’s a folder called root image where we can make changes that will affect it!
So what does the above command really do? No more actually than creating a softlink! Of course we can do that by hand, too. Let’s change our PWD (present working directory) to /root/archlive/releng/root-image/etc/systemd/system. Now let’s create the proper link, shall we? The command for that is ln -s /usr/lib/systemd/system/lxdm.service display-manager.service.
Next step is creating a new directory (that is normally created when LXDM is installed): mkdir ../../lxdm and then I change into that dir. Afterwards I install lxdm on my build system and copy its configuration file into the new dir: cp /etc/lxdm/lxdm.conf . (if you’ve got LXDM installed on any other system, you can of course also copy it from there). Now it’s time to edit lxdm.conf: I simply add user “arch” to the blacklist (right at the end of the default configuration file). It’s a user automatically created by the install scripts and I have not yet looked into how to prevent its creation. For that reason I decided to just block it there so that it’s not offered by LXDM.
Adding a user
This step is important since we disabled the user “arch” and cannot log in as “root”. The solution suggested for this on the Arch wiki is simply copying over the files passwd, shadow and group (all located in /etc) from a system set up the way we want it. This is actually a fine way and since we’re using virtual machines anyway, it does not hurt to simply clone one, adding the desired user (“desktopdemodvd” in my case) there and copying said files over to root-img/etc on our building VM (using a USB device is probably the most confortable way).
That was the easy part. Many DEs will however not work if there’s no proper /home/$username directory present. We could of course create one in root-image/home, but that would be owned by root on our live system so that’s not quite what we want. Again the wiki is outdated (while I’m at it anyway, I should dedicate some love to it when I’m done here, I guess). We want to do things the systemd way! So how to do it in this case? Let’s write a new service for it (woah)!
Luckily things are easier than it might look first. Ok, I admit that it took me a few attempts before things finally worked right. But you can save yourself some time and simply copy what I did. Change into the dir root-img/etc/systemd/system again. Now create a new service file – I called mine “autostart.service”. The content of my file is like this:
ExecStart=/bin/chown desktopdemodvd /home/desktopdemodvd
Note: “ExecStart=/bin/chown desktopdemodvd /home/desktopdemodvd” is one line!
Yes, if I remember correctly, that was all. You should be able to build the iso now.
I don’t know if I did any changes beside these, but this blog entry at least shows two important things: Adding users and using a graphical login manager.
There are of course a lot of things you could customize as well and perhaps I’m going to explore some of these in the future, too. But right now I’m going to wait and see what happens with the “DDD”.
My next post will deal with what should be considered essential graphical applications – and afterwards we’re getting back into the world of toolkits.