Upgrade to 8.7 breaks variables in /etc/os-release

Hi,

My configuration scripts for Rocky Linux 8 use various variables in /etc/os-release. The latest point release has apparently decided to break this stuff.

I thought the point of enterprise Linux was precisely to avoid this sort of nasty surprises. If I wanted to deal with this kind of nonsense, I’d use Arch or some other rolling release.

sigh

I’m not sure I understand the issue.

2c2
< VERSION="8.6 (Green Obsidian)"
---
> VERSION="8.7 (Green Obsidian)"
5c5
< VERSION_ID="8.6"
---
> VERSION_ID="8.7"
7c7
< PRETTY_NAME="Rocky Linux 8.6 (Green Obsidian)"
---
> PRETTY_NAME="Rocky Linux 8.7 (Green Obsidian)"
8a9
> LOGO="fedora-logo-icon"
12,13c13,14
< ROCKY_SUPPORT_PRODUCT="Rocky Linux"
< ROCKY_SUPPORT_PRODUCT_VERSION="8"
---
> ROCKY_SUPPORT_PRODUCT="Rocky-Linux-8"
> ROCKY_SUPPORT_PRODUCT_VERSION="8.7"
15c16
< REDHAT_SUPPORT_PRODUCT_VERSION="8"
---
> REDHAT_SUPPORT_PRODUCT_VERSION="8.7"

What in the os-release file changed that’s broken?

Up until Rocky Linux 8.6, ROCKY_SUPPORT_PRODUCT_VERSION contained the major release:

# grep ROCKY_SUPPORT_PRODUCT_VERSION /etc/os-release 
ROCKY_SUPPORT_PRODUCT_VERSION="8"

Now the schema suddenly includes the minor release:

# grep ROCKY_SUPPORT_PRODUCT_VERSION /etc/os-release
ROCKY_SUPPORT_PRODUCT_VERSION="8.7"

And here’s the test in my configuration script:

# Make sure we're running Rocky Linux 8.x.
if [ -f /etc/os-release ]
then

  source /etc/os-release

  SYSTEM="${ROCKY_SUPPORT_PRODUCT}"
  VERSION="${ROCKY_SUPPORT_PRODUCT_VERSION}"

fi

if [ "${SYSTEM}" != "Rocky Linux" ] && [ "${VERSION}" != "8" ]
then

  echo
  echo "  Unsupported operating system." >&2
  echo

  exit 1

fi

Of course I will edit it to make it behave, but what’s the point in changing stuff like this ?

Those values are for our bug tracker. It has no bearing on system usability and should not matter to most users. With that being said, the changes made were to match how RHEL has their os-release laid out on top of when we migrated back to mantis for bug tracking.

You should be focusing on VERSION_ID instead, which is the standard key value pair that most software keys off of when reading os-release.

2 Likes

Thanks for the clarification. Sorry if my initial message was a bit abrupt, but this latest upgrade broke quite some stuff here, and I’ve lost a sunny day trying to deal with that.

Cheers,

Niki

I was coding something the other day, and am pretty sure it also said 8.6 is /etc/os-release. That said, I just wanted 8, and got it this way:

lsb_release -r | awk '{print $2}' | cut -f1 -d "."

there might be a better way, but it works enough for me :slight_smile:

1 Like

As redhat-lsb is not part of 9 anymore, make sure to notice that, that will only work for <9
But it will for sure :slight_smile:

Tbh… the only improvement I see here is documenting which variables are upstream stable (which all *_SUPPORT_* are not, as they are meant for the bugtracker), or explenation which variable is meant to be used for what.

@lumarel ah yeah good catch :slight_smile: I’ll have to figure out another way then now the lsb_release has disappeared.

I thought about using $releasever, but not sure where this is stored on the system. dnf uses it obviously, just don’t find it under /etc/dnf//vars. I’ll figure out another way though. Pity about lsb_release.

Oh, this will work, for both Rocky 8 and 9:

grep VERSION_ID /etc/os-release | cut -f2 -d "=" | sed 's/"//g' | cut -f1 -d "."

Instead of using four commands, why not use one :slight_smile: :

awk -F'[".]' '/^VERSION_ID=/ {print $2}' /etc/os-release

4 Likes

Yeah mine is probably not the best, plenty of better ones I’m sure :slight_smile:

As an alternative, there are also /etc/redhat-release & /etc/os-release

if grep -q “release 8” /etc/redhat-release; then
VERSION_ID=“8”
fi

In Ansible one can use condition:

when:
- ansible_facts['distribution_major_version'] is version('8', '==')

but that is quite different approach from traditional scripts (and back when Rocky was very new, Ansible had regognition issues).

1 Like

Actually another good option is:

dnf install python3-distro

and then:

[root@rocky8 ~]# distro
Name: Rocky Linux 8.7 (Green Obsidian)
Version: 8.7 (Green Obsidian)
Codename: Green Obsidian

or pull it in JSON format:

[root@rocky8 ~]# distro --json
{
    "codename": "Green Obsidian",
    "id": "rocky",
    "like": "rhel centos fedora",
    "version": "8.7",
    "version_parts": {
        "build_number": "",
        "major": "8",
        "minor": "7"
    }
}

Yet another wacky way, look for the gpg key package:

VERSION=$(rpm -q --queryformat=“%{version}” rocky-gpg-keys)

echo $VERSION
8.7

1 Like

I went with this suggestion. Thanks very much !

I think this may also be the cause of my issue (on rocky 9.1). Unfortunately, there is no way for me to inform the plugin by using a dnf flag.

vagrant vbguest --do install
[mymachine] GuestAdditions 7.0.6 running — OK.
Unable to detect release version (use ‘–releasever’ to specify release version)

Or maybe not. I tried manually editing os-release to use only the major number, but it didn’t fix the problem.