Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:Bug upgrading kismet with sudo
Date:19:26:33 03/11/2016

> Hi,
> I encounter bug when upgrading kismet with sudo, and my user account name is different from username. Found on Ubuntu 16.04.
> 1) Attempt to upgrade kismet:
> sergey@Supermedia:~$ sudo apt-get upgrade kismet
> [sudo] password for sergey:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> kismet is already the newest version (2013.03.R1b-3build1).
> Calculating upgrade... Done
> The following packages have been kept back:
> liboxideqt-qmlplugin liboxideqtcore0 liboxideqtquick0 oxideqt-codecs snapd
> ubuntu-core-launcher
> 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue? [Y/n] Y
> Setting up kismet (2013.03.R1b-3build1) ...
> usermod: user 'Sergey' does not exist <<<<<<<<<<<<<<<<<<< bug
> dpkg: error processing package kismet (--configure):
> subprocess installed post-installation script returned error exit status 6
> Errors were encountered while processing:
> kismet
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> It is trying to refer to user Sergey, but account username is sergey:
> sergey@Supermedia:~$ grep sergey /etc/passwd
> sergey:x:1000:1000:Sergey,,,:/home/sergey:/bin/bash
> It appears you are using account name instead of account username, which is different.
> This bug will happen if you will upgrade not from root, and your account username set different from account name.

If it's using the packaging from the source, then I think it may have been a typo when you entered your username - it uses the debconf db_get to prompt for usernames; it doesn't derive it from the user running the install.

If it's made using a different post-inst script, I'm not sure what they're doing.

The relevant code is in debian/ -

db_get kismet/install-users

if [ "$RET" != "" ]; then
for x in ${RET}; do
usermod -a -G $GROUP $x

which should operate entirely on the user-provided usernames...


Reply to this message