Bug 1714888
Summary: | glibc: Account for size of locale-archive in rpm package. | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Karel Srot <ksrot> | |
Component: | glibc | Assignee: | Florian Weimer <fweimer> | |
Status: | CLOSED ERRATA | QA Contact: | qe-baseos-tools-bugs | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 7.6 | CC: | ashankar, codonell, dj, fweimer, mnewsome, pfrankli, pmatilai, skolosov | |
Target Milestone: | rc | Keywords: | Patch | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | glibc-2.17-304.el7 | Doc Type: | Bug Fix | |
Doc Text: |
Cause: The package manager does not verify that before a glibc update, sufficient disk space to complete the update is available.
Consequence: If a system is low on disk space, installation of a glibc update may terminate abnormally, potentially leaving the system in an unusable state.
Fix: The size of the generated glibc locale file is recorded in the glibc RPM file, so that the package manager can take it it into account during its pre-update checks.
Result: For future updates, the package manager will not start the update in most cases when insufficient disk space is available, reporting an error instead.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1725131 (view as bug list) | Environment: | ||
Last Closed: | 2020-03-31 19:08:32 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | 1725131 | |||
Bug Blocks: | 1710255 |
Description
Karel Srot
2019-05-29 06:12:21 UTC
This looks predominantly like an RPM bug. It should not continue the update if the disk is reported as full, and should be able to complete the installation after the system administrator has freed up some disk space. After all, the pre-transaction check suffers from a TOCTOU race, so it's not completely reliable. It's news to me that %ghost files contribute to transaction size. Is this documented somewhere? I don't know if it's documented anywhere, so many dark corners like this are not.. in any case, it does. The kernel initramfs case convinced me that it *must* be that way. Technically rpm is in position to stop the transaction of course, but ability to signal the admin and continuing would require a new interface that is somehow mandated on all API clients. Presumably, the recommended change looks like this: diff --git a/glibc.spec b/glibc.spec index ebf161b4..c501b9de 100644 --- a/glibc.spec +++ b/glibc.spec @@ -3441,7 +3441,7 @@ $olddir/build-%{target}/elf/ld.so \ --prefix ${RPM_BUILD_ROOT} --add-to-archive \ *_* rm -rf *_* -mv locale-archive{,.tmpl} +cp locale-archive{,.tmpl} popd %endif I have a test build with this change, glibc-2.17-292.el7.bz1714888.0. I missed another file truncation, so the patch should look like this: diff --git a/glibc.spec b/glibc.spec index ebf161b4..5176f5c4 100644 --- a/glibc.spec +++ b/glibc.spec @@ -3441,7 +3441,7 @@ $olddir/build-%{target}/elf/ld.so \ --prefix ${RPM_BUILD_ROOT} --add-to-archive \ *_* rm -rf *_* -mv locale-archive{,.tmpl} +cp locale-archive{,.tmpl} popd %endif @@ -3906,10 +3906,6 @@ touch $RPM_BUILD_ROOT/var/{db,run}/nscd/{passwd,group,hosts,services} touch $RPM_BUILD_ROOT/var/run/nscd/{socket,nscd.pid} %endif -%ifnarch %{auxarches} -> $RPM_BUILD_ROOT/%{_prefix}/lib/locale/locale-archive -%endif - mkdir -p $RPM_BUILD_ROOT/var/cache/ldconfig > $RPM_BUILD_ROOT/var/cache/ldconfig/aux-cache Okay, this should be good to go (but I don't have an easy reproducer for the issue itself): $ rpm -qplv glibc-common-2.17-292.el7.bz1714888.1.x86_64.rpm |grep /locale-archive -rw-r--r-- 1 root root 106065680 May 29 13:54 /usr/lib/locale/locale-archive -rw-r--r-- 1 root root 106065680 May 29 13:54 /usr/lib/locale/locale-archive.tmpl Hi, the change seem to be effective [root@ts ~]# dd if=/dev/zero of=/dev/mychroot bs=1M count=200 [root@ts ~]# losetup /dev/loop0 /dev/mychroot [root@ts ~]# mkfs.ext4 /dev/loop0 [root@ts ~]# mount /dev/loop0 /tmp/chroot/ new glibc: [root@ts ~]# rpm -iv --root /tmp/chroot/ --test --nodeps glibc-common-2.17-292.el7.bz1714888.1.x86_64.rpm Preparing packages... installing package glibc-common-2.17-292.el7.bz1714888.1.x86_64 needs 55MB on the / filesystem old glibc: [root@ts ~]# rpm -iv --root /tmp/chroot/ --test --nodeps glibc-common-2.17-292.el7. glibc-common-2.17-292.el7.bz1714888.1.x86_64.rpm glibc-common-2.17-292.el7.x86_64.rpm [root@ts ~]# rpm -iv --root /tmp/chroot/ --test --nodeps glibc-common-2.17-292.el7.x86_64.rpm Preparing packages... [root@ts ~]# Panu, I can't get this to work with rpm-4.11.3-40.el7.x86_64: # rpm -qplv glibc-common-2.17-304.el7.x86_64.rpm | grep /locale-archive -rw-r--r-- 1 root root 106180368 Aug 1 02:47 /usr/lib/locale/locale-archive -rw-r--r-- 1 root root 106180368 Aug 1 02:47 /usr/lib/locale/locale-archive.tmpl So the %ghost size record is there. (It's not a hard-link ghost file, either. 8-p) I have 167 MiB available: # df -h /usr Filesystem Size Used Avail Use% Mounted on /dev/mapper/rhel_nnn--n420--01-root 50G 50G 167M 100% / RPM testing passes: # rpm -Uv --test glibc-2.17-304.el7.x86_64.rpm glibc-common-2.17-304.el7.x86_64.rpm Preparing packages... Installation fails: # rpm -Uv glibc-2.17-304.el7.x86_64.rpm glibc-common-2.17-304.el7.x86_64.rpm Preparing packages... glibc-common-2.17-304.el7.x86_64 /usr/sbin/build-locale-archive: cannot add to locale archive: No such file or directory /usr/sbin/build-locale-archive: cannot add to locale archive: No such file or directory glibc-2.17-304.el7.x86_64 /usr/sbin/build-locale-archive: cannot add to locale archive: No such file or directory /usr/sbin/build-locale-archive: cannot add to locale archive: No such file or directory glibc-common-2.17-292.el7.x86_64 glibc-2.17-292.el7.x86_64 Unless I'm missing something, RPM doesn't take the %ghost size into account in this version, so we cannot fix this bug. All rpm versions in existence should take the %ghost size into account, but there are always any number of other factors at play. The original bug 1491786 is one possibility (so might be interesting to test with rpm >= 4.11.3-36.el7) but with tight margins all sorts of rounding to block size etc comes to play so coming up with a reliable reproducer can be hard. Try giving it a bit more room to maneuver. This may have something to do with the other change we are making at the same time: -%attr(0644,root,root) %verify(not md5 size mtime mode) %ghost %config(missingok,noreplace) %{_prefix}/lib/locale/locale-archive +%attr(0644,root,root) %verify(not md5 size mtime mode) %ghost %{_prefix}/lib/locale/locale-archive I get FA_SKIP from rpmfiDecideFateIndex for this file, which I believe will exempt it from size accounting. Yes, I think it's the %config change that interacts with this. The size accounting works for future updates, but not an update which combines both changes. Maybe we should move bug 1717512 to a z-stream update to compensate for this? But there will always be some customers that will get both changes at the same time. Nah, it's nowhere near worth bothering with z-stream. This is a rare corner-case issue at best and there'll always be cases where we fail when margins are tight no matter how many tweaks like this we do. It's good to have it fixed though. I suppose the %config change could affect the outcome but can't say for sure offhand. Verified, glibc-common rpm size now calculated with the double size of /usr/lib/locale/locale-archive.tmpl file. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0989 |