There is a problem with the default filesystem that caused apt-get to not function correctly. If you do a
from the default filesystem, you would get the error message:
E: Archive directory /var/cache/apt/archives/partial is missing.
The problem, obviously, is that the directory in question is missing. However, simply creating the directory will not fix the problem completely. The developers decided to store /var/cache/apt in a tmpfs filesystem. This means that the /var/cache/apt directory will be clear on each reboot. This may or may not make sense for you depends entirely on how you use your Sheeva Plug. I'll outline the two methods to fix this problem and the pros and cons of each method.
Method 1 - store the archive locally
- The system will act more like a regular computer and package managers will not be confused as often.
- Takes up space on the local storage.
I would not recommend this method if you plan to use only the internal NAND flash as the archive directory can be large(>100M). However, if space is not an issue then this method would be the way to go. To fix apt-get so that it stores the archive locally, edit the file /etc/fstab and comment out the follow line:
tmpfs /var/cache/apt tmpfs defaults,noatime
Reboot the system for the changes to take effect. The system would not mount /var/cache/apt as tmpfs anymore and now you can create the archives directory with:
mkdir -p /var/cache/apt/archives/partial
After that, apt-get should run without errors.
Method 2 - create the directory each boot
- Takes up no space since the archive is delete on reboot
- You'll need to recreate the archive everytime you want to use apt-get
- The archive, when created, will be held in memory, thus reducing available memory to the system.
The command to create the archives directory is already there in rc.local. Problem is, rc.local tries to load an incompatible driver and quits before the archives directory is created. Here's what rc.local looks like:
#!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. insmod /boot/fat.ko insmod /boot/vfat.ko mkdir -p /var/cache/apt/archives/partial /root/discoverd cd / #./demo.sh date 012618002009 hwclock -w exit 0
The first 2 lines tries to insmod fat.ko and vfat.ko. This means that it tries to install the kernel modules fat.ko and vfat.ko. The problem is that both of these modules were build for a different kernel then the one that came with the Sheeva Plug, so the insmod command fails. This is evident if you were to watch the serial console during the boot process, there is an error near the end of the boot about kernel symbol not found with fat.ko. When the insmod command fails, the boot process stops processing rc.local so the other command do not get executed. To fix this, simply comment out both insmod commands from the file. While you're at it, also comment out the date and hwclock-w. I really don't know why the developer sets the system date to 6pm, Jan 26, 2009 and then writes it to the hardware clock. But that may explain some date problems that people have been seeing.
Did you find this page useful?