Fixing apt-get

From ComputingPlugs

There is a problem with the default filesystem that caused apt-get to not function correctly. If you do a

apt-get update

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

Pros 

The system will act more like a regular computer and package managers will not be confused as often.

Cons 

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

Pros 

Takes up no space since the archive is delete on reboot

Cons 

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.

Comments:

Kenny Says: May 18 2009 2:07 pm Please keep comments clean and constructive. Inappropriate comments will be removed. Thank you. naugtur Says: Jun 26 2009 6:25 am The first solution did not work for me - apt-get stops and says it cannot mmap some files. The flash inside the plug may not support that kind of operation. Are You sure You tested it? I am running default install on a brand new plug with no upgrades yet. Kenny Says: Jun 26 2009 8:39 am yes, I'm running my sheeva plug with method 1 right now. But I'm running my sheeva plug with an external USB harddrive mounted as root. So I have lots of space to hold the apt-get cache. I had noted that I don't recommend doing method 1 if you're running on the flash because you'll run out of space real quick. Maybe that's the problem. naugtur Says: Jun 29 2009 9:59 am I had plenty of free space - it was almost the first thing I did with my plug after plugging it the first time. As I said - it looks like mmap is not working well on the NAND flash. And if You set it up on a USB harddrive - it is no problem for mmap anymore. That's my hypothesis. So I don't recommend 1 without external storage as well - it wouldn't work ;) Kenny Says: Jun 30 2009 9:22 am hmm... I guess so. Maybe if I ever have to reformat the plug I'll give it a try. Alex Says: Jul 06 2009 5:49 pm what is /root/discoverd? I disabled it just in case... Kenny Says: Jul 07 2009 11:41 am I have no idea so I also disabled it. Everything running fine so far... Rick Says: Sep 01 2009 9:57 am Yeah, it looks like whatever driver is providing "rootfs" on the NAND flash doesn't support memory-mapped I/O. Too bad...

Click here to leave a comment