Re: [systemd-devel] systemd-run / Failed to create bus connection: Input/output error
On Fr, 30.04.21 14:33, lejeczek (pelj...@yahoo.co.uk) wrote: > Hi guys. > > I'm do on my pretty vanilla, so I'd like to think, setup this: > > -> $ systemd-run --machine=qemu-8-c8kubernode1 /bin/cat /etc/centos-release > Failed to create bus connection: Input/output error > > Someone would care to decipher that for me or/and shed bit more light on > possible troubleshooting? which host OS, which payload OS? which host systemd, which payload systemd? is this an nspawn container? is the container fully booted up? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] early mounts in systemd
On Fr, 30.04.21 15:14, Kenneth Porter (sh...@sewingwitch.com) wrote: > --On Friday, April 30, 2021 11:39 AM -0400 Rick Winscot > wrote: > > > Early in the project it was decided to make the rootfs read-only... in an > > effort to improve durability in environments where power fluctuations > > might cause problems on the eMMC. At the same time, making logging (e.g. > > /var) persistent for debugging was added to requirements. Persistent > > storage would be achieved by mounting /var to a separate partition that is > > read-write. > > Does /etc need to be read-only? On my last server I decided to make /usr > read-only but root is writable and /var is part of that. I put /home on its > own partition. I think making /usr read-only makes a ton of sense. The way I see it, besides the traditional Linux scheme where the whole fs is writable the following two scenarios make the most sense, and are what I personally intend to support in systemd very well: 1. root fs writable, /var/ part of it, but /usr/ separate and read-only/immutable. 2. rootfs read-only/immutable, /usr/ part of it, but /var/ separate and writable. The main difference I that in the second case the configuration is immutable too, while the firt case allows it to be changed locally. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] early mounts in systemd
On Fr, 30.04.21 18:23, Silvio Knizek (killermoe...@gmx.net) wrote: > Am Freitag, dem 30.04.2021 um 10:39 -0400 schrieb Rick Winscot: > > My question for anyone on the list, is the method outlined below a > > reasonable solution to mounting /var early in the start-up cycle? > > > > Or... is there a better way? Some trimming > > > > Hi Rick, > > by definition if you need to mount /var (or /usr for this argument), > you need an initrd [1] which actually set up everything as you > requires. Anything else has a tendency to break in unpleasant ways due > to race conditions and such. You don't need much, just enough to set up > everything required for the root and API file systems. >From systemd's side we actually explicitly support environments where /var is mounted after the initrd transition. From our side everything should just work, we should have all the necessary deps in place to make /var being mounted post-initrd but still during early boot just work. I'd consider a bug in systemd if something of systemd#s own components can't deal with /var/ being mounted after the transition. (I mean, there have been discussions on whether we shouldn't require /var to be mounted from initrd, but so far we didn't decide that this was necessary, given the political effort this would take to require) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] early mounts in systemd
I believe you can have a hard time if you dont do (the last step
atleast) with a var.mount file.
The mount files are special as systemd will pull those up implicitly
if they are needed.
Maybe you could rework your solution, so that one service mounts your
first or second choice in
a separate directory (/run/mymount) then you add a var.mount unit that
depends ("BindsTo") on said service
and bind-mounts /run/mymount to var.
That way you will hook into the existing systemd machinery.
I did something similar with an overlayfs once. Tested to work correctly,
even if you have further mounts like /var/tmp (systemd should
automatically add dependency to var.mount).
Norbert
# file rootfs-bindmount-var.service
[Unit]
Description=Bind-mount variable storage (/var)
Documentation=man:file-hierarchy(7)
ConditionPathIsSymbolicLink=!/var
# ConditionPathIsReadWrite=!/var
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=local-fs-pre.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/bin/mkdir /run/varoverlay
ExecStartPre=/bin/mount --make-private -n -t tmpfs tmpfs_root_ovl
/run/varoverlay
ExecStartPre=/bin/mkdir /run/varoverlay/lower /run/varoverlay/upper
/run/varoverlay/work
ExecStart=/bin/mount --make-private -n --bind /var /run/varoverlay/lower
ExecStop=/bin/umount -n /run/varoverlay/lower
ExecStopPost=/bin/umount -n /run/varoverlay
ExecStopPost=/bin/rmdir /run/varoverlay
# file var.mount
[Unit]
Description=variable storage (/var)
Documentation=man:file-hierarchy(7)
ConditionPathIsSymbolicLink=!/var
ConditionPathIsReadWrite=!/var
After=rootfs-bindmount-var.service
BindsTo=rootfs-bindmount-var.service
[Mount]
What=overlay_var
Where=/var
Type=overlay
Options=lowerdir=/run/varoverlay/lower,upperdir=/run/varoverlay/upper,workdir=/run/varoverlay/work,redirect_dir=on,index=on,xino=on
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
