Update causes mayhem--sys-apps/systemd-utils to blame?

[Naib]

This usually means something is messing with your clock time ... Files on your system have a specific date but then they are wrong (eg 1h) when bootest).

[asturm]

Fortunately I saw this before it caused me any grief.

Your problems as well as solutions are automatically invalid inside this forum.

[proteusx]

Fortunately I saw this before it caused me any grief.

Your problems as well as solutions are automatically invalid inside this forum.

Nice!

[codefossa]

Just a closing to the issue I brought up. I use chrony so my system clock was fine, and I ran the following which seems to have fixed the hardware clock. Not really sure what caused it to be a bit funky after the upgrade, but seems everything is good now.

Code: Select all

# hwclock --systohc

[mv]

Just a closing to the issue I brought up. I use chrony so my system clock was fine

If you use something like that, I would recommend to set clock_systohc=YES.

Not really sure what caused it to be a bit funky after the upgrade

You mentioned that your hardware clock is in local time; this is not recommended for a reason. Maybe this was your first boot after a DST change (or maybe this issue occurs since the latest DST change)?

[codefossa]

If you use something like that, I would recommend to set clock_systohc=YES.

Thanks for the advice. I checked that out and went ahead and set it.

You mentioned that your hardware clock is in local time; this is not recommended for a reason. Maybe this was your first boot after a DST change (or maybe this issue occurs since the latest DST change)?

The reason I went with local is because I have Windows dual booted and the config suggests using local in that case. I never actually use the Windows install, but like to keep it as an option in case I really need it for work. I'll show below what I see in the hwclock config.

Code: Select all

# Set CLOCK to "UTC" if your Hardware Clock is set to UTC (also known as
# Greenwich Mean Time).  If that clock is set to the local time, then
# set CLOCK to "local".  Note that if you dual boot with Windows, then
# you should set it to "local".
clock="local"

I'm also not even 100% sure if this had anything to do with it, or if it was set to local by Windows at one point. If it's still suggested to change to UTC, got any links so I could read up on it some?

[Gatsby]

It doesn't seem as simple as that...
I use eudev but this new package is blocking

Code: Select all

[blocks B      ] sys-apps/systemd-utils[udev] ("sys-apps/systemd-utils[udev]" is soft blocking sys-fs/eudev-3.2.11-r2)
[blocks B      ] sys-fs/eudev ("sys-fs/eudev" is soft blocking sys-apps/systemd-utils-250.4-r1)

The solution to this problem is to mask sys-fs/eudev-3.2.11-r2 and freeze eudev at version 3.2.11-r1.

[Hu]

Historically, Windows kept the hardware clock in local time for compatibility with earlier versions of Windows, which did it for compatibility with MS-DOS. From that, users who dual-booted with affected Windows installations needed to have Linux keep the clock in local time too. Recent versions of Windows finally introduced a registry knob that can be used to keep the system clock in UTC.

[Ionen]

It doesn't seem as simple as that...
I use eudev but this new package is blocking

Code: Select all

[blocks B      ] sys-apps/systemd-utils[udev] ("sys-apps/systemd-utils[udev]" is soft blocking sys-fs/eudev-3.2.11-r2)
[blocks B      ] sys-fs/eudev ("sys-fs/eudev" is soft blocking sys-apps/systemd-utils-250.4-r1)

The solution to this problem is to mask sys-fs/eudev-3.2.11-r2 and freeze eudev at version 3.2.11-r1.

No, for eudev users the solution is just to disable USE=udev on systemd-utils, or else it's the equivalent of installing <sys-fs/udev-250 with sys-fs/eudev

(Edit: this is mentioned in the upcoming news item, still under review)

[Gatsby]

It doesn't seem as simple as that...
I use eudev but this new package is blocking

Code: Select all

[blocks B      ] sys-apps/systemd-utils[udev] ("sys-apps/systemd-utils[udev]" is soft blocking sys-fs/eudev-3.2.11-r2)
[blocks B      ] sys-fs/eudev ("sys-fs/eudev" is soft blocking sys-apps/systemd-utils-250.4-r1)

The solution to this problem is to mask sys-fs/eudev-3.2.11-r2 and freeze eudev at version 3.2.11-r1.

No, solution is just to disable USE=udev on systemd-utils, or else it's the equivalent of installing <sys-fs/udev-250 with sys-fs/eudev

O.k. .. solution for people like me, using openrc-0.17, virtual/libudev-232-r3 and virtual/udev-217.

All the others must live with ever new systemd-crap.

[codefossa]

Historically, Windows kept the hardware clock in local time for compatibility with earlier versions of Windows, which did it for compatibility with MS-DOS. From that, users who dual-booted with affected Windows installations needed to have Linux keep the clock in local time too. Recent versions of Windows finally introduced a registry knob that can be used to keep the system clock in UTC.

Thank you for taking the time to help out. I've gone ahead and changed it to UTC and made the change in Windows registry. I'll link that below just in case anyone ends up here in the future.
https://wiki.gentoo.org/wiki/System_tim ... th_Windows

[Syl20]

No, for eudev users the solution is just to disable USE=udev on systemd-utils, or else it's the equivalent of installing <sys-fs/udev-250 with sys-fs/eudev

And for... mdev users ?

Code: Select all

# egrep -r "systemd|udev|tmpfiles" /etc/portage
/etc/portage/package.mask/opentmpfiles:sys-apps/systemd-tmpfiles
/etc/portage/package.mask/opentmpfiles:-sys-apps/opentmpfiles
/etc/portage/package.mask/udev:sys-fs/eudev
/etc/portage/package.mask/udev:sys-apps/systemd
/etc/portage/package.mask/udev:sys-fs/udev
/etc/portage/package.mask/udev:virtual/udev
/etc/portage/make.conf:     -systemd -systemd-units -tls-heartbeat -tmpfiles -udev -webstart"
/etc/portage/make.conf:INSTALL_MASK="${INSTALL_MASK} /lib/systemd /lib64/systemd /usr/lib/systemd /usr/lib64/systemd /etc/systemd"

# emerge -pvuDNt world
(snip)
[nomerge       ] virtual/man-0-r4::gentoo 
[nomerge       ]  sys-apps/man-db-2.10.2-r1::gentoo  USE="manpager nls seccomp zlib (-selinux) -static-libs" 
[ebuild     U  ]   virtual/tmpfiles-0-r3::gentoo [0-r1::gentoo] 0 KiB
[ebuild  N     ]    sys-apps/systemd-utils-250.6::gentoo  USE="acl kmod (split-usr) tmpfiles -boot (-selinux) -sysusers -test -udev" 10 950 KiB
(snip)
The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by virtual/tmpfiles-0-r3::gentoo
# required by www-servers/apache-2.4.53::gentoo
# required by @selected
# required by @world (argument)
>=sys-apps/systemd-utils-250.6 tmpfiles

Yes, I still "use" opentmpfiles. I don't use it to autocreate some awful user-owned directories, so opentmpfiles is sufficient and safe.
And no, I do not want systemd crap into my systems. At all.

[Hu]

No, for eudev users the solution is just to disable USE=udev on systemd-utils, or else it's the equivalent of installing <sys-fs/udev-250 with sys-fs/eudev

And for... mdev users ?

Yes, anyone who uses a *dev other than systemd-udevd should either:

• Switch to systemd-udevd by removing the other provider and installing sys-apps/systemd-utils[udev]
• Or: stay with the other provider and disable USE=udev on sys-apps/systemd-utils.

As an mdev user, you probably want the second choice.

Code: Select all

# egrep -r "systemd|udev|tmpfiles" /etc/portage
/etc/portage/package.mask/opentmpfiles:sys-apps/systemd-tmpfiles

You should replace this with either:

• Code: Select all

  sys-apps/systemd-utils tmpfiles

  This will forcibly lock out the USE=tmpfiles flag on sys-apps/systemd-utils.

• Code: Select all

  # Disable ALL systemd utilities:
  # - systemd-udevd
  # - systemd-tmpfiles
  # - systemd
  sys-apps/systemd-utils

Either of these choices may require additional changes elsewhere.

Code: Select all

/etc/portage/package.mask/udev:sys-apps/systemd
/etc/portage/package.mask/udev:sys-fs/udev

These are now obsolete and can be removed.

Code: Select all

# emerge -pvuDNt world
The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by virtual/tmpfiles-0-r3::gentoo
# required by www-servers/apache-2.4.53::gentoo
# required by @selected
# required by @world (argument)
>=sys-apps/systemd-utils-250.6 tmpfiles

According to that output, virtual/tmpfiles-0-r3 requires sys-apps/systemd-utils[tmpfiles]. You must enable that flag, or not install this version of virtual/tmpfiles-0-r3.

Yes, I still "use" opentmpfiles.

Then you must undertake the ever-increasing maintenance burden of retaining it while upstream moves away.

[Syl20]

As an mdev user, you probably want the second choice.

Indeed. That's why, a long time ago, I already disabled the "udev" USE flag (globally), and "tmpfiles" (globally too). But portage persists again and again, it really wants to install systemd-utils.

Code: Select all

# Disable ALL systemd utilities:
# - systemd-udevd
# - systemd-tmpfiles
# - systemd
sys-apps/systemd-utils

Done. But :

Code: Select all

# emerge -pvuDN world

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

!!! The following update has been skipped due to unsatisfied dependencies:

virtual/tmpfiles:0

  selected: (virtual/tmpfiles-0-r1:0/0::gentoo, installed)
  skipped: (virtual/tmpfiles-0-r3:0/0::gentoo, ebuild scheduled for merge) (see unsatisfied dependency below)

!!! All ebuilds that could satisfy "sys-apps/systemd-utils[tmpfiles]" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/systemd-utils-250.6::gentoo (masked by: package.mask)
- sys-apps/systemd-utils-250.5::gentoo (masked by: package.mask, ~amd64 keyword)
- sys-apps/systemd-utils-250.4-r3::gentoo (masked by: package.mask, ~amd64 keyword)

(dependency required by "virtual/tmpfiles-0-r3::gentoo" [ebuild])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

emerge --info

Code: Select all

/etc/portage/package.mask/udev:sys-apps/systemd
/etc/portage/package.mask/udev:sys-fs/udev

These are now obsolete and can be removed.

I'm not sure :

Code: Select all

# cat /etc/portage/package.mask/udev 
sys-fs/eudev
#sys-apps/systemd
#sys-fs/udev
virtual/udev

# emerge -pvuDN world

These are the packages that would be merged, in order:

Calculating dependencies... done!

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by sys-apps/systemd-250.6::gentoo
# required by sys-apps/gentoo-systemd-integration-9::gentoo
>=sys-apps/dbus-1.12.22-r1 systemd

 * In order to avoid wasting time, backtracking has terminated early
 * due to the above autounmask change(s). The --autounmask-backtrack=y
 * option can be used to force further backtracking, but there is no
 * guarantee that it will produce a solution.

!!! All ebuilds that could satisfy ">=virtual/udev-217" have been masked.
!!! One of the following masked packages is required to complete your request:
- virtual/udev-217-r5::gentoo (masked by: package.mask)
/etc/portage/package.mask/udev:
#sys-apps/systemd
#sys-fs/udev

- virtual/udev-217-r3::gentoo (masked by: package.mask)

(dependency required by "sys-fs/udev-init-scripts-34::gentoo" [ebuild])
(dependency required by "sys-apps/systemd-250.6::gentoo" [ebuild])
(dependency required by "sys-apps/dbus-1.12.22-r1::gentoo[systemd]" [ebuild])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

According to that output, virtual/tmpfiles-0-r3 requires sys-apps/systemd-utils[tmpfiles]. You must enable that flag, or not install this version of virtual/tmpfiles-0-r3.

Yes, again. Another package to freeze and another ebuild to move into my local repo, because 1/ too many packages depend on virtual/tmpfiles to simply remove it, and 2/ there are no alternatives. Gentoo is about choice...

Then you must undertake the ever-increasing maintenance burden of retaining it while upstream moves away.

I'm ready to assume that. But here, I also have to continuously fight against some parts of the Gentoo maintainers' work, because I don't like _their_ vision of _my_ systems. If it ain't broke, don't fix it.

So let's keep it simple, stupid :

Code: Select all

# echo "virtual/tmpfiles-9999" >> /etc/portage/profile/package.provided
# emerge -avC virtual/tmpfiles
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean <atom>` to check for reverse dependencies before
 * removing packages.

>>> These are the packages that would be unmerged:

 virtual/tmpfiles
    selected: 0-r1 
   protected: none 
     omitted: none 

All selected packages: =virtual/tmpfiles-0-r1

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Would you like to unmerge these packages? [Yes/No] 
>>> Waiting 5 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) virtual/tmpfiles-0-r1...
No package files given... Grabbing a set.
>>> Regenerating /etc/ld.so.cache...

 * GNU info directory index is up-to-date.

# emerge -avuDN world

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

Nothing to merge; quitting.

And basta.

[Hu]

Code: Select all

# Disable ALL systemd utilities:
# - systemd-udevd
# - systemd-tmpfiles
# - systemd
sys-apps/systemd-utils

I was mistaken here. I should not have listed systemd as a package that would be disabled by this mask. I should have written systemd-boot. Fortunately, as a comment, this mistake has little practical impact.

Done. But :

Code: Select all

# emerge -pvuDN world
!!! One of the following masked packages is required to complete your request:
- sys-apps/systemd-utils-250.6::gentoo (masked by: package.mask)

(dependency required by "virtual/tmpfiles-0-r3::gentoo" [ebuild])

Right. As I noted above, virtual/tmpfiles-0-r3 requires sys-apps/systemd-utils, so you will need to replace or avoid it.

I'm not sure :

Code: Select all

# cat /etc/portage/package.mask/udev 
#sys-apps/systemd

I was wrong. Keep sys-apps/systemd uncommented in the mask file.

Yes, again. Another package to freeze and another ebuild to move into my local repo, because 1/ too many packages depend on virtual/tmpfiles to simply remove it, and 2/ there are no alternatives. Gentoo is about choice...

Gentoo tries to provide choice where practical. The decisions of upstream projects to rely on a tmpfiles provider, and the lack of choices for alternative tmpfiles providers, limit what choices the Gentoo maintainers can offer you. As has been stated elsewhere, if there were a tmpfiles provider that was broadly compatible with the format used by various upstream projects, Gentoo could offer it. There is no such provider. As far as I know, there are three providers:

• opentmpfiles - abandoned upstream, so not supported in Gentoo
• systemd-tmpfiles (now systemd-utils[tmpfiles]) - a freestanding tmpfiles provider extracted from systemd
• systemd - for users who run the full systemd suite

Gentoo no longer offers the first, because it was abandoned. You don't like the second, and you strongly don't like the third. That leaves you with no good options. Find or create a fourth option, and you might well convince the Gentoo maintainers to add it as an alternative in virtual/tmpfiles.

I'm ready to assume that. But here, I also have to continuously fight against some parts of the Gentoo maintainers' work, because I don't like _their_ vision of _my_ systems. If it ain't broke, don't fix it.

Except it is broken, because upstream keeps breaking things. Gentoo is just passing through the problems caused by upstream. If upstream projects treated tmpfiles as optional instead of mandatory, then the dependency on virtual/tmpfiles could be optional. If systemd upstream didn't make it so painful to manage patching their extracted tmpfiles processor, this thread wouldn't exist.

[Syl20]

I should have written systemd-boot. Fortunately, as a comment, this mistake has little practical impact.

OK. Indeed, that doesn't change anything here.

Except it is broken, because upstream keeps breaking things.

I understand Gentoo's choice to not support opentmpfiles, as upstream didn't maintain it anymore. But... opentmpfiles works. Correct me if I'm wrong, but the "security breach" that makes Gentoo maintainers abandon opentmpfiles exists only if a (really) stupid sysadmin hijacks it to autocreate directories writable by a human user.
So, for the vast majority of the sysadmins, opentmpfiles is sufficient.

And so, instead of permitting the existing to... just... keep going (with a notice to the users that opentmpfiles is not maintained anymore), why Gentoo maintainers spend so much time and energy to force everybody to switch to the "dark side" ? Maintainers, please, give us a break.

If upstream projects treated tmpfiles as optional instead of mandatory, then the dependency on virtual/tmpfiles could be optional.

Obvious. And if everybody uses such a tool only for its main usage, this is not a problem.

If systemd upstream didn't make it so painful to manage patching their extracted tmpfiles processor, this thread wouldn't exist.

If systemd upstream didn't make systemd so huge, so complicated, so freaky, so... (add as many swearwords as you want) , and if Redhat didn't make it so unavoidable, this forum database would take up half of its size. Another reason to make this... thing as optional as possible, no ?

[Ionen]

I understand Gentoo's choice to not support opentmpfiles, as upstream didn't maintain it anymore. But... opentmpfiles works.

Even disregarding security, opentmpfiles only works partially. With no maintenance it doesn't support newer tmpfiles options properly and you get bugs like:

https://bugs.gentoo.org/741216

Over time will just be getting more of these if it can't keep up with the reference implementation.

[Hu]

I understand Gentoo's choice to not support opentmpfiles, as upstream didn't maintain it anymore. But... opentmpfiles works. Correct me if I'm wrong, but the "security breach" that makes Gentoo maintainers abandon opentmpfiles exists only if a (really) stupid sysadmin hijacks it to autocreate directories writable by a human user.
So, for the vast majority of the sysadmins, opentmpfiles is sufficient.

As discussed at length in a thread similar to this one, the problem is that the opentmpfiles specification permits upstream projects to write a configuration file that opentmpfiles will process in an unsafe way, and systemd-tmpfiles will process in a safe way. The people who allege this further allege that it is not trivial to validate which configuration files were written safely, so it is not feasible to expect the Gentoo maintainers to flag unsafe files. The only way to use opentmpfiles safely is to INSTALL_MASK out every configuration file that you have not reviewed for safety.

And so, instead of permitting the existing to... just... keep going (with a notice to the users that opentmpfiles is not maintained anymore), why Gentoo maintainers spend so much time and energy to force everybody to switch to the "dark side" ? Maintainers, please, give us a break.

This was also discussed in that other thread. The Gentoo project cannot in good conscience distribute a program that its own maintainer claims has an unfixable security problem. If opentmpfiles is not distributed in ::gentoo, then it is difficult to have virtual/tmpfiles permit it as a provider.

Another reason to make this... thing as optional as possible, no ?

Absolutely. I expect many people look forward to a volunteer stepping up to make tmpfiles support more optional than it is today. None of the existing Gentoo maintainers has publicly declared an intent to be such a volunteer.

[Syl20]

OK, so I really didn't understood all the problems around opentmpfiles. Sorry for the noise.

[figueroa]

Today's update brought in sys-apps/systemd-utils as shown below:

Code: Select all

[ebuild     U  ] virtual/libudev-232-r7 [232-r5]
[ebuild  N     ] sys-apps/systemd-utils-250.6  USE="acl kmod (split-usr) tmpfiles udev -boot (-selinux) -sysusers -test" ABI_X86="(64) -32 (-x32)" 
[uninstall     ] sys-fs/udev-249.6-r2 
[blocks b      ] <sys-fs/udev-250 ("<sys-fs/udev-250" is soft blocking sys-apps/systemd-utils-250.6)
[ebuild     U  ] virtual/udev-217-r5 [217-r3]
[ebuild     U  ] sys-apps/systemd-tmpfiles-250 [249.9]
[blocks b      ] <sys-apps/systemd-tmpfiles-250 ("<sys-apps/systemd-tmpfiles-250" is soft blocking sys-apps/systemd-utils-250.6)
[ebuild     U  ] virtual/tmpfiles-0-r3 [0-r1]

This didn't look quite right, but I let it rip anyway, assuming it would be OK.

As shown above, udev was unmerged, and systemd-tmpfiles was not unmerged. No files ended up in /var/log/portage/elog, although looking through the logs in /var/log/portage there was content that should have been brought to users' attention.

Changes were automatically made within /etc/init.d/ and udev and udev-trigger remains, but the systemd-tmpfiles-setup and systemd-tmpfiles-setup-dev were new and automatically added to boot and sysinit levels automatically.

Afterwards, depclean ultimately removed sys-apps/systemd-tmpfiles. It seems to me that should have been done automatically consistently with with the automatic unmerge of sys-fs/udev.

Should users' reboot? Or, should users' restart some services?

Added - note:

Code: Select all

# tail sys-apps:systemd-utils-250.6:20220531-175512.log
   /lib/udev/v4l_id
   /lib64/libudev.so.1.7.3
 * Adding 'systemd-tmpfiles-setup-dev' service to the 'sysinit' runlevel [ ok ]
 * Adding 'systemd-tmpfiles-setup' service to the 'boot' runlevel ...    [ ok ]
 * Updating hwdb ...                                                     [ ok ]
 * Running udev control --reload for reloading rules and databases ...   [ ok ]

[Ionen]

There's some metapackage version of systemd-tmpfiles/boot and udev that don't install any files and there only to help the transition that may or may not be used (mostly setup to ensure users don't unexpectedly lose anything).

When the metapackage isn't needed anymore, it can just be depcleaned. I know they can look a bit confusing though.

Also, there was a news item about systemd-utils:
https://www.gentoo.org/support/news-ite ... utils.html
...but if portage let you upgrade there's nothing to do. At worst portage may give you some blockers (e.g. due to missing abi_x86_32, or needing to adjust for eudev -- see bottom of news item), but in this case it was all good. It's really just the same thing merged in a single package.

[pjp]

What exactly would setting -udev for sys-apps/systemd-utils change? Is the purpose of that flag only for use when eudev is installed?

I have udev installed, but I prefer to not "expand" functionality where I didn't previously have it. My currently installed systemd-tmpfiles does not have a udev flag, so I'm wondering what the difference in functionality is between systemd-tmpfiles, systemd-utils[udev] and systemd-utils[-udev].

[Ionen]

systemd-utils[udev] is what formerly was sys-fs/udev
systemd-utils[tmpfiles] likewise is systemd-tmpfiles
systemd-utils[boot] likewise is systemd-boot

So setting [tmpfiles,-udev] is the equivalent of telling it "don't install sys-fs/udev, I'm using eudev, but I still need systemd-tmpfiles"

(aka systemd-utils combines them given they all come from the same tarball, and this makes the separate versions obsolete -- ultimately there's no real difference and it installs the same things depending on USE)

[pjp]

Thanks for clarifying. It seems like I either read that or should have known. I guess I was overthinking it.