Is it possible to compile only systemd-resolved from the large systemd sources (without all the rest of systemd) to attempt identify a fix to backport? Can a new systemd-resolved coexist with the rest of a system that is based on an oldish systemd?
Systemd-Resolved Compatibility – Using Different Versions
resolvesystemd
Related Solutions
answering to myself. The lxc-archlinux template is available at https://github.com/dotcloud/lxc/blob/master/templates/lxc-archlinux.in but it does not include the migration to systemd (as of Feb 15 2013) .
there are usable rootfs part of archlinux (e.g http://www.gtlib.gatech.edu/pub/archlinux/iso/2013.02.01/arch/i686/root-image.fs.sfs for i686 there also is a 64 bit version)
I did not run an lxc guest out of it yet but I got a functional i686 chroot from inside ubuntu 12.04 x64. 1/ download and unsquash the root image, mount it somewhere.
2/ as root (sudo) cp -ar the root filesystem to your location and chroot into it
3/ edit /etc/pacman.conf and update the arch line (by default it is auto, which pulls the ar ch from uname, but ubuntu and arch do not use the same designation)
4/ mount /proc /dev/random and /dev/urandom (this is needed by pacman and pacman-key)
I could not get pacman to run without package signature properly setup
5/ pacman-key --init (here it needs a good source of entropy)
6/ pacman-key --populate archlinux
7/ optional: pacman-key --refresh-keys (needs a working internet connection)
8/ edit /etc/pacman.d/mirrorlist to activate mirrors relevant to you.
9/ pacman -Syy
ready to update or install new packages.
What's (direly) missing is the container startup. I'm not up to speed on systemd but if I understand correctly this is mostly a matter of starting dbus and systemd.
When you say you check for a file system mount, it's clear you'll run it if found and mounted, but what's not clear is that if it's not found, what do you want it to do?
I ask because one possible answer is yes, in LSB, it is the run level that determines this. In Linux/Unix boot up, file systems are available at run level 1. So, set in your LSB header "Default-Start: 2 3 4 5". Then, put the filesystem mount entry in /etc/fstab and optionally set it to 'bootwait' to hang your system and prevent transitioning to run level two until it mounts, no matter how long it takes. This is actually how some systems are configured when the (remote) file system is super critical.
Otherwise, the answer is no, you cannot check the existence of a mounted partition ONLY within an LSB header entry itself. And, since you allow this particular system to boot without this particular file system, the file system is obviously not 'important' enough to hang the system awaiting mount availability.
A consideration is if you want it to not run at all when the file system is not mounted because you're trying to satisfy a "Required-Start:" dependency in another init script? Hopefully not as you can see you are sliding down a very slippery slope of init script dependencies.
Hopefully, you want it to not run because if it did, it messes stuff up like filling the root file system (as opposed to being an init dependency)? Then, you can let it run, but just code the init script to check and exit gracefully, as appropriate. The logic to check a file system mount and, if not found, exit, is probably one line of code. It can be inserted just after of the LSB header.
Best Answer
No, only building and upgrading one binary of systemd is not supportable. As in, people you might ask for help will have difficulty reproducing what you are doing.
resolved, like the dozes of binaries that compose this thing, links to some systemd shared code. This is not likely to remain binary compatible across an arbitrary number of releases. It might work, but personally I'm not willing to untangle systemd's internal dependencies to prove it.
Instead, try upgrading all of systemd. For a start, try reproducing the problem on a distro with a relatively new version. In Red Hat land, as of 2021 this could be Fedora 35 or RHEL 9. Once there is evidence the newer distro improves things, then start isolating relevant changes. Or start an OS upgrade project.