No space left on device & Use: 61%

[grant123]

I've installed Gentoo on a Beaglebone and I'm trying to extract a kernel source archive but after awhile I get stuff like:

linux-am33x/Documentation/eisa.txt
tar: linux-am33x/Documentation: Cannot mkdir: No space left on device
tar: linux-am33x/Documentation/eisa.txt: Cannot open: No such file or directory
tar: Exiting with failure status due to previous errors

Afterward I have:

# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 3676352 2105784 1383816 61% /
/dev/root 3676352 2105784 1383816 61% /
tmpfs 126992 136 126856 1% /run
rc-svcdir 1024 52 972 6% /lib/rc/init.d
udev 10240 0 10240 0% /dev
shm 126992 0 126992 0% /dev/shm

It's a 4GB SD card and it looks like I have well over 1GB left even after it tells me I have no space left on device. Does anyone know why this is happening?

# tune2fs -l /dev/mmcblk0p2
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name: rootfs
Last mounted on: <not available>
Filesystem UUID: 1a88a0e4-750e-4e6c-9d26-9d407dcc5bcc
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 233856
Block count: 933778
Reserved block count: 46688
Free blocks: 279608
Free inodes: 33919
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 227
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8064
Inode blocks per group: 504
Filesystem created: Sun Sep 16 14:15:21 2012
Last mount time: Fri Dec 31 16:01:50 1999
Last write time: Fri Dec 31 16:01:50 1999
Mount count: 26
Maximum mount count: -1
Last checked: Sun Sep 16 14:15:21 2012
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 80dcca83-eafc-4411-9495-79b9b5d2afd8
Journal backup: inode blocks

[Hu]

Is that tune2fs output taken immediately after the failure? Your inode count is a bit on the low side, and you likely could not extract a full kernel archive on that partition with so few inodes remaining. If your failed emerge was cleaned out before running tune2fs, then it would look like you had space remaining. When you get No space left on device, always check both your free blocks via df and your free inodes via df -i.

[grant123]

You're right, I'm out of inodes:

# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
rootfs 233856 233856 0 100% /
/dev/root 233856 233856 0 100% /
tmpfs 31748 222 31526 1% /run
rc-svcdir 31748 55 31693 1% /lib/rc/init.d
udev 31748 345 31403 2% /dev
shm 31748 1 31747 1% /dev/shm

What can I do?

[Hu]

Delete some unnecessary files, remake the filesystem with more inodes, or avoid merging packages which require large numbers of inodes. You may be able to cross-compile the kernel from some other system, thereby avoiding the need to install kernel sources.

If you have sufficient RAM, you could unpack the kernel sources into a tmpfs, use them, then free the tmpfs.

[chithanh]

[Jaglover]

Moving it to the NFS was my solution, no need to keep a copy of portage in every box.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[grant123]

Right on fellas, I did 'rm -rf /usr/portage' for now and the kernel sources extract just fine:

# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
rootfs 233856 82297 151559 36% /

[grant123]

Ouch, should have installed u-boot-tools before deleting portage if I wanted to compile those sources.

[paulj]

I just came across the same problem, and as you have found removing portage solved the problem. I would recommend you build the kernel and so on via your main machine. Raul has just updated the gentoo beaglebone guide explaining how to do it (http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml). I have just followed that, and with the following small changes:

• when soft linking sshd in init.d, use

  Code:

  ln -s /etc/init.d/sshd /media/rootfs/etc/runlevels/default/"

  Obviously, you need to change the "/media/rootfs" to match the mount point for your sd card.
  
• I am getting

  Quote:

  modprobe: FATAL: Could not load /lib/modules/3.2.0-00042-g672639b/modules.dep: No such file or directory

  . Following the instructions, no modules have been built or installed. This is not a show stopper - everything runs normally. In order to get rid of this message, I did (with the sd card mounted at /media/rootfs again):
  

  Code:

  make ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- INSTALL_MOD_PATH="/media/rootfs/" modules make ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- INSTALL_MOD_PATH="/media/rootfs/" modules_install

  
  However, this gave me a most bizarre issue. It completed successfully, loaded the files in the right place on the sd card, but when I put it back in the beaglebone, the files weren't visible (logging in as root). Anyway, in the end, I copied them off the sd card into a temporary location, and then after booting the beaglebone scp'ed them across. After that everything was OK.

I'm now off to get the wireless working on it!

[grant123]

I was getting those same modprobe errors but fixed them like this after the appropriate mkdir command(s):

# touch /lib/modules/3.1.0-00010-g66bfbd2/modules.dep

Also if you're using a small SD card (ie 4GB) you can prevent the inode problem altogether if you add "-T small" to the mkfs.ext4 command in the script.

Are you using a USB dongle for wireless?

[Hu]

If you are space constrained, you may be better served by putting the Portage tree in a squashfs, then generating that squashed tree on a full sized machine. The squashed tree was ~45M when I started doing this. It has now grown to ~60M due to new files added by the developers. This is a full tree, with no categories trimmed. Since I store it in a file accessed via loopback, I only use one inode on the ext4 filesystem.

[paulj]

[paulj]

[grant123]

Cool Edimax adapter. I'm curious about squashfs performance too.

[paulj]

It is tiny, and I did get it working under ubuntu on the beaglebone. I want to set it up to connect to a known network if it is available, or to work in peer to peer mode with a laptop. This will allow me to develop software on the beaglebone with it in place in whatever it is controlling (not decided what exactly yet, although autopilot software looks attractive!). I have loaded the modules for RTL8192, and now need to do the configuration side.

[Hu]

SquashFS performance depends on the underlying storage and on your CPU. A squashfs on a spinning drive was considerably faster than an ext4 Portage tree on a spinning drive, since the huge number of small files required a large number of seeks. The CPU penalty for decompressing the squashfs was vastly repaid by time not spent searching the disk for all the small files. The CPU penalty depends on your hardware. I did it with a standard desktop x86/x86_64 chip of the day. An embedded system may have a much slower CPU, which would make the penalty more noticeable. I never measured whether it slowed down the build process, but I suspect the answer is that the performance difference there is difficult to measure since relatively few files are accessed once you have resolved dependencies and begun executing ebuilds. Additionally, if you have adequate RAM for the filesystem cache, the kernel will cache the squashed files in memory, since it considers squashfs to be a filesystem and accessing files from a filesystem is (usually) slower than pulling them from cache. (Some specialty filesystems, like tmpfs, do not need this consideration.)

Your results may be very different if you are using solid stage storage. You will save a significant amount of space, but the very fast random read performance may mitigate the ext4 search penalty enough that you would be better off doing random reads than uncompressing the squashed files.

For any non-embedded device, I still recommend SquashFS Portage over simply spilling it out on the main filesystem. For embedded devices, there are too many variables for me to make a blanket recommendation. I like being able to access the Portage tree at any time without worrying about whether the NFS server is up and reachable, but if you are willing to live with that restriction, then accessing the data over the network is a viable choice.

[grant123]

Thanks Hu. I'm hoping to load Gentoo entirely to the 256B RAM on the BeagleBone with the help of squashfs. I just extracted stage3-armv7a_hardfp-20121020.tar.bz2 and it comes to 534M. If squashfs can do 2:1, that makes 267M. If I can make it a bit smaller it will fit, but when the compressed files are uncompressed during operation they will need additional space in RAM, right? If so, they won't fit, or am I misunderstanding something?

[Hu]

If you need to load everything into memory, then the size of the squashfs as seen on disk will be completely allocated in BeagleBone RAM before considering uncompressed copies, file cache, general kernel memory, or applications. So if the total RAM size of your BeagleBone is 256MB, you will need the squashfs disk form to be much smaller, ideally less than 128MB.

[Deathwing00]

Moved from Installing Gentoo to Kernel & Hardware.

[grant123]

Got it, I was afraid of that. I think I will try Tiny Core for this.