Report from another try of running ostree



Hello everyone,

It's Christmas again, we're all nicer and happier, so what better time
to try running the latest ostree?
The revision I tested was
9c17c4410dbc31198631beda454eaf619c4b681e82f498187991b1adb53d5ff3, and
here is what I got.

First of all I had to update the Grub2 integration script (bug
690744). If you want to try it, it's probably easier than hand-editing
40_custom to add the ostree entries. You need to add
GRUB_DISABLE_LINUX_UUID=true
GRUB_OSTREE_OSNAME=gnome-ostree
export GRUB_OSTREE_OSNAME
to your /etc/default/grub and re-run grub2-mkconfig.
If you want a revision other than current, you can also set + export
GRUB_OSTREE_REVISION.

Then I encountered a problem with dracut not being updated for the
brave new multi-os world (bug 690742). I had to patch
$(ostreeroot)/lib/dracut/modules.d/99base/init.sh to fix the variable
NEWROOT.

After that I finally got it to boot - except that there was no GUI.
Turns out that the yocto kernel is missing the whole drm subsystem,
meaning that no HW acceleration is possible and X starts in vesa mode
with the shadow FB (at 1024x768). AFAIK, this is a known problem, and
Colin is working to prepare a better config for the gnome-ostree
kernel.
But things are actually worse: gnome-session-check-accelerated fails,
which means that gdm-shell fails to gdm-fallback, but metacity is not
installed at all, so it just fails in a loop (5 times, then it gives
up). Obviously, given that fallback mode is no more, IsRunnableHelper
checks need to be dropped from gnome-session (bug 690745)

Ok, so I said to myself, lets get rid of the checks and run with
llvmpipe. With that, X was started correctly and so was g-s-d - I was
finally seeing the Adwaita stripes. At that's about it, because
gnome-shell was not there.
Starting it from terminal, I could only get segmentation faults. No
other output, and my various attempts of getting a core file went no
where - until I rebooted in Fedora today and found them in
$(ostreeroot). Weird. Also, systemd-coredumpd appears to be installed
and running, but I could not find the core files anywhere under /var.
Turns out that the segfault comes in cogl, which (my guess, the core
file is corrupt really) is not able of dealing with the possibility of
failing to build a GLX context. Because, as I found from
/var/log/Xorg.0.log inspection, the real error is
dlopen of /usr/lib/dri/swrast_dri.so failed (libLLVMMCJIT.so: cannot
open shared object file: No such file or directory)
and with post mortem inspection, indeed swrast_dri.so is depending on
a number of missing LLVM libraries. I filed bug 690747 for this.

Finally, I tried to run journalctl from Fedora to recover the journal,
but $(ostreeroot)/var/log/journal is empty, although I powered off
correctly and / was remounted rw.
In particular, there was a warning from logind about "Operation not
supported" trying to apply ACLs, but I don't remember for sure. I hope
that's just a kernel issue, which will be solved by taking a decent
config.

That's all for it. I'll try again in a week, or when you tell me it's
usable again.

Giovanni


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]