> > > I think I came across this issue the other day (also booting on an arm > > board, stuck at kernel 3.1), I think that it may be the change to the > > xattr support in 214 means systemd can no longer be booted if you > > don't have cgroups xattr support. 213 seems fine, but I haven't tried > > to bisect it or revert the xattr changes. > > We don't rely on xattr support in the kernel at all, and not in cgroupfs. > xattr > support is fully optional. (that said, we sometimes break these builds > accidentally, since its not what we test things on) >
Just done a bit more digging into this and it probably isn't the same issue the original poster had, but is probably worth reporting if this is supposed to be a supported kernel version. Setup is an arm i.MX6 device (Compulab Utilite) running 3.0.35, booting into a Gentoo rootfs over nfs, not using an initrd. With 213 compiled with --disable-xattr it boots fine, using 214 or 213 with --enable-xattr it hangs after "Freeing init memory", with no output at all from systemd (booted with systemd.log_level=debug). I've just compiled up 214, but removed the MNT_FATAL flag from line 97 in mount-setup.c and that boots and appears to be fully functional. If I understand the code correctly it should now be trying to mount cgroup with xattr first (not fatal if it fails) then retrying without xattr (but fatal on failure this time). I don't know if this will have any other side effects or is the correct fix. Tom > Lennart > > -- > Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel