Jump to content

sulfum

  • Posts

    2
  • Joined

  • Last visited

  1. Hi everyone, I did some testing in the past days (no UART boot logs though): Deelan suggested that the boot problem may stem from uSD card due to the voltage error message. Hence, I have made two things: Made an image of the current Armbian Fossa install (which is btw on a Kingston 32 GB uSD) and wrote it to a Samsung 32 GB uSD. Behavior did not change. I made a fresh install of Armbian Focal and I chose for an older version 21.08.1: this release from 26-Aug-2021. In short, it, of course, booted up without any issues. I could soft reboot it several time without any issues... the I ran apt update && apt upgrade. The system was brought to the current state (i.e. 21.08.6). The system rebooted ad came online just fine after system/kernel update. All following attempts to reboot the system led to the dark silence. For the note, I have tested it with and without HDDs just in case. The result was the same. For the sake of testing I installed Armbian Bullseye 21.08.1 on the Samsung uSD. The result was the same as for fresh install of Armbian Fossa: 21.08.1 booted up and I soft rebooted it about 10 times with no issues, when the system was updated to 21.08.6, it came online from a soft reboot the first time after update, any follow up attempt of a soft reboot led to dark silence and the system could be brought back online only by unplugging the system. In summary, it looks like Cornelius is right and some of the patches, which were submitted and accepted in the meantime, rendered soft boot of the board/amlogic SoC impossible. I guess I have to cope with it as it is now and shutdown/cold boot the system after each kernel update. Hope that someone with knowledge of this business will get down to the core of the problems (e.g. revert some of the late changes). If there is anything that I can test further.
  2. Hi everybody! I would like to add my two cent to this discussion. I face similar problem with HC4 (not much difference with C4 as Igor pointed out). I run this board under Armbian Focal and got it updated a few hours ago and the board was not coming back online: no heart bit LED, HDDs spinning but heads seem to be parked, Ethernet showing 1 Gbps speed both on the board and on the switch. I had the same problem this Monday after I updated the board and the kernel but then network stack did not work until I restarted the board once again. I intend to use this board with 2x 4TB HDDs as a backup server for critical company data from the main ZFS@FeeBSD bare metal server and inability to do soft reset makes administration if this system less straightforward that usual. At the moment of writing HC4 here rocks following software/firmware: U-Boot I have faced this issue with the HC4 server not being able to come online from a soft reboot a few time now. After some further research I came to a conclusion that it has little to do with kernel update itself but the board seems to boot somewhat differently from when it is a cold start as opposed to soft reboot. I have looked into kernel log and went through syslog, there is nothing bizarre there, all shutdown routines finish just fine: I had my encrypted RAID1 with LVM on top of it as one of the suspects but everything gets nicely unmount, LVM got stopped, and the whole system gets nicely shutdown. The interesting part seems to start at the boot: I hooked up a monitor and a keyboard to the server to see what is going on there. I cannot capture output in any proper way (had to film it with my smartphone) but, it it helps, I can arrange it tomorrow or next week as I have serial to USB adapter at home but not here at work. In short I see the system spits following messages: and this continues for a while until (what seems like) the option in pxelinux.cfg are exhausted and then it just yields and got stuck there. If I issue reset command in U-Boot the whole cycle continues. This does not happen upon cold boot. And by the way, I boot Armbian with mainline U-Boot with the 'old' approach: I have deleted 4 partitions of petitboot (i.e. mtd0 through mtd3) can this somehow interfere with U-Boot here? Is this helpful? Should I capture full U-Boot output via serial and post it here later? Thank you for your time!
×
×
  • Create New...