• Content Count

  • Joined

  • Last visited

About EtlARM

  • Rank
    Advanced Member

Recent Profile Visitors

716 profile views
  1. As I asked the same question some time ago, this thread may help . . .
  2. All motd messages are created by scripts located here: /etc/update-motd.d/ To get another name displayed, I always change /etc/update-motd.d/10-header #TERM=linux toilet -f standard -F metal $BOARD_NAME TERM=linux toilet -f standard -F metal $(hostname -s) ... or whatever you like as name.
  3. Could anybody give a hint where to find the script that is executed during kernel upgrade? Than we could start some high level debugging.
  4. With every upgrade I struggle with a "changed to default" login welcome message and have to do my modifications again. Therefore I would like to explain my changes and hope you can integrate them in the default version...: Your welcome message prints the $BOARD_NAME as ASCII art. Probably you have dozens of boards and can distinguish them in this way. So after login-in you directly see which board it is. I have only one type of "boards" (Cubietruck) and distinguish them by their hostname. So I have to replace "$BOARD_NAME" with "$(hostname -s)" in /etc/update-motd.d/10-header to identify my boards. What do you think about a change in that direction?
  5. Just did the 5.23 -> 5-25 upgrade on a Cubieboard2 (with NAND). Everything went fine! In case someone tries to replicate the problem I mentioned, here a list with things that were different to your test setup: Debian Jessie Server instead of Xenical SATA disk connected and mounted as /backup SD card connected and mounted as /var/ftp/sdcard old system was installed and last updated in summer 2016, so maybe another version and different update level of all packages
  6. Is this problem back again? I also experienced problems with the 5.24 (or was it 5.23?) upgrade made during Christmas. It also bricked the system on NAND, but I don't remember what went wrong. I reinstalled from scratch because no supporting tools where available far away from home. With the right tools to hand it should be possible to recreate the boot files on NAND with the help of the linked thread. As I have to do the 5.25 upgrade in the next days, I would appreciate when this problem gets sorted out sooner than later...
  7. You have to load the correct kernel module to enable watchdog support in general: nano /etc/modules # and append this somewhere (reboot afterwards) sunxi-wdt And you have to install the watchdog package: apt-get install watchdog It is possible to configure some more stuff here: nano /etc/watchdog.conf But I have the feeling that it works just out of the box. I would appreciate if you could post your experience with that settings.
  8. Hi, I'm using the CubieTruck with legacy kernel and also searching for watchdog support. As far as I can figure out, the kernel seems to be compiled without watchdog support: /dev/watchdog is not present and /var/log/syslog does not contain anything with sunxi_wdt
  9. End of last year I received several faked Samsung EVO 32G, therefore I bought a Samsung Pro 32G: Tested on CubieTruck, Armbian 5.11, ext4, card is used for 7 month, system is doing some minor background work.
  10. You have to redo the change described in that post for every upgrade. The upgrade affects also the file /boot/bin/cubietruck.bin so your changes get lost.
  11. Yes, it is very likely the same or similar problem. On my NAND1 I found only a zImage identical to the vmlinuz file but not an uImage. When creating an uImage it is binary different than the zImage. (Expected behavior, as uImage can be a zImage with additional header.) I will do more tests (e.g. booting) when I find some spare time and the serial cable has arrived...
  12. I ordered this one: Amazon PL2303HX USB to TTL Probably shipped from China, so further details from my side will be earliest next month...
  13. Any recommendation for buying a serial cable to get that console boot log?
  14. I did not change system settings, except minor modifications to script.bin (VGA mode and LEDs). NAND1 was mounted as /boot (and NAND2 as /). Probably it was bad luck or a weak power supply (I doubt that, as I also have the battery connected). But as I migrated to SD card anyway, I will stay there for the near future. Maybe I will find some time during the next days to compare the kernel files from NAND1 and SD card. But as this is my "production" system, I would like to avoid additional down time.
  15. "Good" to hear other have the same problem... after the workaround went fine on my CubieBoard2 I bricked my production system CubieTruck the same way, you described. The workaround trick went fine on the CubieTruck. But after reboot the system does not start anymore: red power LED near power jack is lit network LEDs show some activity SATA disk stays off front LEDs stay off VGA has no signal no other reaction observable I had similar NAND boot problems in the past, so I assumed it is the same case again. The last time it was sufficient to leave the board unpowered for some hours (discharging battery a bit), but this time nothing helped. So I migrated my complete system back to SDCARD, and it is working like before. After thinking a night about the problem, it might be sufficient to manually update all kernel files on NAND1. I did not test that. Do you have a serial cable to watch the boot output? (I don't have one.)