Re: mounting diversion script question for unslung
- --- In firstname.lastname@example.org, "Fernando Carolo" <carolo@...> wrote:
>Read about that but did not quite understood all the consequences ...
> --- In email@example.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
> 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"
> 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 firstname.lastname@example.org, "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.
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 isthere
> > > > but at 0 bytes, so it basically does not work. Is theresomething I
> > > > can do to fix it ?Great, learned a lot ! Will also look into that ...
> > 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.
Thanks guys for all the help !
It's much appreciated.