|
Bugzilla – Full Text Bug Listing |
| Summary: | Permission are at 0700 for repositories under '/var/cache/zypp/raw/', cause non root user zypper cmd failing with "Can't create metadata cache directory" | ||
|---|---|---|---|
| Product: | [openSUSE] PUBLIC SUSE Linux Enterprise Desktop 15 SP5 | Reporter: | Richard Fan <richard.fan> |
| Component: | zypper | Assignee: | E-mail List <zypp-maintainers> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | georg.pfuetzenreuter, jhura, jpupava, meissner, richard.fan, santiago.zarate, slemke |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://openqa.suse.de/tests/13951373/modules/clean_pidgin/steps/10 | ||
| Whiteboard: | |||
| Found By: | openQA | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | zypper_logs | ||
|
Description
Richard Fan
2024-04-07 06:10:00 UTC
Please let me know if dev needs to access my setup The latest libzypp package can be found at MU below as well: http://download.suse.de/ibs/SUSE:/Maintenance:/33122/SUSE_Updates_SLE-Module-Basesystem_15-SP5_x86_64/ @Richard, please provide the YAST logs from the installation. I don't find them in the 'logs and assets' (https://openqa.suse.de/tests/13951373#downloads). (In reply to Richard Fan from comment #0) > The issue is gone if I downgrade the 'libzypp' package and then > de-register/register the system again: > > # zypper install --oldpackage libzypp-17.31.31-150400.3.52.2.x86_64 > # suseconnect -d > # suseconnect -r INTERNAL-USE-ONLY-xxxx-xxxx @Richard, are the directory permissions also fixed , if you just do > # suseconnect -d > # suseconnect -r INTERNAL-USE-ONLY-xxxx-xxxx without downgrading libzypp? (In reply to Michael Andres from comment #3) > @Richard, please provide the YAST logs from the installation. I don't find > them in the 'logs and assets' > (https://openqa.suse.de/tests/13951373#downloads). Please find the log at https://openqa.suse.de/tests/13951374/file/logs_from_installation_system-y2logs.tar.bz2 (In reply to Michael Andres from comment #4) > (In reply to Richard Fan from comment #0) > > The issue is gone if I downgrade the 'libzypp' package and then > > de-register/register the system again: > > > > # zypper install --oldpackage libzypp-17.31.31-150400.3.52.2.x86_64 > > # suseconnect -d > > # suseconnect -r INTERNAL-USE-ONLY-xxxx-xxxx > > @Richard, are the directory permissions also fixed , if you just do > > # suseconnect -d > > # suseconnect -r INTERNAL-USE-ONLY-xxxx-xxxx > without downgrading libzypp? Seems no! susetest:/var/cache/zypp/raw # ll |more total 0 drwx------ 1 root root 58 Apr 8 03:03 Basesystem_Module_15_SP5_x86_64:SLE-Module-Basesystem15-SP5-Pool drwx------ 1 root root 44 Apr 8 03:03 Basesystem_Module_15_SP5_x86_64:SLE-Module-Basesystem15-SP5-Updates drwx------ 1 root root 58 Apr 8 03:04 Desktop_Applications_Module_15_SP5_x86_64:SLE-Module-Desktop-Applications15-SP5-Pool drwx------ 1 root root 44 Apr 8 03:04 Desktop_Applications_Module_15_SP5_x86_64:SLE-Module-Desktop-Applications15-SP5-Updates drwx------ 1 root root 58 Apr 8 03:04 Python_3_Module_15_SP5_x86_64:SLE-Module-Python3-15-SP5-Pool drwx------ 1 root root 44 Apr 8 03:04 Python_3_Module_15_SP5_x86_64:SLE-Module-Python3-15-SP5-Updates drwx------ 1 root root 82 Apr 5 18:27 SLED15-SP5-15.5-0 drwx------ 1 root root 44 Apr 8 03:03 SUSE_Linux_Enterprise_Desktop_15_SP5_x86_64:SLE-15-SP5-Desktop-NVIDIA-Driver drwx------ 1 root root 58 Apr 8 03:03 SUSE_Linux_Enterprise_Desktop_15_SP5_x86_64:SLE-Product-SLED15-SP5-Pool drwx------ 1 root root 44 Apr 8 03:03 SUSE_Linux_Enterprise_Desktop_15_SP5_x86_64:SLE-Product-SLED15-SP5-Updates drwx------ 1 root root 44 Apr 8 03:04 SUSE_Linux_Enterprise_Workstation_Extension_15_SP5_x86_64:SLE-15-SP5-Desktop-NVIDIA-Driver drwx------ 1 root root 58 Apr 8 03:04 SUSE_Linux_Enterprise_Workstation_Extension_15_SP5_x86_64:SLE-Product-WE15-SP5-Pool drwx------ 1 root root 44 Apr 8 03:04 SUSE_Linux_Enterprise_Workstation_Extension_15_SP5_x86_64:SLE-Product-WE15-SP5-Updates (In reply to Richard Fan from comment #6) > > without downgrading libzypp? > > Seems no! Thanks. Please attach also the /var/log/zypper.log from the above system. Created attachment 874122 [details]
zypper_logs
(In reply to Michael Andres from comment #7) > (In reply to Richard Fan from comment #6) > > > without downgrading libzypp? > > > > Seems no! > > Thanks. Please attach also the /var/log/zypper.log from the above system. Please see new attached file Hello, As we are highly interested in this zypper update I did some tests on this report to double check if this is an existing bug or a regression, as for regression we cannot release this update, but if its an existing bug we can release current zypper and fix the issue on next update. Results: OLD: A lot of can't create metadata errors like reported, and in the end it shows the package info properly. NEW: A lot of can't create metadata errors like reported, and in the end it shows the package info properly. This is not a regression, it's an existing bug that we need to fix on the next zypper update cycle. @Juraj could you create the RR again? thank! -> OLD zypper/libzypp: tests@localhost:~> rpm -qa |grep zypper zypper-needs-restarting-1.14.68-150400.3.40.2.noarch zypper-1.14.68-150400.3.40.2.x86_64 zypper-lifecycle-plugin-0.6.1601367426.843fe7a-1.60.noarch tests@localhost:~> tests@localhost:~> rpm -qa |grep libzypp libzypp-17.31.31-150400.3.52.2.x86_64 (...) - Can't create metadata cache directory. (...) Information for package xterm: ------------------------------ Repository : SLE-Module-Basesystem15-SP5-Updates Name : xterm Version : 330-150200.11.15.1 Arch : x86_64 Vendor : SUSE LLC <https://www.suse.com/> Support Level : Level 3 Installed Size : 38.0 KiB Installed : No Status : not installed Source package : xterm-330-150200.11.15.1.src Upstream URL : http://invisible-island.net/xterm/ Summary : The basic X terminal program Description : This package contains the basic X.Org terminal program desktop launcher. ----------------------------------------------------------------------------- -> NEW zypper/libzypp: tests@localhost:~> rpm -qa |grep zypper zypper-needs-restarting-1.14.69-150400.3.43.4.noarch zypper-1.14.69-150400.3.43.4.x86_64 zypper-lifecycle-plugin-0.6.1601367426.843fe7a-1.60.noarch tests@localhost:~> rpm -qa |grep libzypp libzypp-17.32.2-150400.3.57.2.x86_64 tests@localhost:~> - Can't create metadata cache directory. Warning: The metadata cache needs to be built for the 'SUSE:Maintenance:33122 (SUSE_Updates_SLE-Module-Basesystem_15-SP5_x86_64)' repository. You can run 'zypper refresh' as root to do this. Warning: Skipping repository 'SUSE:Maintenance:33122 (SUSE_Updates_SLE-Module-Basesystem_15-SP5_x86_64)' because of the above error. Some of the repositories have not been refreshed because of an error. Loading repository data... Reading installed packages... Information for package xterm: ------------------------------ Repository : SLE-Module-Basesystem15-SP5-Updates Name : xterm Version : 330-150200.11.15.1 Arch : x86_64 Vendor : SUSE LLC <https://www.suse.com/> Support Level : Level 3 Installed Size : 38.0 KiB Installed : No Status : not installed Source package : xterm-330-150200.11.15.1.src Upstream URL : http://invisible-island.net/xterm/ Summary : The basic X terminal program Description : This package contains the basic X.Org terminal program desktop launcher. tests@localhost:~> I'd like to point out: We have two issues here. 1) Zypp as non-root prints a warning if the repo would need to be refreshed, and an error if no metadata are available at all. In the first case the old metadata are used, in the second case the repo is skipped. With libzypp 17.32.0 the 'outdated' warning is wrongly printed for each repo, but the metadata are used and the command itself produces the same result. 2) The issue that some respos are created by YAST with permission 0700. But this is something that seems to be an issue in the YAST workflow. AFAICS zypp itself creates new repo chachedirs with respect to the current umask. Refreshed caches keep their permissions, no matter which umask is in affect. I think I finally found it (the reason for the 0700 mode cachedirs). The workflows in yast are quite different for the 'good 0755' and for the 'bad 0700' case. Nevertheless both are legal and must deliver the same result. I'll try to provide the fix for libzypp tomorrow. fixed in libzypp-17.32.4 SUSE-RU-2024:1433-1: An update that has five fixes can now be installed. Category: recommended (moderate) Bug References: 1221525, 1221963, 1222086, 1222398, 1223094 Maintenance Incident: [SUSE:Maintenance:33401](https://smelt.suse.de/incident/33401/) Sources used: SUSE Linux Enterprise Server 15 SP2 (src): libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise Server 15 SP3 (src): libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Enterprise Storage 7.1 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise Micro 5.1 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise Micro 5.2 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 SUSE Linux Enterprise Micro for Rancher 5.2 (src): zypper-1.14.71-150200.76.3, libzypp-17.32.5-150200.99.1 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. *** Bug 1225962 has been marked as a duplicate of this bug. *** |