Argon One doesn't work with Ubuntu

On Ubuntu 22.04 (server and desktop), about half the time everything goes fine, but the other half it gets to the splash screen, then becomes unresponsive and monitor will go to standby. A fresh sd card with Raspberry Pi Desktop 64-bit works fine everytime.

Tested various configurations (various sd cards, hdmi cables, power cables, power supplies, keyboards, keyboard cables, fresh and existing ubuntu installs). Tested the Raspberry 4 inside the Argon One (has issue), outside the Argon One (works fine), and with the SD card in a Raspberry Pi 400 (works fine). Further testing indicates the issue is with the Argon One hat, rather than with the HDMI and audio adapter.

Has anyone got the Argon One working on anything besides Raspberry Pi Desktop (aka Raspian)?

Video of Ubuntu attempt:

Video of Raspberry Pi Desktop attempt:

Core Electronics is refusing to refund, despite no indication at the time that it could be incompatible.

Hey @balupton,

We, and fairly so, can only support the official version of Raspberry Pi OS for Raspberry Pi type products. We were more than happy to provide after-hours support and thank you for testing with Raspberry Pi OS to confirm the issue could not be replicated with it.

It’s with genuine hope that the fix is something simple for Ubuntu. Posting a topic here is a great first step and if it does turn out to be something product-related that Argon40 can confirm/resolve then we would be happy to extend their warranty/coverage as well.

Thanks for taking the time to present the issue clearly.

Video of the further debugging, showing that:

  • the argon hat is the issue, not the hdmi and audio adapter
  • manjaro gnome works

I’ve also made a thread on the Ubuntu forums (their forums don’t do technical support, so the strategy for the thread is to just list (in)compatibility with raspi accessories):

In the known issues of Ubuntu 22.04 there is:

Raspberry Pi

  • The Raspberry Pi desktop images have switched to using the Full KMS graphics drivers. The official Raspberry Pi DSI display does not work with full KMS enabled. To enable the use of the Raspberry Pi DSI display, edit the config.txt file on your Raspberry Pi’s hard drive and change the line dtoverlay=vc4-fkms-v3d to dtoverlay=vc4-kms-v3d

Jammy Jellyfish Release Notes - Release - Ubuntu Community Hub

So I decided to give that a go:

  1. Booted the raspi with Manjaro
  2. Connected the ubuntu sd card via a usb sd card adapter
  3. Open the ubuntu’s config.txt and compared it to Manjaro, there were three differences:
    1. Manjaro had dtoverlay=vc4-fkms-v3d (fake kms enabled) whereas ubuntu had dtoverlay=vc4-kms-v3d (full kms enabled), I changed Ubuntu to match Manjaro.
    2. Manjaro also had disable_splash=1 and a specific kernel applied, I did not make these changes.
  4. I powered the unit off, took out the manjaro sd card, took out the usb adapter, put in the ubuntu sd card into the raspi
  5. I powered the unit on, it successfully booted each time, however with extreme visual tearing when dragging windows. I compared this against full kms enabled on raspberry pi 4 outside argon, and raspberry pi 400 and full kms (the default on ubuntu) produces zero tearing.
  6. During boot I got low power warnings when using usb-c on a 5v3a power supply and usb-c on a 5.2v2.4a power supply. Using usb-a to usb-c on the same 5v3a power supply, and using the adafruit power supply produces no low-power warnings.

So conclusion:

  1. For some reason the Argon One hat (regardless of the hdmi+audio adapter) is not compatible with full kms dtoverlay=vc4-kms-v3d which is required to not experience visual tearing.
  2. usb-c to usb-c power is not completely compatible with the Argon One hat, despite working fine otherwise, usb-a to usb-c power and adafruit power is completely compatible with the Argon One hat.

Great to see some progress. Given the case works fine with so many other OSs, it’s likely a config issue along this path.

While compatible with other power sources, RPi may not work the same way as it does with the official hardware. It’s best to use a Raspberry Pi PSU as they are 5.1V and have thick leads which reduce the voltage drop to the board. This keeps vCPU where it needs to be; to avoid voltage warnings.

I redid all the sd cards, and installed them on the raspberry pi 400, and made sure all updates were applied. This time I used the official/adafruit power supply with the argon one, and seems to reliably work now with all operating systems, including Ubuntu Desktop 22.04. The issue still occurs with the other power supplies, despite them being rated as capable, and despite them working with the raspberry pi 4 8gb outside of the argon one, and also with the raspberry pi 400. While the power supply plays a difference, I am unsure if a ubuntu update may have also made it work.

Hi @balupton,

I’m not sure what you mean by official Adafruit, Raspberry Pi is made by the great folks in the UK: Raspberry Pi Trading (which is owned by Raspberry Pi Foundation). Adafruit is a DIY electronics manufacturer in New York, they do happen to sell RPi Boards as most maker retailers do.

Great to hear this is working now - and a hot tip the Official Raspberry Pi PSU is 5.1V has several other differences compared to ‘chargers’. While most things should work with 5V chargers, the internet has its fair share of empirical tests for products that are not engineered to deliver a genuine 5V to the CPU of a Single Board Computer. This is something easily overlooked while charging consumer products because 4.x volts (less than 5.0V) just means a slower charge rate. For electronics and an SBC; it’s trouble.

There are other factors, though from my experience this is mostly due to the voltage drop of the cable being used. Cables designed for data, rather than those engineered just for power, will easily drop 200+mV by the time they get to the other end (thin wires etc). Longer cables can drop 500+mV (something definitely isn’t going to work for a computer or other sensitive 5.0V logic!)

To wrap up, the Raspberry Pi works best with 5.0V at the CPU as specced by the team at Raspberry Pi. The Official PSU exists for good reason, and there are levels of compatibility for third party hardware and software.


It would be great if you could update the breadcrumbs you’ve left around the internet now that you are aware of the risks that third party chargers/cables can have with SBCs. Official hardware exists for good reason and ultimately you need to be delivering a minimum of 5.0V as specced by Raspberry Pi. I’m sorry that third-party vendors have left you in a spot of trouble.

Given the nature of this content, I believe these are your posts, unsure:

  • Your Ubuntu topic
  • The product review left here
  • Google review -

Given the recent successes, I’ve ordered the intended m2 sata ssd, which will arrive this week, so will test on that. Still cautious, considering everything. Related:

If it works, no worries in updating my reviews.

It’s too bad that the other few thousand cases sold every week don’t report back to share their success stories :slight_smile:

PS - in the linked post they are using the older micro-B 15 Watt PSU, so it’s going through an adaptor of sorts. It’s also not a recommended accessory for the M.2 case. Making price compromises and salvaging old hardware is nice when it works out - though to be fair - it does increase the risk of something not working out as expected.

WD Green Sata Drives work great, and that’s what we recommend.

Using a 1TB WD Blue Sata M2, as it was either that or Samsung Evo available on Amazon.

When booting from the sd card running ubuntu desktop, then plugging in the usb connector to the sata drive, I was able to flash it with ubuntu desktop 22.04 64 bit via the raspberry pi imager software.

When powering off, removing the sd card, and powering on with the sata drive connected, I would receive a raspi boot screen with no sd card error. Reports have said reboots may be needed, so I tried that to no avail.

I then figured perhaps it is old firmware on the flashed image that doesn’t support usb boot, so I followed a guide to copy over the latest firmware from the sd card to the sata drive, and tried again. This time it just boots to a blank screen and is unresponsive, reports say this may be because it is resizing the image to expand on the sata drive, however I left it overnight and no progress.

I apologise if my patience is wearing thin on this, however without any upfront warnings at time of purchase that I should be expecting a 20 minute job to turn into multiple days of troubleshooting, I think my plight is understandable. I appreciate that now such warnings are published, which will help future users, and I hope my situation can be resolved before I have to call it quits.

I will try flashing the sata drive with raspberry pi os, and see if it successfully boots with that, as that could inform future steps for ubuntu users.

If you want to fix this issue, don’t go with Argon software as it is, at best, sort of clumped together to work instead of actually being well written and robust. It also breaks when you modify much of anything.

Especially if you are moving to Ubuntu 22.04 or really much of anything except RPi.

Argon One Daemon

Obviously only helps but so much if you are running Windows and not Linux but it is actually pretty well coded from the ground up.

OS Support

The installer now requires you to run ./configure before you run make. This will set up the installer so that it should be able to install on multiple OS’s. The current list of supported OS’s are

  • Raspberry Pi OS 32bit or 64bit
  • RetroPi
  • Gentoo
  • Manjaro-arm
  • Arch Linux arm (ARMv7 installation ONLY)
  • Ubuntu
  • OSMC
  • TwisterOS
  • Lakka *
  • LibreElec *
  • [Alpine Linux] SEE LINK

*Support for this OS is with the self extracting package system. SEE BELOW

The Argon One CLI tool

This is the new command line tool that lets you change setting on the fly. It communicates with shared memory of the daemon, so the daemon must be running for this tool to be of use. It also introduced new modes for the daemon such as Cool Down and Manual control over the fan.

Cool Down Mode

In cool down mode the fan has a set temperature you want to reach before switching back to automatic control. This is all set as follows argonone-cli --cooldown <TEMP> [--fan <SPEED>]
NOTE: The speed is optional and the default is 10% it’s also import to note that if the temperature continues to climb the schedules set for the fan are ignored.

Manual Mode

As the name implies your in control over the fan the schedules are ignored. To access this as follows argonone-cli --manual [--fan <SPEED>]
NOTE: The fan speed is optional and if not set the fans speed is left alone.

Auto Mode

This is the default mode the daemon always starts in this mode and will follow the schedules in the setting. If you want to change to automatic you do so as follows argonone-cli --auto

Off Mode

Yes an off switch, maybe you want to do something and you need to be sure the fan doesn’t turn on and spoil it. You can turn off the fan as follows argonone-cli --off NOTE: When the fan is off nothing but turning to a different mode will turn it back on

Setting setpoints

Want to adjust the when the fan comes on, maybe it’s not staying on long enough you can change all set points in the schedules from the command line without rebooting. the values are fan[0-2] temp[0-2] and hysteresis. It’s important when changing these values that you remember that the daemon will reject bad values and/or change them to something else. It’s also important to commit the changes you make otherwise they won’t do anything. The value rules are simple each stage must to greater than the one before it and there are minimum and max values.
For temperature the minimum value is 30° the maximum is currently undefined.
For the fan the minimum speed is 10% and the maximum is 100%.
For Hysteresis the minimum is 0° and the maximum is 10°

You can set your values like in this example.
argonone-cli --fan0 25 --temp0 50 --hysteresis 10 --commit

argonone-cli --fan0 25
argonone-cli --temp0 50
argonone-cli --hysteresis 10
argonone-cli --commit

The changes don’t have to made in one shot but you MUST commit them for them to take effect.

Package System

This isn’t a traditional package system for mainstream OS support this is meant to make an installer for an OS that otherwise isn’t able to build the project locally.

To generate a package you need to follow this procedure.

make mrproper

If successful the package will be in the build directory.

Screenshot of the packager

    ___                                                __
   /   |  _________ _____  ____  ____  ____  ___  ____/ /
  / /| | / ___/ __ `/ __ \/ __ \/ __ \/ __ \/ _ \/ __  / 
 / ___ |/ /  / /_/ / /_/ / / / / /_/ / / / /  __/ /_/ /  
/_/  |_/_/   \__, /\____/_/ /_/\____/_/ /_/\___/\__,_/   
Distro check [libreelec] : OK
gcc : OK
dtc : OK
make : OK
Dependency Check : Successful
INFO:  Preparing build environment ... OK
INFO:  Building Source Files ... OK
INFO:  Checking files ... OK
INFO:  Building Installer ... OK
INFO:  Packing files ... OK
INFO:  Verify package ... OK
INFO:  Package build/ is complete 

Not sure why, but today when I had time to test again. I did fresh flash of raspberry pi desktop os 64 bit on the ssd, worked fine (as suspected). However, I then did a fresh flash of ubuntu desktop 22.04 64 bit on the ssd, it also worked fine. Not sure why it is now working, when otherwise everything else is the same.

I’ll do more experiments over the week.