NSLU2-Linux
view · edit · print · history

Known problems in Unslung firmware

In all major software systems there are known issues. Some are easily fixed and some not so easily fixed. Unslung's commitment to Linksys compatibility also restricts what can be fixed as not all Linksys SW for the NSLU2 is available in source form. This page will have some minor points as well as major sections describing workarounds. People resolving one or more of the major issues here will be regarded as heroes of the people and receive an embarrassing amount of praise.

Unslung 6.8-beta & Unslung 6.10-beta

  • Unslung does not support U3-enabled USB flash devices. U3 USB flash devices do not identify themselves as standard mass storage devices. You must use the flash devices vendor's utility to disable the U3 functionality and return it to a standard USB mass storage mode before you can use the device with Unslung. Note that this problem is not limited to Unslung firmware; U3 devices are problematic with the native Linksys firmware (and many other systems) as well. (The presence of a U3 device can usually be determined by examining the output of the "dmesg" command in Unslung -- a U3 device will identify itself as a CDROM as well as the standard device.) HowTo.RemoveU3
  • The README erroneously states that the smallest USB flash device that is supported is 256MB. In fact, due to changes in the partition sizes used by the Linksys firmware, the smallest USB flash device that can be formatted by the Web GUI is 512MB. If you must use a smaller device, a (non-trivial) technique for doing so is documented on the wiki.
  • There have been a number of reports of difficulties formatting certain types of devices with Unslung 6.8-beta. Generally, these devices seem to be large disks (where "large" seems to be drives greater than 250GB in size). These problems include the inability to format the drives with the Linksys Web GUI, and may also include the inability to "fsck" the filesystems at boot, and other problems. One workaround to this problem is to format the "large disk" with fat32 using the disk manufacturer's disk formatting utility. After this is complete, reformat the "large disk" using the Linksys Web GUI. There have also been verified cases of select USB flash devices that fail to format with Unslung 6.8-beta. The problem description is rather vague -- which is part of the problem (as soon as the problem is better-defined, a solution may be easier to find). One case, involving a Sandisk Mini Cruzer 1.0GByte flash device, has been reproduced, and a workaround has been documented on the Unslung.FailedFormatFix page.
  • Some users have reported that after unslinging, the device is unable to automatically mount FAT or NTFS disks that previously the Linksys R63 firmware was able to mount. An additional symptom is that on the Web GUI, the FAT or NTFS drive is displayed as "Not Formatted" even though the drive is correctly formatted and can be mounted and used with the standard Linksys R63 firmware. This problem may be due to selecting Language Support other than "USA (437)" on the Web GUI, Administration->System page. See Unslung.UnslungLanguageSupport for more information on this.
  • The "Administration->Advanced->Upgrade" page in Unslung 6.8-beta is exactly the same as the same page in the Linksys R63 firmware. However, the documentation clearly states that this page cannot be used to upgrade or install firmware. You must use Redboot Upgrade Mode to install firmware, be it Unslung or Linksys firmware. See HowTo.InstallUnslungFirmware for more information.
  • Unslung is not aware of the 2007 changes to Daylight Savings Time affecting users in the United States, Canada, and Bermuda. Unslung uses the timezone information from the Linksys firmware, which has not been updated to include the new DST info passed into law by the Energy Policy Act of 2005. Starting in 2007, DST will run from the second Sunday in March to the first Sunday in November, extending the total time period for DST by 4 weeks. During these 4 weeks, the date/time information used and displayed by the Linksys firmware and by Unslung will remain on standard time instead of DST. Brian Zhou mentions a way to fix this problem: http://www.nslu2-linux.org/wiki/Unslung/TimeZoneUpdate
  • Creating a share, or adding a user with a private share, via the Linksys Web GUI can create two shares: one with the original name, the other with the original share name with "~1" appended -- each is associated with a different drive in a two-drive NSLU2 configuration. Since the share directory only actually exists on one of the two drives, only one of the two shares will work. This is not an Unslung 6.x bug -- this is actually completely consistent with the (strange) behavior of the native Linksys R63 firmware. Since the shares are managed by Linksys code for which we have no source code, this is not something that can be changed in Unslung.

Just to expand on the above issues:

* Following reboot of the NSLU2 a share created on disk1 will retain the correct name and clients will be able to reconnect without issue. A 'dummy' share with ~1 mapped to a non-existent directory on disk2 will be created but this can be ignored. It isn't possible for a client to connect to this 'dummy' share.

* On reboot R63 mangles any shares previously created on disk2 by rewriting /etc/share.info and /etc/samba/smb.conf. The original share will be remapped to point at a non-existent directory on disk1 and a new share with ~1 created and correctly mapped to disk2. This breaks client connectivity. To reconnect, clients must now use the share name with a ~1 appended to connect to the disk2 share. It isn't possible for clients to connect to the remapped 'dummy' original share.

* Following a reboot the dummy shares created by R63 will be shown in red in the web interface.

So, the bottom line is that if you build shares on disk2, expect to reconfigure client connectivity or bypass via HowTo.UseSharesOnTwoNativeDisksInUnslung68. This isn't a major problem as in all cases the NSLU2 maps data to the correct drive but it is irritating. - richdunlop


Unslung 5.5

Virtually all optware packages are broken because /opt/bin is not in the system path!! hack to fix:

 
# create /etc/profile
echo export PATH=/opt/local/bin:/opt/bin:$PATH:/opt/sbin:/opt/usr/bin:/opt/usr/sbin >/etc/profile
echo export LD_LIBRARY_PATH=/opt/lib >> /etc/profile
echo export TERMINFO=/opt/share/terminfo >> /etc/profile
echo alias ls='ls -F' >> /etc/profile
echo export PS1='\u@\h:\w\$ ' >> /etc/profile
# reload the new profile
. /etc/profile 

/dev/random blocks rather then giving random data as it is supposed to... this effects dropbear and other packages that need to generate keys... dropbear install hangs with the following message:

 
Will output 1024 bit rsa secret key to '/opt/etc/dropbear/dropbear_rsa_host_key'
Generating key, this may take a while...
Warning: Reading the random source seems to have blocked.
If you experience problems, you probably need to find a better entropy source.

hack to fix:

 
mv /dev/random /dev/random-blocks
ln -s /dev/urandom /dev/random
# To read about the difference between urandom and random go here:
# http://people.freebsd.org/~dougb/randomness.html

then reinstall dropbear or restart whatever process blocked trying to get data from random. In order to be able to ssh in after a reboot, you may want to apply the hack in the /opt/etc/init.d/S51dropbear before starting dropbear.

view · edit · print · history · Last edited by Bermuda.
Based on work by maisondouf, mwester, mkohler, marceln, Jeremy Jefferson, na, jbf, Prenexus, richdunlop, adriaan, osas, g, KGP, rwhitby, williamwaggoner2003, and bobtm.
Originally by bobtm.
Page last modified on June 28, 2008, at 04:37 PM