Sunday, July 24, 2011

guruplug and slow USB devices

I've got my guruplug connected to a seagate 1TB external expansion drive. At boot, the guruplug doesn't detect the seagate drive on first usb start (in the uboot process, before it even boots the linux kernel).

It's a timing issue, the drive just takes a while to start up and with the default bootcmd setup (just one usb start), the drive just isn't available yet when linux comes up.


edit the bootcmd so that where it does the "usb start", it should next do a "usb stop;sleep 10;usb start". I thought it might be sufficient to do "sleep 10;usb start", but it isn't. The first usb start wakes up the disk. If we skip it by just doing a sleep 10, the disk still isn't detected fast enough by the succeeding usb start.

So we startup usb (usb start), stop it (usb stop) so we can start it again later, sleep a bit, and then start it. The second time we start it, it's already spun up and is available to uboot (and later, to debian).

I still had to set the passcount in /etc/fstab to zero so it wouldn't be auto-fsck'ed. This is because processing of /etc/fstab and auto-fsck happens before the USB devices are detected by the kernel. So if passcount is not zero then linux tries to check the drives to see if they should be fsck'ed but the USB drives aren't available yet and I need to Ctrl-D and type the root password for maintenance.

I might put the root filesystem on the USB drive (still thinking about it). I like the idea of having the rootfs on USB (SDCard is not an option for me since this is not the GuruPlug Server plus, no SDCard slot) since I had to install uboot, kernel and rootfs from scratch because some random power cycling corrupted the NAND and when I did an fsck on it, it corrupted it enough so that I had to unbrick it with the JTAG :-).

I've done that twice now (once here and once on the Tonido). If this (or similar) plug is going to be deployed in places where power is unstable, then having the rootfs on an external device that can be easily fscked on some other linux machine is essential.

Wednesday, July 20, 2011

ecryptfs and changing password

Apparently we need ecryptfs-rewrap-passphrase ~/.ecryptfs/wrapped-passphrase

or (if it's not mounted), then ecryptfs-rewrap-passphrase /home/ecrypts/[username]/.ecryptfs/wrapped-passphrase.

Thursday, July 14, 2011

dos2unix in vim

the gist of which is:


and to compose the ^M character you need to press 

Wednesday, July 13, 2011