[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Running actual systemd‑based distribution image in systemd‑nspawn
Ulrich Windl
Ulrich.Windl at rz.uni-regensburg.de
Mon Jul 11 11:57:09 UTC 2022
>>> Lennart Poettering <lennart at poettering.net> schrieb am 30.06.2022 um 22:23
in
Nachricht <Yr4GSeliNVpW/wUY at gardel-login>:
> On Do, 16.06.22 09:27, Colin Guthrie (gmane at colin.guthr.ie) wrote:
>
>> Andrei Borzenkov wrote on 15/06/2022 16:56:
>> > I tried it (loop mounting qemu image):
>> >
>> > systemd‑nspawn ‑D ./hd0 ‑b
>> >
>> > and it failed miserably with "Timeout waiting for device
>> > dev‑disk‑by...". Which is not surprising as there are no device units
>> > inside of container (it stops in single user allowing me to use sysctl
>> > ‑t device).
>> >
>> > Is it supposed to work at all? Even if I bind mount /dev/disk it does
>> > not help as systemd does not care whether device is actually present or
> not.
>>
>> I've not tried "booting" a real install inside nspawn before (just images
>> installed by mkosi mostly), but could this just be a by‑product of it
trying
>> to do what /etc/fstab (or other mount units) say to do?
>>
>> Can you try something like:
>>
>> touch blank
>> systemd‑nspawn ‑‑bind‑ro=./blank:/etc/fstab ‑D ./hd0 ‑b
>
> This should not be necessary, as systemd‑fstab‑generator actually
> ignores all /etc/fstab entries referencing block devices. See this:
>
>
https://github.com/systemd/systemd/blob/main/src/fstab‑generator/fstab‑generat
> or.c#L602
>
> (i.e. container managers such as nspawn should mount /sys/ read‑only,
> which is indication to container payloads that device management
> should not be done by them but is done somewhere else. This is used as
> check whether to ignore the fstab entries that look like device patjs,
> i.e. start with /dev).
>
> How precisely does the offending fstab line look like for you?
> Normally it should be ignored just like that. If it is not ignored,
> this looks like a bug.
>
>> to override the /etc/fstab (there may be other more elegant ways to
disable
>> fstab processing!) and see if that helps?
>
> No need. Should happen automatically.
>
> That said: I strongly recommend that distros ship empty /etc/fstab by
> default, and rely on GPT partition auto discovery
> (i.e. systemd‑gpt‑auto‑generator) to mount everything, and only depart
> from that if there's a strong reason to, i.e. default mount options
> don't work, or external block device referenced or so.
What if you have multiple operating systems in various partitions on one
disk?
/etc/fstab absolutely makes sense
Regards,
Ulrich
More information about the systemd-devel
mailing list