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.