I'm running Armbian on a 4 GB Rock64, downloaded and installed yesterday. I've been using Debian/Raspbian/Armbian for about 10 years and I've really come to rely on Synaptic for searching and being able to make download scripts. Not every day but about once a week especially if I'm setting up something (like this Rock64).
This Synaptic's access to the package database seems incredibly slow. A single search may take 20 minutes. After installing something it reloads the list and shows it on the screen, that can be another 20 minutes. During this time it's got 1 thread using 100% of one CPU. Typing is sometimes impaired, window repainting usually.
In this picture Synaptic was behind Firefox and I clicked on it to bring it to the foreground. That still hadn't happened here (it finally did) and I wanted to screenshot it, so there are also bits of the screenshot utility being dragged off the screen. Synaptic's using too much CPU for the screen to be redrawn.
From my database experience it reminds me of one time I forgot to build an index on a table. It can still be searched but very slowly. Every access requires reading the whole thing over again. I always thought it was strange there wasn't a normal SQL database somewhere, /var/cache/apt/pkgcache.bin may be it:
about fixing some apt/synaptic problems but didn't help in this case. Oh, and I'm now subscribed to the mailing list synaptic-devel@nongnu.org but I could be the only one. The last Synaptic changes were in 2012.
Question
ab1jx
I'm running Armbian on a 4 GB Rock64, downloaded and installed yesterday. I've been using Debian/Raspbian/Armbian for about 10 years and I've really come to rely on Synaptic for searching and being able to make download scripts. Not every day but about once a week especially if I'm setting up something (like this Rock64).
This Synaptic's access to the package database seems incredibly slow. A single search may take 20 minutes. After installing something it reloads the list and shows it on the screen, that can be another 20 minutes. During this time it's got 1 thread using 100% of one CPU. Typing is sometimes impaired, window repainting usually.
In this picture Synaptic was behind Firefox and I clicked on it to bring it to the foreground. That still hadn't happened here (it finally did) and I wanted to screenshot it, so there are also bits of the screenshot utility being dragged off the screen. Synaptic's using too much CPU for the screen to be redrawn.
From my database experience it reminds me of one time I forgot to build an index on a table. It can still be searched but very slowly. Every access requires reading the whole thing over again. I always thought it was strange there wasn't a normal SQL database somewhere, /var/cache/apt/pkgcache.bin may be it:
But I don't think it's possible to use the nice GUI editors like for PostgreSQL, MySQL, SqlLite on it.
The page in Firefox was an interesting article at https://unix.stackexchange.com/questions/383999/why-are-some-packages-not-available-in-my-debian-jessie-installation
about fixing some apt/synaptic problems but didn't help in this case. Oh, and I'm now subscribed to the mailing list synaptic-devel@nongnu.org but I could be the only one. The last Synaptic changes were in 2012.
The problem seems peculiar to Armian, Synaptic works normally in Raspbian and Debian Buster. Could be file permissions (but not obvious) or some PAM/Selinux/Apparmor thing. The FileMagic (https://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_numbers_in_files on this pkgcache.bin is DC 76 FE 98.
Link to comment
Share on other sites
11 answers to this question
Recommended Posts