--- In
nslu2-linux@..., "Mike Westerhof (mwester)" <mwester@...> wrote:
>
> slackline wrote:
> > Turns out the original errors were because /usr/sbin/ (and /sbin) were not in root's $PATH environment despite /etc/profile having them listed for root.
>
> Can you please investigate this a bit more? This is a serious problem;
> if this happens auto-magically as a result of installing either native
> or optware packages, we must fix this ASAP. On the other hand, if this
> is a result of "pilot error", a note on the wiki would be important.
>
> For SlugOS, not much will work correctly if you don't have /sbin and
> /usr/sbin in the root's $PATH, and its also worth noting that those
> directories must appear before /opt/sbin or /opt/usr/sbin, if the latter
> appear at all.
I expect (as with most things) its down to pilot error. These are the steps I took.
I modified the PATH="" in my /etc/profile after I (manually) installed the optware feed. I added /opt/bin to the end...
PATH="/usr/local/bin:/usr/bin:/bin:/opt/bin"
...so that I could use the optware installed transmission as user (sometimes I ssh in to add torrents) and then for root there was...
if [ "`id -u`" -eq 0 ]; then
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin
fi
After discovering /sbin and /usr/sbin were no longer in $PATH with the above I then went on to modify the lines to...
PATH="/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/sbin:/sbin"
if [ "`id -u`" -eq 0 ]; then
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin:/opt/bin/sbin:/opt/usr/sbin:/opt/usr/local/sbin
fi
(I realise its insecure to have /sbin and /usr/sbin in normal users $PATH, but it didn't seem to be picking them up in the root section so I added them there).
You say that having /opt/sbin and/or /opt/usr/sbin before /sbin and /usr/sbin would be a problem, could it be that this is also true if /opt/bin is defined before /sbin and /usr/sbin ?
Showing my ignorance here, but why does the order matter? If the shell can't find the command in the first path it searches it moves onto the next, then the next doesn't it?
> > However, I now get an error message that portmap can't be started...
>
> Yep. Expected... it's an ordering issue. If you install portmap first,
> then start it (manually, or reboot), then install nfs-utils, all is
> well. But I find that too much effort; I just install it, ignore the
> errors that you detail below, and reboot. All should be well after a
> reboot.
>
> (And yes, this is a bug in the install/startup scripts for nfs.)
>
Looks good, /etc/init.d/nfsserver restart seemed to do the trick and there weren't any complaints. I rebooted just to make sure too. Although the /etc/exports file I copied over from the 4.8 install now results in...
# /etc/init.d/netmount restart
* Unmounting network filesystems... [ ok ]
* Mounting network filesystems...
mount.nfs: access denied by server while mounting slug:/media/sda5
mount.nfs: access denied by server while mounting slug:/media/sda6
mount.nfs: access denied by server while mounting slug:/media/sda7
mount.nfs: access denied by server while mounting slug:/media/sdb1
mount.nfs: access denied by server while mounting slug:/media/sdb2
mount.nfs: access denied by server while mounting slug:/media/sdb3
mount.nfs: access denied by server while mounting slug:/media/sdb5
mount.nfs: access denied by server while mounting slug:/media/sdb6
mount.nfs: access denied by server while mounting slug:/media/sdb7
mount.nfs: access denied by server while mounting slug:/media/sdb8
* Could not mount all network filesystems [ !! ]
...when I try and mount the partitions on my desktop, but I suspect this may have something to do with the permissions the drives are being mounted as and/or the busybox issue I had).
> Peruse the mailing list archives; you will want to disable the SlugOS
> "automount" facility (/etc/udev/something-or-other). Then mount your
> partitions by UUID instead of /dev/sd* -- this will avoid much pain and
> sadness.
Will search the archives on the above, have a poke around and see if I can solve it.
Hope the above on PATH is useful and thanks for taking the time to reply.
Cheers,
Neil