Currently there are precious few SystemReady Arm computers—computers like the System76 Thelio Astra I was sent recently to test.
The level or 'band' of SystemReady SR used by modern Ampere-based arm64 workstations and servers means you can install any out-of-the-box Linux distributions, as long as they provide an arm64-compatible installer.
Ubuntu has some of the most complete support for arm64, so I went to download a Live CD ISO I could flash to a USB stick, to install on my test Thelio Astra. For server installs (with no GUI), either 4k or 64k page sizes, there are easily-findable ISOs:
However, for desktop, you can only get it via daily build downloads:
Regardless of download, I was having trouble installing Ubuntu on my system. The install would proceed as normal, but eventually it would error out, leaving the installation kinda working.
Conmand: ['unshare', '--fork', '--pid', '--option=Dpkg::options::=--force-unsafe-io', '--option=Dpkg::options::=--force-confold', 'install', '--download-only', 'linux-generic-hwe-24.04']
I would have to manually mount the Ubuntu data partition, use sudo chroot /mnt/partition_here, and add a user account manually. But some other stuff in the install was broken too, and that's just no fun!
After posting about this in my testing thread for the Thelio Astra, GitHub user bexcran mentioned:
I'd guess it's getting confused about existing partitions.
And even though I was choosing the "Erase and install" option in the Ubuntu installers (both on Server and Desktop), for some reason (I guess just 'user misunderstanding'?), that was not wiping the disk enough that it would install successfully.
So to counter that, before completing the Ubuntu installation, I opened a Terminal window when booted from the Live Install CD, and ran these commands:
sudo wipefs /dev/nvme0n1 --all
sudo parted /dev/nvme0n1 print # to confirm the partition table is wiped
After that, the installation completed without a hitch.
I'm not certain, but I don't remember having this issue on my x86 machines, when installing Ubuntu on them... though last time I tried a new Ubuntu install on one of those was probably a year or so ago!
I'm mostly posting this for my own future reference, because I can guarantee I'll have the same problem again, and my silly brain won't remember that I just had to wipe the partitions prior to installing Ubuntu.
Comments
I've had similar issues when installing both Pop!_OS and, surprisingly, OpenBSD on x86_64 hardware that has had previous Linux or BSD OSes installed on it. In both cases, doing a simple "dd if=/dev/zero of=/dev/nvme0n1 count=16384" would fix it, essentially wiping the partition table. The same can obviously be achieved with your wipefs command, with fdisk by creating a new empty partition table, or even via GUI with GParted.
It's a strange thing, it's like the installer doesn't actually erase the right bits of the partition, even if the exact same OS was installed before. Good to know it's not just me though, haha.
When it comes to SSD storage, I use blkdiscard to trim the entire drive. Avoids unnecessary write cycles, and resets the drive's garbage collection.