BBB with Angstrom: No space left on device

GoogleGroups
1

BBB clean out of the box,

opkg update

opkg upgrade

Samba installed

All works fine, SSH via Ethernet and USB.
When programming in c++ and saving a source file in Nano, I get “Error writing : No space left on device”

So I do this:
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 1738184 1659368 0 100% /
/dev/root 1738184 1659368 0 100% /
devtmpfs 255276 0 255276 0% /dev
tmpfs 255404 4 255400 1% /dev/shm
tmpfs 255404 236 255168 1% /run
tmpfs 255404 0 255404 0% /sys/fs/cgroup
tmpfs 255404 4 255400 1% /tmp
/dev/mmcblk0p1 71133 55239 15895 78% /media/BEAGLEBONE

So the root filesystem look pretty full eh?
Has anyone got an idea what could be wrong, or a structured way of finding undesired files that fill up my memory?
Thanks!

2

‘du -s -k /*’

I’m betting /var is full because your logs are out of control. Connected via ethernet over USB, using Angstrom?

For some reason the Anstrom kernel is compiled with debugging enabled for the driver that provides ethernet over USB. This fills the logs.

Until the driver (g_multi.ko) is compiled without debugging turned on you will need to limit the logs by doing what is described here:

https://groups.google.com/forum/#!searchin/beagleboard/journal%7Csort:date/beagleboard/1NguS-SK-G8/EdbLDWfl4IUJ

Credit to Andy. It’s possible someone pointed it out before Andy - if so, my apologies. His solution keeps your filesystem usage under control.

Unfortunately the log files will be worthless since they are being filled with garbage and that won’t change until the kernel is compiled without debugging turned on for the USB gadget driver. If you are comfortable compiling the kernel yourself then you can fix it by compiling a custom kernel.

Kleven

3

Hi Kleven,

thanks for your response. I wonder if /var/log is extremely full:

du -s -k /*

4576 /bin

4480 /boot

4 /dev

40532 /etc

35960 /home

41272 /lib

16 /lost+found

529 /media

8 /mnt

du: cannot access `/proc/30353/task/30353/fd/3’: No such file or directory

du: cannot access `/proc/30353/task/30353/fdinfo/3’: No such file or directory

du: cannot access `/proc/30353/fd/3’: No such file or directory

du: cannot access `/proc/30353/fdinfo/3’: No such file or directory

du: cannot access `/proc/30354’: No such file or directory

0 /proc

236 /run

2244 /sbin

0 /sys

4 /tmp

945000 /usr

586108 /var

ls -lh /var/log

total 464K

drwxr-xr-x 2 root root 4.0K Jan 1 2000 ConsoleKit

-rw-r–r-- 1 root root 1.1K May 20 11:51 README

-rw-r–r-- 1 root root 8.3K Jan 1 2000 Xorg.0.log

-rw-r–r-- 1 root root 8.5K Aug 7 15:31 Xorg.0.log.old

-rw------- 1 root utmp 0 Jan 1 2000 btmp

drwx------ 4 root root 4.0K Jan 2 2000 cores

drwxr-xr-x 2 root root 4.0K May 29 21:41 gateone

-rw-r–r-- 1 root root 41K Jan 1 2000 gateone.log

drwxrwx–T 2 root gdm 4.0K Jan 1 2000 gdm

drwxr-xr-x 3 root root 4.0K Jan 1 2000 journal

-rw-r–r-- 1 root root 286K Aug 9 15:23 lastlog

-rw-r–r-- 1 root root 3.5K Jan 1 2000 log.nmbd

-rw-r–r-- 1 root root 1.9K Jan 1 2000 log.smbd

-rw-r–r-- 1 root root 389 Jan 1 2000 mpd.log

-rw-r–r-- 1 root root 23K Aug 7 15:32 ntpd.log

-rw-r–r-- 1 root root 1.6K Aug 7 15:32 pm-powersave.log

drwxr-xr-x 2 root root 4.0K Feb 25 00:36 samba

-rw-r–r-- 1 root root 0 Aug 7 11:28 samba-log.192.168.0.119

-rw-r–r-- 1 root root 0 Aug 7 11:35 samba-log.192.168.7.1

-rw-r–r-- 1 root root 25K Aug 7 15:35 samba-log.peter-hp

-rw-r–r-- 1 root root 33K Aug 9 15:40 samba-log.smbd

-rw-rw-r-- 1 root utmp 231K Aug 9 15:23 wtmp

-rw-r–r-- 1 root root 204 Aug 7 15:32 xinput_calibrator.pointercal.log

For a 2GB memory a directory of 464kB is not shocking, do you think?

I followed Andy’s advice, this is the resultr:

root@freek:/# df

Filesystem 1K-blocks Used Available Use% Mounted on

rootfs 1738184 1551616 96604 95% /

/dev/root 1738184 1551616 96604 95% /

devtmpfs 255276 0 255276 0% /dev

tmpfs 255404 4 255400 1% /dev/shm

tmpfs 255404 520 254884 1% /run

tmpfs 255404 0 255404 0% /sys/fs/cgroup

tmpfs 255404 4 255400 1% /tmp

/dev/mmcblk0p1 71133 55239 15895 78% /media/BEAGLEBONE

root@freek:/# du -s -k /*

4576 /bin

4480 /boot

4 /dev

40536 /etc

36176 /home

41272 /lib

16 /lost+found

525 /media

8 /mnt

du: cannot access `/proc/621/task/621/fd/3’: No such file or directory

du: cannot access `/proc/621/task/621/fdinfo/3’: No such file or directory

du: cannot access `/proc/621/fd/3’: No such file or directory

du: cannot access `/proc/621/fdinfo/3’: No such file or directory

0 /proc

520 /run

2244 /sbin

0 /sys

4 /tmp

945000 /usr

474620 /var

So we have reclaimed 5% of the rootfs, and for the time being I can proceed, but isn’t 95% usage far too much?

Thanks,

Peter

4

If you need more space you can always Expand the File System Partion on a microSD

http://circuitco.com/support/index.php?title=Expanding_File_System_Partition_On_A_microSD

5

Hi Peter,

I think you may want to take a closer look at everything in /var/log.

‘du -s -k /var/log/*’

I’ve been playing with those settings trying to get my journal to shrink but unfortunately the ‘live’ journal for the current boot remains quite large. Several hundred MB is definitely way too much for system logs.

Kleven

6

Kleven,

If you tweak SystemMaxUse in your journald.conf file, it will take a while for you to notice a difference.
The reason for this is that the journal is split into 5 or 6 files, and the space savings after the configuration change is only realized gradually as each “oldest file” is deleted by the system.

Don

7

Don,
Where is the journald.conf file located? I’ve hit the same problem with the log files filling, and have worked around it for now by manually deleting them. I’m looking forward to limiting their size using something like the SystemMaxUse you describe. However, I can’t find it in the /etc directory, nor sysconfig under that. FYI - My journal was split into 14 files.

Scott

8

The journald.conf file should be in /etc/systemd/journald. Mine is attached. I also keep my logs in volatile storage which automatically limits the resources. See:

http://www.freedesktop.org/software/systemd/man/journald.conf.html

HTH,

Dave

journald.conf-argus (701 Bytes)

9

Thanks Juan, but this would force me to install a different OS (Debian, Ubuntu) whilst I had the idea to start doing practical things with my BBB (like controlling the temperature of my wine :wink: ).

10

Thanks Kleven,

11

Hi Peter,

I ended up having to delete those older files in the journal directory as well. After I made the changes to restrict the logging the older files didn’t get deleted for some reason.

After manually deleting them things seem to be under control. Not sure why that happened - I probably should have tried to stop the journal service before modifying the settings or something like that.

Either way, after deleting the files, the disk usage remains under control.

For Angstrom, the rootfs is nearly 1.2 GB on first boot. You don’t need to install very many packages or do much development before you’ve used up another couple hundred MB and you are at (or over) 75% on the 2GB eMMC.

Depending on what you are doing, the shipping version of Angstrom on BBB contains many packages that you won’t need.

For instance, if your end application is running headless (no display) then consider developing on a desktop machine and deploying your application to the BBB. Then you can remove all X server and GNOME related packages. This will free up a notable amount of space.

Once you are further along, I’d recommend exploring the Yocto/OpenEmbedded build environment. With those environments you could basically build your own distro for your application. Then you would have exactly what you need and would likely have a lot more free storage space.

Another (IMHO simpler) option is to use Robert Nelson’s debian (wheezy) or ubuntu (raring) images. He has created a ‘flasher’ image (http://www.rcn-ee.net/deb/flasher/) that behaves essentially just like the Angstrom flasher images. His debian image is barebones and extremely small. If you are used to using debian/ubuntu, this might be the best option for you since it would ease your learning curve and give you more space at the very start.

Kleven