Reputation Activity
-
I finally created SDCard with android 4.2.2 with PhoenixCard from here and android image from here . It's old but it works. One problem is mounting an internal SD card. Android detects SDCARD as external with a, b c partitions. I tried to change fstab to mount partition 3 from sdcard , but no success (works only via terminal like #mount /dev/block/mmc /sdcard/ .
-
gas_85 got a reaction from Whoami in OFFTOP Android TV/Libreelec/Media center on CubieTruck (A20)Hey I try 2 images - stable and nightly (LibreELEC-A20.arm-9.80-devel-20191230203035-9d103bd-cubietruck.img.gz and LibreELEC-A20.arm-9.80-nightly-20200201-a869d6c-cubietruck.img.gz), but after SD card resizing it is coming nothing on the display, seems I have the same error as you described on other forum. Currently I have no cable to connect to the SSH and try to solve it. Sad, but it does not really work out of the box with Cubietruck.
-
There is no need to do such backup, since your "rootfs" is on the HDD.
Simply reburn image on new SDCard, do the initial boot setup (passwd & new user), then edit /boot/armbianEnv.txt so that "rootdev=UUID=" point to you HDD according to "blkid" report.
-
gas_85 reacted to RenatoL in DNS resolvingI have a similar problem and that solved:
sudo dpkg-reconfigure resolvconf according to this post:
-
sudo modprobe tun If this fixes the error for you, you should add
tun to /etc/modules (on a new line)
-
Take a look at /etc/cron.daily/armbian-ram-logging - might want to comment that line as well...
In any event - the services and crontab entries for ramlogging at well intentioned to keep pressure off the flash, so step carefully...
-
Long story short - it's a chained series of events that gets one to here...
in systemd... (nice that these are in systemd - I have no skin in the whole systemd discussion other than to recognize that it's there)
armbian-ramlog.service
armbian-zram-config.service
One can disable them easily enough by just doing systemctl...
the crontab tip is good...
To get zram back - install zram-config, and for the log stuff once the ramlog is disable (along with the crontab entry), look at logrotate...
-
Symptoms:
Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
Following or similar output can be grabbed from the serial console:
U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
Most likely cause:
Malfunctioning microSD slot card detect switch.
It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
Illustration (example) of a working switch:
Verification (with a multimeter):
Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
No card - circuit is open
Card inserted - circuit is shorted
Photos - card is not inseted on the left and is fully inserted on the right:
Orange Pi
Pine64 (switch is more visible)
Can it be fixed?
Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.
-
gas_85 reacted to Bernie_O in [SOLVED] Cubietruck strange CPU load after purge rpimonitor on 5.36 in headless modeNow that you wrote that, I also remember, that it took quite a while for the „freeze“ to disappear. So all you have to do is being patient ;-)
-
gas_85 reacted to Igor in [SOLVED] Cubietruck strange CPU load after purge rpimonitor on 5.36 in headless modeThis is normal. We only pushed an update to packages which had some troubles - board support and left others as is.
I started with a clean image made from sources and could not reproduce problems you have. Here is my armbianmonitor -u: http://ix.io/DLr
It was wrong permission for this file: /etc/cron.d/armbian-updates
-
gas_85 reacted to Bernie_O in [SOLVED] Cubietruck strange CPU load after purge rpimonitor on 5.36 in headless modeI also had this problem after updating to 5.36. I then noticed a permission error in /var/log/syslog. Once I corrected the permissions of the appropriate path/file the welcome-screen did not „hang“ anymore with old information.
Unfortunately I can‘t remember which path or file I had to change the permissions, but it was clear when I saw the error in syslog.
Hope that helps at least for that „hanging“-with-old-information issue.