You are not logged in.
Pages: 1
Hi
I run to get:
# cat /etc/devuan_version && cat /etc/debian_version
jessie
9.2
It doesnt return ascii.
Thankyou
Last edited by makh (2017-12-18 07:02:49)
HP Probook 440 G2: Arch, Debian Stable
Others: Devuan, Centos, Ubuntu, Opensuse
GUI: Openbox, Xfce, Cinnamon
Chroot: Debian, Ubuntu, Fedora
Offline
For what its worth...
In Ceres,
# cat /etc/devuan_version && cat /etc/debian_version
ascii/ceres
cat: /etc/debian_version: No such file or directory
Offline
Running lsb_release gives this (I'm running ascii):
sgage@ascii:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Devuan
Description: Devuan GNU/Linux ascii
Release: ascii
Codename: n/a
sgage@ascii:~$
I think it should be Release: 2.0 and Codename: ascii.
Last edited by sgage (2017-12-06 12:23:20)
Offline
Hi!
I had the same problem of no-root buggy outputs of lsb_release on my devuan2 real and virtual machines upgraded from devuan1 and debian7.
As I noticed that problem does not concern freshly installed devuan2 machines, I made investigations and... I have just found how to fix it :
chmod 755 /var/lib/apt/lists
---
For information, I share the details of my investigations here:
That bug does not concern fresh installed devuan2 from DVD:
demo@fresh_installed_devuan2:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Devuan
Description: Devuan GNU/Linux 2.0 (ascii)
Release: 2.0
Codename: ascii
But it concerns upgraded devuan2 machines when lsb_release is executed with no root permission:
demo@upgraded_devuan2:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Devuan
Description: Devuan GNU/Linux ascii
Release: ascii
Codename: n/a
Comparison between upgraded and fresh_installed devuan2:
I have compared the base-files package files + the script /usr/bin/lsb_release between my machines, but I found no difference.
Comparison between root and no root execution of lsb_release on an upgraded devuan2:
As /usr/bin/lsb_release imports /usr/lib/python2.7/dist-packages/lsb_release.py, I decided to compare the execution of its function guess_devuan_release() between root and no root execution on an upgraded devuan2:
root@upgraded_devuan2:~# python
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lsb_release
>>> lsb_release.guess_devuan_release()
{'DESCRIPTION': u'Devuan GNU/Linux 2.0 (ascii)', 'RELEASE': u'2.0', 'CODENAME': 'ascii', 'OS': 'GNU/Linux', 'ID': 'Devuan'}
demo@upgraded_devuan2:~$ python
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lsb_release
>>> lsb_release.guess_devuan_release()
{'RELEASE': 'ascii', 'OS': 'GNU/Linux', 'ID': 'Devuan', 'DESCRIPTION': 'Devuan GNU/Linux ascii'}
Going on deeper within that script, I found out that:
/etc/devuan_version remains buggy in devuan2 (ascii instead of 2)
Unnoticed indent error: from line #321 to #334 of lsb_release.py (lsb-release 4.1+devuan2), the function guess_devuan_release() uses mixed 2 and 4 spaces indent instead of the 4 ones used in the rest of the script
rinfo = guess_release_from_apt()
if rinfo:
release = rinfo.get('version')
if release:
codename = lookup_codename(release, 'n/a')
else:
release = rinfo.get('suite', 'unstable')
if release == 'testing':
# Would be nice if I didn't have to hardcode this.
codename = TESTING_CODENAME
else:
codename = 'ceres'
distinfo.update({ 'RELEASE' : release, 'CODENAME' : codename })
Called by guess_devuan_release(), the function parse_apt_policy() of lsb_release.py executes in a sub-shell the command 'env LC_ALL=C apt-cache policy'
Then, I suspected /usr/bin/apt-cache. Indeed, it fails with no root permission:
demo@upgraded_devuan2:~$
Package files:
100 /var/lib/dpkg/status
release a=now
Pinned packages:
demo@upgraded_devuan2:~$
What's broken with apt?
I reinstalled the package apt. But this makes no change.
Debugging this re-installation with apt-get -o Debug::RunScript -o Debug::pkgAcquire::Worker -o Debug::pkgAcquire::Auth -y --reinstall install apt, I saw nothing interesting.
The perms and ownerships of /etc/apt/sources.list and /etc/apt/sources.list.d/* looked normal.
So as a last resort, I decided to check the execution of /usr/bin/apt-cache with strace :
demo@upgraded_devuan2:~$ strace -x -e trace=open,close,read,write -o apt-cache_strace_demo.log env LC_ALL=C apt-cache policy
root@upgraded_devuan2:~# strace -x -e trace=open,close,read,write -o apt-cache_strace_root.log env LC_ALL=C apt-cache policy
root@upgraded_devuan2:~# grep "Permission denied" apt-cache_strace_root.log
demo@upgraded_devuan2:~$ grep "Permission denied" apt-cache_strace_demo.log
open("/var/lib/apt/lists/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
...
Never was so close to the truth:
demo@upgraded_devuan2:~$ stat /var/lib/apt/lists
Fichier : /var/lib/apt/lists
Taille : 4096 Blocs : 8 Blocs d'E/S : 4096 répertoire
Périphérique : fe00h/65024d Inœud : 1047578 Liens : 3
Accès : (0770/drwxrwx---) UID : ( 0/ root) GID : ( 0/ root)
demo@fresh_installed_devuan2:~$ stat /var/lib/apt/lists
Fichier : /var/lib/apt/lists
Taille : 4096 Blocs : 8 Blocs d'E/S : 4096 répertoire
Périphérique : 801h/2049d Inœud : 260613 Liens : 3
Accès : (0755/drwxr-xr-x) UID : ( 0/ root) GID : ( 0/ root)
Obviously, the only problem that prevented apt-cache to run correctly as a no-root user, with side effects on lsb_release is a directory permission.
Then I fixed it:
chmod 755 /var/lib/apt/lists
Hope this can help.
Last edited by voomto (2018-08-24 01:04:15)
Offline
Pages: 1