alpe Posted October 1, 2019 Posted October 1, 2019 Clean Armbian Bionic 5.3 install. Login with root/1234. It asks for a new password. I type it, and the connection is closed. I tried many passwords, all the same.
martinayotte Posted October 1, 2019 Posted October 1, 2019 7 minutes ago, alpe said: Login with root/1234. Don't forget that it ask for 1234 password twice, and then ask for new one, which required to be "not simple" (ie : use some mix of uppercases/lowercases and numbers)
alpe Posted October 1, 2019 Author Posted October 1, 2019 Thanks and sorry. It was probably this. I have been solving a lot of things the entire day and I missed this simple thing. I rebooted my board and it is taking forever for it to get an ip. Maybe because it is doing the "first boot" config again since I don't finished it the first time. Will update once it boots.
alpe Posted October 1, 2019 Author Posted October 1, 2019 55 minutes ago, martinayotte said: Don't forget that it ask for 1234 password twice, and then ask for new one, which required to be "not simple" (ie : use some mix of uppercases/lowercases and numbers) Yes, this was the problem. However there is another one. Every time I reboot it's taking about 20 minutes for it to request an ip and become online.
Igor Posted October 1, 2019 Posted October 1, 2019 29 minutes ago, alpe said: Every time I reboot it's taking about 20 minutes for it to request an ip and become online. Whenever you ask for help, supply logs. Without, we know little to nothing. armbianmonitor -u
alpe Posted October 1, 2019 Author Posted October 1, 2019 45 minutes ago, Igor said: Whenever you ask for help, supply logs. Without, we know little to nothing. armbianmonitor -u I rebooted it, and after 40m of waiting for network I gave up and flashed it again. Now, first boot log:http://ix.io/1NEc I rebooted it now. It will probably take 20 minutes or more for it to become online. When/if it does, I'll run the armbianmonitor again and update here. Sadly I don't have a USB -> serial adapter, so if network don't connect I won't be able to run it. I guess if that happens I can put this on rc.local: sleep 60 && armbianmonitor -u >> someplace Edit: This wouldn't work, since it uploads to internet, duh. Does it have a parameter to output directly to stdout instead of uploading? (still waiting for the board to boot, so I can't check there) Update: After the reboot, the network led stays off. It turns on for a few seconds, as usual, and then turns off and stays off. The heartbeat led is flashing as expected.
Igor Posted October 2, 2019 Posted October 2, 2019 7 hours ago, alpe said: the entire day Well. If it works, works. Remember we don't support C1 - I hope you did notice that? ... because this "small" problem could lead in wasting hours to weeks. Which is out of range. On a quick log scan it network seems alright. It gets up. You will need to get console and see ... Last time I was testing my C1 it was working normally. Network went up, USB ports were working and IIRC even DVFS is operational. Almost all but HDMI.
guidol Posted October 2, 2019 Posted October 2, 2019 @alpe as it is sn amlogic sbc you could try to install rng-tools to fill your random-number-pool faster. if the pool isnt filled you couldnt ssh until your c1, because ssh-server needs these random numbers. you could check the time how long it takes with dmesg|grep random after the installation of the rng-tools (apt install rng-tools) it should be much faster (normally under a minute) see also about the boot/ip/ssh problem the following thread: @Igor do you remember my first pull-request for rng-tools as a default package for amlogic-devices?
Igor Posted October 2, 2019 Posted October 2, 2019 4 hours ago, guidol said: do you remember my first pull-request for rng-tools as a default package for amlogic-devices? Yes, hmm. That should be present.
alpe Posted October 2, 2019 Author Posted October 2, 2019 8 hours ago, Igor said: Well. If it works, works. Remember we don't support C1 - I hope you did notice that? ... because this "small" problem could lead in wasting hours to weeks. Which is out of range. On a quick log scan it network seems alright. It gets up. You will need to get console and see ... Last time I was testing my C1 it was working normally. Network went up, USB ports were working and IIRC even DVFS is operational. Almost all but HDMI. Yes I know. That's why I posted on "Peer to peer technical support". I though it would be ok. Yes, it used to work. I was using for a few months with no problem, and building/updating the firmware from time to time. After updating to 5.3 this problem occurs. I formatted my sd card and downloaded the full image from the site to start over. And same problem. I downloaded the official odroid image to see if the problem was my board, and it worked. I'm trying to find the 5.2.y image somewhere but I can't. :/ On the site it says 5.2.y, but the link if for 5.3. Just found the 5.1.y somewhere on my hdd. Will flash it and not update again. Update: 5.1.y works as before. 7 hours ago, guidol said: @alpe as it is sn amlogic sbc you could try to install rng-tools to fill your random-number-pool faster. if the pool isnt filled you couldnt ssh until your c1, because ssh-server needs these random numbers. you could check the time how long it takes with dmesg|grep random after the installation of the rng-tools (apt install rng-tools) it should be much faster (normally under a minute) see also about the boot/ip/ssh problem the following thread: @Igor do you remember my first pull-request for rng-tools as a default package for amlogic-devices? Thanks, while this could be causing the first boot to take way longer than it should, I don't think it apply to the network not coming up after reboot.
cmeerw Posted October 6, 2019 Posted October 6, 2019 I ran into the same problem yesterday. Didn't really try to analyse it in detail, but it looked like it didn't set up the network correctly after the first boot. What I did to fix it was essentially uninstalling network-manager and configuring the interface instead in /etc/network/interfaces (as dhcp). One other thing I noticed was that one script was failing because of a missing "iozone" test run (but not sure if that then caused the network configuration issue).
Recommended Posts