Tido reacted to Fluora in My apt search has become super slow recently
Oh, sure enough. I see this now.
I had a look at the strace dumps again, and it looks like this is in fact an upstream bug affecting all apt versions I tested.
I didn't think this was the case at first because Armbian is the only one where the bug inflates the processing time enough to make apt search actually unusable - on my Raspberry Pis running Raspbian and laptop running Debian, searching with compressed indexes only takes a few seconds, even despite the many repeated access operations. I remain perplexed as to why only Armbian seems to take around two orders of magnitude longer to complete the operation (presumably due to a similarly higher number of extraneous read operations).
In any case, the solution in the meantime is just to disable compression, either by commenting out the lines in /etc/apt/apt.conf.d/02-armbian-compress-indexes or by removing that file, then clearing and re-fetching the index files in /var/lib/apt/lists/. When operating on uncompressed lists, apt seems to be much better behaved, and I don't tihnk I see any signs of the vast numbers of repeated file accesses that I see when the lists are compressed. As I already mentioned, and contrary to what has been said previously in this thread, switching to gzip will not be effective. Disabling list compression entirely seems to be the only way to dodge this bug at the moment. Fortunately, it does appear to work properly; when operating on uncompressed lists, apt doesn't seem to perform the extraneous reads at all (and you're not just being saved by your disk cache).
I still can't quite figure out why this seems to be affecting Armbian so much more severely than any of the other Debian-derived distros I currently run. The bug clearly happens on my other systems, but only makes the search operation take around 10 seconds at most, whereas on Armbian, searches on compressed lists take upwards of 20 minutes, and don't go faster than about 16 seconds even with uncompressed ilsts. It could be that there are just more lists to search through under my Armbian install than on my others, but I don't think the differences are enough to account for that, even considering that the bug causes the time it takes to load a file to scale with the third power of the file size.
Anyway, a bug report clearly needs to be opened on apt upstream, and Armbian's configuration tweak to enable compression of index files should probably be removed or disabled, at least until the upstream bug is fixed.
Tido reacted to haskal in My apt search has become super slow recently
i have reviewed the strace output helpfully provided by Fluora and most of it is taken up by repeatedly opening, reading, and closing the same index file over 26 thousand times. specifically, the file is opened, one chunk is read, then it is closed, and the process repeats. eventually it gets to reading 2 chunks on each iteration, and then 3, and so on
that seems like the problem! there's no reason to be repeatedly opening and reading a file from the beginning tens of thousands of times just for one search. and this does sound like an apt bug -- somehow it is deciding to just spin the same file read for 20 minutes, rather than just reading it once
Tido got a reaction from pfeerick in Need your help - what else beside Etcher
@Ash Martin @Werner @guidol You do know that this thread is about a BETTER software than Etcher, right?
And you do know we recommend USBimager OVER Etcher, right?
If not, I recommend to read the first couple posts of this thread. Instead of misleading people @Ash Martin just be quiet. It is not as if you had to comment every post.
Tido reacted to Heisath in THE testing thread
Yes that is old and only limited switch capability given.
Correct that thread is pretty up-to-date. I have received the boards and confirmed the Power and Serial Mux is working (with minor changes). Currently we are developing the firmware for the sdcard muxer (STM32 based). The hardware of the sdcard mux seems good, I was able to connect a sd card to USB (and read with PC) and also to some SBC and boot it with reasonable fast speeds.
The current step is advancing the firmware so it is possible to select which SD card to mux where via USB or I2C.
You can check the state on the github https://github.com/armbian/mpads
Tido reacted to FHam in MyGica 1960 S912B trying hard to get Ubuntu installed
Thanks Tido, Seriously, I wish I was kidding. I have already followed the steps prior to your message. and I get the same error regardless of the dtb file I use. I have renamed and tried both u-boot-s905x-s912 and the s922 --> renamed to u-boot.ext
See the screen capture below. Note I have even tried copying the files and renaming it to dtb.img and I get the same crappy error message. The 1st screen capture shows the use of the "meson-gxl-s905x-p212.dtb" which btw like all makes no difference.
Tido reacted to jeanrhum in MyGica 1960 S912B trying hard to get Ubuntu installed
You have an error in your extlinux.conf: you should comment the rk3399 lines and uncomment 1 line of amlogic starting with fdt and the last one starting with append.
Here is the one I use for s912 boxes (you may change the dtb if the generic q200 is not relevant):
And you may also change the extlinux.conf-menu file:
Tido got a reaction from Werner in Using acronyms feature
VPU - video processing unit (encoding/decoding)
GPU - graphic processing unit (3D acceleration)
SoC - System on a Chip
SBC - Single Board Computer
WIP - Work in progress
NAND - Flash storage
GPIO - general purpose input/output
CSC - the weirdo.. no support abbreviation
EOS - End of Support - Hey Werner, die beiden schreien nahe zu nach einer Zusammenführung.
Tido reacted to guidol in Create an ftp server in tvbox
In the past I did also install vsftpd, but some time ago I did see that the package oppenssh not only has openssh-client / openssh-server...
As third part there is the openssh-sftp-server which armbian does install.
So I never installed vsftpd additionally again
The 3 packets in armbian (on my installation) are:
openssh-client 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) client, for secure access to remote machines openssh-server 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) server, for secure access from remote machines openssh-sftp-server 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) sftp server module, for SFTP access from remote machines An idea for the configuration of openssh-sftp-server could be found at
Tido reacted to sgjava in User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces
@Tido I made an edit to top of post. https://github.com/sgjava/java-periphery
Tido reacted to Werner in Jira
Agree. Maybe things should not be pushed so hard. Not only there is (from gut feels) little effect on (to use @Tido's scheme for simplification) patch releases, it also increases the administration effort as @Igor noted.
What about this? Do not push out intermediate releases (like 20.08.4) UNLESS there are critical issues like board does not boot.
Everything else can most likely be pushed via apt kernel upgrade anyways and will be merged in the next 3-month-release as well.
If somebody wants a provided fix faster they have to build their own either image or kernel package from master or wait. No discussion.
my two cents.
Tido got a reaction from Werner in Jira
For a common understanding.. semantic versioning 8.5.4 == MAJOR.MINOR.PATCH - for a programm, not a distribution. But, people really care which version they have and they want the latest an greatest - as we know from questions in the forum.
Ubuntu LTS on the other hand fixes stuff and after a period they release 20.04.1 that incorporates all the fixes. However, I guess your release cycle is too short.
Tido reacted to guidol in Need your help - what else beside Etcher
USBImager V1.0..4 is now 2 months old, but I today recommend by cnx-software:
Filter out drives on the same disk as C:
Tido reacted to Igor in Remove/adjust moderator notes from registration terms
Tido reacted to Werner in Merge "SD card and PSU issues" with "Board does not start"?
Yep, something like this.
Another reason to get rid of one of those
Understand. But it seems to me it is kind a mixed at the moment because there was not much such "movement".
Tido reacted to ubobrov in 4kp30 video on Orange Pi Lite and mainline hardware acceleration
Here are the Armbian bionic images with installed RTSP streamer using H264 HW encoding on Allwinner H3 boards
Orange Pi One
Orange Pi Zero
Images are able to run on any board with Allwinner H3
Tido got a reaction from bowsboy in USBImager Write Error on Mac Catalina
hmm, UUByte DMG Editor, does this software verify the flash process bit for bit, like USBimager does?
Defects, good point. There is a section in the Documentation how to check the SDcard for proper function.
// sent from mobile phone //