Repository navigation
[FEATURE REQUEST] Debian grains do not report minor version #66935
Description
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.7Expected 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
Activity
dmurphy18 commentedon Sep 30, 2024
@nf-brentsaner Just ran
lsb_release -aand gotRelease: 12no minor version, but will check later again once updated the VM used. Cannot provide a minor version iflsb_release -ais not giving one, and btw:cat /etc/os-releasealso did not provide a minor version either.nf-brentsaner commentedon Oct 1, 2024
Note: /etc/debian_version is where the minor is
dmurphy18 commentedon Oct 1, 2024
@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 commentedon Oct 2, 2024
What then is the purpose of then
osrelease*grains vslsb_release_*grains?dmurphy18 commentedon Oct 2, 2024
@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:Note: Ubuntu
trixie/sidAnd 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
dmurphy18 commentedon Oct 2, 2024
As for Rocky 9, and suggestion on osfinger, there is no information as to patch level etc in /etc/os-release
For Ubuntu 24.04
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 commentedon Nov 21, 2024
@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 commentedon Nov 21, 2024
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_veror the like- that would contain information including the minor.Add onto that, including the minor in
osfingeris likely correct but it'd be an API-breaking change for any state logic that depends on that instead ofosandosmajorrelease.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 commentedon Nov 22, 2024
@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_versionand update the minor version in the 3008 branch (currently master branch), but wonder if it is a bug in/etc/os-releasehandling or did Debian deliberately move away from supplying the minor version, like they used to before Debian 10.[-][BUG] Debian grains do not report minor version[/-][+][FEATURE REQUEST] Debian grains do not report minor version[/+]