denox

I wish you didn't move a topic outside technical support because of an unrelated comment from someone beyond the author of the thread. Unlike that comment from a user on Jessie, I am using Stretch and use all the latest packages. The original issue that I reported is very much an issue related to Armbian. As a workaround, I've installed the latest version of armbian-config and use the mirrors.netix.net mirror over HTTP. At the same time I've just upgraded to 5.70 (from 5.60) and 4.19.13-sunxi. Unfortunately, no changes to my issue. The mirror workaorund is no fix, but it's at least a way to stay current with Armbian package updates over HTTP. Having said that, I would really like to be able to use HTTPS without issues. Beyond impacting APT, this issue is also impacting GIT. As I can't clone any GIT repo over HTTPS.

Shameless bump as I'm still experiencing this issue. Any suggestions from anyone?

Hi, For the longest time, I've had this issue, but it never really bothered me much. All git updates can be done through git:// and the source lists that I require are still on HTTPS. Since the apt.armbian moved to HTTPS I've been experiencing the following apt-get update error: Reading package lists... Done E: Method https has died unexpectedly! E: Sub-process https received a segmentation fault. E: Method /usr/lib/apt/methods/https did not start correctly I'm currently on ARMBIAN 5.60 stable Debian GNU/Linux 9 (stretch) 4.14.70-sunxi and would love to get HTTPS working again over apt. My system details here: http://ix.io/1s6m It's not an issue with the sources.list file itself as that contains the HTTP protocol. And that you redirect the request to HTTPS is only a good thing. $ sudo cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com stretch main The issue is that my HTTPS method is broken, and I can't seem to find a way to fix it. I've tried reinstalling everything reported through debsums, but no changes. Looking forward to your suggestions on how to fix this HTTPS and APT issue. Thanks!

Just letting you know that I undid the kernel freeze about two weeks ago and upgraded to the latest stable release. Since then I've been running fine (for 14 days now) on ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.14.18-sunxi. * linux-dtb-next-sunxi 5.41 * linux-headers-next-sunxi 5.41 * linux-image-next-sunxi 5.41 * linux-stretch-root-next-lime2 5.38 * linux-u-boot-lime2-next 5.371 Since my last report of this issue in late February, I've done some clean-up on packages, disk space and cron jobs as I often have mariadb v15.1 resulting in an out of memory event on my A20 Lime2 machine (1GB memory) while I run my nightly update script (apt, git, composer, npm, pip). This is even after some fine-tuning and achieving a maximum possible memory usage for mariadb of 351.6M (35.30% of installed RAM). Annoying, but not a big issue. This clean-up activity may have helped with preventing the unresponsiveness issue from occurring again. The only other difference is that I'm now on 4.14.18-sunxi instead of 4.14.15-sunxi. Perhaps that's what resolved it? Eitherway, my issue has now been resolved. Thanks!

We're 13 days later and I'm happy to report that I haven't experienced any crashes or issues on this quoted setup (downgrade to 5.35 for dtb, image and u-boot).

Thank you for the updated kernel/fix. Unfortunately, it still results in similar behavior for me as well. I'm currently trying out the following combination based on Igor's recommendation to downgrade. I also froze kernel updates via armbian-config. * linux-dtb-next-sunxi 5.35 (both 5.38 and 5.41 resulted in similar behavior) * linux-image-next-sunxi 5.35 (both 5.38 and 5.41 resulted in similar behavior) * linux-u-boot-lime2-next 5.35 (5.371 resulted in similar behavior) * linux-headers-next-sunxi 5.41 (didn't roll this back, let me know if I should; I'm asking because it's frozen through armbian-config) * linux-stretch-root-next-lime2 5.38 (didn't roll this back, let me know if I should; I'm asking because it's frozen through armbian-config) I'll monitor and report back.

I'll keep monitoring my machine, without some services running, to see if it crashes again to try and isolate whether or not it is power (or peak) consumption related. After the next crash I will also roll back the kernel and try again.

Hi all, I've been using the A20-Lime2 together with Armbian for about two years now and I love the effort that the developers and the community have put into this amazing product. Until not too long ago I was on Debian 8 (jessie) on the legacy kernel for webcam compatibility reasons (after having tried switching to mainline from time to time). With the release of Debian 9 I finally had everything that I was looking for in the mainline kernel so I decided to upgrade to Debian 9 and then switch to the mainline kernel. I'm currently on ARMBIAN 5.38 stable with 4.14.15-sunxi and just had to force a reboot. The server I'm running is mainly a webserver, emailserver and home monitoring server (webcam). It also sends me things worth looking into periodically to email using logcheck. I'm no expert by any stretch of the imagination and consider myself more of a linux enthusiast with some basic knowledge and a lot of patience to research and experiment. Since my upgrade to stretch and mainline kernel I've noticed sporadic freezes (which brings back memories of years ago with power supply, before changing my setup). I believe it may have something to do with mysql and/or php-fpm consuming a lot of memory. Logcheck warns me of a kernel panic from time to time and forces a restart of mysql. I actually have a daily restart of services script to avoid those services from clogging up too much memory. The freezes are unrecoverable (after waiting several days). While the kernel LED is still indicating activity, as is the LAN light, nothing is responding otherwise (not through debug UART, not through SSH or web or any other port, not through HDMI output [no signal]). Prior to my upgrade, so while I was on legacy kernel and jessie, I had uptimes for about 6 months until I rebooted for a security update, and then another uptime of again 6 months before I decided to upgrade to stretch. It's why I don't believe it's related to my SD card, or power setup (USB OTG), or USB peripherals. As I'm writing this I am going to disable mysql and php services for a while to see if I still get the freeze or if my initial suspicion about memory hogs/kernel panics may be correct. I've had these freezes occur several times, and after it occurred the last time I decided to do a system check-up, fix some minor things and run some diagnostics (based on a topic on providing debug output from tkaiser). You can see that initial debug output here: http://ix.io/F9A from 2/2/2018. After freezing up again when I was reading RSS feeds (through tt-rss) on my own hosted webserver, I waited a couple of days and forced a reboot today. That debug output can be found here: http://ix.io/Fmj from 2/6/2018. I noticed that both outputs have the same shutdown log (from 1/28 when I was on 4.13.16-sunxi), I'm not sure why that is, or if that will help or prevent troubleshooting assistance. Hopefully with this background and details someone will be able to spot something that looks off, or some explanation as I'm hopeful to identify and resolve the issue. Update on 2/6 at 8:10 PM: after reading this post on (under)powering an SBC through Micro USB, I wanted to clarify that because of some mistakes that I had made about 2 years ago, my A20 LIME2 cannot be powered on through it's PWR jack. I somehow must have messed that up and as such I have been using USB OTG to power my board. Again, I don't think that this is the cause as I have a good power supply (had issues with that 2 years ago and bought a good one) and haven't had issues on the legacy kernel in the past 2 years, but it's always possible that the mainline kernel responds differently to power fluctuations (or causes them more so). I'm running the armbian monitor submodule (since 9 AM this morning) that reports loads and DC-IN every 5 seconds to see what the latest reported data is upon crashing (if it crashes again now that I have turned off php/mysql/dovecot/postfix services). So far, in the past 11 hours, I'm seeing (of 7337 measures): * CPU min: 528Mhz, max: 960Mhz, average: 915Mhz * Load min: 0.06, max: 2.7, average: 0.49 * CPU load min: 2%, max: 100%, average: 18% * CPU temp min: 41.4°C, max: 50.4°C, average: 43.8°C * DC-IN min: 4.86V, max: 5V, average: 4.96V