Carlos Hartmann

Just a brief update to say that I've gotten overwhelmed with other things in my life. I still primarily suspect something is up with the connection to the serial console and that I should experiment there, as @Igor suggested. In three weeks time, I will have several days at my server's location with plenty of time to devote to this. I will try to get my hands on a machine with a USB-A port running something other than macOS.

Briefly tried with Bullseye and the fans don't even come on. Could be the "refusing to boot without drives" behavior mentioned before. Will try both Bullseye and Buster on my original machine on Sunday and see if anything changes.

I see, now I get it! So it's everyone's duty to keep around what they think might still be necessary ahead. Did not know of this quirk in the world of Linux. Definitely OT: This explains the running gag among data hoarders when they justify their ample storage space with "Linux ISOs" but really mean socially less accepted things.

Oh yes, I've been meaning to test an older version but didn't find any anywhere. Can you upload here directly? Maybe slightly OT: Do you know why older versions aren't preserved anywhere? I thought it'd be easy to find buster and bullseye images but didn't manage at all. Seems like it can't be too uncommon that a newer version causes issues and one has to fall back.

I set up an Ubuntu VM on my Mac to do linux stuff. With that I edited the ambianEnv.txt as you said. Behavior is the same. I should also add that there is a regular double-blink of the System LED after the initial fans (of about 2-3 seconds). I now remember that back when I set up the Helios, I was told to use PuTTY on Windows instead of my mac. Maybe there's an incompatibility of some sort? I checked and they recommend a set of drivers for Mac that I hadn't installed. I did and after playing around -- and only occasionally while playing around with connecting, disconnecting, rebooting -- did I sometimes get some garbled output in the serial window: posting it because it's the longest and least garbled output I've gotten so far. The command was exactly as on the Helios64 website, i.e. the baud rate was correct. Not sure where to go from here and what to blame.

baudrate: indeed at 1500000 The serial actually did not work before. Back when I first installed the Helios I used a C-A cable. Now I gave it a try with one and it improved the behavior: instead of appearing and disappearing, the usbserial device is now constant. The issue is just that nothing is shown via `screen`. I think I'll try by inserting a HDD because of what you said. I remember the USB-C cable issue. To be sure, I had removed a sliver of plastic using a cutter just like I did a couple years ago. No issues with clarity, I know about that quirk of the Helios. But yeah, this was not the issue now as I only worked with "modified" USB-C connectors. I unmounted the "disk" (SD card) before working with it. That should be safe as nothing tried mounting it afterward. Was the whole thing written: The `dd` command finished and balena Etcher even confirmed that the Flash was complete. So I think this is also a yes. conv=fsync: No I did not do this. Repeating the whole procedure with this and then after reinserting, I'll get a sha256sum of the contents… It worked, the resulting sha256sum is identical. Just trying to boot the machine again… Same behavior, sadly. HDD not yet inserted btw, will do that tomorrow.

Just a short update to say that I also tried the balena Etcher with no changed behavior.

Hi, The output of `parted [.img file] unit s print` is: I'm on macOS, which isn't able to read ext4. Mounting didn't work at all. I also tried with a Debian image via docker but the mount command was not permitted (even with using sudo). The only other Linux machine I have is a Steam Deck, which I might be able to use in Desktop mode for this. I did run sha256sum on the downloaded file and checked with the hash on the Armbian page. Afterwards just ran `xz` and `dd`. I repeated this on a different machine (also macOS) and the outcome still the same. EDIT: Oh you meant for me to run sha256sum on the unxz'd file, so the .img file directly. The checksum is indeed the same as what you posted. I do agree that it seems like the SDcard and/or image are at fault. I tested two different power cables on two different Helios64 machines, it kind of has to be this. But what else could I try? The USB-C cable I use to get access via `screen` is USB-C to USB-C and is confirmed to be for data&charge. I saw that the Helios64 documentation says to use USB-C to USB-A but I doubt that this is the reason for the flaky connection. It does seem like an issue with the Helios64.

Hi there, appreciate you answering! I downloaded via the browser and manually ran xz -d Armbian_24.8.1_Helios64_bookworm_current_6.6.47_minimal.img.xz I then ran the dd command using the resulting .img file. However, diskutil does not show a partition called ambi_root. Relevant part of diskutil list: /dev/disk4 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *31.3 GB disk4 1: Linux 31.0 GB disk4s1 (free space) 325.1 MB - Not sure if this points to something being out of order. Also, I should mention I tried USBImager but it will not even start as macOS says it is "damaged". The balena Etcher is not recommended according to the Armbian documentation. On that documentation page I saw that they recommend specific microSD cards. Comparing with the ones I bought I think I may need to buy one that is actually recommended. Even if it's not the cause of the issues, I saw somewhere that the wrong SD card can be a headache in the long run. As for the drives, I had a full stack of 5 drives in my main Helios, and 4 non-configured ones in the spare Helios (was just using it as cold storage really). I transported the spare Helios without any drives to my place now and verified that the behavior remains the same. So, in short: same behavior with and empty, full, and 4/5 Helios.

Quick preface: I'm a noob in many ways, though I'm trying to learn. I may make obvious mistakes and may need clearer instructions than most. Would really appreciate someone working with me here! So I realized earlier this year that I was still on Buster and that there were two newer OSs that I could upgrade to. I upgraded to Bullseye with support from ChatGPT which worked nicely. The upgrade to Bookworm hosed my system and it now fails to reboot. System Info (prior to failure): - Helios64 board - Armbian with OMV - Originally running Buster, then upgraded in sequence: first to Bullseye (worked fine), then to Bookworm - System was always booted from an SD card, not eMMC - Upgrade was done via `apt` commands, no manual flashing of U-Boot Current Symptoms: - After Bookworm upgrade, the system fails to boot. - Via USB-C serial connection (using `screen`), I get mostly garbled output like: �`���x�f������������f�������f��~�怘����怘� Or: ZZ���B>��^�������������N��f�&F�goFFWFWGGG�oo{{q�{{{{z{{����_G_�#g�_WN�o.���wgG�WwwwWw�NWN�W�_ow_fW�Wo�v�oNogoWffOgFGFONNfFOW^Wf_G�~gg� - Occasionally, I saw more verbose output including: SetTTY (fd 5): ioctl failed: Invalid argument Sorry, could not find a PTY - No SSH access; connection refused (network stack never comes up). - The fans spin up for a few seconds and the Ethernet LED blinks briefly, then stalls. What I've Tried: - Reflashed several SD cards (Verbatim Premium and Sandisk Extreme Pro) with the latest Armbian Bookworm images (Minimal, OMV, and Noble). - I still have my old SD card that was Buster and got upgraded to Bullseye and then Bookworm, also made a backup image of it. - Repeated all tests on my second, so-far unused Helios64 — same symptoms. - Changed power cables and tried both UPS and direct plugging to wall socket. - Verified serial setup with `screen /dev/tty.usbserial 1500000`. SD Card Behavior: - After flashing via `dd`, macOS warns “Cannot initialize disk” — I believe this is expected. - On insertion and power-up: usually fans spin and LEDs blink, but no consistent or successful boot. Desired Outcome: - I'd like to use Bookworm on Helios 64. If not possible, then I'd like to use Bullseye I guess, but I wasn't able to find an image online. Only Bookworm, Jammy, and Noble. - I'm aware of firmware and DTB tweaks recommended on here to make Bookworm stable — but I can’t try these yet because I never reach a usable system. Questions: 1. Is there any place where I can download an official or community-maintained Bullseye image for Helios64? Should I even try to use Bullseye? 2. Is the serial output I’m seeing a sign of a bootloader issue (U-Boot or DDR init)? 3. Can the Bookworm image be made to boot reliably with certain tweaks *before* boot (e.g. editing partitions manually)? ChatGPT suggested to boot the system without eMMC and this is certainly territory where I don't trust AI anymore. I think I need to try fixing the server with help from you and understanding the process myself. Since my main Helios64 is offsite, I took my second Helios64 home with me until I figure out what the issue is and I'm able to boot it up and get it running. Then I'll hopefully be able to fix my offsite machine during one of my visits there. I should also say that it would occasionally get "stuck" on a reboot attempt and I needed to physically turn it off and an again to boot successfully. This never happened twice in a row, i.e. the manual reboot always fixed it. Regular reboots worked with roughly a 80-90% success rate but it didn't have to reboot very often at all. Still, this makes me believe that maaaybe there is some hardware issue present. Then again, the second Helios experiencing the same issues makes this more unlikely I suppose.