Warning: This is quite long. If replying, please trim the response to
just the relevant portion.
I have spent the last week building systemd on a qemu instance. I'm
writing this to document some of the things I learned.
I started up qemu using a debian 8.8 iso. The command I used was:
#!/bin/bash
SUDO=sudo
[ $EUID == 0 ] && SUDO=
$SUDO qemu -enable-kvm -boot d \
-drive file=/mnt/qemu/debian88.img \
-cdrom debian-8.8.0-amd64-CD-1.iso \
-m 2G \
-cpu host \
-smp 2 \
-vga vmware \
-net nic -net bridge \
-machine type=pc,accel=kvm
Installing debian was uneventful.
I then used jhalfs to install lfs-systemd. Again this was uneventful. I
created a custom kernel and booted with no problems, but more on that later.
I deviated from my normal procedures and used only /boot as a separate
file system. Generally I also have /home in common with all my builds.
At that point I wanted to use jhalfs-blfs to show me the boot order. I
wanted to build gnome, so I selected gnome-terminal and a few other items
and ran jhalfs. It seemed to work well, however all the scripts were on
the debian system because the tools needed were not yet installed on my
new build.
There does seem to be a issue transitioning from the host to lfs via
jhalfs. I really only wanted to get a build order from jhalfs and doing
ls -1 > build-order seemed to be useful. That order, with some of my
notes is at http://anduin.linuxfromscratch.org/~bdubbs/files/build-order.
I have my sources available on an nfs exported partition and I mounted
that on the debian host as /usr/src and then 'mount --bind /usr/src
/mnt/lfs/usr/src' Now I can build in chroot!
Starting out, there are several packages needed to really get things
going. In my case openssh, wget, nfs (libtirpc/nfs-utils/rpcbind), and
sudo. Using the order generated by jhalfs indicates to me some problems
we have in the blfs book. Most of these are issues with dependencies.
For instance with gptfdisk, popt should be recommended.
I also note for the order generated that there are optional dependencies
for a package built after the current package. I did only ask for
recommended dependencies, but if an optional package is going to be built
anyway, then it should be before the main package, Again, popt came up as
number 189 when it could have been between numbers 6 and 7. I'm sure this
would be quite difficult to implement, but I'm just pointing out
possibilities.
The circular dependency of freetype -> harfbuzz -> freetype was not picked up.
Another issue is that package configuration needed to be done as the
packages are built to get a working system. I do not have any ideas about
how to automate that. It's a very difficult issue.
When I got to #34 (sudo), I rebooted. I was able to do my nfs mount and
resume building. I'll note that it is very convenient to build via ssh.
Some tests do not work, but I generally skipped those.
The script I use to launch teh new system in qemu is:
$SUDO qemu \
-enable-kvm \
-boot c \
-m 4G \
-cpu host \
-smp 4 \
-vga std \
-net nic -net bridge \
-machine type=pc,accel=kvm \
-drive file=/mnt/qemu/debian88.img \
-drive file=/mnt/qemu/tmp.img \
-usbdevice tablet
A couple of notes here. The tmp.img is a separate partition as I
generally use that for the actual builds. systemd by default uses a tmpfs
for /tmp. I wonder about the wisdom of that, especially in a multi-user
system as I initially ran out of memory.
systemd is not a very admin friendly system. One of the principles of
software user interface is to try to make things discoverable. My opinion
is that the functionality is quite opaque. It takes a lot of research to
figure out anything. In system V you generally only need to go to
/etc/init.d and look at the scripts. They are all quite short.
Another issue I had was that systemd, in it's wisdom, creates
/run/nologin. AFAICT it is never automatically removed. It is actually
defined in the file /usr/lib/tmpfiles.d/systemd-nologin.conf but you
override it by creating a file /etc/tmpfiles.d/systemd-nologin.conf. To
me that makes no sense at all.
Indeed the configuration files for systemd are spread out all over the place:
/etc/systemd 45 files
/etc/tmpfiles.d 3 files
/lib/systemd 340 files
/usr/lib/systemd 46 files
Enough of that for now.
One problem with running an lfe system in qemu is that it captures the
mouse. To release it back to the host you have to do ctrl-alt-G. There
are two ways to fix the problem. The first is to work on the host via
ssh. This allows copy/paste since everything is really on the same
system. The second is to add -usbdevice tablet to the qemu startup. This
frees up the mouse but still does not allow copy/pate between the qemu
host and client. Evidently you need an add on called spice and libvirt
for that. I have not explored that.
Also I had a problem getting xorg to work properly and at the right
resolution. The solution was to use the right xorg.conf. This is what I
ended up with:
Section "Device"
Identifier "Virtual-1"
Driver "modesetting"
VendorName "QEMU"
#BoardName "Virtual"
Option "AccelMethod" "none"
EndSection
Section "Screen"
Identifier "screen"
Device "Virtual-1"
Monitor "monitor"
DefaultDepth 24
SubSection "Display"
Modes "1400x1050" "1280x1024" "1024x768" "800x600"
EndSubSection
EndSection
=====
Back to jhalfs.
As I was going through the list of packages, I was unsure of the versions
I had vs what was in the book. In the script names, is would be helpful
if the package version was also listed. for instance:
120-z-cmake vs
120-z-cmake-3.8.2
======
Now I would like to talk about gnome. I had a heck of a time getting it
working. I would not work from startx and gdm would not work -- failing
and restarting very quickly. It DID work from sddm though.
I then tried as root and it also worked from startx. I finally figured
out that both gnome gdn and were trying to write to a file and did not
have permissions. I will be adding
export XDG_RUNTIME_DIR=/tmp/xdg-$USER
to /etc/profile to fix the problem, but it strikes me as pretty bad that
the whole system fails because of this without any type of error message.
I'll stick with xfce.
-------
And finally an interesting success. Because of the above problems, I
decided to remove qemu from the picture, I did the following as root:
On the virtual system:
cd /tmp
tar -cf systemd.tar / --one-file-system
The tarball was 8.6G. I copied it to my development system and
On the development system:
Used gdisk to create a new partition
mkfs.ext4 /dev/sdb16
mount /dev/sdb16 /mnt/tmp
cd /mnt/tmp
tar -xf /tmp/systemd.tar
edit etc/fstab
edit /boot/grub/grub.cfg
ensure qemu kernel is in /boot
reboot
Came up with only minor glitches. Fix network device (what's the systemd
equivalent to ifup/ifdown?) Rebuild kernel for mouse I forgot in the qemu
version. That was about it. Everything seems to work now.
Total time: 7 days.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
