VSIDO Community

How can I run inxi as a non-root user?

Do you have the correct permission to write to your inxi.conf file?

I have never used inxi before, but usually these problems are a permission issue.

From terminal, do a

whereis inxi

If it reports either of these

inxi: /usr/sbin/inxi

/usr/local/bin/inxi

Run from terminal

/usr/sbin/inxi

or

/usr/local/bin/inxi

If either of these work then it is an environment path issue.

I can run inxi on my install without sudo, this is why I think it is a path issue

I was about to suggest permissions but falldown already had..

;D ;D

Quote from: falldown on January 17, 2013, 06:46:02 PM
Do you have the correct permission to write to your inxi.conf file?

I have never used inxi before, but usually these problems are a permission issue.

It is installed natively on VSIDO, why not try to run it and see?

@VastOne
Exactly as you described.
How can I fix this to just type inxi (-F)

EDIT: Hmm...this is odd.
Since I logged into openbox I can run inxi -F as a normal user.
In xfce4 desktop I definitely had to be root.
Any ideas?

Quote from: VastOneI was about to suggest permissions but falldown already had..

;D ;D

:D

Run

echo $PATH

and report what it shows ... My guess is that :/usr/sbin is not included in yours.. and will need to be fixed

This is mine

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/vastone/bin


neil@vsido:~$ echo $PATH
/home/neil/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/neil/bin:/sbin:/usr/sbin:/home/neil/bin


Both OB and Xfce use ~.bashrc, which is where these variables are set

Your path statement shows everything is correctly set

I am at a loss as to why it works in OB and not Xfce

You might want to run the echo $PATH in Xfce to verify

As I said, it also runs fine on my Xfce

@falldown, will you run it from Xfce to see what you get?

@VastOne
Thanks for the tips.
I will give this a try in xfce and post back on this thread ASAP.

In xfce I have to sudo it.. OB does not require sudo.

Very strange indeed.

@ mrneilypops et all

Check this out: inxi the super script - bash aliases (http://vsido.org/index.php/topic,21.0.html)

Gotta put that in my sig.  :D

@falldown
Thanks for the confirmation.

I will track this down and find the solution today

Run this in Xfce terminal

export PATH="$PATH:/sbin:/bin"

Then try to run inxi without sudo and let me know the results

Quote from: VastOne on January 18, 2013, 04:38:15 PM
Run this in Xfce terminal

Code Select Expand

export PATH="$PATH:/sbin:/bin"

Then try to run inxi without sudo and let me know the results

That took care of it for me VastOne.  In Xfce it now runs for me without root priveleges.

jed@jedsdesk:~$ export PATH="$PATH:/sbin:/bin"
jed@jedsdesk:~$ inxi
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
CPU~Dual core Intel Core i7-2640M CPU (-HT-MCP-) clocked at 800.000 Mhz Kernel~3.7-trunk-amd64 x86_64 Up~5 days Mem~629.2/7899.7MB HDD~256.1GB(28.4% used) Procs~148 Client~Shell inxi~1.8.27 
jed@jedsdesk:~$ inxi -F
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
System:    Host: jedsdesk Kernel: 3.7-trunk-amd64 x86_64 (64 bit) Desktop: Xfce 4.10.0 Distro: VSIDO
Machine:   System: Dell product: Dell System XPS 15Z
           Mobo: Dell model: N/A Bios: Dell version: A10 date: 02/20/2012
CPU:       Dual core Intel Core i7-2640M CPU (-HT-MCP-) cache: 4096 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx)
           Clock Speeds: 1: 800.00 MHz 2: 800.00 MHz 3: 800.00 MHz 4: 800.00 MHz
Graphics:  Card-1: Intel 2nd Generation Core Processor Family Integrated Graphics Controller
           Card-2: NVIDIA GF108 [GeForce GT 540M]
           X.org: 1.12.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 80x24
Audio:     Card: Intel 6 Series/C200 Series Chipset Family High Definition Audio Controller driver: snd_hda_intel
           Sound: Advanced Linux Sound Architecture ver: k3.7-trunk-amd64
Network:   Card-1: Intel Centrino Advanced-N 6230 [Rainbow Peak] driver: iwlwifi
           IF: wlan0 state: up mac: 88:53:2e:cc:f9:0c
           Card-2: Atheros AR8151 v2.0 Gigabit Ethernet driver: atl1c
           IF: eth0 state: down mac: 84:8f:69:cd:26:89
Drives:    HDD Total Size: 256.1GB (28.4% used) 1: id: /dev/sda model: LITEONIT_LCT size: 256.1GB
Partition: ID: / size: 25G used: 8.3G (37%) fs: ext4 ID: /home size: 125G used: 34G (29%) fs: ext4
           ID: swap-1 size: 4.19GB used: 0.00GB (0%) fs: swap
Sensors:   System Temperatures: cpu: 55.0C mobo: 55.0C
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 148 Uptime: 5 days Memory: 629.6/7899.7MB Runlevel: 2 Client: Shell (bash) inxi: 1.8.27
jed@jedsdesk:~$ inxi -M
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
Machine:   System: Dell product: Dell System XPS 15Z
           Mobo: Dell model: N/A Bios: Dell version: A10 date: 02/20/2012


Thanks jedi

Now I need someone in Xfce to run this sequence and post the out put one at a time

echo $PATH

export PATH="$PATH:/sbin:/bin"

echo $PATH

Works for me too;

neil@vsido:~$ export PATH="$PATH:/sbin:/bin"
neil@vsido:~$ inxi -F
System:    Host: vsido Kernel: 3.7.0-2.dmz.1-liquorix-amd64 x86_64 (64 bit) Desktop: Xfce 4.10.0 Distro: VSIDO
Machine:   Mobo: Abit model: FP-IN9 SLI(C55-MCP51) version: 1.x Bios: Phoenix version: 6.00 PG date: 12/17/2007
CPU:       Dual core Intel Core2 Duo CPU E8400 (-MCP-) cache: 6144 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3 vmx)
           Clock Speeds: 1: 1890.00 MHz 2: 1890.00 MHz
Graphics:  Card: NVIDIA G96 [GeForce 9500 GT]
           X.Org: 1.12.4 drivers: nouveau (unloaded: fbdev,vesa) Resolution: 1920x1080@60.0hz
           GLX Renderer: Gallium 0.4 on NV96 GLX Version: 2.1 Mesa 8.0.5
Audio:     Card: NVIDIA MCP51 High Definition Audio driver: snd_hda_intel Sound: ALSA ver: k3.7.0-2.dmz.1-liquorix-amd64
Network:   Card: NVIDIA MCP51 Ethernet Controller driver: forcedeth
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 00:50:8d:9e:ef:25
Drives:    HDD Total Size: 1188.3GB (1.7% used) 1: id: /dev/sda model: OCZ size: 60.0GB
           2: id: /dev/sdb model: OCZ size: 128.0GB 3: id: /dev/sdc model: WDC_WD10EADS size: 1000.2GB
Partition: ID: / size: 116G used: 9.4G (9%) fs: ext4
Sensors:   System Temperatures: cpu: 25.0C mobo: N/A gpu: 34.0
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 127 Uptime: 1 min Memory: 271.7/3952.5MB Client: Shell (bash) inxi: 1.8.27



neil@vsido:~$ echo $PATH
/home/neil/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/neil/bin:/sbin:/usr/sbin:/home/neil/bin:/sbin:/bin



neil@vsido:~$ export PATH="$PATH:/sbin:/bin"
neil@vsido:~$



neil@vsido:~$ echo $PATH
/home/neil/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/neil/bin:/sbin:/usr/sbin:/home/neil/bin:/sbin:/bin:/sbin:/bin


Here you go;

jed@jedsdesk:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/jed/bin:/sbin:/bin


jed@jedsdesk:~$ export PATH="$PATH:/sbin:/bin"
jed@jedsdesk:~$


jed@jedsdesk:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/jed/bin:/sbin:/bin:/sbin:/bin:/sbin:/bin
jed@jedsdesk:~$


@jedi, was that done on another partition that you had not run this on before?

export PATH="$PATH:/sbin:/bin"

This is very strange... all that

export PATH="$PATH:/sbin:/bin"

code is doing is adding /sbin:/bin to what is already there...

I need another test

For someone in Xfce who has not done anything yet to simply run from terminal

re

which is an alias for

source ~/.bashrc

Then try to run inxi -F again to see if that corrects it

This was on my go to partition.  I had run inxi before but in Xfce it always wanted root priveleges.  I'd never tried it in OB.  I only ran inxi out of curiousity when I read the original post.  Today I saw your response, tried it, and now no root priveleges needed.
I can log into another partition and experiment if you need me too.  Still have 3 other "test builds" installed on sda5-sda8...  And it hasn't ever been ran on them....

^^ @ VastOne

Just re-installed VSIDO - Debian kernel, XFCE4 session...
sector11@sda1-2:~$ inxi -F
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$ re
sector11@sda1-2:~$ inxi -F
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda1-2:~$

brb with OB session on same install.... wait for it please.

OpenBox Session:
sector11@sda1-2:~$ inxi -F
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda1-2:~$ re
sector11@sda1-2:~$ inxi -F
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$


Quote from: VastOne on January 18, 2013, 06:37:37 PM
This is very strange... all that

Code Select Expand

export PATH="$PATH:/sbin:/bin"

code is doing is adding /sbin:/bin to what is already there...

I need another test

For someone in Xfce who has not done anything yet to simply run from terminal

Code Select Expand

re

which is an alias for

Code Select Expand

source ~/.bashrc

Then try to run inxi -F again to see if that corrects it

In Xfce on a partition where inxi has never been run before;

jed@jedsdesk:~$ re

                                  User: jed
          _sudZUZ#Z#XZo=_         Hostname: jedsdesk
       _jmZZ2!!~---~!!X##wx       OS: Debian 7.0 x86_64
    .<wdP~~            -!YZL,     Kernel: 3.7.0-1.dmz.1-liquorix-amd64
   .mX2'       _xaaa__     XZ[.   Uptime: 0:02
   oZ[      _jdXY!~?S#wa   ]Xb;   Window Manager: Xfwm
  _#e'     .]X2(     ~Xw|  )XXc   Desktop Environment: Xfce
.2Z`      ]X[.       xY|  ]oZ(   Shell: Bash
.2#;      )3k;     _s!~   jXf`   Terminal: Xterm
  1Z>      -]Xb/    ~    __#2(    Packages: 1729
  -Zo;       +!4ZwerfgnZZXY'      CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
   *#[,        ~-?!!!!!!-~        RAM: 465 MB / 7935 MB
    XUb;.                         Disk: 68G / 231G
     )YXL,,                       
       +3#bc,                     
         -)SSL,,                 
            ~~~~~                 
                                 

jed@jedsdesk:~$ inxi -F
Error No: 1 - You must be root to run this script!


@jedi, you must have changed the re alias   ???

Quote from: VastOne on January 18, 2013, 07:17:05 PM
@jedi, you must have changed the re alias   ???

Haven't changed a thing other than archey at the bottom of .bashrc

Please post your .bashrc

If re is showing archey then something is amiss

.bashrc follows...

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar

# make less more friendly for non-text input files, see lesspipe(1)
#[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
    else
color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    #alias grep='grep --color=auto'
    #alias fgrep='fgrep --color=auto'
    #alias egrep='egrep --color=auto'
fi

# shortcut to reload the font cache
alias fontreload='fc-cache -fv'

# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi
export PATH=$PATH:/sbin:/usr/sbin:$HOME/bin
archey


Jed - "re" read your bash script and the last thing in it was a command: archey

That's why you see it.

OK, I'm going back to "my system" now.

OK, what is it that you want archey to do at the end of bashrc? For what reason?

I need your thought process on this one

Not a thing actually.  It's there because I thought it had to be in order for terminal to display the pretty debian graphic with the sys info stuff...
I can definitely remove it if you want me to test or something...

All you have to do is run archey from terminal to get it to run...

Yes, having it there has an impact on .bashrc and I would remove it

Now, to solve this, I can add a startup function in Xfce to run

export PATH="$PATH:/sbin:/bin"

on login

One other thing I would like confirmed is whether or not this command is needed after one time being run.. Meaning does a shutdown and restart keep this

And it still makes no sense at all why adding something that is already there is needed to be added again

jed@jedsdesk:~$ export PATH="$PATH:/sbin:/bin"
jed@jedsdesk:~$ inxi -F
Error No: 1 - You must be root to run this script!

also, that is after removing archey from .bashrc

@ vastOne

Did you see my post #23 in this thread?
I reinstalled VSIDO and ran the test you wanted.  I am getting "root" requirement in both XFCE4 and OB on a fresh install.

Fresh install: XFCE4
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory

Fresh install: OB
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory

here:

Quotebash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/sector11/bin: No such file or directory

something strange with the path in the fresh install on the XFCE4 side of the house!

BINGO!

Look here:
/home/sector11/bin/inxi

Looks at the sizes:
(http://t.imgbox.com/admzjuwX.jpg) (http://imgbox.com/admzjuwX)

A shutdown and restart does indeed keep it!  Runs fine for me...

I did see all posts related to this...

I am getting more and more confused by the minute.

Is it working, is it not working?

@Sector11 ... If you run this

/usr/local/bin/inxi -F

or this in either Xfce or OB

/usr/sbin/inxi -F

it does run fine without root.. It is not a size issue or anything missing... For whatever as yet to be resolved reasons, a full path is needed for it to run

Ok in xcfe to run inxi I had to sudo it.

VastOne gave this code..
export PATH="$PATH:/sbin:/bin"

So I followed direction and
falldown@VAIO:~$ export PATH="$PATH:/sbin:/bin"
falldown@VAIO:~$ inxi
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
CPU~Dual core Intel Core2 Duo CPU T8100 (-MCP-) clocked at 1200.000 Mhz Kernel~3.7.0-1.dmz.6-liquorix-amd64 x86_64 Up~6 min Mem~362.8/3951.6MB HDD~320.1GB(37.8% used) Procs~127 Client~Shell inxi~1.8.27 


So now sudo is not needed..
falldown@VAIO:~$ inxi
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
CPU~Dual core Intel Core2 Duo CPU T8100 (-MCP-) clocked at 1200.000 Mhz Kernel~3.7.0-1.dmz.6-liquorix-amd64 x86_64 Up~9 min Mem~401.6/3951.6MB HDD~320.1GB(37.8% used) Procs~127 Client~Shell inxi~1.8.27 
and sudo is not needed on restart.

I will add this as a Xfce startup variable to be run one time

export PATH="$PATH:/sbin:/bin"

Unless someone can solve why it is not running already from the .bashrc variable that is already in place

^^^ OK I see what you mean - this is my default system where a simple "inxi" in a terminal works:
sector11 @ sector11
18 Jan 13 | 17:37:25 ~
         $ /usr/local/bin/inxi -F
bash: /usr/local/bin/inxi: No such file or directory
sector11 @ sector11
18 Jan 13 | 17:37:27 ~
         $ /usr/sbin/inxi -F
Error No: 1 - You must be root to run this script!
sector11 @ sector11
18 Jan 13 | 17:38:03 ~
         $ inxi -F
System:    Host: sector11 Kernel: 3.7.0-2.dmz.1-liquorix-amd64 x86_64 (64 bit)
--- and more

When I first got it I saw it was a bash script, I never thought about it twice, I put it in ~/bin where I own it and have never had a problem with it.

That's why it works for me. I kISS'ed it (Keep It Stupidly Simple)

Since VSIDO has a ~/bin installed by default and is in your path on the fresh install I just did, why not put inxi in there and eliminate all problems in the future?

^ ^ @ VastOne

That fixes XFCE4 but what about OB?
It did not work in either on my Fresh install an hour or so ago.

Because both /usr/local/bin and /usr/sbin are also in the path by default

I also want to keep it in it's default place so that when there are updates to it there will not be any issues

I have not had any issues with /usr/local/bin which is where I store everything else.  So this is more to do with the syntax in the .bashrc than anything IMO

I just need to look at it closer and figure out what is going on

So far, you are the only one who has said it does not work in OB.

This variable works across both platforms

export PATH="$PATH:/sbin:/bin"

Meaning that when you run it in Xfce it works in OB and vice versa, it is debian specific not WM specific

Can anybody else confirm this, that it is not working in OB?

^ I'm going to reboot to the fresh install ... be right back.

I'm back in my go to partition now, so I don't know if my info will help or is even relevant.  Logged into OB mine works fine without root same as in Xfce.  Of course I've ran

export PATH="$PATH:/sbin:/bin"

so it works in Xfce and OB and I've also shut down, logged back in and it works with no issues...  (that is on my sda1 which is my go to)

As you can see by my last post in this thread, logged into my /sda7 (test install) which is my Liquorix VSIDO install, even after running the export PATH="$PATH:/sbin:/bin" it still wanted root...  So, I'm confused too.  Works in one install, but not the other?  How weird is that?

Fresh install of:
VSIDO Debian kernel 3.7-1
VSIDO kernel 3.7-1 - Latest Upload 10JAN2013 12:30 CST
ONLY change, I brought ~/.mozilla over to get my bookmarks.

Currently in OpenBox session.
/home/sector11/bin is empty
(http://t.imgbox.com/aclNce62.jpg) (http://imgbox.com/aclNce62) (http://t.imgbox.com/acmUUXFS.jpg) (http://imgbox.com/acmUUXFS)

sector11@sda1-2:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda1-2:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$

sector11@sda1-2:~$ export PATH="$PATH:/sbin:/bin"
sector11@sda1-2:~$ re
sector11@sda1-2:~$ inxi -F
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$ /usr/local/bin/inxi -F
bash: /usr/local/bin/inxi: No such file or directory
sector11@sda1-2:~$ /usr/sbin/inxi -F
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$


As you see: sector11@sda1-2 <<--- partition 1&2 - the 100% fresh install.

Could it be that there is something different between the three ISO's ??
OR - as I see from Jed's post above (I got a warning) -- maybe it is a kernel related thing.

grabbing at straws now ... I will stay in this Debian "TRUNK" version for now to TEST ... tell me what else I can to.

Why is it only 14k? Mine is 303k

Have you ran smxi on this setup yet?

smxi and inxi and all of the smxi scripts are just a placeholder for a setup until you run smxi the first time.  It then goes out and grabs and installs all of the smxi scripts

I wonder if this is the entire issue on newer installs

^ No this is a 100% fresh install - no welcome script - no smxi script have been run.
You got inxi via smxi?

If so that might be a part of the problem.

Yes, inxi is part of the smxi scripts.  That is the only way it is installed in VSIDO

Quote from: VastOne on January 18, 2013, 10:40:47 PM
Yes, inxi is part of the smxi scripts.  That is the only way it is installed in VSIDO

Well, if you look back a few posts your see that in my default setup, inxi is only 14k there as well, "except" for the version that I brought over from my backup that has the script in ~/bin.

I have never seen the inxi script in smxi, all I have ever done there is get a kernel and nvidia drivers.

I originally grabbed the deb here:

http://code.google.com/p/inxi/wiki/Installation

For debian systems use cathbards repo:

wget ftp://cathbard.com/binary/inxi*.deb

Or if you have cathbards repos ( add cathbard repos ) in your apt sources.list:

apt-get update && apt-get install inxi

sector11@sda1-2:~$ wget ftp://cathbard.com/binary/inxi*.deb
--2013-01-18 19:47:42--  ftp://cathbard.com/binary/inxi*.deb
           => '.listing'
Resolving cathbard.com (cathbard.com)... 178.77.75.34
Connecting to cathbard.com (cathbard.com)|178.77.75.34|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /binary ... done.
==> PASV ... done.    ==> LIST ... done.

    [    <=>                                ] 19,611      25.4KB/s   in 0.8s   

2013-01-18 19:47:47 (25.4 KB/s) - '.listing' saved [19611]

Removed '.listing'.
--2013-01-18 19:47:47--  ftp://cathbard.com/binary/inxi_1.8.4-1_all.deb
           => 'inxi_1.8.4-1_all.deb'
==> CWD not required.
==> PASV ... done.    ==> RETR inxi_1.8.4-1_all.deb ... done.
Length: 115066 (112K)

100%[======================================>] 115,066     74.8KB/s   in 1.5s   

2013-01-18 19:47:50 (74.8 KB/s) - 'inxi_1.8.4-1_all.deb' saved [115066]

sector11@sda1-2:~$

Again, there is no need to install inxi, it is and has always been part of the smxi scripts

I only grabbed it to look at the bash script - it is the same.

I am running "up" now ... then will run smxi to get inxi

Upgrading 71 getting 2 ... this could take a bit.

Where do I find it in smxi?

OK up is done now ...

Where do I find it in smxi? - as I said I have never seen it there.

Hello!!!

It is not 'in' smxi anywhere

smxi is a series of scripts that include the smxi, sgfxi, svmi, rbxi, and inxi scripts.  Each of these are separate scripts all packaged together when you install smxi

The smxi in VSIDO is a stub installer, a script in place to run and install the first time smxi is run on a system  Here is info on the stub installer (http://smxi.googlecode.com/svn/trunk/smxi-stub/smxi-stub)

I could not run and then package smxi because it would take on my settings for everyone and that is not a good idea.  The stub installer is perfect

I will write that up in the install notes and the Install How To

Sorry I did not get back to you right away, I had to eat.

Quote from: VastOne on January 18, 2013, 11:53:49 PM
Sorry I did not get back to you right away, I had to eat.

Yea we have to do that on occasion  :D

And your explanation tells me exactly why root is needed.  Root is needed for; smxi, sgfxi, svmi, rbxi so it would stands to reason that it would be required for inxi as well.

I just installed the Nvidia driver via smxi (twice to get rid of nouveau) - it did NOT install inxi!

sector11@sda1-2:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$

Looks like smxi did not install it search after running smxi:
(http://t.imgbox.com/adqiBOrV.jpg) (http://imgbox.com/adqiBOrV)

sector11@sda1-2:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin
sector11@sda1-2:~$ export PATH="$PATH:/sbin:/bin"
sector11@sda1-2:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin:/sbin:/bin
sector11@sda1-2:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$ re
sector11@sda1-2:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$

/lib/live/mount/rootfs/filesystem.squashfs/usr/sbin/inxi
#!/bin/bash
########################################################################
####  Script Name: smxi-stub
####  stub installer for smxi scripts
####  Only supports true Debian based distros.
####  version: 3.0
####  Date: 24 February 2010
########################################################################
####  Copyright (C) Harald Hope, sidux team members 2007-2010
####
####  This program is free software; you can redistribute it and/or modify it under
####  the terms of the GNU General Public License as published by the Free Software
####  Foundation; either version 2 of the License, or (at your option) any later version.
####
####  This program is distributed in the hope that it will be useful, but WITHOUT
####  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
####  FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
####
####  Get the full text of the GPL here: http://www.gnu.org/licenses/gpl.txt
########################################################################

# Please do not change the logic here, it makes it too hard to read linearly:
# [ ! -f somefile ] && do something is far easier to read than [ -f somefile ] || do something
# tempfile primary cleanup is now handled by called scripts, so no need to complicate this
# simple stub with the cleanup stuff. Now it just cleans up after itself each time.

# To get the full power and user friendliness for this stub installer
# rename it to: smxi
# place it in /usr/sbin, that is, as /usr/sbin/smxi, make it executable: chmod +x /usr/sbin/smxi
# add the following symbolic links in /usr/sbin pointing to /usr/sbin/smxi:
# ln -s /usr/sbin/smxi /usr/sbin/inxi
# ln -s /usr/sbin/smxi /usr/sbin/sgfxi
# ln -s /usr/sbin/smxi /usr/sbin/svmi
# because of how default $PATH works, /usr/sbin will always be checked first for the
# scripts, and if they are missing, this stub will download and execute them, otherwise
# the request will simply be passed along to /usr/local/bin location of actual scripts

# this will handle stub for any other script also
CALLER="$( basename $0 )"
PREFIX='/usr/local/bin/'
DOWNLOAD_URL=''
DOWNLOAD_URL_INXI='http://inxi.googlecode.com/svn/trunk/'
DOWNLOAD_URL_SGFXI='http://smxi.org/sg/'
DOWNLOAD_URL_SMXI='http://smxi.org/sm/'
DOWNLOAD_URL_SVMI='http://smxi.org/sv/'
FILE_DATA_TEMP='' # will handle failed downloads
IS_GOOD=''
# this is the tester for ##**EOF**## endings present in scripts, change this
# if you want to extend this stub to other scripts, smxi/svmi/inxi/sgfxi all use this
SCRIPT_EOF='##\*\*EOF\*\*##'

# args: $1 - error number; $2 - extra data
error_handler()
{
local message=''
case $1 in
1) message='You must be root to run this script!'
;;
2) message="Script download exited with errors.\nThe following download url failed with wget error: $2/n$DOWNLOAD_URL$SCRIPT"
;;
3) message='Failed to download script properly. The file data is corrupted or incomplete!'
;;
4) message="$PREFIX$SCRIPT exec command failed with error number: $2\nPlease try again."
;;
5) message="$PREFIX$SCRIPT not executable!"
;;
6) message="Unknown script requested: $CALLER"
;;
*) message='Unknown error, exiting now.'
;;
esac
echo -e "Error No: $1 - $message"
exit $1
}

# set the SCRIPT/DOWNLOAD_URL/SCRIPT_EOFvalues
case $CALLER in
sgfxi)
SCRIPT="$CALLER"
DOWNLOAD_URL=$DOWNLOAD_URL_SGFXI
;;
smxi)
SCRIPT="$CALLER"
DOWNLOAD_URL=$DOWNLOAD_URL_SMXI
;;
svmi)
SCRIPT="$CALLER"
DOWNLOAD_URL=$DOWNLOAD_URL_SVMI
;;
inxi)
SCRIPT="$CALLER"
DOWNLOAD_URL=$DOWNLOAD_URL_INXI
;;
*)
error_handler 6
;;
esac

# if $SCRIPT exists, it will handle the root tests. Root tests cannot
# be run first because they kill the -h help function
if [ -x "$PREFIX$SCRIPT" ];then
# I'm just going to put a test for basically everything that can go wrong
exec "$PREFIX$SCRIPT" "$@" || error_handler 4 "$?"
else
# only in case of requirement to download script do root test, and just exit
# if not root, anything else is counterintuitive I think for users.
if [ "$( id -u )" -ne 0 ];then
error_handler 1
fi
# downloading to overwrite existing file, but to temp variable, which we then test
FILE_DATA_TEMP="$( wget -q -O - $DOWNLOAD_URL$SCRIPT )" || error_handler 2 "$?"
IS_GOOD=$( grep -si "$SCRIPT_EOF" <<< "$FILE_DATA_TEMP" )
# test to make sure downloaded data has EOF marker, if yes, it's complete
if [ -z "$IS_GOOD" ];then
error_handler 3
else
# now that the data is tested and not corrupted move to real file
echo "$FILE_DATA_TEMP" > $PREFIX$SCRIPT
# make new file executable
chmod 705 "$PREFIX$SCRIPT"
# then run it with an error handler for unknown weirdness which I'm sure will appear.
if [ -x "$PREFIX$SCRIPT" ];then
# If for some reason it errors on script execution, exit here, but that could be
# something as simple as bad options used
exec "$PREFIX$SCRIPT" "$@" || error_handler 4 "$?"
else
error_handler 5
fi
fi
fi


/usr/sbin/inxi
#!/bin/bash
########################################################################
####  Script Name: smxi-stub
####  stub installer for smxi scripts
####  Only supports true Debian based distros.
####  version: 3.0
####  Date: 24 February 2010
########################################################################
####  Copyright (C) Harald Hope, sidux team members 2007-2010
####
####  This program is free software; you can redistribute it and/or modify it under
####  the terms of the GNU General Public License as published by the Free Software
####  Foundation; either version 2 of the License, or (at your option) any later version.
####
####  This program is distributed in the hope that it will be useful, but WITHOUT
####  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
####  FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
####
####  Get the full text of the GPL here: http://www.gnu.org/licenses/gpl.txt
########################################################################

# Please do not change the logic here, it makes it too hard to read linearly:
# [ ! -f somefile ] && do something is far easier to read than [ -f somefile ] || do something
# tempfile primary cleanup is now handled by called scripts, so no need to complicate this
# simple stub with the cleanup stuff. Now it just cleans up after itself each time.

# To get the full power and user friendliness for this stub installer
# rename it to: smxi
# place it in /usr/sbin, that is, as /usr/sbin/smxi, make it executable: chmod +x /usr/sbin/smxi
# add the following symbolic links in /usr/sbin pointing to /usr/sbin/smxi:
# ln -s /usr/sbin/smxi /usr/sbin/inxi
# ln -s /usr/sbin/smxi /usr/sbin/sgfxi
# ln -s /usr/sbin/smxi /usr/sbin/svmi
# because of how default $PATH works, /usr/sbin will always be checked first for the
# scripts, and if they are missing, this stub will download and execute them, otherwise
# the request will simply be passed along to /usr/local/bin location of actual scripts

# this will handle stub for any other script also
CALLER="$( basename $0 )"
PREFIX='/usr/local/bin/'
DOWNLOAD_URL=''
DOWNLOAD_URL_INXI='http://inxi.googlecode.com/svn/trunk/'
DOWNLOAD_URL_SGFXI='http://smxi.org/sg/'
DOWNLOAD_URL_SMXI='http://smxi.org/sm/'
DOWNLOAD_URL_SVMI='http://smxi.org/sv/'
FILE_DATA_TEMP='' # will handle failed downloads
IS_GOOD=''
# this is the tester for ##**EOF**## endings present in scripts, change this
# if you want to extend this stub to other scripts, smxi/svmi/inxi/sgfxi all use this
SCRIPT_EOF='##\*\*EOF\*\*##'

# args: $1 - error number; $2 - extra data
error_handler()
{
local message=''
case $1 in
1) message='You must be root to run this script!'
;;
2) message="Script download exited with errors.\nThe following download url failed with wget error: $2/n$DOWNLOAD_URL$SCRIPT"
;;
3) message='Failed to download script properly. The file data is corrupted or incomplete!'
;;
4) message="$PREFIX$SCRIPT exec command failed with error number: $2\nPlease try again."
;;
5) message="$PREFIX$SCRIPT not executable!"
;;
6) message="Unknown script requested: $CALLER"
;;
*) message='Unknown error, exiting now.'
;;
esac
echo -e "Error No: $1 - $message"
exit $1
}

# set the SCRIPT/DOWNLOAD_URL/SCRIPT_EOFvalues
case $CALLER in
sgfxi)
SCRIPT="$CALLER"
DOWNLOAD_URL=$DOWNLOAD_URL_SGFXI
;;
smxi)
SCRIPT="$CALLER"
DOWNLOAD_URL=$DOWNLOAD_URL_SMXI
;;
svmi)
SCRIPT="$CALLER"
DOWNLOAD_URL=$DOWNLOAD_URL_SVMI
;;
inxi)
SCRIPT="$CALLER"
DOWNLOAD_URL=$DOWNLOAD_URL_INXI
;;
*)
error_handler 6
;;
esac

# if $SCRIPT exists, it will handle the root tests. Root tests cannot
# be run first because they kill the -h help function
if [ -x "$PREFIX$SCRIPT" ];then
# I'm just going to put a test for basically everything that can go wrong
exec "$PREFIX$SCRIPT" "$@" || error_handler 4 "$?"
else
# only in case of requirement to download script do root test, and just exit
# if not root, anything else is counterintuitive I think for users.
if [ "$( id -u )" -ne 0 ];then
error_handler 1
fi
# downloading to overwrite existing file, but to temp variable, which we then test
FILE_DATA_TEMP="$( wget -q -O - $DOWNLOAD_URL$SCRIPT )" || error_handler 2 "$?"
IS_GOOD=$( grep -si "$SCRIPT_EOF" <<< "$FILE_DATA_TEMP" )
# test to make sure downloaded data has EOF marker, if yes, it's complete
if [ -z "$IS_GOOD" ];then
error_handler 3
else
# now that the data is tested and not corrupted move to real file
echo "$FILE_DATA_TEMP" > $PREFIX$SCRIPT
# make new file executable
chmod 705 "$PREFIX$SCRIPT"
# then run it with an error handler for unknown weirdness which I'm sure will appear.
if [ -x "$PREFIX$SCRIPT" ];then
# If for some reason it errors on script execution, exit here, but that could be
# something as simple as bad options used
exec "$PREFIX$SCRIPT" "$@" || error_handler 4 "$?"
else
error_handler 5
fi
fi
fi


OK what do you want me to do now?

As several people have shown today inxi does not need root to run.  This is a path/environment issue

We have a temp solution now that a person can run

export PATH="$PATH:/sbin:/bin"

or you can run

inxi: /usr/sbin/inxi

/usr/local/bin/inxi

and that will run it... a person could even create a alias if they wanted to

I am on a system that I used to the latest VSIDO installer with and I have never installed inxi, it comes with the smxi installation that is part of VSIDO

All those packages you are finding verify that.

This is not a pressing issue right now, I just need some time to focus on it.. of which right now I do not have.

sector11@sda1-2:~$ export PATH="$PATH:/sbin:/bin"
sector11@sda1-2:~$ re
sector11@sda1-2:~$ inxi: /usr/sbin/inxi
bash: inxi:: command not found
sector11@sda1-2:~$ /usr/local/bin/inxi
bash: /usr/local/bin/inxi: No such file or directory
sector11@sda1-2:~$

OK I stop as well.
It is not here, smxi did not get it.  I wonder if it because I didn't allow smxi to "downgrade" the kernel.

I'll try installing the liquorix version. On sda10 & 11

No panic.

It has nothing to do with the kernel

run this

whereis inxi

Quote from: VastOne on January 19, 2013, 12:32:46 AM
It has nothing to do with the kernel

run this

Code Select Expand

whereis inxi

I am now on:
    VSIDO Liquorix Kernel 3.7.0-6
    VSIDO Liquorix Kernel 3.7.0-6 - Latest Upload 06JAN2013 20:58 CST

Ran smxi twice to get rid of "nouveau" liquorix updated and nvidia added.

sector11@sda10-11:~$ whereis inxi
inxi: /usr/sbin/inxi /usr/share/man/man1/inxi.1.gz
sector11@sda10-11:~$

That looks promising ... I am in OB:
sector11@sda10-11:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda10-11:~$

OK, next:
sector11@sda10-11:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda10-11:~$ export PATH="$PATH:/sbin:/bin"
sector11@sda10-11:~$ re
sector11@sda10-11:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin:/sbin:/bin:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda10-11:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda10-11:~$

Hmmmm reboot I believe I read.
BRB

No go:
sector11@sda10-11:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda10-11:~$

but it is here:
sector11@sda10-11:~$ sudo inxi
[sudo] password for sector11:
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
CPU~Triple core AMD Athlon II X3 450 (-MCP-) clocked at 3214.616 Mhz Kernel~3.7.0-2.dmz.1-liquorix-amd64 x86_64 Up~2 min Mem~333.9/5962.4MB HDD~250.1GB(3.1% used) Procs~121 Client~Shell inxi~1.8.28 
sector11@sda10-11:~$

I must be junxed.

No - not me, OpenBox ... I changed sessions:
Now in XFCE4

sector11@sda10-11:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda10-11:~$ export PATH="$PATH:/sbin:/bin"
sector11@sda10-11:~$ re
sector11@sda10-11:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin:/sbin:/bin:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda10-11:~$ inxi
Resuming in non X mode: glxinfo not found. For package install advice run: inxi --recommends
CPU~Triple core AMD Athlon II X3 450 (-MCP-) clocked at 3214.616 Mhz Kernel~3.7.0-2.dmz.1-liquorix-amd64 x86_64 Up~6 min Mem~167.4/5962.4MB HDD~250.1GB(3.1% used) Procs~118 Client~Shell inxi~1.8.28 
sector11@sda10-11:~$

Now I go back to OB and it works just fine.

So the problem is OB playing nice.

I'm going back to SDA1-2  for a bit...

Back on SDA1-2
Does not work at all.
I am in XFCE4:
sector11@sda1-2:~$ whereis inxi
inxi: /usr/sbin/inxi /usr/share/man/man1/inxi.1.gz
sector11@sda1-2:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda1-2:~$ export PATH="$PATH:/sbin:/bin"
sector11@sda1-2:~$ re
sector11@sda1-2:~$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/home/sector11/bin:/sbin:/bin:/sbin:/usr/sbin:/home/sector11/bin: No such file or directory
sector11@sda1-2:~$ inxi
Error No: 1 - You must be root to run this script!
sector11@sda1-2:~$


OK, end it for tonight....

I finally found time to install a new VSIDO setup and have found the issue and now know what has been causing inxi to need sudo to run

inxi is part of smxi script package and now is a symlink to smxi instead of being it's own file, which is why Sector11 kept seeing it as a 14k file.. that is the size of the symlink

This requires running inxi as sudo because that is a smxi requirement. 

Solution - You can get the independent version of inxi and place it in your path and never have to use sudo again. The issue with this is it will never be updated, unless you go out and update it manually. This is an issue because it was updated just today within smxi

The VSIDO solution is to keep it just as it is, within the smxi scripts as a symlink and will require sudo to run it.  This will guarantee that inxi will stay updated.  I would recommend an alias of sudo inxi so that you only have to enter your password when you run it.

I think what has changed just recently is that smxi changed it from a full install of inxi to the symlink model.

At least I now know what is going on...

@Sector11 - Thanks for all your help on this!