Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Mantas Mikulėnas]

On Sat, Nov 5, 2022 at 12:52 PM TJ  wrote:

> On 05/11/2022 10:36, Mantas Mikulėnas wrote:
> > On Sat, Nov 5, 2022 at 12:06 PM TJ  wrote:
> >
> >> Just seen this announcement in the v252 changelog:
> >>
> >> "We intend to remove support for split-usr (/usr mounted separately
> >> during boot) ..."
> >>
> >> How does this align with support for separate /usr/ with dm-verity ?
> >>
> >> For example, this will affect nspawn. See "man 1 systemd-nspawn" and
> >> "--root-hash=" where in respect of /usr/ it says:
> >>
> >> "Note that this configures the root hash for the root file system. Disk
> >> images may also contain separate file systems for the /usr/ hierarchy,
> >> which may be Verity protected as well. The root hash for this protection
> >> may be configured via the "user.verity.usrhash" extended file attribute
> >> or via a .usrhash file adjacent to the disk image, following the same
> >> format and logic as for the root hash for the root file system described
> >> here."
> >>
> >
> > /usr can remain on a separate partition as long as it's mounted *by the
> > initrd* (the same way initrd currently mounts your rootfs), so that by
> the
> > time systemd starts it already has the full filesystem.
>
> How does this work when systemd is used inside the initrd, as
> "recommended" / discussed at, for example "Using systemd inside an initrd"
> :
>

>From the initrd's perspective, it's not being mounted *at* /usr – it's
being mounted at /newroot/usr or such (like how the rootfs itself is
mounted at /newroot). The initrd has its own / and its own /usr.

-- 
Mantas Mikulėnas

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[TJ]

On 05/11/2022 11:32, Luca Boccassi wrote:


Does it also affect the command-line options "mount.usr=,
mount.usrfstype=, mount.usrflags=, usrhash=, systemd.verity_usr_data=,
systemd.verity_usr_hash=, systemd.verity_usr_options=" as per "man 7
kernel-command-line" ?



No, that is unrelated. This is about the ancient notion (that no initrd
tools support anymore) that you can boot userspace with /bin /lib /sbin and
no /usr, with the latter being set up late at boot. This is what is no
longer going to be supported.


Thank-you Luca; that makes more sense! I don't think everyone is as 
clear on the implications on what this affects just from the terse 
"split-usr /usr" since your description seems at odds with what Mantas 
wrote in an earlier reply with:


"What's finally being removed is support for having the rootfs itself 
mount /usr halfway through ..."


I'd have interpreted that as meaning using an fstab entry for /usr

I do a /lot/ of work with systemd-nspawn (subvol) containers with 
separate mounts for various parts of the OS file-system so wanted to be 
really clear on what is affected.




OpenPGP_0xEFEC37A429CD6080.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Mantas Mikulėnas]

On Sat, Nov 5, 2022 at 12:06 PM TJ  wrote:

> Just seen this announcement in the v252 changelog:
>
> "We intend to remove support for split-usr (/usr mounted separately
> during boot) ..."
>
> How does this align with support for separate /usr/ with dm-verity ?
>
> For example, this will affect nspawn. See "man 1 systemd-nspawn" and
> "--root-hash=" where in respect of /usr/ it says:
>
> "Note that this configures the root hash for the root file system. Disk
> images may also contain separate file systems for the /usr/ hierarchy,
> which may be Verity protected as well. The root hash for this protection
> may be configured via the "user.verity.usrhash" extended file attribute
> or via a .usrhash file adjacent to the disk image, following the same
> format and logic as for the root hash for the root file system described
> here."
>

/usr can remain on a separate partition as long as it's mounted *by the
initrd* (the same way initrd currently mounts your rootfs), so that by the
time systemd starts it already has the full filesystem.

What's finally being removed is support for having the rootfs itself mount
/usr halfway through, which requires many things that normally are on
/usr/lib to be split between it and /lib instead (such as on Debian).

Using the initrd to mount /usr isn't new.


-- 
Mantas Mikulėnas

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Luca Boccassi]

On Sat, 5 Nov 2022, 10:53 TJ,  wrote:

> On 05/11/2022 10:36, Mantas Mikulėnas wrote:
> > On Sat, Nov 5, 2022 at 12:06 PM TJ  wrote:
> >
> >> Just seen this announcement in the v252 changelog:
> >>
> >> "We intend to remove support for split-usr (/usr mounted separately
> >> during boot) ..."
> >>
> >> How does this align with support for separate /usr/ with dm-verity ?
> >>
> >> For example, this will affect nspawn. See "man 1 systemd-nspawn" and
> >> "--root-hash=" where in respect of /usr/ it says:
> >>
> >> "Note that this configures the root hash for the root file system. Disk
> >> images may also contain separate file systems for the /usr/ hierarchy,
> >> which may be Verity protected as well. The root hash for this protection
> >> may be configured via the "user.verity.usrhash" extended file attribute
> >> or via a .usrhash file adjacent to the disk image, following the same
> >> format and logic as for the root hash for the root file system described
> >> here."
> >>
> >
> > /usr can remain on a separate partition as long as it's mounted *by the
> > initrd* (the same way initrd currently mounts your rootfs), so that by
> the
> > time systemd starts it already has the full filesystem.
>
> How does this work when systemd is used inside the initrd, as
> "recommended" / discussed at, for example "Using systemd inside an initrd"
> :
>
> https://systemd.io/INITRD_INTERFACE/
>
> > What's finally being removed is support for having the rootfs itself
> mount
> > /usr halfway through, which requires many things that normally are on
> > /usr/lib to be split between it and /lib instead (such as on Debian).
> >
> > Using the initrd to mount /usr isn't new.
> > <
> https://web.archive.org/web/20150906203654if_/https://www.gentoo.org/support/news-items/2013-09-27-initramfs-required.html
> >
> >
>
> Does it also affect the command-line options "mount.usr=,
> mount.usrfstype=, mount.usrflags=, usrhash=, systemd.verity_usr_data=,
> systemd.verity_usr_hash=, systemd.verity_usr_options=" as per "man 7
> kernel-command-line" ?
>

No, that is unrelated. This is about the ancient notion (that no initrd
tools support anymore) that you can boot userspace with /bin /lib /sbin and
no /usr, with the latter being set up late at boot. This is what is no
longer going to be supported.

>

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[TJ]

Just seen this announcement in the v252 changelog:

"We intend to remove support for split-usr (/usr mounted separately 
during boot) ..."


How does this align with support for separate /usr/ with dm-verity ?

For example, this will affect nspawn. See "man 1 systemd-nspawn" and 
"--root-hash=" where in respect of /usr/ it says:


"Note that this configures the root hash for the root file system. Disk 
images may also contain separate file systems for the /usr/ hierarchy, 
which may be Verity protected as well. The root hash for this protection 
may be configured via the "user.verity.usrhash" extended file attribute 
or via a .usrhash file adjacent to the disk image, following the same 
format and logic as for the root hash for the root file system described 
here."

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[TJ]

On 05/11/2022 10:36, Mantas Mikulėnas wrote:

On Sat, Nov 5, 2022 at 12:06 PM TJ  wrote:


Just seen this announcement in the v252 changelog:

"We intend to remove support for split-usr (/usr mounted separately
during boot) ..."

How does this align with support for separate /usr/ with dm-verity ?

For example, this will affect nspawn. See "man 1 systemd-nspawn" and
"--root-hash=" where in respect of /usr/ it says:

"Note that this configures the root hash for the root file system. Disk
images may also contain separate file systems for the /usr/ hierarchy,
which may be Verity protected as well. The root hash for this protection
may be configured via the "user.verity.usrhash" extended file attribute
or via a .usrhash file adjacent to the disk image, following the same
format and logic as for the root hash for the root file system described
here."



/usr can remain on a separate partition as long as it's mounted *by the
initrd* (the same way initrd currently mounts your rootfs), so that by the
time systemd starts it already has the full filesystem.


How does this work when systemd is used inside the initrd, as 
"recommended" / discussed at, for example "Using systemd inside an initrd" :


https://systemd.io/INITRD_INTERFACE/


What's finally being removed is support for having the rootfs itself mount
/usr halfway through, which requires many things that normally are on
/usr/lib to be split between it and /lib instead (such as on Debian).

Using the initrd to mount /usr isn't new.




Does it also affect the command-line options "mount.usr=, 
mount.usrfstype=, mount.usrflags=, usrhash=, systemd.verity_usr_data=, 
systemd.verity_usr_hash=, systemd.verity_usr_options=" as per "man 7 
kernel-command-line" ?




OpenPGP_0xEFEC37A429CD6080.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature