Antw: [EXT] Re: [systemd‑devel] Running actual systemd‑based distribution image in systemd‑nspawn

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

 



>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 30.06.2022 um 22:23
in
Nachricht <Yr4GSeliNVpW/wUY@gardel-login>:
> On Do, 16.06.22 09:27, Colin Guthrie (gmane@xxxxxxxxxxxxxx) 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






[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux