[FEATURE REQUEST] Debian grains do not report minor version

[nf-brentsaner]

Description
See below; Debian does not include minor version in grains.

Setup
N/A

• on-prem machine
• VM (Virtualbox, KVM, etc. please specify)
• VM running on a cloud service, please be explicit and add details
• container (Kubernetes, Docker, containerd, etc. please specify)
• or a combination, please be explicit
• jails if it is FreeBSD
• classic packaging
• onedir packaging
• used bootstrap to install

Steps to Reproduce the behavior

# salt --out=json 'DEBIAN_MINION' grains.items | grep -Ev '^jid:' | jq '.[] | with_entries(if (.key|test("^(os|lsb)")) then ( {key: .key, value: .value } ) else empty end )'

{
  "os": "Debian",
  "os_family": "Debian",
  "oscodename": "bookworm",
  "osfullname": "Debian GNU/Linux",
  "lsb_distrib_id": "Debian GNU/Linux",
  "lsb_distrib_release": "12",
  "lsb_distrib_codename": "bookworm",
  "osrelease": "12",
  "osarch": "amd64",
  "osrelease_info": [
    12
  ],
  "osmajorrelease": 12,
  "osfinger": "Debian-12"
}

Yet, e.g.:

DEBIAN_MINION:~ # cat /etc/debian_version
12.7

Expected behavior
e.g. on AlmaLinux:

# salt --out=json 'ALMA_MINION' grains.items | grep -Ev '^jid:' | jq '.[] | with_entries(if (.key|test("^(os|lsb)")) then ( {key: .key, value: .value } ) else empty end )'

{
  "os": "AlmaLinux",
  "os_family": "RedHat",
  "oscodename": "Cerulean Leopard",
  "osfullname": "AlmaLinux",
  "lsb_distrib_id": "AlmaLinux",
  "lsb_distrib_release": "8.10",
  "lsb_distrib_codename": "Cerulean Leopard",
  "osrelease": "8.10",
  "osarch": "x86_64",
  "osrelease_info": [
    8,
    10
  ],
  "osmajorrelease": 8,
  "osfinger": "AlmaLinux-8"
}

Both the major and minor are available via lsb_distrib_release, osrelease, and osrelease_info.
(One may argue the osfinger should include any minor/patch/revision version info as well, but c'est la vie.)

Screenshots
N/A

Versions Report
N/A, see above

Additional context
N/A

[dmurphy18]

@nf-brentsaner Just ran lsb_release -a and got Release: 12 no minor version, but will check later again once updated the VM used. Cannot provide a minor version if lsb_release -a is not giving one, and btw: cat /etc/os-release also did not provide a minor version either.

[nf-brentsaner]

Note: /etc/debian_version is where the minor is

[dmurphy18]

@nf-brentsaner I understand where the /etc/debian_version is where the minor version is, but the grains for Debian / Ubuntu platforms make use of lsb_release, which is providing the information. It used to provide the minor version, thinking back to 8.6 being reported, but it is now only reporting major versions

[nf-brentsaner]

What then is the purpose of thenosrelease* grains vs lsb_release_* grains?

[dmurphy18]

@nf-brentsaner Not all platforms have lsb_release support, so osrelease grains are there in general, and lsb_release also provided on those platforms which do. The grains handling for operating systems was re-architected a few years ago, to more accurately utilize the information provided by the OS, that is /etc/os-release etc.

The fact that Debian and lsb_release or /etc/os-release on Debian 12 is no longer providing minor versions is beyond the control of Salt, esp. when it used to, go look at stretch. Given the minimal resources and time available to the Salt Core Team, a PR addressing the issue with unit tests and changelog would be much appreciated which resolves the matter for Debian and Ubuntu, noting that on Ubuntu:

trixie/sid
david@david-XPS-15-9570:~/devcode/dgm_salt_3006/salt$ cat /etc/os-release 
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo
david@david-XPS-15-9570:~/devcode/dgm_salt_3006/salt$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.1 LTS
Release:	24.04
Codename:	noble
david@david-XPS-15-9570:~/devcode/dgm_salt_3006/salt$

Note: Ubuntu trixie/sid

And understand this not reporting minor version has been around since Debian 10, but missed. So first to notice this, thanks for bringing it to attention.

Also wanted to draw your attention to the understanding on using /etc/os-release,

salt/salt/grains/core.py

Lines 2221 to 2224 in 58c89a8

	Most Linux distributions should ship a os-release file
	and this file should be the sole source for deriving the
	OS grains. To not cause regressions, only switch the
	distribution that has been tested.

[dmurphy18]

As for Rocky 9, and suggestion on osfinger, there is no information as to patch level etc in /etc/os-release

[root@ip-10-2-4-75 rocky]# cat /etc/os-release 
NAME="Rocky Linux"
VERSION="9.4 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.4"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.4 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.4"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.4"

For Ubuntu 24.04

root@ip-10-2-5-97:/home/ubuntu# cat /etc/os-release 
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

For osfinger suggestion, could grab the 24.04.1 for patch level etc. If interested in this, then please add a 'Feature Request' against the master branch for the added functionality, detailing the additional functionality and how it would work on RedHat, Debian/Ubuntu, Windows and MacOS families.

[dmurphy18]

@nf-brentsaner Are you interested in adding the feature request, if so, please turn this into a feature request otherwise please consider closing this issue, given the current code is replying with the contents from the underlying OS.

[nf-brentsaner]

Potentially- the issue I have here is ultimately if /etc/os-release is intended to be the authoritative source, then this is functionally a Debian bug- but it's still release info useful to Salt. So this would likely need to be fixed upstream, but the alternative would be a new grain- something like distro_ver or the like- that would contain information including the minor.

Add onto that, including the minor in osfinger is likely correct but it'd be an API-breaking change for any state logic that depends on that instead of os and osmajorrelease.

Would it then make more sense to target a future version of Salt or a future release of the distro for such breaking changes? etc.

So kind of.. unsure what the decision process on that typically is.

[dmurphy18]

@nf-brentsaner It would be in a future version of Salt, for example: 3008 which isn't shipping and the next version of Salt. All new features are going into that future version.

Could add to the code for Debian to read /etc/debian_version and update the minor version in the 3008 branch (currently master branch), but wonder if it is a bug in /etc/os-release handling or did Debian deliberately move away from supplying the minor version, like they used to before Debian 10.

[dwoz]

This feature request was moved out of the issue tracker as part of a backlog cleanup — there is no active development commitment behind it. If you intend to implement this, please leave a comment and a maintainer can convert the discussion back to an issue to track the PR.