RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1152862 - autofs shouldn't have kernel as a dependency
Summary: autofs shouldn't have kernel as a dependency
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: autofs
Version: 7.1
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: JianHong Yin
URL:
Whiteboard:
Depends On: 1113601
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-15 05:52 UTC by Ian Kent
Modified: 2015-03-05 13:24 UTC (History)
12 users (show)

Fixed In Version: autofs-5.0.7-45.el7
Doc Type: Bug Fix
Doc Text:
Cause: an ancient kernel Requires was causing problems when installing autofs into a Docker container. Fix: remove obsolete Requires in the package spec file. Result: when installing autofs into a Docker container no kernel dependency should be required by the yum installer.
Clone Of: 1113601
Environment:
Last Closed: 2015-03-05 13:24:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0525 0 normal SHIPPED_LIVE autofs bug fix and enhancement update 2015-03-05 16:33:54 UTC

Description Ian Kent 2014-10-15 05:52:48 UTC
+++ This bug was initially created as a clone of Bug #1113601 +++

Description of problem:

When kernel is installed as a dependency of autofs, various errors concerning /var are shown in posttrans.

Version-Release number of selected component (if applicable):

docker-io-1.0.0-4.fc20.x86_64
fedora:20 image as of today: 3f2fed40e4b0

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have Dockerfile:

FROM fedora:20
RUN yum install -y autofs

2. Run docker build -t autofs-test .

Actual results:

# docker build -t autofs-test .
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon 
Step 0 : FROM fedora:20
 ---> 3f2fed40e4b0
Step 1 : RUN yum install -y autofs
 ---> Running in 9b0bbf2f654d
http://mirrors.zimcom.net/pub/fedora/linux/updates/20/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2607:f550:100:33::23: Network is unreachable"
Trying other mirror.
Resolving Dependencies
--> Running transaction check
---> Package autofs.x86_64 1:5.0.7-40.fc20 will be installed
--> Processing Dependency: kernel >= 2.6.17 for package: 1:autofs-5.0.7-40.fc20.x86_64
--> Processing Dependency: libtirpc.so.1()(64bit) for package: 1:autofs-5.0.7-40.fc20.x86_64
--> Processing Dependency: libhesiod.so.0()(64bit) for package: 1:autofs-5.0.7-40.fc20.x86_64
--> Running transaction check
---> Package hesiod.x86_64 0:3.2.1-2.fc20 will be installed
---> Package kernel.x86_64 0:3.14.8-200.fc20 will be installed
--> Processing Dependency: linux-firmware >= 20130724-29.git31f6b30 for package: kernel-3.14.8-200.fc20.x86_64
---> Package libtirpc.x86_64 0:0.2.4-3.0.fc20 will be installed
--> Running transaction check
---> Package linux-firmware.noarch 0:20140605-38.gita4f3bc03.fc20 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package           Arch      Version                           Repository  Size
================================================================================
Installing:
 autofs            x86_64    1:5.0.7-40.fc20                   updates    524 k
Installing for dependencies:
 hesiod            x86_64    3.2.1-2.fc20                      fedora      29 k
 kernel            x86_64    3.14.8-200.fc20                   updates     32 M
 libtirpc          x86_64    0.2.4-3.0.fc20                    updates     83 k
 linux-firmware    noarch    20140605-38.gita4f3bc03.fc20      updates     21 M

Transaction Summary
================================================================================
Install  1 Package (+4 Dependent packages)

Total download size: 53 M
Installed size: 192 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
warning: /var/cache/yum/x86_64/20/fedora/packages/hesiod-3.2.1-2.fc20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
Public key for hesiod-3.2.1-2.fc20.x86_64.rpm is not installed
Public key for autofs-5.0.7-40.fc20.x86_64.rpm is not installed
--------------------------------------------------------------------------------
Total                                              4.0 MB/s |  53 MB  00:13     
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64
Importing GPG key 0x246110C1:
 Userid     : "Fedora (20) <fedora>"
 Fingerprint: c7c9 a9c8 9153 f201 83ce 7cba 2eb1 61fa 2461 10c1
 Package    : fedora-release-20-3.noarch (@fedora-updates/$releasever)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-x86_64
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : hesiod-3.2.1-2.fc20.x86_64                                   1/5 
  Installing : libtirpc-0.2.4-3.0.fc20.x86_64                               2/5 
  Installing : linux-firmware-20140605-38.gita4f3bc03.fc20.noarch           3/5 
  Installing : kernel-3.14.8-200.fc20.x86_64                                4/5 
  Installing : 1:autofs-5.0.7-40.fc20.x86_64                                5/5 
No '/dev/log' or 'logger' included for syslog logging
mknod: '/var/tmp/initramfs.aD5A0T/dev/null': Operation not permitted
mknod: '/var/tmp/initramfs.aD5A0T/dev/kmsg': Operation not permitted
mknod: '/var/tmp/initramfs.aD5A0T/dev/console': Operation not permitted
No '/dev/log' or 'logger' included for syslog logging
mknod: '/var/tmp/initramfs.XRmzzi/dev/null': Operation not permitted
mknod: '/var/tmp/initramfs.XRmzzi/dev/kmsg': Operation not permitted
mknod: '/var/tmp/initramfs.XRmzzi/dev/console': Operation not permitted
/usr/lib/kernel/install.d/51-dracut-rescue.install: line 59: /boot/loader/entries/5b2a1f96231d4de69964798a33d2add8-0-rescue.conf: No such file or directory
warning: %posttrans(kernel-3.14.8-200.fc20.x86_64) scriptlet failed, exit status 1
Non-fatal POSTTRANS scriptlet failure in rpm package kernel-3.14.8-200.fc20.x86_64
  Verifying  : 1:autofs-5.0.7-40.fc20.x86_64                                1/5 
  Verifying  : linux-firmware-20140605-38.gita4f3bc03.fc20.noarch           2/5 
  Verifying  : libtirpc-0.2.4-3.0.fc20.x86_64                               3/5 
  Verifying  : hesiod-3.2.1-2.fc20.x86_64                                   4/5 
  Verifying  : kernel-3.14.8-200.fc20.x86_64                                5/5 

Installed:
  autofs.x86_64 1:5.0.7-40.fc20                                                 

Dependency Installed:
  hesiod.x86_64 0:3.2.1-2.fc20                                                  
  kernel.x86_64 0:3.14.8-200.fc20                                               
  libtirpc.x86_64 0:0.2.4-3.0.fc20                                              
  linux-firmware.noarch 0:20140605-38.gita4f3bc03.fc20                          

Complete!
 ---> e11ccfbfb8a0
Removing intermediate container 9b0bbf2f654d
Successfully built e11ccfbfb8a0

Expected results:

Either kernel not pulled in, or no (or less) errors from posttrans.

Additional info:

Using docker-io component as a start of discussion about supporting autofs in Docker containers and if something can be changed in packaging of autofs or kernel or in the fedora:20 image to lower the posttrans noise.

--- Additional comment from Matthew Miller on 2014-06-26 14:55:58 EDT ---

See https://lists.fedoraproject.org/pipermail/packaging/2014-March/010083.html


I thiink the only reason autofs has this requirement is that it needs to run on a kernel newer than or equal to 2.6.17. So, I'm moving this bug to autofs.


Of course, having that kernel package installed doesn't mean that one is running under that kernel. Docker obviously demonstrates this, but also, there's no reason one couldn't have a kernel 2.6.17 package installed but be running 2.6.16 since the system wasn't rebooted.

However, all of that seems pretty much moot now, since we're long past the required kernel version in Fedora and even back to RHEL 5. My strong recommendation is to just remove the "Requires: kernel" line.


(Another option would be to use "Conflicts: kernel < 2.6.17", but that still has the conceptual problem with package vs. running kernel. I say just drop it.)

--- Additional comment from Ian Kent on 2014-06-26 21:18:42 EDT ---

(In reply to Matthew Miller from comment #1)
> See
> https://lists.fedoraproject.org/pipermail/packaging/2014-March/010083.html
> 
> 
> I thiink the only reason autofs has this requirement is that it needs to run
> on a kernel newer than or equal to 2.6.17. So, I'm moving this bug to autofs.
> 
> 
> Of course, having that kernel package installed doesn't mean that one is
> running under that kernel. Docker obviously demonstrates this, but also,
> there's no reason one couldn't have a kernel 2.6.17 package installed but be
> running 2.6.16 since the system wasn't rebooted.
> 
> However, all of that seems pretty much moot now, since we're long past the
> required kernel version in Fedora and even back to RHEL 5. My strong
> recommendation is to just remove the "Requires: kernel" line.
> 
> 
> (Another option would be to use "Conflicts: kernel < 2.6.17", but that still
> has the conceptual problem with package vs. running kernel. I say just drop
> it.)

Fair enough, I'll drop it.

--- Additional comment from Fedora Update System on 2014-10-15 00:37:14 EDT ---

autofs-5.0.7-41.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/autofs-5.0.7-41.fc20

--- Additional comment from Ian Kent on 2014-10-15 00:42:24 EDT ---

Sincere apologies for taking so long with this.

It occurs to me that while this Requires is clearly obsolete
now, for packages that need a Requires for a particular kernel,
that Docker should handle it rather than trying to pull in the
kernel dependency ....

Just a thought.
Ian

Comment 4 errata-xmlrpc 2015-03-05 13:24:22 UTC
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://rhn.redhat.com/errata/RHBA-2015-0525.html


Note You need to log in before you can comment on or make changes to this bug.