• Content Count

  • Joined

  • Last visited

About FanDjango

  • Rank

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 ar
  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 opin
  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.
  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.
  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/ 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=
  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? Nev
  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.