use of lsb_release instead of /etc/os-release for getting OS information on linux

In

Lines 175 to 178 in 4f41a90

    
           export async function getLinuxInfo() { 
        
             const {stdout} = await exec.getExecOutput('lsb_release', ['-i', '-r', '-s'], { 
        
               silent: true 
        
             });

the lsb_release legacy command line is relied upon for identifying linux distros. By now however, as part of systemd you should have /etc/os-release which should cover a vast majority if not all OSes that linux runners would be using (GitHub-hosted, Ubuntu-based self-hosted, or other non-Ubuntu-self-hosted otherwise).

Description:

The proposal would be to migrate from relying on the lsb_release executable in favor of the /etc/os-release and the contents there for identifying the OS information.

Justification:

Issues like #1214 and error messages on self-hosted runners such as Error: The version '3.13' with architecture 'x64' was not found for this operating system. are quite misleading because they indicate that setup-python has no x64 architecture for the operating system, when in actuality it is the operating system that setup-python does not support which is (frustratingly) hidden away in the advanced usage of the documentation.

Are you willing to submit a PR?

Yes, but I would not know how to test this.

@kratsg

Hi @kratsg , Thank you for creating this issue. We will investigate it and provide feedback as soon as we have some updates.

@kratsg

Hi @kratsg, thanks for raising this and for the detailed justification.

As of #1323, getLinuxInfo() now falls back to /etc/os-release whenever lsb_release is unavailable. This means OS detection no longer fails on self-hosted or non-Ubuntu runners that don't ship lsb_release, which was the root cause behind the misleading "...was not found for this operating system" errors you described.

We chose to keep lsb_release as the primary source and use /etc/os-release as the fallback, rather than replacing it outright, to preserve existing behavior and cache-key compatibility for current users while still covering the systemd-based cases you mentioned.

Please give it a try on your runners and let us know if you run into any further issues.

Hi @priyagupta108 can confirm this is now fixed.

Navigation Menu

Repository navigation

use of lsb_release instead of /etc/os-release for getting OS information on linux #1265

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	export async function getLinuxInfo() {
	const {stdout} = await exec.getExecOutput('lsb_release', ['-i', '-r', '-s'], {
	silent: true
	});

use of lsb_release instead of /etc/os-release for getting OS information on linux #1265

Description

Activity

v-chiranjib-swain commented on Jan 9, 2026

v-priyagupta108 commented on Jun 24, 2026

kratsg commented on Jun 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions