alwi Posted February 5, 2020 Posted February 5, 2020 (edited) Since 10 days I try to install NextcloudPi on Odroid HC1. Unfortunately neither the nextcloud image nor the armbian image boots on the Odroid HC1. Also an attempt with OMV failed. In my experience with the raspi, the sd card had to have a boot partition and a rootfs partition. Etcher and dd always create only one rootfs. The blue LED flashes: short, short, pause. Also exchanged hardware was unsuccessful (HC1 and SD cards). Edited February 5, 2020 by alwi
NicoD Posted February 5, 2020 Posted February 5, 2020 You could try with the stock kernel. There's been boot problems with mainline kernel and the HC1. 5 minutes ago, alwi said: In my experience with the raspi, the sd card had to have a boot partition and a rootfs partition. That's on the Raspberry pi, not the same with official Armbian. Only one partition is used.
alwi Posted February 5, 2020 Author Posted February 5, 2020 10 minutes ago, NicoD said: You could try with the stock kernel. There's been boot problems with mainline kernel and the HC1. I'm a beginner in this field. Would you please help? 11 minutes ago, NicoD said: That's on the Raspberry pi, not the same with official Armbian. Only one partition is used. This was essential for me. So far, no one has had an answer. Thanks
NicoD Posted February 5, 2020 Posted February 5, 2020 1 hour ago, alwi said: I'm a beginner in this field. Would you please help? Try this image instead. https://dl.armbian.com/odroidxu4/Buster_legacy_desktop
Igor Posted February 5, 2020 Posted February 5, 2020 3 hours ago, alwi said: The blue LED flashes: short, short, pause. We fixed problems with a modern 5.4.y kernel only 4 days ago - images were not updated yet. Wait for new images or build image on your own. If you can't wait for modern kernel or you are unable to DIY ... and you want to install OMV, this will be the best image: https://dl.armbian.com/odroidxu4/Stretch_legacy Most recent OMV, that runs on Buster, is not ready (out of our power to fix) for beginners.
martinayotte Posted February 5, 2020 Posted February 5, 2020 54 minutes ago, alwi said: Both images do not work, sadly. Did you check boot log using Serial Debug port ?
alwi Posted February 6, 2020 Author Posted February 6, 2020 @martinayotte Thats new to me, please help me.
martinayotte Posted February 6, 2020 Posted February 6, 2020 5 hours ago, alwi said: Thats new to me, please help me. All SoC boards usually have a 3 or 4 pins Debug header. So, you can attach a Serial-TTL Debug USB dongle there, such as this one : https://www.ebay.ca/itm/Economic-USB-to-TTL-Converter-CH340G-STC-5V-3-3V-6Pin-Uart-Serial-Adapter-Module/252471831265 This will allow you to see all debug traces and figure out which boot steps are blocking and prevent to reach login prompt ...
jshc1 Posted February 7, 2020 Posted February 7, 2020 On 2/5/2020 at 4:09 PM, alwi said: Since 10 days I try to install NextcloudPi on Odroid HC1. Unfortunately neither the nextcloud image nor the armbian image boots on the Odroid HC1. Also an attempt with OMV failed. Are you sure you're doing everything right? Not long ago I tested buster and 4.14 on HC1 and it was ok. Until recently there was a problem with 5.y on HC. And as @Igor said, wait or make yourself. Or just start with buster and 4.14 and for some time when 5.x will be stable for HC then you will change. As for OMV and clouds, I don't know what exactly doesn't work for you. For omv use armbian-config. But remember that omv 5.x is still beta. I still use 4.x because of 5.x there are a lot of problems all the time so I prefer to wait until the end of the year. You can run the clouds in the docker ... If you prefer video help, watch "Techno Dad Life" has a lot of material about OMV and docker but on x86 basis so you will have to show some independence in adoption. As for HC1, try this one https://dl.armbian.com/odroidxu4/Buster_legacy don't worry, let etcher take care of the partitions. It should work ... If it still doesn't work and somehow this is a problem with 20.y then maybe https://dl.armbian.com/odroidxu4/archive/Armbian_19.11.6_Odroidxu4_buster_legacy_4.14.161.7z Or go into old age and just install stretch 19.x / 4.14.x for me on HC1 works 100%. If that doesn't work, then you either do something wrong or you have hardware problems. https://dl.armbian.com/odroidxu4/archive/Armbian_19.11.6_Odroidxu4_stretch_legacy_4.14.161.7z 1
alwi Posted February 10, 2020 Author Posted February 10, 2020 Thank you for your advice. My most urgent wish at the moment is to have an OS running on my hardware. Among the 4 people involved Nextcloud-Odroid, Armbian, Balena-Etcher and myself I have to find the problem. For this I will quote my text to Balena: -- In the meantime I was on other forums: (Nextcloud) Odroid and Armbian. I could not find a solution. For me as an outsider it is difficult to determine where the fault lies. So far I have already exchanged the hardware without success. I have flashed OVM and Armbian in 3 variations on the SD card. I verified the image files and checked the checksums. Could I exclude the errors in the images? Can the same hardware errors occur twice? Is my installation of Belena-Etcher faulty? With the command dd I found the following peculiarity: sudo dd if=Armbian_20.02.0-rc1_Odroidxu4_stretch_legacy_4.14.165.img of=/dev/mmcblk0 bs=1M [sudo] Passwort für xy: 1076+0 Datensätze ein 1076+0 Datensätze aus 1128267776 bytes (1,1 GB, 1,1 GiB) copied, 0,519291 s, 2,2 GB/s This means nothing was copied. This I had never before. In such a constellation I have heard for 30 years that the buck always lies with the others, including me. ---- Where do I start best with troubleshooting in a targeted manner?
jshc1 Posted February 10, 2020 Posted February 10, 2020 2 hours ago, alwi said: Thank you for your advice. My most urgent wish at the moment is to have an OS running on my hardware. Among the 4 people involved Nextcloud-Odroid, Armbian, Balena-Etcher and myself I have to find the problem. For this I will quote my text to Balena: -- In the meantime I was on other forums: (Nextcloud) Odroid and Armbian. I could not find a solution. For me as an outsider it is difficult to determine where the fault lies. So far I have already exchanged the hardware without success. I have flashed OVM and Armbian in 3 variations on the SD card. I verified the image files and checked the checksums. Could I exclude the errors in the images? Can the same hardware errors occur twice? Is my installation of Belena-Etcher faulty? With the command dd I found the following peculiarity: sudo dd if=Armbian_20.02.0-rc1_Odroidxu4_stretch_legacy_4.14.165.img of=/dev/mmcblk0 bs=1M [sudo] Passwort für xy: 1076+0 Datensätze ein 1076+0 Datensätze aus 1128267776 bytes (1,1 GB, 1,1 GiB) copied, 0,519291 s, 2,2 GB/s This means nothing was copied. This I had never before. In such a constellation I have heard for 30 years that the buck always lies with the others, including me. ---- Where do I start best with troubleshooting in a targeted manner? Maybe not use dd .... 1. Install the latest version of balenaEtcher. 2. Make sure your sd card is ok and the system is able to save files / create partitions on it. 3. Download the correct Armbian file, maybe https://dl.armbian.com/odroidxu4/Buster_legacy 4. Extract Armbian from 7z. 5. Run balenaEtcher (as root) select the Armbian_20.02.0-rc1_Odroidxu4_buster_legacy_4.14.165.img and write to the card. 6. Must work. If nothing is dumped on the sd card then try on a different system / sd card. If that's such a problem then I can make a clean copy of the system with the help of acronis true image and you will use it ... But I don't see such a need.
alwi Posted February 10, 2020 Author Posted February 10, 2020 @jshc1 Thanks for the instructions, which I had in principle already executed several times (also with other images). As I made my experiences with the RPi 3 and 4, I always waited for a green LED to flicker. But I always saw only one blue LED shining rhythmically "blink, blink, pause, ..." every second. Now I see the device as "odroidxu4" in the network. That means I could access it with ssh. ssh ??@odroid-IP. What's the name before "@"? ssh odroid@IP gives back: "reset by IP port 22"
martinayotte Posted February 10, 2020 Posted February 10, 2020 9 minutes ago, alwi said: ssh ??@odroid-IP. What's the name before "@"? On "virgin" Armbian first boot, "root" with "1234" as password !
alwi Posted February 10, 2020 Author Posted February 10, 2020 ssh odroid@IP gives back: "reset by IP port 22"
martinayotte Posted February 10, 2020 Posted February 10, 2020 21 minutes ago, alwi said: ssh odroid@IP gives back: "reset by IP port 22" Maybe something wrong with SSHD ... Did you ordered a USB Serial-TTL dongle ? I think it your only way to debug, otherwise it is simply blind debugging ...
TRS-80 Posted February 10, 2020 Posted February 10, 2020 30 minutes ago, alwi said: ssh odroid@IP gives back: "reset by IP port 22" No, read more carefully (or maybe you are new to ssh?). You need to do (as @martinayotte said above): ssh root@odroid_IP And then enter default password ("1234").
alwi Posted February 10, 2020 Author Posted February 10, 2020 @TRS-80 I had also tried root with the same result. ssh root@192.168.178.42 Connection reset by 192.168.178.42 port 22
alwi Posted February 10, 2020 Author Posted February 10, 2020 @martinayotte Please bear with me. Ebay and Amazon are taboo for me. I'd rather pass.
martinayotte Posted February 10, 2020 Posted February 10, 2020 52 minutes ago, alwi said: Connection reset by 192.168.178.42 port 22 This occurs usually when /etc/ssh/ssh_host* key files are corrupted from some reasons (bad SDCard, etc) ... To recover them, you need the Serial Debug, then you can delete those corrupted files and recreate them using "dpkg-reconfigure openssh-server". ... Or, take a new SDCard, write again the image, and retry the process ... 1
martinayotte Posted February 10, 2020 Posted February 10, 2020 54 minutes ago, alwi said: Please bear with me. Ebay and Amazon are taboo for me. I'd rather pass. If you don't want to go on eBay or Amazon, maybe a local store could have such dongle. Bear with me, those Serial-TTL dongle are tools anyone working with SBC should have handy ! Personally, I've about 15 of them to avoid disconnecting them from one SBC to connect to another ...
alwi Posted February 10, 2020 Author Posted February 10, 2020 @martinayotte Uff. I need a little time. But thank you!
jshc1 Posted February 10, 2020 Posted February 10, 2020 2 hours ago, alwi said: As I made my experiences with the RPi 3 and 4, I always waited for a green LED to flicker. But I always saw only one blue LED shining rhythmically "blink, blink, pause, ..." every second. Odroid does not behave like PI. Odroid has one blue diode which signals heartbeat signal. After connecting the power it will light up. If it finds a boot and starts booting, it will start flashing. The blinking speed depends on the load. The red LED is on all the time when the current reaches the sbc. The green LED lights up when HDD is connected, blinks when HDD has activity. The first start of Armbian needs about 30 seconds before it is ready for the first login. 1
jshc1 Posted February 10, 2020 Posted February 10, 2020 3 hours ago, alwi said: That means I could access it with ssh. ssh ??@odroid-IP. What's the name before "@"? ssh odroid@IP gives back: "reset by IP port 22" ssh -v may tell you something more. (ssh -v root@IP) I have never had a problem with armbian and ssh on the first login. Try again from the beginning ...
TRS-80 Posted February 10, 2020 Posted February 10, 2020 20 minutes ago, jshc1 said: Odroid does not behave like PI. Odroid has one blue diode which signals heartbeat signal. After connecting the power it will light up. If it finds a boot and starts booting, it will start flashing. The blinking speed depends on the load. The red LED is on all the time when the current reaches the sbc. The green LED lights up when HDD is connected, blinks when HDD has activity. Is this behavior documented somewhere? Whilst perusing the forums, I am trying to collect such little useful nuggets of information... And perhaps add them to Documentation, wikis, etc... where they can be more easily found later.
TRS-80 Posted February 10, 2020 Posted February 10, 2020 (edited) 2 hours ago, alwi said: Ebay and Amazon are taboo for me. I'd rather pass. Ha! Me too (As much as possible). I like you, so I will give some unsolicited advice: I like to cut out the middle man and order directly on AliExpress (or your preferred Chinese site, I heard others mention BangGood, etc.) for most things. Down side of that is you will be waiting weeks of course. So I do few things to mitigate that: I always have numerous projects going I order multiples of things, assortments, etc. if I realize I will need some tool (ex. from preliminary research) I order it far ahead of when I plan to start So, all in all, I am not affected by the weeks of shipping time. But clearly as you can see I have optimized for cost (I am frugal, aka euphemism for "cheap"). Over time you will also build up nice inventory of hacking tools and supplies. If you need something sooner, you need to branch out and make friends in your local hacker communities: ham radio guys, Linux User Group, hacker spaces, etc... Edited February 10, 2020 by TRS-80 clarify
jshc1 Posted February 10, 2020 Posted February 10, 2020 35 minutes ago, TRS-80 said: Is this behavior documented somewhere? I'm not sure. It is possible that somewhere on the odroid forum / wiki something is about it. I wrote it from my own observations based on Odroid HC1, which I had for two years.
TRS-80 Posted February 11, 2020 Posted February 11, 2020 (edited) After a careful re-reading of this entire thread, the following clues jumped out at me: On 2/7/2020 at 3:37 PM, jshc1 said: Are you sure you're doing everything right? Not long ago I tested buster and 4.14 on HC1 and it was ok. On 2/10/2020 at 9:25 AM, alwi said: Can the same hardware errors occur twice? [...] With the command dd I found the following peculiarity: [...] This means nothing was copied. This I had never before. 20 hours ago, martinayotte said: This occurs usually when /etc/ssh/ssh_host* key files are corrupted from some reasons (bad SDCard, etc) .. 19 hours ago, jshc1 said: I have never had a problem with armbian and ssh on the first login. Try again from the beginning ... This leads me to think the problem may still be that old reliable rule #1 of power and/or SD card issues (in this case, I think SD card)... This even bit someone as experienced as @lanefu as we all realized in IRC last night (in his case, power)! Even though you state: On 2/5/2020 at 10:09 AM, alwi said: Also exchanged hardware was unsuccessful (HC1 and SD cards). I cannot help but wonder if all the SD cards were of the same batch perhaps? At this point I would do a thorough testing of the SD card(s) as outlined here, i.e., use f3 if you are on GNU/Linux or the other one mentioned if on Windows. And let us know the results of that. Edited February 11, 2020 by TRS-80 clarify
alwi Posted February 20, 2020 Author Posted February 20, 2020 I thank all of you who have helped me with advices. The main problem was that I learned only late that Odroid HC1/2 behaves differently than a Raspi at the start and that the LEDs give different signals. ODROID HC1/2 is a very good hardware, for which there should also be a similar installation guide as for RPI. According to recommendation I have installed the build Armbian_20.02.0-rc1_Odroidxu4_buster_legacy_4.14.165 Then I installed Nextcloudpi with the script: # curl -sSL https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh | bash i spent some days testing the possibilities and settings of ncp. That's why I write so late. Everything is running fine, also backup, restore, snapshot. The old data from the previous installation is restored. Many thanks for all your help! What I have left is the duplication of the SD card.
Recommended Posts