mrjpaxton

  • Content Count

    8
  • Joined

  • Last visited

Everything posted by mrjpaxton

  1. 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
  2. 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
  3. 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 sta
  4. 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 thi
  5. 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 th
  6. 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&a
  7. 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
  8. 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" I