Hello,
This is a follow-up to a thread from 2020 that was auto-closed due to
inactivity and can no longer be replied to:
"System identifier unknown with VT OID 1.3.6.1.4.1.25623.1.0.108441"
In that thread, a Greenbone team member (cfi) acknowledged the issue
with Linux Mint not being properly detected during authenticated scans
and mentioned that the provided information "should be enough to
implement at least some basic OS Detection capabilities." However,
five years later, the issue still appears to be present - at least
for the system I tested.
CURRENT ISSUE:
The NVT "Determine OS and list of installed packages via SSH login"
(OID: 1.3.6.1.4.1.25623.1.0.50282) fails to detect the OS and does not
retrieve the package list on a target running Linux Mint 22.3 ("Zena"),
based on Ubuntu 24.04 ("noble").
Despite a successful SSH login (confirmed via "SSH Authorization Check"),
the scan reports:
"System identifier unknown: [...] Therefore no local security checks
applied (missing list of installed packages) though SSH login provided
and works."
SYSTEM DETAILS:
/etc/os-release:
NAME="Linux Mint"
VERSION="22.3 (Zena)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 22.3"
VERSION_ID="22.3"
VERSION_CODENAME=zena
UBUNTU_CODENAME=noble
Output of `uname -a`:
Linux PCMINT-0822 7.0.0-38-generic #38~24.04.4-Ubuntu SMP
PREEMPT_DYNAMIC Mon Sep 14 16:37:11 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
POSSIBLE CONTRIBUTING FACTORS:
1. As suspected in the 2020 thread, Linux Mint also provides
/etc/debian_version with a Debian-specific codename, which might
confuse the detection logic between Ubuntu and Debian matching.
2. NEW OBSERVATION: The kernel version "7.0.0-38-generic" is unusually
high for an Ubuntu 24.04 base system (typically 6.8.x). This might
not match the expected version patterns in the NVT's parsing logic.
3. NEW OBSERVATION: The build timestamp in the uname output appears
truncated/incomplete - it ends with "UTC 2" instead of a full
4-digit year (e.g. "UTC 2026"). This is reproducible when running
`uname -a` manually via SSH, so it's not a display artifact of the
scan report. This specific issue was not present in the 2020 thread
(the kernel string there, "4.10.0-38-generic #42~16.04.1-Ubuntu SMP
Tue Oct 10 16:32:20 UTC 2017", had a complete, valid year). This
might indicate a separate upstream kernel packaging issue, but it
could also be interfering with the NVT's regex-based parsing in
addition to the original Linux Mint detection problem.
ADDITIONAL TESTS PERFORMED:
- Confirmed that `dpkg -l` works correctly and returns a full, valid
package list when run manually via SSH - the package database itself
is fully accessible and intact.
- As a test, I temporarily changed ID=linuxmint to ID=ubuntu in
/etc/os-release and re-ran the scan - this had no effect on the
result, suggesting the NVT relies solely on the `uname -a` output
(and possibly /etc/debian_version) rather than /etc/os-release for
the initial OS match.
ENVIRONMENT:
- NVT version (50282): 2026-09-30T05:49:05Z
- Greenbone Community Feed: 20261005T0609
QUESTIONS:
1. Given that this issue was already reported in 2020, is there any
update on whether basic Linux Mint detection support is planned or
has been deprioritized?
2. Could someone confirm whether the incomplete kernel timestamp
("UTC 2" instead of a full year) is a known issue, and whether it
could independently affect the NVT's parsing logic?
Happy to provide additional debug output or test further changes if
that would help move this forward.
Thank you!
Hello,
and welcome to this community forums. Only short:
- Linux Mint is currently not a supported platform (so there is no detection problem), there is AFAICT no priority in covering it and i don’t think that it will be covered anytime soon
- The Kernel build timestamp / uname topic is completely unrelated / irrelevant
1 Like