[Solved] Headless Alta doesn't boot unless also connected by a serial

Hello, new user here.

I recently purchased the Alta board, and can’t get it to work. I need a headless setup, where the board will not have either monitor, keyboard or a mouse connected. All of the communication is to be done over wired network.

I’ve tried several distributions: Raspbian 12 Lite and Full, Debian 12 base and Ubuntu Desktop and Server.

The Lite/Base/Server distros exhibit a very similar and strange symptom:
If I first open the serial connection and then power the board I see the board booting and eventually starting to respond to PINGs on the IP I configured. Then (depending on the distro) I can log in over SSH and everything works fine. If, however, the serial is not connected to the board on boot - nothing happens. The PINGs to the board never start getting a reply and the board doesn’t seem like it booted (only the red LED is lit).

I’ve tried two different power adapters both rated for 3A on 5V and, considering the seemingly fine boot with serial, I don’t think there’s a problem with the power supply.

I’m using SanDisk Ultra A1 32GB MicroSD card. Again, considering the board seems to be booting fine with the serial, I doubt the SD card is the culprit.

For the flashing I tried using both Balena Etcher and Raspberry Pi Imager. The recommended Win32DiskImager instacrashes on my (Windows 10 Pro) machine. While hard to rule out some obscure failure with the imaging process, I doubt different distros would result in the same type of failure.

A piece of information I’m not sure is important, but feels it could be related. Before succeeding to boot with the serial, I tried booting in a desktop configuration (hence the Raspbian Full and Ubuntu Desktop) but my desktop environment would never come up. The text mode initialization prints would be shown fine, but then - just black screen. With Raspbian I’d see the cursor blinking part of the time in the top left corner and disappearing. With Ubuntu - nothing. I tried with two monitors, but both are by Acer and both are somewhat finicky, so I’m not sure who’s to blame here.

Am I missing something really dumb and basic? I couldn’t find any similar question.

I’m runing Debian 12 on my Alta, which is connected to the ethernet only. I have no problem in rebooting and connecting again with ssh.

I think you need to make Win32 Disk Imager work on your Windows 10 machine. Many of weird problems were solved just by switching to the right flashing tool.

Thank you for replying! I think I managed to finally solve this.

TL;DR: I shouldn’t have been lazy and had to disconnect the serial wires completely from the board. Just keeping them floating, even if disconnected from the serial interface, apparently messes something up.

I looked into the Win32 disk imager again. It has a documented bug of instacrashing if a ramdisk is used. I didn’t setup any ramdisk on my machine, but apparently the GoogleDrive app I was using did (or did something with the same effect). Closing the GoogleDrive allowed me to start the Win32DiskImager.

After making the images with it, I still experienced the same problem as before, however I noticed that its verification process fails immediately. A problem described here. It turned out that Windows (ugh!) was creating a “System Volume Information” folder and this was failing the verification. For posterity - here are the instructions on how to prevent Windows from doing this nonsense.

After successful verification, however, the same baffling problem persisted.

Then I did something I haven’t tried before - I disconnected the serial wires completely. It’s a bit of a hassle to connect them, so previously I’d only disconnect the end of the wires that went into the USB serial interface device, keeping the ~10’’ long wires plugged into the board and floating. I didn’t expect it to have any effect, but, suddenly everything started working. The board boots as expected!

I’m not sure what was the problem when I tried the full images, the serial wasn’t connected then yet, but I’ve updated the firmware since, so it’s probably fixed already.

Anyway, thanks again! Now on to learning more.