Bugzilla – Bug 1217979
package xfsprogs: error while installing libhandle1
Last modified: 2024-05-31 20:30:03 UTC
During a tumbleweed installation I saw this error message in /var/log/zypp/history: # 2023-12-11 14:37:08 libhandle1-6.5.0-1.1.x86_64.rpm installed ok # Additional rpm output: # /var/tmp/rpm-tmp.ywCvQW: line 2: mkdir: command not found # /var/tmp/rpm-tmp.ywCvQW: line 3: touch: command not found # 2023-12-11 14:37:08|install|libhandle1|6.5.0-1.1|x86_64||openSUSE-20231210-0|b9253b5573636c9723bccb7083cdcf371f1d3b9adc1de9045fe144fd2b25d7a6a89df186bf4adf81590 When libhandle1 is installed it runs the post scriptlet %{regenerate_initrd_post} which runs the command mkdir and touch which fail if coreutils is not installed The fix is to add: %package -n %{libname} Summary: XFS Filesystem-specific Shared library Group: Development/Libraries/C and C++ +Requires(post): coreutils in the spec file. I did try to submit a fix branching filesystems:xfsprogs but the branched package was empty.
(In reply to Giacomo Comes from comment #0) > which runs the command mkdir and touch which fail if coreutils is not > installed Under what circumstances would coreutils not be installed? There are probably a ton of things relying on the coreutils binaries, I would assume that the system would not even be bootable without it.
the error is due to the fact that when libhandle1 is installed and the post scriptles is executed, coreutils has not been installed yet. Adding Requires(post): coreutils assures that coreutils is installed before libhandle1 is
(In reply to Giacomo Comes from comment #2) > the error is due to the fact that when libhandle1 is installed and the post > scriptles is executed, coreutils has not been installed yet. > Adding Requires(post): coreutils assures that coreutils is installed before > libhandle1 is ah ok, now I noticed that you mention this is happening during installation. I am not sure how the installer environment is set up, but I would expect that coreutils to be part of the base installation. Otherwise this would create a problem to many other packages too that need to regenerate the initrd. The btrfsprogs pkg seems to be using your proposed solution, and e2fsprogs similarly requires /usr/bin/{mkdir,touch}. Still I'm not sure this is the right solution, or merely a workaround. The issue is that there are much more dependencies for regenerating the initrd (e.g. shell, dracut, and everything that dracut calls), otherwise we may be just silencing this particular error, but not fixing the real problem. I'd rather not add all the transitive dependencies in every affected package, if possible.
We seem to be doing the same across all packages that require regen of initrd, and the same issue was fixed for xfsprogs before libhandle split in bsc#1055492, which already briefly discusses the reason. So in that case I'd say go ahead and submit the proposed fix. > I did try to submit a fix branching filesystems:xfsprogs but > the branched package was empty. Not sure why this is the case, I can branch/checkout just fine, but in any case the development of the xfsprogs package in particular has moved to https://src.opensuse.org/pool/xfsprogs. You can fork that and do a merge request with the usual git workflow (no need to involve obs at all).
The macros are using mkdir and touch. This can be replaced by not using a subdirectory and ">" instead of touch and no dependency on coretuils would be necessary. On the other side: coreutils triggers the rebuild of the initrd, too. So the only change which is necessary is, to not run the macro if coreutils is not yet installed (check if /usr/bin/mkdir exists). Because we know, initrd will be regenerated later when coreutils get installed. All the Requires are not really necessary.
>This can be replaced by not using a subdirectory. I'm not sure about that. It looks like the procedure to trigger the regeneration of initrd is to create the file: /run/regenerate-initrd/all If we skip the creation of the subdirectory "generate-initrd" and do: : >/run/all are you sure the initrd will get regenerated? Also what you suggest is to replace the system macro %regenerate_initrd_post with an alternative implementation that may do the same thing now. But if in the future such macro get changed because the way to trigger the regeneration of initrd changes, who is going to remember that and change the reimplementation for libhandle1?
Adding Martin, as he maintains suse-module-tools.
One week has passed and nobody else has commented on this issue. I would suggest to go ahead and accept the pull request I submitted. That will allow to close this bug. A better solution, once available, can be used later.
(In reply to Thorsten Kukuk from comment #5) > The macros are using mkdir and touch. > This can be replaced by not using a subdirectory and ">" instead of touch > and no dependency on coretuils would be necessary. Using ">" is fine, be we can't simply write to /run. As Giacomo already pointed out in comment 6, these markers are stored in /run/regenerate-initrd, and I don't think polluting /run with this content makes sense. > On the other side: coreutils triggers the rebuild of the initrd, too. > So the only change which is necessary is, to not run the macro if coreutils > is not yet installed (check if /usr/bin/mkdir exists). Because we know, > initrd will be regenerated later when coreutils get installed. > > All the Requires are not really necessary. macros.initrd is maintained in the rpm-config-SUSE package. I propose to redefine the macro as follows: %regenerate_initrd_post \ ! command -v mkdir >/dev/null || mkdir -p /run/regenerate-initrd/; \ [ ! -d /run/regenerate-initrd ] || > /run/regenerate-initrd/all; \ %nil This would work if either /run/regenerate-initrd pre-exists, or "mkdir" is available.
(In reply to Thorsten Kukuk from comment #5) > On the other side: coreutils triggers the rebuild of the initrd, too. > So the only change which is necessary is, to not run the macro if coreutils > is not yet installed (check if /usr/bin/mkdir exists). Because we know, > initrd will be regenerated later when coreutils get installed. Hm, coreutils is not the only package that provides "mkdir". busybox-coreutils doesn't call %regenerate-initrd-post, AFAICS. Perhaps we should add /run/regenerate-initrd to tmpfiles.d to make sure it always exists? Would that work during installation?
(In reply to Martin Wilck from comment #10) > Perhaps we should add /run/regenerate-initrd to tmpfiles.d to make sure it > always exists? Would that work during installation? ... and if we do so, which package should own that tmpfiles.d entry? rpm-config-SUSE I suppose?
(In reply to Martin Wilck from comment #10) > (In reply to Thorsten Kukuk from comment #5) > > > On the other side: coreutils triggers the rebuild of the initrd, too. > > So the only change which is necessary is, to not run the macro if coreutils > > is not yet installed (check if /usr/bin/mkdir exists). Because we know, > > initrd will be regenerated later when coreutils get installed. > > Hm, coreutils is not the only package that provides "mkdir". > busybox-coreutils doesn't call %regenerate-initrd-post, AFAICS. busybox-coreutils is only usable for containers, where you don't have an initrd. On a "real" system it's not installable/breaks systemd/... > Perhaps we should add /run/regenerate-initrd to tmpfiles.d to make sure it > always exists? Would that work during installation? During installation the installer creates the initrd anyways, if this hasn't changed. But you still have the ordering problem here. If you have no installer, again, there is the dependency ordering problem. You can only create /run/regenerate-initrd with tmpfiles.d after systemd is installed. In the update case: again, ordering of packages still using mkdir and packages not using it. I don't have enough insight in which packages trigger rebuild of initrd and how deep they are in the dependency stack. So I don't have a real, good idea. Except: don't touch /run/regenerate-initrd/XXX, but /run/regenerate-initrd-XXX and loop over all /run/regenerate-initrd-* files or something like that. No idea if this is feasible.
(In reply to Thorsten Kukuk from comment #12) > > Perhaps we should add /run/regenerate-initrd to tmpfiles.d to make sure it > > always exists? Would that work during installation? > > During installation the installer creates the initrd anyways, if this hasn't > changed. But you still have the ordering problem here. During installation the "mkdir" utility should be available, no? This isn't specific to s-m-t or initrd building. Creating directories is the second-most elementary operation on a Unix system. No explicit dependencies should be necessary to make it work. > If you have no installer, again, there is the dependency ordering problem. > You can only create /run/regenerate-initrd with tmpfiles.d after systemd is > installed. I don't get this argument. systemd would only be responsible for creating the directory if it is running as PID 1, which apparently wouldn't be the case in the installation scenario you have in mind. In that case, either the tool that's doing the installation (kiwi or whatnot) should create the necessary directories, or (preferred) mkdir should be provided. > I don't have enough insight in which packages trigger rebuild of initrd and > how deep they are in the dependency stack. So I don't have a real, good idea. Here's a list from Bernhard's openSUSE repo: xfsprogs xen transactional-update thin-provisioning-tools ucode-intel systemd suse-module-tools suse-prime sof-firmware sg3_utils selinux-targeted-setup s390-tools plymouth open-iscsi multipath-tools microos-tools mdadm lvm2 kmod kexec-tools kernel-firmware kbd ignition health-checker haveged e2fsprogs dracut dmraid cryptsetup clevis coreutils combustion btrfsprogs blog biosdevname I have the feeling that this list is too long, but we've had this discussion before and couldn't come to an agreement :-) > Except: don't touch /run/regenerate-initrd/XXX, but > /run/regenerate-initrd-XXX and loop over all /run/regenerate-initrd-* files > or something like that. No idea if this is feasible. Feasible: I suppose so, but I don't like it at all. It's against the conventions of /run as far as I am aware. As I said above, I think "mkdir" is essential enough that packages should be able to rely on its existence.
I will implement comment 9. In addition, I will add a macro %regenerate_initrd_requires \ Requires(post): /usr/bin/mkdir \ %{nil} that packages can use if they so desire.
https://github.com/openSUSE/suse-module-tools/pull/99 https://github.com/openSUSE/rpm-config-SUSE/pull/71 Please review.
(In reply to Martin Wilck from comment #15) > https://github.com/openSUSE/suse-module-tools/pull/99 > https://github.com/openSUSE/rpm-config-SUSE/pull/71 > > Please review. The "command -v" did create now problems in other packages and we had to replace that with "test-x /usr/bin/mkdir". But I'm not a shell expert nor do I know more details.
(In reply to Thorsten Kukuk from comment #16) > The "command -v" did create now problems in other packages and we had to > replace that with "test-x /usr/bin/mkdir". But I'm not a shell expert nor do > I know more details. Ok, I understand now the problem with the other packages, the above PRs are fine for me and should not have that problem.
I've merged the change in macros.initrd in suse-module-tools, but that will affect SLE15 only (to be clarified which SLE15 SPs to submit this to; I think I will submit it only to SP6 for now, the problem hasn't been reported for SLE15 and it doesn't warrant a maintenance incident). Assigning to Ludwig for rpm-config-SUSE / Tumbleweed. @Ludwig, can you think about a more elegant way to solve this issue? I thought about implementing %regenerate_initrd_post in lua, but that would require changes in almost every package using the macro because it is typically used in shell code. Do we have a chance to implement this with filetriggers of some sort?
I have pushed the change to the sles15-sp6 branch of suse-module-tools. But because of "factory first", I don't think it should be pushed to SP6 repos before it has reached Factory via rpm-config-SUSE.
File triggers would only work if we maintain a list of all files that potentially get included in the initrd. Kind of unrealistic IMO. The general idea to have package management resp the system magically know that the initrd may need rebuilding is good though. Unfortunately there's no global post transaction hook that's not attached to a specific package on rpm level AFAIK. If we had such a hook, dracut could record what it pulled in and check against that after packages got (un)installed. Maybe we can dodge the problem entirely in the future by using OBS generated initrd bits instead of client side dracut.
(In reply to Ludwig Nussel from comment #20) > If we had such a hook, dracut could record what it pulled in and > check against that after packages got (un)installed. Hm, I don't like that idea much. In theory, dracut could check if any file currently included in the intramfs has changed, and rebuild if so. But that would be a very time-consuming operation in every %posttrans. I doubt users would welcome it much. But I guess it's pointless to argue about a feature that isn't available anyway :-) In fact, we have open bugs from users that don't want their initrds to be rebuilt, ever, because of package updates. And I think they have a point. > Maybe we can dodge the problem entirely in the future by using OBS generated > initrd bits instead of client side dracut. Unfortunately that's still far-away future, right?
(In reply to Martin Wilck from comment #21) > (In reply to Ludwig Nussel from comment #20) > > If we had such a hook, dracut could record what it pulled in and > > check against that after packages got (un)installed. > > Hm, I don't like that idea much. In theory, dracut could check if any file > currently included in the intramfs has changed, and rebuild if so. But that > would be a very time-consuming operation in every %posttrans. I doubt users > would welcome it much. But I guess it's pointless to argue about a feature > that isn't available anyway :-) Depends on how such a hook would be implemented. Rpm knows the list of changed files so could pass it, just like it's done with file triggers. Missing features could be implemented if SUSE decides to put resources. > In fact, we have open bugs from users that don't want their initrds to be > rebuilt, ever, because of package updates. And I think they have a point. > > > Maybe we can dodge the problem entirely in the future by using OBS generated > > initrd bits instead of client side dracut. > > Unfortunately that's still far-away future, right? Matter of resources again. Here's an overly simple PoC https://build.opensuse.org/package/show/home:lnussel:systemd/initrd
This is an autogenerated message for OBS integration: This bug (1217979) was mentioned in https://build.opensuse.org/request/show/1143010 Factory / suse-module-tools
SUSE-RU-2024:1887-1: An update that has five fixes can now be installed. Category: recommended (moderate) Bug References: 1192014, 1216717, 1217979, 1223278, 1224320 Maintenance Incident: [SUSE:Maintenance:34011](https://smelt.suse.de/incident/34011/) Sources used: openSUSE Leap 15.6 (src): suse-module-tools-15.6.9-150600.3.3.3 Basesystem Module 15-SP6 (src): suse-module-tools-15.6.9-150600.3.3.3 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.