Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Running actual systemd‑based distribution image in systemd‑nspawn
On Mo, 11.07.22 13:57, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > 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 See boot loader spec about that. Basically, the assumption that for things like swap, /var/tmp or /home it's OK or even a good thing if shared between OSes. The major execption is /var/ itself, which is per OS installation and should not be shared between multiple installations. The boot loader spec hence by default will only auto-mount /var/ partitions only if the GPT partition uuid of that is hashed from the machine id. But there are two distinct concepts here: 1. tag your partitions properly by type uuid. This is always a good idea, and makes nspawn just work. and all other tools that recognize partition type uuids, i.e. all the --image= switches systemd tools have, and so on. 2. actually ship an empty /etc/fstab and rely solely on gpt auto discovery. i'd always do that whereever possible (i.e. any OS where multibot does't matter, i.e. appliances, images for VMs/nspawn, cloud stuff, servers). i.e. concept 1 should always be done. If you then also adopt concept 2 is up to you. You can, but you don't have to. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Running actual systemd‑based distribution image in systemd‑nspawn
>>> Lennart Poettering schrieb am 30.06.2022 um 22:23 in Nachricht : > On Do, 16.06.22 09:27, Colin Guthrie (gm...@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
