Wrong oscodename if lsb_release is not installed

[darkpixel]

I think this is related to #30123
Here is fresh install of Debian 8:

root@salt:/srv/salt# salt-ssh -i 'uslogdcnas04.smiles.local' grains.get oscodename
uslogdcnas04.smiles.local:
    Debian GNU/Linux 8 (jessie)

Because of this, the Salt formula generates a bad /etc/apt/sources.list/saltstack.list file:

deb http://repo.saltstack.com/apt/debian/8/amd64/latest Debian 8 GNU/Linux main (jessie)

instead of:

deb http://repo.saltstack.com/apt/debian/8/amd64/latest jessie main

See: saltstack-formulas/salt-formula#270

After running 'apt-get install lsb-release', I get the following correct response:

root@salt:/srv/salt# salt-ssh -i 'uslogdcnas04.smiles.local' grains.get oscodename
uslogdcnas04.smiles.local:
    jessie
root@salt:/srv/salt# 

I think the fallback when lsb_release isn't installed is broken.

[Ch3LL]

@darkpixel how did you install salt? the lsb_release python module is installed alongside with salt-common from repo.saltstack.com

also what version of salt are you seeing this on?

[darkpixel]

I installed the salt master, salt-ssh, and installed the salt-formula for automatically installing/configuring salt on remote nodes. Then I populated /etc/salt/roster with all the nodes I wanted to bring under management and ran salt-ssh -i '*' state.highstate. ~100 nodes joined, 1 node didn't.

Looking at the ~100 nodes that joined, they all have lsb_release installed (after the fact, not sure about before), but the one node that failed to join definitely didn't have lsb_release installed. I had to manually install it, then re-run salt-ssh against it.

[bdrung]

This is a duplicate of #34423

[Ch3LL]

Thanks for bringing this to my attention @bdrung.

@darkpixel i/m going to close this issue and we can track this at that other issue