Loading ...
Sorry, an error occurred while loading the content.

Re: [nslu2-linux] Re: SlugOS 4.8 -> 5.3 upgrade

Expand Messages
  • Mike Westerhof (mwester)
    ... 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
    Message 1 of 9 , Jun 30, 2009
    • 0 Attachment
      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.

      > 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.)

      > # opkg install nfs-utils portmap --force-reinstall
      > Reinstalling nfs-utils (1.1.2-3) on root...
      > Downloading http://ipkg.nslu2-linux.org/feeds/slugosbe/cross/5.3-beta/nfs-utils_1.1.2-3_armv5teb.ipk
      > Reinstalling portmap (6.0-r3) on root...
      > Downloading http://ipkg.nslu2-linux.org/feeds/slugosbe/cross/5.3-beta/portmap_6.0-r3_armv5teb.ipk
      > Configuring nfs-utils
      > System startup links for /etc/init.d/nfsserver already exist.
      > stopping mountd: done
      > stopping statd: done
      > starting mountd: Cannot register service: RPC: Unable to receive; errno = Connection refused
      > done
      > starting statd: done
      > Configuring portmap
      > System startup links for /etc/init.d/portmap already exist.
      >
      >
      > Will report back when I've solved this too.
      >
      >> (The /media/sdb* errors are due to the HD being tempramental, plugging it into the desktop solved this in the past, something to do with the cable, or ultimately an excuse to get another HD).

      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.

      > Sorted this, power-cycling and plugging into the desktop then repeating and plugging back into slug sorted it.
      >
      > Neil

      Mike (mwester)
    • slackline
      ... 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
      Message 2 of 9 , Jul 1, 2009
      • 0 Attachment
        --- In nslu2-linux@yahoogroups.com, "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
      • slackline
        ... Okay, had a chance to dig around and sort this out. Found a few pointers in the archives (some here
        Message 3 of 9 , Jul 6, 2009
        • 0 Attachment
          --- In nslu2-linux@yahoogroups.com, "slackline" <nshephard@...> wrote:
          >
          > > 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.
          >

          Okay, had a chance to dig around and sort this out.

          Found a few pointers in the archives (some here http://tech.groups.yahoo.com/group/nslu2-linux/message/21936 some mirrored on nabble http://www.nabble.com/SlugOS-5.3,-Memstick---HDD----device-name-confusion-(sda---sdb)-td23927062.html ).

          I listed the UUID of my HD' using the following...

          # ls -lha /dev/disk/by-uuid/
          drwxr-xr-x 2 root root 280 Jul 6 18:51 .
          drwxr-xr-x 3 root root 60 Jul 6 18:45 ..
          lrwxrwxrwx 1 root root 10 Jul 6 18:51 1a823ba7-2374-4217-92d9-acf0ab26bd94 -> ../../sdb5
          lrwxrwxrwx 1 root root 10 Jul 6 18:51 282acb86-7e36-4958-bcda-37d2dc82d3e6 -> ../../sdb8
          lrwxrwxrwx 1 root root 10 Jul 6 18:51 39f901a5-e345-4198-8af3-648bee321a20 -> ../../sdb2
          lrwxrwxrwx 1 root root 10 Jul 6 18:45 3d5fad71-9aea-4ce4-89ee-6017fc479eca -> ../../sda7
          lrwxrwxrwx 1 root root 10 Jul 6 18:51 3db6ca09-c7f3-4204-bab8-3fdda5a52da9 -> ../../sdb3
          lrwxrwxrwx 1 root root 10 Jul 6 18:45 4c375f41-e91d-4fe3-aadb-6ac7f312c4db -> ../../sda3
          lrwxrwxrwx 1 root root 10 Jul 6 18:45 4c56a407-97fd-491c-9032-c5068a8f1f16 -> ../../sda1
          lrwxrwxrwx 1 root root 10 Jul 6 18:45 55f82e1f-8fc1-479f-bbae-06611eb40142 -> ../../sda6
          lrwxrwxrwx 1 root root 10 Jul 6 18:51 a0dc2378-713c-4baf-8a68-bdd6da270436 -> ../../sdb6
          lrwxrwxrwx 1 root root 10 Jul 6 18:51 aa5f1bb9-573d-40e2-b001-d0d3336e852f -> ../../sdb1
          lrwxrwxrwx 1 root root 10 Jul 6 18:51 e6657696-2cfe-48f1-98b0-802e8eb18c1c -> ../../sdb7
          lrwxrwxrwx 1 root root 10 Jul 6 18:45 f1909c33-a679-4c39-967b-2a8a246e5b38 -> ../../sda5


          Then wrote my /etc/fstab to reflect this...

          #/dev/sda3 / ext3 defaults 1 1
          ## /dev/sda1
          UUID=4c56a407-97fd-491c-9032-c5068a8f1f16 /mnt/backup ext3 deafults 1 2
          ## /dev/sda2 (swap)
          #UUID=
          ## /dev/sda3
          UUID=4c375f41-e91d-4fe3-aadb-6ac7f312c4db / ext3 defaults 1 1
          ## /dev/sda5
          UUID=f1909c33-a679-4c39-967b-2a8a246e5b38 /mnt/portage ext3 defaults 1 3
          ## /dev/sda6
          UUID=55f82e1f-8fc1-479f-bbae-06611eb40142 /mnt/torrents ext3 defaults 1 4
          ## /dev/sda7
          UUID=3d5fad71-9aea-4ce4-89ee-6017fc479eca /mnt/albums ext3 defaults 1 5
          ## /dev/sdb1
          UUID=aa5f1bb9-573d-40e2-b001-d0d3336e852f /mnt/music ext3 defaults 1 1
          ## /dev/sdb2
          UUID=39f901a5-e345-4198-8af3-648bee321a20 /mnt/video ext3 defaults 1 1
          ## /dev/sdb3
          UUID=3db6ca09-c7f3-4204-bab8-3fdda5a52da9 /mnt/pics ext3 defaults 1 1
          ## /dev/sdb5
          UUID=1a823ba7-2374-4217-92d9-acf0ab26bd94 /mnt/doc ext3 defaults 1 1
          ## /dev/sdb6
          UUID=a0dc2378-713c-4baf-8a68-bdd6da270436 /mnt/work1 ext3 defaults 1 1
          ## /dev/sdb7
          UUID=e6657696-2cfe-48f1-98b0-802e8eb18c1c /mnt/work2 ext3 defaults 1 1
          ## /dev/sdb8
          UUID=282acb86-7e36-4958-bcda-37d2dc82d3e6 /mnt/ref ext3 defaults 1 1


          The above links pointed me to root around in /etc/udev/rules.d and in /etc/udev/rules.d/local.rules I commented out the two following lines so that the block devices weren't automounted..

          # Media automounting
          #SUBSYSTEM=="block", ACTION=="add" RUN+="/etc/udev/scripts/mount.sh"
          #SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"

          ...and that seems to have worked as the /dev/sda is all mounted fine on reboot (/dev/sdb had to be plugged into the desktop then back into the NSLU2, think I might take the hint of a new USB cable).

          However, I can't seem to mount the file systems via NFS on my desktop. I adjusted the paths in /etc/exports to reflect the mount points drives now have in /etc/fstab and also on the desktop adjusted /etc/fstab to reflect these too, but am told that there is an incorrect mount option specified...

          On the NSLU2...

          # grep portage /etc/fstab
          UUID=f1909c33-a679-4c39-967b-2a8a246e5b38 /mnt/portage ext3 defaults 1 3
          # grep portage /etc/exports
          /mnt/portage 192.168.1.0/255.255.255.0(rw,async,subtree_check,no_root_squash)
          l# ls /mnt/portage/
          app-accessibility dev-lang games-util net-im skel.metadata.xml
          app-admin dev-libs gnome-base net-irc sys-apps
          app-antivirus dev-lisp gnome-extra net-libs sys-auth
          app-arch dev-ml gnustep-apps net-mail sys-block
          app-backup dev-perl gnustep-base net-misc sys-boot
          app-benchmarks dev-php gnustep-libs net-nds sys-cluster
          app-cdr dev-php5 gpe-base net-news sys-devel
          app-crypt dev-python gpe-utils net-nntp sys-freebsd
          app-dicts dev-ruby header.txt net-p2p sys-fs
          app-doc dev-scheme java-virtuals net-print sys-kernel
          app-editors dev-tcltk kde-base net-proxy sys-libs
          app-emacs dev-tex kde-misc net-voip sys-power
          app-emulation dev-texlive licenses net-wireless sys-process
          app-forensics dev-tinyos local net-zope virtual
          app-i18n dev-util lxde-base perl-core www-apache
          app-laptop distfiles mail-client profiles www-apps
          app-misc eclass mail-filter rox-base www-client
          app-mobilephone games-action mail-mta rox-extra www-misc
          app-office games-arcade media-fonts sci-astronomy www-plugins
          app-pda games-board media-gfx sci-biology www-servers
          app-portage games-emulation media-libs sci-calculators x11-apps
          app-shells games-engines media-plugins sci-chemistry x11-base
          app-text games-fps media-radio sci-electronics x11-drivers
          app-vim games-kids media-sound sci-geosciences x11-libs
          app-xemacs games-misc media-tv sci-libs x11-misc
          dev-ada games-mud media-video sci-mathematics x11-plugins
          dev-cpp games-puzzle metadata sci-misc x11-proto
          dev-db games-roguelike net-analyzer sci-physics x11-terms
          dev-dotnet games-rpg net-dialup sci-visualization x11-themes
          dev-embedded games-server net-dns scripts x11-wm
          dev-games games-simulation net-firewall sec-policy xfce-base
          dev-haskell games-sports net-fs skel.ChangeLog xfce-extra
          dev-java games-strategy net-ftp skel.ebuild


          On the desktop (running Gentoo, hence mounting portage which will be synced nightly on the NSLU2)...

          # grep portage /etc/fstab
          slug:/mnt/portage /usr/portage nfs auto,rw,users 0 0
          # mount /usr/portage
          mount.nfs: an incorrect mount option was specified

          Ditto for all the other drives. I realise this may be a problem on the desktop (client) side of things, but beyond changing the paths in /etc/fstab on the desktop nothings changed, and I've been pretty careful that I've not made typos and have the paths correct (checked three times now).

          Can anyone see what I've done wrong or might have problems with. I can provide more verbose output but I'm stumped at the moment.

          Oh and one final question, how do I specify the swap partition when I'm using UUID, it only seems to be provided for formatted partitions and not partitions formatted for swap? I guess I could put the device (/dev/sda2) in there, but that kind of defeats the object of using UUID's and may not be correct if for some strange reason things get assigned devices in a different order.


          Thanks in advance,

          Neil
        • Mike Westerhof (mwester)
          ... In the case that an executable of the same name exists in both optware and the native feeds, it would be desirable that the native executable be chosen.
          Message 4 of 9 , Jul 8, 2009
          • 0 Attachment
            slackline wrote:
            > 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?

            In the case that an executable of the same name exists in both optware
            and the native feeds, it would be desirable that the native executable
            be chosen.

            -Mike (mwester)
          • slackline
            ... Ah, yes sloppy writing on my behalf, I m not quite that ignorant and get that having the native apps would be preferable, but was wondering why /opt/bin
            Message 5 of 9 , Jul 9, 2009
            • 0 Attachment
              --- In nslu2-linux@yahoogroups.com, "Mike Westerhof (mwester)" <mwester@...> wrote:
              >
              > slackline wrote:
              > > 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?
              >
              > In the case that an executable of the same name exists in both optware
              > and the native feeds, it would be desirable that the native executable
              > be chosen.
              >

              Ah, yes sloppy writing on my behalf, I'm not quite that ignorant and get that having the native apps would be preferable, but was wondering why /opt/bin might prevent binaries in /sbin and/or /usr/sbin from being found.

              Still having NFS issues but haven't really had time to sit down and thrash through them yet. Maybe if its raining this weekend I'll do it.

              Cheers,

              Neil
            Your message has been successfully submitted and would be delivered to recipients shortly.