• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  General Category / Success stories / Re: Managing a USB hard drive on the Plug on: August 31, 2014, 08:53:02 AM
@birdman, I had a chance to play around with the various INIT options.  The following has worked so far for me in terms of running wait4usbdisks until just before checkfs.sh but also ensuring that checkfs.sh does not start before wait4usbdisks has finished.

# Provides:          wait4usbdisks
# Required-Start:    checkroot
# Required-Stop:
# Should-Start:
# Should-stop:
# Default-Start:     S
# Default-Stop:
# X-Interactive:     true
# X-Start-Before:    checkfs
# X-Stop-After:
# Short-Description: Delays boot to ensure USB disks are connected.

I also removed the "exit 1" from the "start)" logic to prevent errors being posted after wait4usbdisks had finished. 
2  General Category / Success stories / Re: Managing a USB hard drive on the Plug on: August 06, 2014, 02:38:17 PM
@birdman, that is definitely an option.  Unfortunately, I am still having problems getting my head around the LSB-compliant init scripts stuff.  I can read the words but the detailed logic still eludes me.  The right solution would be to have wait4usbdisks finish before checkfs.sh starts, without having to modify 'stock' initialization scripts. 
3  General Category / Success stories / Re: Managing a USB hard drive on the Plug on: August 05, 2014, 07:54:50 AM
I tried the code provided by mgillespie (post #11) without success - mountall.sh is running before wait4usbdrives gets a chance to slow down the process.  It may be my setup: I am running Debian Squeeze and the USB harddrive is connected to a hub - it takes 8 seconds before the drive is recognized and added to /dev.  rcconf slotted wait4usbdisks after checkfs.sh and before mountall.sh but based on https://wiki.debian.org/LSBInitScripts/ it appears Debian Squeeze is running boot scripts according to dependency information provided by the scripts rather than the older numeric Snn sequence.  The FAQ at the bottom of https://wiki.debian.org/LSBInitScripts/ implies that there is no standard way to get wait4usbdrives to run before checkfs.sh without modifying the headers in checkfs.sh. 

For the moment, I have modified checkfs.sh at the beginning of the do_start routine to include the code from restamp amd mgillespie.  I will play around with the X-Start-Before and X-Stop-After headers mentioned in the FAQ when I get some time.
4  General Category / General Discussion / Re: Accessing SheevaPlug Serial (JTAG) Console from Windows7 on: March 24, 2013, 02:00:29 PM
@odoll, I had a lot of problems on Win7 trying to update the drivers from the ZIP file.  The installer at http://www.ftdichip.com/Drivers/CDM/CDM20828_Setup.exe worked a lot better.  I removed all instances of the old drivers, removed the JTAG cable, ran the setup and then inserted the JTAG cable.  After checking Windows Update, Windows eventually found the pre-installed drivers.  I do not have Win8 so have not been able to test whether this works.
5  General Category / General Discussion / Accessing SheevaPlug Serial (JTAG) Console from Windows7 on: March 02, 2013, 08:47:39 AM
I needed to get the serial console (JTAG) working to resolve a SheevaPlug problem but had recently upgraded to Windows7 Pro 64-bit.  The TeraTerm drives provided on the SheevaPlug CD did not work - although they installed, I was not able to get the drivers to start. 

I found instructions at http://apvsbr700.blogspot.ca/2010/04/connecting-to-sheevaplug-using-windows.html that pointed me in the right direction.  I downloaded the 2.08.28 setup executable from http://www.ftdichip.com/Drivers/VCP.htm.  It contains both the 32-bit and 64-bit drivers and installs them in the correct place where Windows will find them.  I connected the JTAG cable to a USB port.  Windows recognized the USB devices (JTAG1.jpg in attached ZIP), checked Windows Update for drivers and then loaded the correct drivers installed earlier (JTAG2.jpg).  The Device Manager showed USB devices USB Converter A and USB Converter B along with USB Serial Port COM11 (JTAG3.jpg).  The serial port may be different depending on your system configuration.  The instructions above indicated that USB Converter B needed to have Load VCP enabled in Properties/Advanced, but this option was already enabled in my case.

I was able to successfully access the SheevaPlug using Putty: Serial connection, COM11, speed 11520 (JTAG5.jpg).

It is a good idea to set up serial console access before you actually need it.  In my case, the SheevaPlug was constantly rebooting causing the JTAG port to 'flap'.
6  General Category / General Discussion / A Tale of a Corrupted Root Filesystem on SD Card on: March 02, 2013, 07:47:25 AM
I picked up two SheevaPlugs back in 2009.  Early on, I moved the root file system to an 8GB SDHC card (ext3 file system).  To increase the available space and reduce wear on the SDHC card, I moved /home and /var to an external USB harddrive.  I intended upgrading the kernel or switching to a full Debian install but never got around to it.  One of the SheevaPlugs has been serving as a file, networking caching and backup server since then with relatively few problems other than a failed power supply that I replaced by an external 5V power supply.

I rebooted the server last week and noticed the lighttpd daemon would not start because the configuration file was corrupted.  I had noticed a message during the boot that I should run e2fsck against the root file system.  Although the file date was 2009, about 10 characters within the file had changed sometime in the previous week, suggesting that the flash was failing.  Although there are a lot of cloning applications available, I happen to have  ChkFlsh (http://mikelab.kiev.ua/index_en.php?page=PROGRAMS/chkflsh_en) which not only tests flash cards but also support creating and restoring flash card image.  I was unable to get the SheevaPlug to boot properly with either the cloned or original SDHC card.  In addition to I/O errors on the harddrive, I could not get the Ethernet connection up and /dev did not look at all right.

I ran fsck/e2fsck against the external harddrive from another Linux system (no errors).  I decided to run e2fsck against the cloned 8GB SDHC card and was horrified to see a large number of inode and other errors, all of which e2fsck claimed it corrected.  The problem was not due to the cloning - the same errors showed up on the original SDHC card.  The good news is that the repaired SDHC card booted successfully and seems to be working just fine.  What is odd is that the original SDHC card passed a 10 hour Full Pattern read/read test with no errors. 

The morale of the story: with SDHC cards, no news is not always good news.  I will be regularly cloning the SDHC card and running e2fsck.  I might even build a current Debian system.
7  Hardware and U-Boot firmware / Hardware / Re: Poll: Sheeva Plug Power Supply failures - does the mains voltage matter? on: December 22, 2010, 12:12:23 PM
A SheevaPlug that had been running continuously as a squid, backup and file server (externally powered USB drive) failed earlier this week - blinking lights, random restarts and finally nothing.  Fortunately, I stumbled on this forum.  The power supply looked OK, although the tops of two of the smaller capacitors seemed to be a bit bulged.  Unloaded voltage read 5V.  I plugged the power supply into the circuit board and got a green LED.  However, output voltage of the power supply dropped to 3V and then cycled between 0V and 3V.  Fortunately, I run Linx off an SD card and had a spare SheevaPlug, although it took a while to clean up the file systems on the external harddrive.

Just to confirm, can I safely replace the power supply with an external 5V/3A regulated power supply?  I assume there is nothing special about the two pairs of wires - it is hard to tell from the power supply with all the brown glue, but it looks like the black wires are soldered together and the two red wires are connected through the circuit board.

Best wishes for the holidays,
8  General Category / Application ideas and development Q/A / backuppc on SheevaPlug, Possible File::RsyncP Issue? on: June 30, 2010, 07:10:08 AM
Is anyone running backuppc on the SheevaPlug?  I moved backuppc from a Linux/Intel system to a SheevaPlug with an external drive in February to backup both local and remote servers.  Files are being backed up properly, but data volumes are significantly higher than I saw on the previous system. 

backkupc uses a Perl version of rsync so that only modified blocks are copied.  Although the rsync command itself works fine on the SheevaPlug, the File::RsyncP code used by backuppc appears to incorrectly identify a significant percentage of blocks as different even if the source/target files are identical.

I would appreciate confirmation that others using backuppc are seeing the same problem.  I can provide instructions for reproducing it.
     thanks, Norbert
9  General Category / General Discussion / Steps Required to Upgrade SheevaPlug Kernel on: July 31, 2009, 08:37:57 AM
I recently took delivery of a SheevaPlug that I want to turn into a software router for a 3G USB Modem.  Since the pre-installed kernel is missing the required drivers, I plan to install the kernel from http://sheeva.with-linux.com/sheeva/.

My original goal was to leave the pre-installed system untouched, for recovery and problem-determination purposes.  I followed the steps in http://www.openplug.org/plugwiki/index.php/SD_Card_As_Root_File_System to get the root file system on an 8GB SDHC card and have done all of my customization on this filesystem. 

My current uImage partition appears to be 2MB in size, and based on other posts the kernel will not fit.  Would the following steps work?
  • copy the recovery version of the root jffs2 to the SDHC card
  • boot using the SDHC rootfs and override mtdparts to define a 4MB uImage and a new NAND rootfs start
  • flash_eraseall the NAND rootfs and nand_write the root jffs2
  • save the environment variables
  • re-boot using the NAND rootfs to verify that everything is working
  • use the shell script http://sheeva.with-linux.com/sheeva/README- to download and upgrade the kernel
  • reboot using the NAND rootfs after setting the mainlineLinux, arcnumber and bootargs as listed in shell script
  • reboot using the SDHC rootfs

An alternative solution would be to put the kernel and the rootfs on the SDHC card after upgrading u-Boot using the pointers found near the end of http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html.  Assuming that the newer u-Boot supports my SDHC card, this sounds like the best approach.  It allows me to keep the kernel and the rootfs together and minimizes the changes to the NAND setup.  Once I have the new u-Boot running, I should be able to figure out the steps to:
  • boot from the NAND rootfs
  • set up the boot and rootfs partitions on the SDHC card
  • copy over my existing SDHC rootfs setup
  • install the on the /boot partition of the SDHC card
  • reboot after setting the bootargs to use the SDHC uImage and rootfs partitions

Any guidance would be appreciated!  Although learning about the inner workings of u-Boot and Linux kernels is valuable, I would rather focus on getting my software router up and running.
      Thanks, Norbert
Pages: [1]