Kernel 4.1.9 overlays not working

apt-get update: "This step is important every reboot. As the /etc/apt/sources.list file is not kept on “disk”. This is meant to help keep writes to flash media at a minimum – In case you were wondering."

Wait, what? Why would this make sense? I write the flash all the time, what's wrong with writing it on the rare occasions I issue "apt-get update?"

I'd much rather write to flash than risk forgetting to update apt and screwing something up by installing the wrong package.

http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

apt-get update: "This step is important every reboot. As the /etc/apt/sources.list file is not kept on “disk”. This is meant to help keep writes to flash media at a minimum – In case you were wondering."

Wait, what? Why would this make sense? I write the flash all the time, what's wrong with writing it on the rare occasions I issue "apt-get update?"

+1

Dziekuje bardzo.

W dniu 2015-10-19 o 11:39, Taceant Omnes pisze:

Wait, what? Why would this make sense? I write the flash all the time, what’s wrong with writing it on the rare occasions I issue “apt-get update?”

So, don’t bother with apt-get update the next time you reboot. Do you think that will prevent the error you get while running apt, without updating ?

By the way Rick, how much did I charge you for the information I give out on my blog ?

I'm not attacking you, William, I'm asking for clarification. It doesn't make any sense to me that apt-get update wouldn't write its results to disk.

You don't need to apt-get update all the time, if it writes its results to disk. But if it doesn't, and you forget to next time you apt-get install, you run the risk of downgrading something you have installed (or otherwise corrupting it), don't you?

It's really hard to down-grade in debian, and any cache corruption
should stop dpkg from installing a *.deb package..

Regards,

I’m not attacking you, William, I’m asking for clarification. It doesn’t make any sense to me that apt-get update wouldn’t write its results to disk.

You don’t need to apt-get update all the time, if it writes its results to disk. But if it doesn’t, and you forget to next time you apt-get install, you run the risk of downgrading something you have installed (or otherwise corrupting it), don’t you?

Not attacking you either Rick, but here is the point. The official images come with this enabled. So whether you, I, or anyone else cares, it’s already in there. The apt sources cache is either completely in RAM, with a default cache set at build time, or it is a minimal gzipped archive. Technically, no you do not have to run apt-get update every_single_time you go to use APT, but generally it is a good idea. All it takes is an update in one repo or another( depending ), and apt-get install, apt-get upgrade, etc will fail, barfing out some message similar to E: could not locate x.y.z.

Either way, the blog was meant for people who are new to Beaglebone, or Linux development in general. If you’re good with Debian(Linux), you probably do not need my guides.

Passed that, many people are worried about writing to flash too much, and I’m one of them. I’ve been using an A5A for gaining on 3 years now, with no flash problems, and that includes the Sony class 10 SDHC card that we bought for it back then. As it is, I make enough mistakes of writing to flash, accidentally, to worry about all the compiling, apt-get installing, etc. This is also why one of my first blog posts was on how to setup NFS shares, and NFS root for the Beaglebone. Not to mention I compile often, and a lot. Granted, compiling over an NFS share is slower, but I can live with that. But it’s also why I have a cross system for the larger projects, or is why I wrote another blog on how to setup a USB rootfs . . .

I was also a bit “quick” this morning . . . which is how I normally am for the first few hours after waking up. Still, if I write something in my blog posts, and you do not get it. Don’t worry so much about it. It was probably not meant for you, or other advanced users. It was meant to keep people, who are new out of “trouble”, with minimal explanation required from me.

My problem is that I don't understand how putting the apt cache in RAM is beneficial if what you're trying to do is avoid flash writes. If you're updating the cache, then you're also intending to install or upgrade software, which will write to flash. If it's in RAM and not persisted, forcing you to do an update each time you do an install or upgrade, how does this prevent writing to flash?

So, either I'm not understanding the intent, or I'm not understanding how apt works.

If instead it's best practice to always update before installing, then why not have apt-get install just update the cache each time?

All I see is no benefit but the potential for error (e.g., not getting the version of the package you thought you were getting, or in the best case, confusing errors due to conflicts). I don't see how putting the cache in RAM helps anyone, novice or expert.

Now, if the intent is just to speed up accesses, rather than reduce flash writes, then loading the cache at boot from a store on disk, and accessing the cache in ram, makes sense. However, it seems that in this case, apt-get update should update both the cache and the on-disk store.

In all this, I'm questioning the wisdom of the apt authors, not you or Robert or anyone else on this list.

It's not in local ram, it's on disk...

When you run "apt-get update" a local cache database is created, this
database can become out of date.. Especially if your running
testing/unstable. For stable (wheezy) it's not really an issue,
unless you have someone like me pushing kernel and bb.org package
updates to the repo.

For official images, i "clear" out this local apt cache, to 1: save
space, 2: it can be months out of date.. :wink:

Regards,

So, we’re working with an embedded device. This device, depending can use a tiny rootfs depending. In effect, the apt cache “problem” is two fold.

First, writing to media, which in the case of our board here is flash. Sure, maybe if you’re using apt you’re installing something, which does write to flash. But why compound that by also writing the cache to flash too ?

Second, is size. the apt cache can eat up a lot of space, if you let it. Sometimes, this is not so important, other times it is. I’ll let you use your imagination here.

It has been a long, long time since I’ve seen really bad “apt errors” - e.g. corrupting the rootfs somehow, or broken packages etc. But it did used to happen, which is why we can read about, or talk to people who swear by aptitude. Now days, I’d go so far to say that this is a non issue. However . . . what you will run into is APT complaining about your repo(s) not being in sync, and the error message given is not always obvious. I can not give you the exact text of the errors I’ve seen in the past, but they typicaly go something like “E: unable to lock . . .” or “E: unable to find . . .”. Sometimes these error might even confuse a user into believing that a given package does not exist . . . which is the main reason why I suggest just to use apt-get update always. It’s less pain for them, and others when trying to help with various problems.

It’s not in local ram, it’s on disk…

Ok, so looks like I have my “facts” confused with perhaps something else. As far as the cache goes. Still, run apt-get update before you use apt to install something. Especially if you use it very seldom.

You could put them in a tmpfs to cut down on writes :wink:

/var/cache/apt/

voodoo@hestia:/var/cache$ sudo apt-get clean
voodoo@hestia:/var/cache$ du -sh apt
60K apt
voodoo@hestia:/var/cache$ sudo apt-get update
<>
voodoo@hestia:/var/cache$ du -sh apt
76M apt

Regards,

Updating your APT cache may be necessary, especially if it’s been a while since doing so. If you’re getting errors relating to using APT. This may very well be why.

Better ? :wink:

the 60k is:

voodoo@hestia:/var/cache/apt$ ls -lh ./*
total 4.0K
-rw-r----- 1 root root 0 Dec 29 2013 lock
drwxr-xr-x 2 root root 4.0K Oct 18 20:28 partial
voodoo@hestia:/var/cache/apt$ ls -lh ./*/*
-rw-r----- 1 root root 0 Dec 29 2013 ./archives/lock

./archives/partial:
total 0

so on tmpfs mount it would be easy to create..

Regards,

You could put them in a tmpfs to cut down on writes :wink:

/var/cache/apt/

voodoo@hestia:/var/cache$ sudo apt-get clean
voodoo@hestia:/var/cache$ du -sh apt
60K apt
voodoo@hestia:/var/cache$ sudo apt-get update
<>
voodoo@hestia:/var/cache$ du -sh apt
76M apt

I thought that was what you were doing already. Hence my confusion. But to be honest I never really looked too deep into it. So the discussion you and I had months ago, I guess I just took that for granted( caches to ram cache . . )

Meanwhile . . . I’m destroying this SD card trying to get PRU C compiler working without CCS, and without losing my sanity . . .

Nah doing 'other' funky things so that optional features of the apt
'cache' never reach the disk. :wink:

dropped translations, uncompressed, etc..

and when you do:

sudo apt-get update ; sudo apt-get install xzy

it's actually doing:

sudo apt-get update ; sudo apt-get install xzy ; sudo apt-get clean

Regards,