mrjpaxton

Hey, I have uninstalled cron from my system completely, but I just thought I might help contribute, even just a little, by making some services and timer files to replace the ones in these folders: /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly Now keep in mind that I have not fully tested any of these yet! I would appreciate feedback in testing these, since most of these I won't even use on my system. I barely even use the armbian-config utility at all, so... yeah... The files in question are these. Let me know if I should add more: armbian-truncate-logs armbian-updates armbian-ram-logging These are the Armbian specific ones. I know there's ones for like man-db, mdadm, logrotate, fake-hwclock and a bunch more that get installed by default. And I think systemd already has timer files for some of these. In fact, here's the timers in use on my Kobol system right now: # systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Sat 2021-09-11 18:43:28 PDT 13min left Fri 2021-09-10 18:43:28 PDT 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago logrotate.timer logrotate.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago man-db.timer man-db.service Sun 2021-09-12 05:57:58 PDT 11h left Sat 2021-09-11 17:25:28 PDT 1h 4min ago apt-daily.timer apt-daily.service Sun 2021-09-12 06:20:19 PDT 11h left Sat 2021-09-11 06:59:08 PDT 11h ago apt-daily-upgrade.timer apt-daily-upgrade.service n/a n/a Sat 2021-09-11 05:57:28 PDT 12h ago update-ddns.timer update-ddns.service 6 timers listed. Pass --all to see loaded but inactive timers, too. The "update-ddns" timer and service is my own custom one. The rest are defaults. So we'll start in order of shortest to longest activation times: armbian-truncate-logs (runs every 15 minutes) /etc/systemd/system/armbian-truncate-logs.timer [Unit] Wants=armbian-truncate-logs.service [Timer] OnActiveSec=15m [Install] WantedBy=timers.target /etc/systemd/system/armbian-truncate-logs.service [Unit] Description=Truncate the Armbian log files [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-truncate-logs [Install] WantedBy=multi-user.target armbian-updates (runs daily and on boot up) Note: We are going to change this to run after the network is brought Online, but still make it run daily. /etc/systemd/system/armbian-updates.timer [Unit] Wants=armbian-updates.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target /etc/systemd/system/armbian-updates.service [Unit] Description=Check for updates on the Armbian system After=network-online.target [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-apt-updates [Install] WantedBy=multi-user.target armbian-ram-logging (runs daily) Note: It is mentioned that this cron job should only run when logrotate is a cron job. This was confusing wording at first, because it doesn't tell you if it prefers to either have logrotate as a systemd timer, or if logrotate should not run at all. After looking inside the script "/usr/lib/armbian/armbian-ramlog", which passes "write" as the first argument, I tried to see if there was any problematic code that conflicts with logrotate... Using the "syncToDisk ()" function, it doesn't seem like it'd conflict with logrotate at first glance. Just to be safe, I've included the line "Conflicts=logrotate.service" just in case. If this can be safely removed, let me know. /etc/systemd/system/armbian-ram-logging.timer [Unit] Wants=armbian-ram-logging.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target /etc/systemd/system/armbian-ram-logging.service [Unit] Description=Perform Armbian RAM logging Conflicts=logrotate.service [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-ramlog write [Install] WantedBy=multi-user.target --- That's about it. Again, not sure if any of these should be set to "oneshot" or "simple" services, or if they need to be active "RemainOnExit" or whatnot. Just hope I can give a good template for converting cron jobs to systemd timers. It's a lot simpler than I thought to convert them. Have a wonderful day, Armbian team. And thank you for all you contribute to this project.

EDIT: Removed.

Well, here's my issue. I'd like to explain it. The problem was I wasn't even doing a full upgrade. I was just using "apt update; apt upgrade", and upgrading the system normally. So if even a normal upgrade breaks the system, there's something seriously wrong here... I don't know much about Debian's policies, but I do know a full distribution upgrade should only be done with "apt dist-upgrade" or "apt full-upgrade", and this policy wasn't respected. It would have been fine if the latest rockchip64 kernel image was held back before the upgrade, so that it had time to get bug fixes. Also, the version numbering is confusing. The version for "linux-image-current-rockchip64" is set to "21.08.01", but that's not what version the kernel is. Shouldn't it be "5.10.60-rockchip64". That might have helped me avoid this problem altogether, so at least I'd know what version of the kernel I was about to install. In other words, I had no idea "21.08.01" had the broken kernel "5.10.60-rockchip64". I know Armbian is different than Debian, but it really should play more nicely to what regular Debian users are used to, rather than deviating too much from it. It's one of the reasons why I chose Armbian! It is because I expected it 99% to work like Debian, except maybe for the fact that it uses a different kernel, DTD, maybe a BSP (base support package), U-Boot, and a few necessary patches. But changing how core OS updates and upgrades work is just wrong to me. A side note, I know U-Boot isn't GRUB, but it really would be nice to have support for multiple (backup) kernels like I'm used to on x86 with GRUB. It is different code, and a different arch, so I guess that makes sense though... Still a shame. I will look around and see if the solutions work. Otherwise, I'll try to use my full rsync backup.

Hi, Ever since updating to kernel version 5.10.60 (#21.08.1), I have been getting these weird kernel error messages. Such error messages pop up constantly when doing certain operations, like: mmc2: running CQE recovery And also some of these: EXT4-fs warning (device mmcblk2p1): ext4_end_bio:349: I/O error 10 writing to inode 256 starting block 968704) As well as these: kernel: print_req_error: 47 callbacks suppressed kernel: blk_update_request: I/O error, dev mmcblk2, sector 7716864 op 0x1:(WRITE) flags 0x4000 phys_seg 8 prio class 0 kernel: Buffer I/O error on device mmcblk2p1, logical block 954373 And when updating with "apt update", I get this: Traceback (most recent call last): File "/usr/lib/cnf-update-db", line 26, in <module> col.create(db) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 94, in create self._fill_commands(con) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 132, in _fill_commands self._parse_single_contents_file(con, f, fp.stdout) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 228, in _parse_single_contents_file l = l.decode("utf-8") UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 2625: invalid start byte Reading package lists... Error! E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi' E: Sub-process returned an error code E: LZ4F: /var/lib/apt/lists/security.debian.org_dists_buster_updates_main_binary-arm64_Packages.lz4 Read error (18446744073709551600: ERROR_decompressionFailed) E: LZ4F: /var/lib/apt/lists/us.mirrors.fossho.st_armbian_apt_dists_buster_main_binary-arm64_Packages.lz4 Read error (18446744073709551600: ERROR_decompressionFailed) W: You may want to run apt-get update to correct these problems E: The package cache file is corrupted Honestly, it's pretty bad. But I did run this: badblocks -v /dev/mmcblk2 And no errors were found. It makes me think that it was just the upgrade that broke everything. This one is NOT an attempt to try to upgrade to Bullseye, but just a regular Buster/Armbian upgrade. If anyone else has had a successful upgrade, then let me know... I am not sure how to diagnose or fix any of this. I am indeed running from eMMC, and not the SD card slot. The big problem is that since APT is completely broken, I can't even downgrade the kernel with it. What do I do to help fix this? I did do a full backup of my system, so I think I might be able to restore from it, but I'm not sure. In any case, it would be nice to know how to solve this without going to my backup, since it boots up and uses the networking stuff just fine, it's just that I can't update or upgrade anymore...

Hi, I'm not exactly sure where this type of thread goes. If it doesn't go here, can someone please politely move it? Thank you very much! There seems to be a rogue file in the "/etc/sysfs.d/" directory with the file "20-gpu-governor.conf" on my system. This file is meant to tune the GPU governor to "performance", instead of the default "simple_ondemand". But I'm confused as to which package supplies this. It is not supplied by sysfsutils, so maybe it's Armbian specific? Not sure. This file is on Armbian for the Helios64. Here are the contents of the file "/etc/sysfs.d/20-gpu-governor.conf": # Set "performance" GPU devfreq governor, "simple_ondemand" works bad in recent kernels devices/platform/ff9a0000.gpu/devfreq/ff9a0000.gpu/governor = performance Anyway, I just went ahead and APT purged the old-style sysfsutils package, since I wanted to go with something more standardized to systemd, such as tmpfiles.d. I am using this Arch Wiki page as a reference: https://wiki.archlinux.org/index.php/CPU_frequency_scaling#Make_changes_permanent Here is the proposed replacement file "/etc/tmpfiles.d/00-armbian-gpu-governor.conf": # Set "performance" GPU devfreq governor, "simple_ondemand" works bad in recent kernels w- /sys/devices/platform/ff9a0000.gpu/devfreq/ff9a0000.gpu/governor - - - - performance I am not sure about udev. However, it seems that as long as "systemd-tmpfiles-setup" is active, it should always set the governor to performance, I did a test with "cat /sys/devices/platform/ff9a0000.gpu/devfreq/ff9a0000.gpu/governor" and it looks like it returned as "performance", so everything is good. And please, stop using sysfsutils.

Okay, sorry for the multiple posts, by the way. I think I have found a solution for the problem. For my next test case, I just tried uncompressed. I made quick a backup of my `/etc/apt/apt.conf.d/` as `/etc/apt/apt.conf.d.bak/`, and then I edited a few lines. Firstly, I changed the line in `/etc/apt/apt.conf.d/02-armbian-compress-indexes` to this: Acquire::GzipIndexes "false"; Secondly, I changed each line of "KeepCompressed" in `/etc/apt/apt.conf.d/50apt-file.conf` to this: KeepCompressed "false"; Now use this command: rm -r /var/lib/apt/lists/ And run `apt update`. Wait for it to finish, then try `apt search` again. It should work for now! I could provide patch files on request, but I think some simple changes to config files can be done by anyone. I'm going to make sure that daily, sequential runs of `apt update` and/or `apt clean` do not break this. But so far, it's looking good. EDIT on 11 Feb 2021: One more thing I noticed after browsing around in my config files was `/etc/logrotate.conf` has an uncommented line that says "compress". Can anyone verify if commenting that out gets rid of LZ4 compression for APT? I already have the uncompressed solution above working for me, but maybe I can eventually test in the future to see if logrotate is causing any issues. I'm going to guess not, since it really shouldn't interfere with dpkg/APT lists, but maybe I'm wrong.

Now in theory, I could try to manually remove the *.lz4 files only, but that is a hack, and I'm not going to do that. It doesn't actually solve the problem in a concise, concrete way. I feel like the overly intrusive lz4 files are just going to be rebuilt somehow, and there's no stopping them. It's like they are hard-coded in to ruin us ARM users. I also want to correct a mistake that I made. I think `apt update` is actually building both *.gz and *lz4 archives in the `/var/lib/apt/lists/partial` directory the whole time, and not just *.gz Yeah, this is starting to be a really bad problem for people who have updated their systems... worse than I thought. You know what's interesting though, I actually have an Ubuntu 20.04 system, and I compared the `/var/lib/apt/lists` directories, and Ubuntu actually keeps them uncompressed with some .gz files, so the Ubuntu patch must have been changed, or been deprecated, or something. I dunno. This is just weird. It could be something Debian-specific, but that's just speculation at that point. I need to check a proper Debian Live or Debian desktop or something, and find out. Then I can compare the apt.conf files from Ubuntu 20.04 and Debian Buster, and maybe find a solution for this problem on Armbian.

Okay, after looking in `/etc/apt/apt.conf.d/` I noticed there is a higher priority file called 50apt-file.conf, which might be the culprit here. And here's why... First of all, it's a higher priority than 02-armbian-compress-indexes so that means it is going to run after or override those settings, secondly, I noticed a line that says: KeepCompressed "true"; I've never seen this kind of line before, and nothing about this is mentioned in the manpage for `man apt.conf` so this had me really curious.... I looked up that exact option parameter, and ran into this page: https://www.apt-browse.org/browse/ubuntu/xenial/main/amd64/appstream/0.9.4-1/file/etc/apt/apt.conf.d/50appstream This Webpage also mentions a like that says: KeepCompressedAs "gz"; These lines are not located anywhere in the `50apt-file.conf` shipped with Armbian. My thoughts now go in two directions: Is the default compression for `50apt-file.conf` LZ4, or is it gzip? Okay, so I'll add those `KeepCompressedAs "gz";` lines to the end of each stanza in that file, run my test again, reboot, and see what happens.... WOW, okay. Something really interesting and strange happened now. I have both *.gz and *.lz4 files, except for `security.debian.org` It really doesn't make sense to me. Why are LZ4 files still being created? Hmm... I'll run the "apt-search speed test" now anyways.... Yep, still slow! Ugh... it just seems like nothing is working, and I'm running out of options here. Time to look at apt.conf some more....

Okay, okay, listen to this. This is very important. So I tested by clearing out the directory with `rm -r /var/lib/apt/lists/` and rebooting. Then I ran `apt update` and noticed that the files in `/var/lib/apt/lists/partial/` were, indeed, *.gz files. Well this was a good start, I thought. However, when the apt update command completed though, everything was moved out of the partial directory as LZ4 files. What the heck is going on??? So now I need to figure out if the files have been renamed, or have been recompressed because that's an important difference. I'm a bit skeptical at using the `file` command because it only uses the MIME types of files. But using `file` did report it as LZ4. This was odd to me because `apt update` still works quickly. Is the problem here that LZ4 can compress quickly on ARM, but uncompress very slowly? So I ran another test. I had to install rename `apt install rename`, which could rename these files as *.gz instead with the built-in `rename` command, like so... rename 's/.lz4$/.gz/' *.lz4 I thought that maybe I could trick APT/dpkg to handle these files specifically as *.gz since I thought there was no way that after `apt update` it would compress so quickly into LZ4. I was really wondering... When I tried that though, I got these errors: E: Encountered a section with no Package: header E: Problem with MergeList /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-arm64_Packages.gz E: The package lists or status file could not be parsed or opened. E: Encountered a section with no Package: header E: Problem with MergeList /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-arm64_Packages.gz E: The package lists or status file could not be parsed or opened. I ran `file` again, just to make absolutely sure, and I got the same result as last time: It says: "LZ4 compressed data (v1.4+)" Okay, so what the heck is causing this? It really should be gzip compression. I'll keep clearing `/var/lib/apt/lists` try to see if there are any apt.conf rules that can explicitly disable LZ4, because that's stupid. I'm sorry but... wow. What kind of idiot makes a patch to force compression rules like that? I'm also going to look in /etc/apt/apt.conf.d/ and report back....

I am also suffering from this issue on my Helios64. Let's also look at this from a more scientific and engineering perspective with what info we gathered so far... The big problem is why the problem keeps returning for people. Something might be trying to force LZ4 compression on both the apt lists when we are specifically trying to specify gzip instead in the `/etc/apt/apt.conf.d/02-armbian-compress-indexes` file. It might be related to that Ubuntu patch mentioned here: https://forum.armbian.com/topic/14064-my-apt-search-has-become-super-slow-recently/?do=findComment&comment=102968 Or it could be something else. It is a completely different method of compression from gzip compression. It's slower, but gives a higher compression ratio. Seems like most 32-bit or 64-bit ARM CPUs don't optimize for LZ4 well, so Armbian could either try something lighter like gzip, or leave it uncompressed and clean it once in a while, right? By the way, has anyone also disabled their ZRAM and RAM logging? Mine have been disabled. I can't remember if that affects `/var` or `/tmp`. But just for the record, mine is disabled. Okay, so with that in mind I am still working on my own solution to this problem. I think we should really stop using LZ4 (just as a test case), and try out gzip, then uncompressed if gzip doesn't work. I'm going to at least check and see if I get some `*.gz` files to populate in my `/var/lib/apt/lists` directory, then see if that works. If no gzip files show up, then we know something is trying to force lz4, and that's a bigger issue on our hands. If both gzip and uncompressed don't work "quickly enough", then that's also a big issue.

Sure thing. Luckily, it didn't take much time to figure it out. Thanks to the person who answered here: https://unix.stackexchange.com/questions/16578/resizable-serial-console-window/283206 I was able to use something POSIX standard like the "res()" shell function he described to get it working. I just put it in as a bash function in my .bashrc file and had it only call when "TERM=linux" which seems reasonable to me for now, since picocom (and the regular Linux pTTY) always seems to set the TERM variable to that. resize-term() { OLDSTTY=$(stty -g) stty raw -echo min 0 time 5 printf '\0337\033[r\033[999;999H\033[6n\0338' > /dev/tty IFS='[;R' read -r _ rows cols _ < /dev/tty stty "$OLDSTTY" echo "Set cols = $cols"; echo "Set rows = $rows" stty cols "$cols" rows "$rows" } [ "$TERM" == "linux" ] && resize-term

Hi, I have an issue that is irritating me, and I'm not sure what to do about it. So on the Helios64 page (I am also using it with the Kobol enclosure), they give you a simple command like this to use: picocom -b 1500000 /dev/ttyUSB0 This is so you can access a serial TTY without an Internet connection. My problem is that the "window size" is set back to 80x24 characters. I'm not sure why this happens. I've also noticed that it somehow sets "TERM=linux" instead of what I have in my host PC's "$TERM" which is "xterm-256color" Is this by design, or is there something strange going on that I don't understand? The thing is, I would really like to set the terminal screen size to my host's terminal size each time, whether or not I'm using a TTY, or a terminal emulator, or... whatever! It's just so annoying to have to type in "stty cols 240 rows 60" for example with a 1080p screen. Instead, I would just like picocom or some other application, whatever is supposed to be setting the TTY, to automatically set the terminal to whatever the host's is. As an aside, there have also been really strange problems where after using that "stty" command, the serial console may actually freeze. Even after quitting from picocom with Ctrl-A, Ctrl-Q, and launching again, it will still remain frozen. I would like to avoid these freezing problems since the serial TTY is supposed to be super-duper reliable (duh). Now that I think about it, the freezing may have been caused by something else in the past. I haven't had it happen in the past month or so.... So is there any way to do what I want? I would be really grateful for any help!