# 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

```
Filesystem Inodes IUsed IFree IUse% Mounted on 

rootfs 233856 233856 0 100% / 
```

The portage tree alone occupies around 150k inodes. Moving it to a separate filesystem may help.

----------

## Jaglover

Moving it to the NFS was my solution, no need to keep a copy of portage in every box.

----------

## 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

 :Smile:   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 

```
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):

```

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

 *grant123 wrote:*   

> 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
> 
> 

 

I realised I could do this, but I wanted to have the modules for the RTL8192 wireless chip loaded later so I wanted to get it working with module capability.

 *Quote:*   

> 
> 
> 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.
> 
> 

 

Thanks for the tip - I'll bear that in mind for my next installation foray!

 *Quote:*   

> Are you using a USB dongle for wireless?

 

it's an edimax EW7811UN. http://www.amazon.co.uk/Edimax-EW-7811UN-Wireless-802-11b-150Mbps/dp/B003MTTJOY/

You might find the videos on youTube from Derek Malloy interesting. One of them goes through the steps to set this wireless adaptor up in ubuntu (here).

----------

## paulj

 *Hu wrote:*   

> 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.

 

I don't need to install anything without a connection to the internet (well, local network), so I made portage on my main machine accessible through nfs. I should probably cross compile and bundle the packages I want to install to save time as well. Out of interest, does the squashfs approach slow down portage? I have considered whether to either increase disk throughput by adding raid striping to my desk top PC, or by adding a solid state drive for heavily used directories (apologies for drifting off topic - I guess this should be followed in another thread!)

----------

## 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.

----------

