View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010301||CentOS-7||yum||public||2016-02-02 12:45||2019-02-12 21:06|
|Target Version||Fixed in Version|
|Summary||0010301: yum makes a wrong check of space available on /opt, when /opt is automounted; should not depend on /opt/rh|
|Description||Starting point: fresh install of 7.1-1503, plus configuration to make the machine an NFS client. Machine configured so that `/opt` is automounted, and `/opt/rh` does not exist on the NFS-mounted device..|
A `yum update` fails with the error
Transaction check error:
installing package scl-utils-20130529-17.el7_1.x86_64 needs 4KB on the /opt filesystem
I then added `rh` to the `opt` mount map so that `/opt/rh` mounted a writable directory from localhost, and verified that `/opt/rh` then existed and was writable (`# echo foo >/opt/rh/stamp.txt`). `yum update` again failed, with the same error.
I note that the system reports `/opt` as having zero size available:
# df /opt
Filesystem 1K-blocks Used Available Use% Mounted on
auto.opt 0 0 0 - /opt
I speculate therefore that at some point when checking the presence of, and space available under, `/opt/rh`, yum checks the space available on `/opt` (or something equivalent to this), and therefore erroneously gets a wrong size, causing it to fail.
I then set `diskspacecheck=0` in `yum.conf`, and the update proceeded without error, incidentally leaving `/opt/rh` empty apart from the above stamp file (ie, nothing was being installed there).
* bug: when `/opt` is automouted, yum fails to detect that `/opt/rh` exists and is writable
* enhancement: yum should not, I think, demand that `/opt/rh` exists, in the case where it is not going to install anything there. That is, given that I do not plan to install any Software Collections on a client machine, I should be able to mount `/opt` read-only, without `/opt/rh`. (I'm happy to make this a separate enhancement request if you feel that would be neater).
|Steps To Reproduce||See above. I've selected reproducibility 'N/A' since it seems clear that it's `/opt` being automounted that is the key feature.|
|Additional Information||1. It would be desirable to be able to choose to relocate `/opt` at installation time (as opposed to when one is constructing the metapackage), but I appreciate this may be infeasible, and so I have not included this as an enhancement request.|
2. The notes at <https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html/Packaging_Guide/chap-Advanced_Topics.html#sect-Using_Software_Collections_over_NFS> remark that 'This enables you to mount the /opt file system hierarchy over NFS as read-only', so that this is at least intended as a supported configuration (though I can see that might be approaching the problem from the slightly different point of view of doing the yum install to /opt on the NFS server).
3. The FHS description at <http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages> is not particularly clear, but the remark 'Package files that are variable (change in normal operation) must be installed in /var/opt.' seems to imply that /opt is mountable read-only. The FHS doesn't say anything about NFS in the context of /opt The remark 'Distributions may install and otherwise manage software in /opt under an appropriately registered subdirectory' does not, I think, imply that /opt should be writable other than when deliberately installing things in /opt.
|Tags||No tags attached.|
Same problem here, for the same reasons.
The workaround (setting "diskspacecheck=0" in yum.conf) cripples a nice safeguard in yum.
|This is still true in 7.5.1804|
Which is still not current. 7.6.1810 is current.
And since it doesn't seem to be mentioned anywhere in this ticket, CentOS is a rebuild of RHEL with only modifications to remove trademarks and branding. To get any bugs fixed they need to be reported on bugzilla.redhat.com. Once Redhat fix it for RHEL and release the package, CentOS will rebuild it.
Ah, right -- I wasn't sure how that worked.
Duly reported there: https://bugzilla.redhat.com/show_bug.cgi?id=1676685