FanDjango

Members
  • Content Count

    14
  • Joined

  • Last visited

About FanDjango

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. What I sometimes do before I resort to the serial port: If you are starting from sd-card, take it and insert it with a USB adapter on a linux pc. Mount it and look at /var/log to get some hints. Perhaps put some diagnostic commands into /etc/rc.local, like "systemctl status ssh.service (with output into a file)" or whatever (like netstat -tlpen, is port even open?). Especially perhaps try to run "armbianmonitor -u" in there. Reboot, and then take it to a pc again and look at the output. It's a pain but sometimes you can see something while you are waiting for the USB-TTL serial dongle.
  2. They must have a reason. Maybe they are doing a countdown and when they reach 0, they will release a Tinkerboard S+
  3. Okidoki, I know what to do now. Half of our stuff is on Stretch already by now. I will expedite moving the rest. Thanks.
  4. As I said, I understand. Everything is ok. And now that I have been informed that Jessie is the root cause, I now know what I can do. I consider that to be friendly advice and good support. Thank you. I have the feeling that my only error was to stay with Jessie so long. Similarly, another error some days ago was to upgrade from 4.14 to 4.19. All else is a direct result of those two bad decisions. I am not aware of any other errors currently. So how long will Armbian Stretch be viable or should I go for Bionic, to have another years peace and quiet, in your opinion. Just opinion and advice, I won't nail you to it.
  5. Ok, I understand. But so sorry, I downloaded this image in the early days, more than a year go, can't even remember - could even be end of 2017, probably beginning of 2018. Right when XU4 support began in Armbian. Still have many XU4s on Jessie. You used to have Jessie on the site to download. I am sure that you might remember. This is Armbian Debian Jessie, OMV I installed myself on top of it. Been running it continuously ever since - and have no opportunity to Jessie->Stretch. Nevertheless, I just posted this to inform you of what happened. I wasn't expecting any action - I solved the problem myself in a quick and dirty fashion, just wanted to pass it on. I don't quite understand the paranoia - I couldn't have downloaded this Armbian anywhere else and if it is suddenly too old to be considered in the code, I will take that into account and update to Stretch as soon as I have time or choose some other distro, although on some of the other Jessie systems of mine, that move has many consequences for the software running on them. But if supported Armbian stuff can just dissappear suddenly, maybe it would be nice to know in advance what the lifetime of Armbian Debian Stretch will be so that one can plan on that.
  6. Thanks for the info. Meanwhile I have found and solved my issues with armbian-config / system / other not working. I have opened up a separate issue concerning that. https://forum.armbian.com/topic/9361-armbian-configsystemother-fail-3-issues-on-my-system/
  7. I needed to downgrade from 4.19 back to 4.14 so I wanted to use armbian-config/system/other. It gave me an empty list. To fix that, in /usr/lib/armbian-config/functions.sh I needed to change the apt-cache command as follows: apt-cache show linux-image-next-odroidxu4 | grep -E "Package:|version:|Version:" | sed -n -e 's/^.*: //p' | sed 's/\.$//g' I added "-next-" That gave me a list, finally. Then the next issue: apt -s -y --allow-downgrades --no-install-recommends install linux-image-next-odroidxu4=5.60 linux-dtb-next-odroidxu4=5.60 failed with: E: Command line option --allow-downgrades is not understood I needed to remove the "--allow-downgrades", no longer necessary, seemingly. Finally, the aptitude remove command also needed to be given the "-next-": aptitude remove ~nlinux-image-next-*${LINUXFAMILY} --quiet=100 -y >> /var/log/upgrade.log 2>&1 Then the process worked perfectly and after reboot, the downgrade became active.
  8. Could one of the armbian gurus comment on this statement by hardkernel? because then I would worry that some other specific XU4 or ordroid features might have silently dissapeared after the upgrade from 4.14 -> 4.19
  9. I'm happy with console=tty0, it works. But next time I hook up the headless board to HDMI, I will also try console=serial. Note that the original was not console=both. It was (at least on my tinkerboard S): console=ttyS3,115200n8 verbosity=7 fdt_file=rk3288-miniarm.dtb console=ttyS3,115200n8 rootdev=UUID=24a05491-1fbb-4a44-894d-f3dbef5f721b rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
  10. Ok, here is what I found out about 4.14.xx vs 4.19.xx on Odroid XU4: Ok, I've never gone backwards before. I'm back to the original question: After switching back in armbian-config, after a reboot, Nothing happens. LOL - a solitary update for armbian-config just came in. I installed it in the hopes… but now it doesn't give me a list of possible other kernels like before - it says 'No other kernels available'. Ok, I'll do it the hard way, I have backups...
  11. Even if you specify verbosity=7, there are no boot messages. But if you ALSO specify console=tty0 instead of console=ttyS3... the boot messages will appear,
  12. Odroid XU4 with Cloudshell2 Coming from 4.14.69, upgraded to 4.19.14 The fbtft_device module for the Cloudshell-LCD now reports: fbtft_device: display not supported: 'hktft9340' And yes, the source for fbtft_device seems to no longer contain hktft9340. I will ask in the Hardkernel Forum - this is just for info here. Question: When I use armbian-config to switch to an earlier package, I get a nice list, I select one and say ok, but after reboot nothing has changed. Is there something I could be missing in order to make this switch work? Never tried it before - I was hoping this would help me temporarily.
  13. Read the entire thread to find out how to see boot messages on HDMI, which were not appearing even if verbosity=7. Turns out you need to specify console=tty0 in armbianEnv.txt instead of console=ttyS3...…..
  14. I had the same problem. After some googling and reading, I found the following (abbreviated) solution and explanation: In /etc/console-setup there are "cached…" files, whose time-stamp might preclude the script that should execute setupcon from actually doing this. I deleted all "cached_...." files in /etc/console-setup and then rebooted - suddenly my armbian-config of the keyboard was working.