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 1766754 - /usr/lib/os-release doesn't exist and /etc/os-release is not a symlink
Summary: /usr/lib/os-release doesn't exist and /etc/os-release is not a symlink
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: redhat-release
Version: ---
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: 8.2
Assignee: Leon Kang
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-29 19:56 UTC by Debarshi Ray
Modified: 2022-05-02 00:26 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-17 12:35:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELBLD-2409 0 None None None 2022-05-02 00:26:20 UTC
Red Hat Issue Tracker RHELPLAN-38311 0 None None None 2022-05-02 00:22:41 UTC

Description Debarshi Ray 2019-10-29 19:56:43 UTC 
On RHEL 8, there's no /usr/lib/os-release, and /etc/os-release is a regular file instead of a symbolic link.

This is different from Fedora, where /etc/os-release is a symbolic link to /usr/lib/os-release. This set-up helps have stateless OSes, makes it easier to implement factory reset, etc. [1] and is quite helpful for variants like CoreOS and Silverblue.

[1] http://0pointer.net/blog/projects/stateless.html
Comment 2 Josh Boyer 2019-11-12 12:11:36 UTC 
This make sense to me.  I'd like to hear from Ian if it would indeed help RHCOS.
Comment 3 Debarshi Ray 2019-11-12 16:19:38 UTC 
For what it's worth, I had briefly discussed this with sgallagh on IRC before filing this bug.
Comment 4 Debarshi Ray 2019-11-12 16:22:04 UTC 
One of my motivations for filing this was from the perspective of the Toolbox [1] project.

Toolbox looks at /usr/lib/os-release for various reasons, and it was pointed out that both RHEL and CentOS 8 are different from Fedora in that regard. Having this minor delta ironed out would be nice.

[1] https://github.com/containers/toolbox
Comment 5 Lars Karlitski 2019-11-22 10:35:37 UTC 
I just stumbled across this issue for osbuild as well. It uses systemd-nspawn with an (almost) empty `/etc` to create images that are independent from host configuration. nspawn creates the symlink `/etc/os-release`, but on RHEL it ends up dangling.

This is also contrary to the man page `os-release(5)`.
Comment 7 Neal Gompa 2020-02-16 16:19:44 UTC 
I've also just encountered this problem myself when trying to build images and containers using RHEL 8 and CentOS 8.

I've made a proposed fix for centos-release, which should be a good reference for how to fix it in RHEL: https://git.centos.org/rpms/centos-release/pull-request/9
Comment 11 Peter Kotvan 2020-02-28 13:16:38 UTC 
RTT has prodvided qe_ack+. We will also extend existing redhat-release content verification tests to cover this as well.
Comment 12 Josh Boyer 2020-02-28 20:49:28 UTC 
Code committed.  Thank you to Neal for the implementation reference.
Comment 14 Peter Kotvan 2020-03-12 11:30:53 UTC 
I tried to verify this on RHEL-8.2.0-Snapshot-3.0 -> RHEL-8.2.0-20200310.0:

# ls -l /usr/lib/os-release /etc/os-release 
lrwxrwxrwx. 1 root root  22 Mar  9 15:03 /etc/os-release -> ..//usr/lib/os-release
-rw-r--r--. 1 root root 513 Mar  9 15:03 /usr/lib/os-release

Is it deliberate that there are // at the beginning of the referenced path in the symlink?
Comment 15 Leon Kang 2020-03-12 14:35:23 UTC 
I didn't actually implement this, it was tacked on as part of rebuild for another bug so i will need to ping others to get that information for you
Comment 16 Josh Boyer 2020-03-12 15:59:33 UTC 
(In reply to Peter Kotvan from comment #14)
> I tried to verify this on RHEL-8.2.0-Snapshot-3.0 -> RHEL-8.2.0-20200310.0:
> 
> # ls -l /usr/lib/os-release /etc/os-release 
> lrwxrwxrwx. 1 root root  22 Mar  9 15:03 /etc/os-release ->
> ..//usr/lib/os-release
> -rw-r--r--. 1 root root 513 Mar  9 15:03 /usr/lib/os-release
> 
> Is it deliberate that there are // at the beginning of the referenced path
> in the symlink?

No.  At the same time, it doesn't functionally change anything.  We can fix it in 8.3.0.
Comment 17 Leon Kang 2020-03-16 12:04:26 UTC 
Josh Boyer has provided the requested information
Note You need to log in before you can comment on or make changes to this bug.