|
Bugzilla – Full Text Bug Listing |
| Summary: | [Build 20230623] zdup failure: order of package installation can result to failures | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Dominique Leuenberger <dimstar> |
| Component: | Basesystem | Assignee: | systemd maintainers <systemd-maintainers> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | fbui, fvogt, guillaume.gardet, kukuk, lnussel, mkoutny |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://openqa.opensuse.org/tests/3378887/modules/zdup/steps/23 | ||
| Whiteboard: | |||
| Found By: | openQA | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | zypper.log.xz showing the dep cycles | ||
https://openqa.opensuse.org/tests/3381401#step/zdup/604 shows the error better in the openQA context It looks almost like zypp did not honor our request in sysuser-shadow: Requires(pre): (systemd >= 238 if systemd) At the point where system-group-kvm is being installed, we have sysuser-shadow 3.1 installed (done just before system-group-kvm) - but systemd apparently has not been updated to systemd >= 238 as requested (In reply to Dominique Leuenberger from comment #2) > It looks almost like zypp did not honor our request in sysuser-shadow: > Requires(pre): (systemd >= 238 if systemd) Do we have now a dependency loop? I normally only see this if there is a dependency loop and zypper has to break that up somehow. If there is a loop it doesn't seem to be a trivial one, as I cannot see one. (In reply to Thorsten Kukuk from comment #3) > If there is a loop it doesn't seem to be a trivial one, as I cannot see one. Me neither. Can we have the zypper logs ? They don't seem to be provided by default. Finally I found them: > CRITICAL cycle: --> systemd-253.5-3.1.x86_64 ##45##> util-linux-2.39-1.1.x86_64 --44--> libutempter0-1.2.1-1.2.x86_64 --88--> system-group-hardware-20170617-24.13.noarch --88--> sysuser-shadow-3.1-5.3.noarch --80--> > CRITICAL cycle: --> systemd-253.5-3.1.x86_64 --44--> dbus-1-1.14.8-1.2.x86_64 --60--> dbus-1-daemon-1.14.8-1.2.x86_64 ##41##> libdbus-1-3-1.14.8-1.2.x86_64 --40--> dbus-1-common-1.14.8-1.2.noarch --80--> sysuser-shadow-3.1-5.3.noarch --80--> > CRITICAL cycle: --> systemd-253.5-3.1.x86_64 --44--> dbus-1-1.14.8-1.2.x86_64 --40--> dbus-1-tools-1.14.8-1.2.x86_64 ##41##> libdbus-1-3-1.14.8-1.2.x86_64 --40--> dbus-1-common-1.14.8-1.2.noarch --80--> sysuser-shadow-3.1-5.3.noarch --80--> > CRITICAL cycle: --> systemd-253.5-3.1.x86_64 --44--> dbus-1-1.14.8-1.2.x86_64 ##41##> dbus-1-common-1.14.8-1.2.noarch --80--> sysuser-shadow-3.1-5.3.noarch --80--> > CRITICAL cycle: --> systemd-253.5-3.1.x86_64 --44--> dbus-1-1.14.8-1.2.x86_64 --c4--> libdbus-1-3-1.14.8-1.2.x86_64 ##41##> dbus-1-common-1.14.8-1.2.noarch --80--> sysuser-shadow-3.1-5.3.noarch --80--> > CRITICAL cycle: --> systemd-253.5-3.1.x86_64 --84--> system-group-hardware-20170617-24.13.noarch --88--> sysuser-shadow-3.1-5.3.noarch ##81##> Unlike the other cycles, the last one has probably been introduced by a recent change [1] in the systemd packaging: systemd had "Requires(pre): group(lock)" and we recently added [1] "Requires: group(lock)" to make sure that the group "lock" won't be uninstalled after the transaction is finished. This has the side effect to make systemd requires "system-group-hardware" and create the dep cycle which might have been resolved by zypper by dropping systemd from the upgrade transaction. But I'm not sure about this assumption as I couldn't find any info about the resolutions of the cycles in the logs. Thorsten, any idea on how to solve that ? Does system-group-hardware really have to require sysuser-shadow since it contains only group definitions ? [1] https://build.opensuse.org/package/rdiff/Base:System/systemd?linkrev=base&rev=1399 Created attachment 867839 [details]
zypper.log.xz showing the dep cycles
(In reply to Franck Bui from comment #5) > > CRITICAL cycle: --> systemd-253.5-3.1.x86_64 --84--> system-group-hardware-20170617-24.13.noarch --88--> sysuser-shadow-3.1-5.3.noarch ##81##> > Thorsten, any idea on how to solve that ? Not yet > Does system-group-hardware really have to require sysuser-shadow since it > contains only group definitions ? sysuser-shadow creates the users and _groups_ from sysusers.d if systemd is not yet installed (boot strapping of a new installation) or if it is used in a container. And since systemd pre-requires the lock group, it needs to be created before systemd can be installed, thus yes, this requires is necessary. I see two options: 1. find somehow out if systemd-sysusers is new enough at runtime. No idea how we could do that. 2. drop the dependency on "group(lock)". The lock group is only used by the tmpfile creating /run/lock and only for lockdev. RedHat solved this in a different way: /run/lock is owned by root:root and 755 lockdev is using /run/lock/lockdev, which is owned by root:lock Problem solved, and servers are more secure. (In reply to Thorsten Kukuk from comment #7) > I see two options: > 1. find somehow out if systemd-sysusers is new enough at runtime. No idea > how we could do that. > 2. drop the dependency on "group(lock)". > Maybe: 3. introduce a "standlone" version of systemd-sysusers so the tool can be installed independently of systemd. Most of other distros already do that. That might allow to simplify sysuser-shadow substantially. > The lock group is only used by the tmpfile creating /run/lock and only for > lockdev. > RedHat solved this in a different way: > /run/lock is owned by root:root and 755 > lockdev is using /run/lock/lockdev, which is owned by root:lock > > Problem solved, and servers are more secure. Ok good if /run/lock can use the perm "root:root", I'm all for it. (In reply to Franck Bui from comment #8) > Ok good if /run/lock can use the perm "root:root", I'm all for it. BTW couldn't the initialization of /run/lock be handled by filesystem or any other "base" package ? systemd currently ships a tmpfiles rule for the init of this directory but it might make more sense to move it elsewhere. (In reply to Franck Bui from comment #9) > BTW couldn't the initialization of /run/lock be handled by filesystem or any > other "base" package ? Maybe after the dependency to "lock" got dropped we could evaluate that. But first we need to drop the dependency on "lock", else we have to many core packages we need to modify in sync at the same time. the whole point of lockdev is to implement legacy lock files according to https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varlockLockFiles in /var/lock using a different directory defeats the purpose of lockdev. We could however remove the setgid bit from lockdev, change /run/lock to root:root and therefore turn lockdev into a noop. We just need to make sure it fails gracefully. It's legacy stuff anyway and should be dropped. lockdev comes from Debian and was dropped there, not in Ubuntu either anymore I suppose. We should really drop it instead of patching around. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728023 (In reply to Ludwig Nussel from comment #13) > lockdev comes from Debian and was dropped there, not in Ubuntu either > anymore I suppose. We should really drop it instead of patching around. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728023 Agreed. However it seems that the version of lockdev shipped by Factory is outdated compare to the one that Base:System has. Any reason why Base:System/lockdev has never been submitted to Factory since a couple years ago ? I'm asking because Base:System/lockdev actually ships %{_tmpfilesdir}/lockdev.conf which takes care of creating /run/lock. This seems to be the straightforward way to fix the problem as long as lockdev is around. (In reply to Franck Bui from comment #14) > I'm asking because Base:System/lockdev actually ships > %{_tmpfilesdir}/lockdev.conf which takes care of creating /run/lock. This > seems to be the straightforward way to fix the problem as long as lockdev is > around. No, it does not. Please look at the consumers of /run/lock, lockdev is the most unimportant one of all, and none of the other consumers should require lockdev only to get /run/lock. That's contra productive. (In reply to Thorsten Kukuk from comment #15) > No, it does not. Please look at the consumers of /run/lock, lockdev is the > most unimportant one of all, and none of the other consumers should require > lockdev only to get /run/lock. That's contra productive. Oops yeah I focused too much on lockdev. So at that point should we convert lockdev to /run/lock/lockdev or should we drop it completely ? Meanwhile I'll revert the part in systemd that introduced the dep cycle. (In reply to Franck Bui from comment #16) > (In reply to Thorsten Kukuk from comment #15) > > No, it does not. Please look at the consumers of /run/lock, lockdev is the > > most unimportant one of all, and none of the other consumers should require > > lockdev only to get /run/lock. That's contra productive. > > Oops yeah I focused too much on lockdev. > > So at that point should we convert lockdev to /run/lock/lockdev or should we > drop it completely ? > > Meanwhile I'll revert the part in systemd that introduced the dep cycle. Remove the "group(lock)" dependency from systemd completley and make /run/lock owned by root:root mode 755 like e.g. RedHat has. And ignore lockdev for now. I think we should either drop lockdev or we should become compatible with RedHat, but doing our own way here doesn't make any sense. As somebody wrote on LWN.net some weeks ago: we should not limit ourself (Linux) for no good reason just because there was an OS 40 years ago with this limitation, which nobody remembers anymore today. (In reply to Thorsten Kukuk from comment #17) > Remove the "group(lock)" dependency from systemd completley and make > /run/lock owned by root:root mode 755 like e.g. RedHat has. And ignore > lockdev for now. https://build.opensuse.org/package/rdiff/Base:System/systemd?linkrev=base&rev=1405 Drop lockdev bug https://bugzilla.suse.com/show_bug.cgi?id=1212801 This is an autogenerated message for OBS integration: This bug (1212674) was mentioned in https://build.opensuse.org/request/show/1095850 Factory / systemd Fix released with snapshot 20230629, closing. Thanks all for your inputs. |
## Observation The zdup call ends with .[ 256.877383] [RPM][3581]: scriptlet %prein(system-group-kvm-20170617-24.13.noarch) failure: 2 [ 256.878250] [RPM][3581]: install system-group-kvm-20170617-24.13.noarch: failure [ 256.878958] [RPM][3581]: 1 elements failed, 1 scripts failed [ 256.880005] [RPM][3581]: Transaction ID 6496bd42 finished: -1 The actual problem is that of: sysusers-shadow is being updated, then adding --replace=… to the command line parameters of systemd-sysusers. systemd though is not yet updated on the target system (is later in the transaction) - this in turn makes the update fail, as the --replace command is not yet understood on the outdated systemd version The issue appeared with the requires(pre): group(kvm) being added on udev, which triggers a group update way earlier than before, pulling this in front of the systemd update. sysusers2shadow has this code: if [ -x /usr/bin/systemd-sysusers ] && [ -e /proc/version ]; then if [ -n "$1" ] && [ "$1" != "%3" ]; then REPLACE_ARG="--replace=/usr/lib/sysusers.d/$1" ||: fi # Use systemd-sysusers and let it read the input directly from stdin run /usr/bin/systemd-sysusers $REPLACE_ARG - i.e. it unconditionally adds the --replace=… parameter whenever the command exists - always expecting a recent enough version openQA test in scenario opensuse-Tumbleweed-NET-x86_64-zdup-Leap-15.2-gnome@64bit fails in [zdup](https://openqa.opensuse.org/tests/3378887/modules/zdup/steps/23) ## Test suite description ## Reproducible Fails since (at least) Build [20230623](https://openqa.opensuse.org/tests/3377659) ## Expected result Last good: [20230622](https://openqa.opensuse.org/tests/3375507) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=NET&machine=64bit&test=zdup-Leap-15.2-gnome&version=Tumbleweed)