Solution to Odd behaviour

Added 2009-12-29 by PaulBrandt?

Indeed the incorrect mounting of both drive's /conf onto /dev/sdb is the source of this issue. An apparent solution has been described in CorrectBadSharingWithTwoDrives . Thanks to Alain for pointing this out.

Of course, if disk 1 had exploded and I had tried to institute my mad plan of then booting off disk 2, THEN I would have been bit by disk 2 having disk 1's conf partition...

The solution suggested as "exception to rule #1" in WhichUSBPortforUnslung6, putting the root (flash) device in port 1 and the usb disk in port 2, does not solve this problem. See NonNativeDiskMount for a workable solution.

=====

I have ~never~ run into this problem in my 6.8 setup, and I consciously (but ineffectively, according to this article) elected to format BOTH 300Mb drives using Linksys's format util because I wanted to be able to "boot off the other one if the first one failed." (I had no idea that the second one's conf was being blown away each time.)

However, puzzling over why I never had a problem with my shares, I realized its because I never used the webpages to define them! Instead, I (apparently) edited smb.conf via ssh and used smbpasswd to create smbpasswd, only on the master disk. I accessed the second drive's "share" folders by putting links to them in the first drive's data/public folder, so it appeared that all my shares resided on disk 1. As a result, no share information lived on drive 2 so blowing it away never affected anything.

Sometimes it's better to be lucky than smart...

=====

Disk Behaviour with Linksys R63 Firmware

This article pertains to:

• Unslung 6.x only

Linksys version 2.3R63 has support for NTFS disks, and changes the handling of attached disks significantly from previous versions. This page documents our current knowledge about that new behaviour (which will be mainly preserved in Unslung 6.x).

Single FAT/NTFS device per port

FAT partitions are recognised on Disk1 (USB Port 1) and Disk2 (USB Port 2). NTFS partitions are only recognised on Disk1.

Multiple partitions per single device

Disk1 will mount multiple FAT and NTFS partitions. Disk2 will only mount FAT partitions.

Multiple FAT/NTFS devices per port (using a hub)

Multiple FAT/NTFS devices behind a hub are only recognised on USB Port 1.

On USB Port 2, only the first single device plugged in is mounted and any additional devices are ignored (even if the first device is subsequently disconnected).

Installation Recommendations

See WhichUSBPortforUnslung6.

If you want to use a hub with Unslung 6.x it has to be connected to USB Port 1. The firmware is able to recognize multiple disks behind the hub and mount them auto magically.

Unfortunately you can't put your root disk on the hub. The first found disk on the hub will be used as "/dev/sdb" and there is no reliable way to ensure that the root disk is always "/dev/sdb".

The best solution is to simply put the Unslung root disk on USB Port 2.

There is a discusion about this on the mailinglist.

Odd Behavior

rc.bootbin in 2.3R63 (and thus Unslung 6.x) behaves oddly when confronted with two native ext3 formatted drives. In short, it mounts the conf partition (number 2) of the device in slot 2 (/dev/sdb) in both /share/hdd/conf and /share/flash/conf! This is Very Bad since it effectively deletes your share configuration (and password file) every time it reboots, resulting in an odd appearance of tilde-1 versions of your shares.

For example, let's say you unslung to a flash drive in slot 2 and have a native-formatted hard disk in slot 1 (as suggested in numerous 6.x documents). Now you create a "music" share on the hard disk. This creates /share/flash/data/music and adds it to /share/flash/conf/share.info. Now you reboot. You will be surprised to find an unusable "music" share pointing to the nonexistant /share/hdd/data/music, and a usable but unmanageable "music~1" share pointing to /share/flash/data/music. Now reboot again. Your music share is gone (though the data remains).

The solution suggested as "exception to rule #1" in WhichUSBPortforUnslung6, putting the root (flash) device in port 1 and the usb disk in port 2, does not solve this problem. See NonNativeDiskMount for a workable solution.

[url=http://biotechteensex.741.com/sitemap.xml]wet blonde teen sex[/url] <a href="http://biotechteensex.741.com/sitemap.xml">wet blonde teen sex</a>

Disk Behaviour with Linksys R63 Firmware

This article pertains to:

• Unslung 6.x only

Linksys version 2.3R63 has support for NTFS disks, and changes the handling of attached disks significantly from previous versions. This page documents our current knowledge about that new behaviour (which will be mainly preserved in Unslung 6.x).

Single FAT/NTFS device per port

FAT partitions are recognised on Disk1 (USB Port 1) and Disk2 (USB Port 2). NTFS partitions are only recognised on Disk1.

Multiple partitions per single device

Disk1 will mount multiple FAT and NTFS partitions. Disk2 will only mount FAT partitions.

Multiple FAT/NTFS devices per port (using a hub)

Multiple FAT/NTFS devices behind a hub are only recognised on USB Port 1.

On USB Port 2, only the first single device plugged in is mounted and any additional devices are ignored (even if the first device is subsequently disconnected).

Installation Recommendations

See WhichUSBPortforUnslung6.

If you want to use a hub with Unslung 6.x it has to be connected to USB Port 1. The firmware is able to recognize multiple disks behind the hub and mount them auto magically.

Unfortunately you can't put your root disk on the hub. The first found disk on the hub will be used as "/dev/sdb" and there is no reliable way to ensure that the root disk is always "/dev/sdb".

The best solution is to simply put the Unslung root disk on USB Port 2.

There is a discusion about this on the mailinglist.

Odd Behavior

rc.bootbin in 2.3R63 (and thus Unslung 6.x) behaves oddly when confronted with two native ext3 formatted drives. In short, it mounts the conf partition (number 2) of the device in slot 2 (/dev/sdb) in both /share/hdd/conf and /share/flash/conf! This is Very Bad since it effectively deletes your share configuration (and password file) every time it reboots, resulting in an odd appearance of tilde-1 versions of your shares.

For example, let's say you unslung to a flash drive in slot 2 and have a native-formatted hard disk in slot 1 (as suggested in numerous 6.x documents). Now you create a "music" share on the hard disk. This creates /share/flash/data/music and adds it to /share/flash/conf/share.info. Now you reboot. You will be surprised to find an unusable "music" share pointing to the nonexistant /share/hdd/data/music, and a usable but unmanageable "music~1" share pointing to /share/flash/data/music. Now reboot again. Your music share is gone (though the data remains).

The solution suggested as "exception to rule #1" in WhichUSBPortforUnslung6, putting the root (flash) device in port 1 and the usb disk in port 2, does not solve this problem. See NonNativeDiskMount for a workable solution.

[url=http://mp3zz.741.com/sitemap.xml]mp3 zz[/url] <a href="http://mp3zz.741.com/sitemap.xml">mp3 zz</a>

rc.bootbin in 2.3R63 (and thus Unslung 6.x) behaves oddly when confronted with two native ext3 formatted drives. In short, it mounts the conf partition (number 2) of the device in slot 2 (/dev/sdb) in both /share/hdd/conf and /share/flash/conf! This is Very Bad since it effectively deletes your share configuration (and password file) every time it reboots, resulting in an odd appearance of tilde-1 versions of your shares.

The solution suggested as "exception to rule #1" in WhichUSBPortforUnslung6, putting the root (flash) device in port 1 and the usb disk in port 2, does not solve this problem. See NonNativeDiskMount for a workable solution.

NOTE: The information below should be moved to its own wiki article - ~mwester

NOTE: The information below should be moved to its own wiki article - mwester

 [=

1. ! /bin/sh

 [=

1. df

[=#! /bin/sh

[=# df

(:table border=0 width=100% bgcolor=#eeeeff:) (:cell:)

 #! /bin/sh
# Diversion script: to mount a formatted drive under /share/flash/data
#
mount /dev/sdb1 /share/flash/data/sdb

return 1

(:tableend:)

(:table border=0 width=100% bgcolor=#eeeeff:) (:cell:)

 # df
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                  723320     34748    681224   5% /
/dev/sda1                 6528      6328       200  97% /initrd
/dev/sda1               723320     34748    681224   5% /
/dev/sda1               723320     34748    681224   5% /share/flash/data
/dev/sda2               123811      4144    118389   3% /share/flash/conf
/dev/sdb1            480719056   5497276 450802580   1% /share/flash/data/sdb

(:tableend:)

1. Now we have to tell the slug to mount the drive on startup after running rc.bootbin but before starting Samba. We'll do this with a diversion script called /unslung/rc.samba. From the shell, type "cat > /unslung/rc.samba" and paste in the following text:
   1. ! /bin/sh
   2. Diversion script: to mount a formatted drive under /share/flash/data
   mount /dev/sdb1 /share/flash/data/sdb
   return 1

  # df
  Filesystem           1k-blocks      Used Available Use% Mounted on
  rootfs                  723320     34748    681224   5% /
  /dev/sda1                 6528      6328       200  97% /initrd
  /dev/sda1               723320     34748    681224   5% /
  /dev/sda1               723320     34748    681224   5% /share/flash/data
  /dev/sda2               123811      4144    118389   3% /share/flash/conf
  /dev/sdb1            480719056   5497276 450802580   1% /share/flash/data/sdb

The following setup does work, however!

We will use a USB flash disk in port 2 (/dev/sda) and a USB hard disk in port 1 (/dev/sdb). This maximizes flexibility and compatibility.

1. Start with a fresh NSLU2!
2. Install Unslung 6.x. Do not configure any shares or users yet!
3. Insert the flash drive in port 2 and format it through the Web interface. It will remain here forever!
4. Reboot
5. Get a shell and unsling to the flash with "unsling disk2"
6. Reboot
7. Use another PC to configure your USB hard disk (or second flash device) with a single large partition, if it isn't that way already. You will not be using the GUI on the NSLU2 to partition it!
8. Plut the second USB drive into port 1 of the NSLU2
9. Get a shell and format it as ext3 with "mkfs.ext3 /dev/sdb1"
10. We will mount it under the flash disk at /share/flash/data/sdb. You must create this directory now from the shell with "mkdir /share/flash/data/sdb".
11. Now we have to tell the slug to mount the drive on startup after running rc.bootbin but before starting Samba. We'll do this with a diversion script called /unslung/rc.samba. From the shell, type "cat > /unslung/rc.samba" and paste in the following text:

<pre>

1. ! /bin/sh
2. Diversion script: to mount a formatted drive under /share/flash/data

mount /dev/sdb1 /share/flash/data/sdb

return 1 </pre>

1. Now reboot. When it comes up, your df output should look like this:

<pre>

1. df

Filesystem 1k-blocks Used Available Use% Mounted on rootfs 723320 34748 681224 5% / /dev/sda1 6528 6328 200 97% /initrd /dev/sda1 723320 34748 681224 5% / /dev/sda1 723320 34748 681224 5% /share/flash/data /dev/sda2 123811 4144 118389 3% /share/flash/conf /dev/sdb1 480719056 5497276 450802580 1% /share/flash/data/sdb </pre>

1. Now you can create users and shares. Specify "Disk 2" for shares and specify "/sdb/whatever" when creating a share. For example, a music share would be on "Disk 2" and would specify the "/sdb/music/" folder in the GUI. Don't worry - it'll actually reside on the disk you mounted on sdb.
2. Note that any user shares you create will be created on the disk in port 2 (the flash disk) as you can't specify where to put them! So maybe you won't want to create them...

The solution suggested as "exception to rule #1" in WhichUSBPortforUnslung6, putting the root (flash) device in port 1 and the usb disk in port 2, does not solve this problem.

How to set up a workable two-disk configuration in R63/Unslung6

Due to the odd behavior of rc.bootbin as discussed above, it is not advisable to use two natively-formatted disks in R63 or Unslung6!

The following setup does work, however!

The solution suggested as "exception to rule #1" in WhichUSBPortforUnslung6, putting the root (flash) device in port 1 and the usb disk in port 2, does not solve this problem.

For example, let's say you unslung to a flash drive in slot 2 and have a native-formatted hard disk in slot 1 (as suggested in numerous 6.x documents). Now you create a "music" share on the hard disk. This creates /share/flash/data/music and adds it to /share/flash/conf/share.info. Now you reboot. You will be surprised to find an unusable "music" share pointing to the nonexistant /share/hdd/data/music, and a usable but unmanageable "music~1" share pointing to /share/flash/data/music. Now reboot again. Your music share is gone (though the data remains).

The solution to this problem is simply to follow the "exception to rule #1" in WhichUSBPortforUnslung6. That is, put the root (flash) device in port 1 and the usb disk in port 2.

mailinglist.

Odd Behavior

rc.bootbin? in 2.3R63 (and thus Unslung 6.x) behaves oddly when confronted with two native ext3 formatted drives. In short, it mounts the conf partition (number 2) of the device in slot 2 (/dev/sdb) in both /share/hdd/conf and /share/flash/conf! This is Very Bad since it effectively deletes your share configuration (and password file) every time it reboots, resulting in an odd appearance of tilde-1 versions of your shares.

For example, let's say you unslung to a flash drive in slot 2 and have a native-formatted hard disk in slot 1 (as suggested in numerous 6.x documents). Now you create a "music" share on the hard disk. This creates /share/flash/data/music and adds it to /share/flash/conf/share.info. Now you reboot. You will be surprised to find an unusable "music" share pointing to the nonexistant /share/hdd/data/music, and a usable but unmanageable "music~1" share pointing to /share/flash/data/music. Now reboot again. Your music share is gone (though the data remains).

FAT partitions are recognised on Disk1 (USB Port 1) and Disk2 (USB Port 2). NTFS partitions are only recognised on Disk1.

Installation Recommendations

This article pertains to:

• Unslung 6.x only

Disk Behaviour with Linksys R63 Firmware

Linksys version 2.3R63 has support for NTFS disks, and changes the handling of attached disks significantly from previous versions. This page documents our current knowledge about that new behaviour (which will be mainly preserved in Unslung 6.x).

Multiple FAT/NTFS devices behind a hub are only recognised on USB Port 1.

On USB Port 2, only the first single device plugged in is mounted and any additional devices are ignored (even if the first device is subsequently disconnected).

See WhichUSBPortforUnslung6.

If you want to use a hub with Unslung 6.x it has to be connected to USB Port 1. The firmware is able to recognize

Unfortunately you can't put your root disk on the hub. The

The best solution is to simply put the Unslung root disk on USB Port 2.

Installation recommendations

If you want to use a hub with unslung 6.x it has to be connected to port 1. The firmware is able to recognize multiple disks behind the hub and mount them auto magically.

Unfortunately you can't put your root disk in the hub. The first found disk on the hub will be used as "/dev/sdb" and there is no reliable way to ensure that the root disk is always "/dev/sdb".

The solution is to put the unslung root disk on port 2.

There is a discusion about this on the mailinglist.

Disk1 will mount multiple FAT and NTFS partitions. Disk2 will only mount FAT partitions.

Multiple FAT/NTFS devices per port (using a hub)

FAT partitions are recognised on Disk1 and Disk2. NTFS partitions are only recognised on Disk1.

Multiple partitions per single device

Disk1 will mount multiple FAT and NTFS partitions. Disk2 will only mount FAT partitions.

Multiple partitions per device

Multiple FAT/NTFS devices per port (using a hub)

Multiple FAT/NTFS devices behind a hub are only recognised on Disk1.

On Disk2, only the first single device plugged in is mounted and any additional devices are ignored (even if the first device is subsequently disconnected).

<<<<<<<

Multiple FAT/NTFS devices behind a hub are only recognised on Disk1. On Disk2, only the first single device plugged in is mounted and any additional devices are ignored (even if the first device is subsequently disconnected).

=======

>>>>>>>

Single FAT/NTFS device per port

Multiple FAT/NTFS devices per port (using a hub)

Multiple FAT/NTFS devices behind a hub are not recognised on Disk2. Only the first device plugged in is mounted.

Single device per port

Multiple devices per port

Linksys version 2.3R63 has support for NTFS disks, and changes the handling of attached disks significantly from previous versions. This page documents our current knowledge about that new behaviour (which will become part of Unslung 6.x).