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

Re: mounting diversion script question for unslung

Expand Messages
  • Patrick Sansoucy
    ... Read about that but did not quite understood all the consequences ... I guess the solution proposed is the way to go. I will try it this week-end and see
    Message 1 of 6 , Aug 31, 2006
    • 0 Attachment
      --- In nslu2-linux@yahoogroups.com, "Fernando Carolo" <carolo@...> wrote:
      >
      > --- In nslu2-linux@yahoogroups.com, "Patrick Sansoucy"
      > > I have 2 ext3 formatted permanent harddrive plugged ... My problem is
      > > that mounts /share/flash/conf to sdb2 instead of sda2 and I do not kno
      > > w why.
      > > /dev/sdb1 6528 6344 184 97% /initrd
      > > /dev/sdb1 192055260 316704 189787384 0% /
      > > /dev/sdb1 192055260 316704 189787384 0% /share/hdd/data
      > > /dev/sdb2 116661 4157 111300 4% /share/hdd/conf
      > > /dev/sda1 192055260 31664 189787404 0% /share/flash/data
      > > /dev/sdb2 116661 4157 111300 4% /share/flash/conf
      >
      > This is a known issue with Linksys firmware R63 and has been
      > documented in the wiki. Since Unslung 6.6 is based on R63, it behaves
      > the same way. Quoting from
      > http://www.nslu2-linux.org/wiki/Unslung/WhichUSBPortforUnslung6:
      >
      > ---
      > Rule #1: The root device must be connected to USB Port 2.
      >
      > One of the ports will always be consumed by the root device. Since
      > clearly USB Port 1 is the most flexible port, plugging the root device
      > into USB Port 2 and leaving Port 1 open for other devices is the most
      > sensible choice.
      >
      > But - a problem arises in one specific situation. If a system is
      > Unslung following Rule #1, and a natively-formatted device is attached
      > to USB Port 1, some Not So Very Good Things can happen. Skipping the
      > gory details, the configuration data that used to be stored on the
      > device in USB Port 2 will be copied to the new device in USB Port 1
      > and it will be used from that location going forward. Once this
      > happens, the NSLU2 is now dependent upon both devices for proper
      > operation. (User experiences as noted in the mailing lists seem to
      > imply that the situation is not as simple as the previous sentences
      > imply; and that the addition of a natively-formatted device to an
      > already-unslung NSLU2 will lead to unpredictable but usually "bad"
      > behavior.)
      > ---
      >
      > This behaviour comes from the Linksys binaries, so there is no way to
      > easily avoid it. One possible solution is the one mentioned by
      > urgentdeath1999 on another message:
      >
      > --- In nslu2-linux@yahoogroups.com, "urgentdeath1999"
      > <urgentdeath1999@> wrote:
      > > I had the same problem with a 1gb stick and a hdd. So i formated the
      > > stick with the web-interface of the nslu2 and formated the hdd by
      > > myself as one ext3 partition with my desktop pc. I mount the hdd in
      > > rc.local
      > >
      > > /dev/sda1 on /share/flash/data type ext3 (rw,noatime)
      > > /dev/sda2 on /share/flash/conf type ext3 (rw,sync,noatime)
      > > /dev/sdb1 on /storage type ext3 (rw,noatime)
      > >
      > > Probably this could help you
      >
      > I actually had a similiar setup a while ago, with a flash memory drive
      > on port 2 acting as sda1 and a hard drive on port 1 with one ext2 and
      > one swap partition, both mounted explicity in rc.local (it worked ok
      > until the memory stick died and had to do a quick job
      > of reinstalling everything to a single hard disk). Using this setup
      > you will not run into the mess around /share/flash/conf.
      >

      Read about that but did not quite understood all the consequences ...
      I guess the solution proposed is the way to go. I will try it this
      week-end and see how it turns out.


      > > > > Another question is pertaining the /proc/cpuinfo. The file is
      there
      > > > > but at 0 bytes, so it basically does not work. Is there
      something I
      > > > > can do to fix it ?
      > >
      > > Have not tried cat but with vi the file is empty ... Does vi behave
      > > like cat in those cases ?
      > >
      > I did a test and looks like vi does check the file size using
      > stat64(). When it learns that the size for /proc/cpuinfo is zero, it
      > does not even try to read the contents, it just assumes that the file
      > is empty. This is not a good practice with pseudo-files under /proc.
      > cat just tries and reads the file, without worrying about the size and
      > this works.
      >
      > Regards,
      >
      > Fernando
      >

      Great, learned a lot ! Will also look into that ...

      Thanks guys for all the help !
      It's much appreciated.
      Patrick S.
    Your message has been successfully submitted and would be delivered to recipients shortly.