#1020893 lsb_release does not show version info in unstable

Package:
lsb-release
Source:
lsb-release
Submitter:
Yukiharu YABUKI
Date:
2026-08-07 08:51:04 UTC
Severity:
normal
Tags:
#1020893#5
Date:
2022-09-28 04:30:18 UTC
From:
To:
Dear Maintainer,

lsb_release command says

```
$ lsb_release -cs
No LSB modules are available.
n/a

$ lsb_release
No LSB modules are available
```

I'd like to get infomation from lsb_release command.
#1020893#10
Date:
2022-09-28 05:56:29 UTC
From:
To:
Control: retitle -1 lsb_release does not show version info in unstable
Control: severity -1 wishlist
Control: tags -1 wontfix
Control: block -1 by 1008735
Control: affects 1008735 lsb-release

The reported behavior happens only on unstable and testing.

`lsb_release` reads the release data from `/etc/os-release`. The
`/etc/os-release` file shipped by `base-files` in Debian unstable and
testing does not contain the required VERSION_* variables.

There is an open bug against `base-files` requesting the addition of
said variables to `/etc/os-release`: <https://bugs.debian.org/1008735>.

Regards,
#1020893#23
Date:
2022-10-01 17:33:43 UTC
From:
To:
Started seeing this issue today on my system:

user@debian:~$ lsb_release -r
No LSB modules are available.
Release:	n/a
user@debian:~$ lsb_release -sr
No LSB modules are available.
n/a
user@debian:~$


user@debian:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
user@debian:~$


user@debian:~$ dpkg -l base-files lsb-release
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-======================================================================
ii  base-files     12.2         amd64        Debian base system miscellaneous files
ii  lsb-release    12.0-1       all          Linux Standard Base version reporting utility (minimal implementation)
#1020893#28
Date:
2022-10-03 06:04:22 UTC
From:
To:
A workaround (while waiting for the root issue #1008735 to be fixed) is
to add to `/etc/os-release` the following two lines:

```
VERSION_ID=unstable
VERSION_CODENAME=bookwork
```
#1020893#33
Date:
2022-10-11 11:29:55 UTC
From:
To:
Hi!

The root issue #1008735 has been recently fixed, and this bug is
indirectly fixed by it.

To confirm:

$ lsb_release -cs
No LSB modules are available.
n/a
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux bookworm/sid
Release:	n/a
Codename:	n/a
$ # apt-get upgraded in another terminal ...
$ lsb_release -cs
No LSB modules are available.
bookworm
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux bookworm/sid
Release:	n/a
Codename:	bookworm

Cheers,

Alex
#1020893#44
Date:
2026-08-06 20:31:12 UTC
From:
To:
This will be in my ansible playbooks in the future. It will probably
also mean that I need to manage /etc/os-release even on stable systems
with ansible as well to cater for systems that got installed as
unstable/testing and then went stable with the release.

BUt at least this saves me from patching gazillions of rules and getting
snappy answers from role autors why Debian is the only distribution that
needs ugly (and ever changing!) workarounds in version gates.

Is it the intended behavior that an unstable system managed with ansible
will report a DIFFERENT distribution_major_version depending on whether
lsb-release is installed or not?

Without lsb-release, VERSION_ID is "forky/sid", with lsb-release, it's
"n/a". Guess which variant makes more sense to me.

Greetings
Marc
#1020893#47
Date:
2026-08-06 20:31:12 UTC
From:
To:
This will be in my ansible playbooks in the future. It will probably
also mean that I need to manage /etc/os-release even on stable systems
with ansible as well to cater for systems that got installed as
unstable/testing and then went stable with the release.

BUt at least this saves me from patching gazillions of rules and getting
snappy answers from role autors why Debian is the only distribution that
needs ugly (and ever changing!) workarounds in version gates.

Is it the intended behavior that an unstable system managed with ansible
will report a DIFFERENT distribution_major_version depending on whether
lsb-release is installed or not?

Without lsb-release, VERSION_ID is "forky/sid", with lsb-release, it's
"n/a". Guess which variant makes more sense to me.

Greetings
Marc
#1020893#52
Date:
2026-08-07 08:41:53 UTC
From:
To:
That is a different, but connected issue.

As you said, Debian still requires ad-hoc handling and there is no
consensus how that handling should happen. If you check `_distro.py` in
Ansible you'll see a series of Debian-specific code branches, some of
which will be executed only when `/usr/bin/lsb_release` is not
available. (For all other modern distros the data is gathered by simply
reading `{/etc,/usr/lib}/os-release`.)

Regards,
#1020893#55
Date:
2026-08-07 08:41:53 UTC
From:
To:
That is a different, but connected issue.

As you said, Debian still requires ad-hoc handling and there is no
consensus how that handling should happen. If you check `_distro.py` in
Ansible you'll see a series of Debian-specific code branches, some of
which will be executed only when `/usr/bin/lsb_release` is not
available. (For all other modern distros the data is gathered by simply
reading `{/etc,/usr/lib}/os-release`.)

Regards,