BeagleBone Black: v3.8.13-bone37 kernel flash slowly fills up

Thank you. That does seem pretty simple. Unfortunately, I get this error message:

debian@beaglebone:/opt/scripts/tools$ sudo ./update_kernel.sh
info: checking archive
–2014-05-18 00:24:33-- https://rcn-ee.net/deb/wheezy-armhf/LATEST-omap-psp
Resolving rcn-ee.net (rcn-ee.net)… 69.163.222.213
Connecting to rcn-ee.net (rcn-ee.net)|69.163.222.213|:443… connected.
ERROR: The certificate of `rcn-ee.net’ is not trusted.
The certificate has not yet been activated

Is there a way to make it ignore the certificate?

Thanks again,
James

update your clock:

sudo ntpdate pool.ntp.org

The certificate was updated in August 2014 (the image if the time
isn't updated starts in May 2014)

Regards,

That did it. Thanks. The update went fine.

I’m still seeing the disk filling up at the same rate as before. I delete log files before checking disk space. There is data in a temporary file that fills up at a rate of about 1mb/day. The space gets freed on a reboot.

Can you think of what may be doing this? Is this the same problem that others have reported?

That did it. Thanks. The update went fine.

I'm still seeing the disk filling up at the same rate as before. I delete
log files before checking disk space. There is data in a temporary file that
fills up at a rate of about 1mb/day. The space gets freed on a reboot.

1mb/day!!!! This original thread was about 1x'smb/minute.. :wink:

Can you think of what may be doing this? Is this the same problem that
others have reported?

I've capped systemd around 8mb max via:

SystemMaxUse=8M

Regards,

I agree that 1mb/day is a slowish leak. I’m glad it has improved. Until recently, my system only had 40mb free at all, so this would fill up in a month. I hope it is capped at 8mb as you say.

But is the 8mb limit relevant if I’m deleting the logs before checking space? /var/log is empty when I check space. Are you sure this will halt at 8mb, or is there something else I should check for?

I’ve been thinking more about this slow leak. I do believe it has something to do with logging, and it seems that logs are being stored in a temporary file until reboot even after being written to /var/log. But perhaps the more important question is, “why are there so many errors being logged?”

I see constant error messages to the console even when no applications are being run. These are the repeating errors I see:

[ 21.170242] libphy: PHY 4a101000.mdio:01 not found
[ 21.177302] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 26.880502] libphy: PHY 4a101000.mdio:01 not found

[ 26.886371] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 27.335371] libphy: PHY 4a101000.mdio:01 not found
[ 27.341350] net eth0: phy 4a101000.mdio:01 not found on slave 1

[ 602.052044] tilcdc 4830e000.fb: timeout waiting for framedone

What is going on here? Do you have any suggestions?

Thanks for your help.
James

The errors I posted recently don’t show up as often as I claimed, so that’s not the problem. This is a mystery to me. Sorry for all the emails about this. If you have any suggestions on things to test for, I’d love to hear. Thanks again.

Ok, I figured this all out. There is no filling up of the disk from the operating system. My method of investigating was causing the problem. I started with a real disk use issue in my own software that I fixed. Then I noticed a remaining and much slower disk use that turned out to be caused by the way I was looking into the problem. No, I wasn’t logging to the beaglebone itself, I was logging data to another machine, but … poorly.

Both bone67 and bone50 are fine.

Feel free to delete my comments about this non issue.

Thanks again for your time and for showing me how to upgrade the kernel.

James

Either way, this still would not be “a leak” This is standard Linux behavior. Logging that is.

If logging was the problem, then you are correct. Logging was only one of the possible reasons I was looking into.

Well you’re not the first to experience this “issue” and maybe not the last. However with that said I’ve yet to experience it myself. The only thing I can think of is that I use a custom rootsfs based off of Roberts barefs image. I also compile my own kernel, but I would think that should have little to do with it.