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
Re: [systemd-devel] Running actual systemd-based distribution image in systemd-nspawn
On Sa, 18.06.22 07:45, Andrei Borzenkov (arvidj...@gmail.com) wrote: > On 16.06.2022 11:27, Colin Guthrie 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 > > > > Yes, --bind=/dev/null:/etc/fstab > > allows boot to complete. Of course next it refuses root login because > pts/0 is not secure :) pam_securetty is archaic cruft, and a broken idea. Please work with your distribution to remove it. It might have made some vague sense on 1980's fixed line terminal environments, but is security theatre and a nothing more than a nuisance in today's world. Modern distributions do not enable it anymore. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Running actual systemd-based distribution image in systemd-nspawn
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-generator.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. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Running actual systemd-based distribution image in systemd-nspawn
On Mi, 15.06.22 18:56, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 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. Yes, this should just work. I use it daily for work. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Running actual systemd-based distribution image in systemd-nspawn
On 16.06.2022 11:27, Colin Guthrie 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 > Yes, --bind=/dev/null:/etc/fstab allows boot to complete. Of course next it refuses root login because pts/0 is not secure :) Thanks.
Re: [systemd-devel] Running actual systemd-based distribution image in systemd-nspawn
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 to override the /etc/fstab (there may be other more elegant ways to disable fstab processing!) and see if that helps? If you have specific .mount units you may have to add specific workarounds to block them too. HTHs Col
[systemd-devel] Running actual systemd-based distribution image in systemd-nspawn
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.
