MultiTaction Base Linux Image

MultiTaction Base Linux Image is the universal operating platform for current MultiTaction Hydra Appliances. It is distributed on a self-contained Installer USB that can install without network access.

See the installation and operations manual, the security information report, and the FAQ for more detail.

MultiTaction Base Linux Image - Ubuntu 24.04 Noble (UEFI boot)

Engineering preview — not a qualified release. These builds use a development signing key and have not completed hardware qualification. Do not use them for production or customer deployments.

There is one Base Image for current H2, H4, H8, H12, and H16 Hydra Appliances. It includes Ubuntu 24.04 LTS, NVIDIA support, a minimal Xfce/X11 configuration and diagnostics environment, and Teleport remote-support capability. MT Applications and optional hardware drivers are installed later as Approved Packages; there are no Full and Slim variants.

Secure Boot is required for supported installations.

Download

Each build has its own writing instructions, because the dd command in them names that build's ISO. Use the instructions published alongside the image you download.

Current — build 2026-09-10 (golden image goldenV260910)

Use build 2026-09-10 for any new installation. Earlier preview builds have been withdrawn: they are superseded by this one and several carried defects that are only visible after installation.

New in build 2026-09-10

Warm reboots survive. On earlier images a restart could leave the appliance dark and unresponsive, having written nothing to its logs explaining why. The cause was the graphics driver being handed the text console as well as the display: a restart deadlocked against it, and everything that touched the console afterwards — including the service that records what happened — stopped with it. Because switching the appliance off at the wall and on again always cleared it, while a restart from the desktop always brought it back, the fault read as random. It is not: this build declines the console handover and the deadlock cannot occur.
Application data is on the Application Data filesystem from the first boot. Earlier images created the operator's home directory, the applications directory and the servers' storage on the 63 GB system partition, and moving them afterwards was a field engineer's job. This build establishes the layout before any application exists, so applications installed later land on the large filesystem by construction. A single large Showcase import previously filled an appliance completely and stopped its server; there is now no path by which application data lands on the system partition.
Showcase's server storage is included in that layout, which it was not before. An appliance that had been put right by hand still placed a future Showcase installation's data on the system partition.

Remediation script for appliances already installed

Appliances installed from any build before 2026-09-10 need this script run once. It is not required for a machine you are installing today, and it is safe to run more than once — it reports what it finds and changes nothing unless asked.

Copy it to the appliance and run it as root. It carries everything it installs, so the appliance needs no access to the software archive:

tsh scp mt-bring-appliance-current.sh root@<appliance>:/tmp/
tsh ssh root@<appliance> 'bash /tmp/mt-bring-appliance-current.sh --check'

--check inspects and reports. --apply makes the changes, stopping and restarting the desktop where it has to. Add --reboot to restart the appliance at the end, which is the only real proof the storage changes survive.

What it puts right:

Application data on the wrong filesystem. /home/multi, /opt and the Showcase server's storage were on the 63 GB system partition rather than the 817 GB Application Data partition. A single large Showcase import filled one appliance completely and stopped the server.
Showcase staging in /tmp, which is also on the system partition, so the largest single writer was aimed at the smallest filesystem.
A display layout that appeared to be ignored, because Xfce re-applied its own saved monitor arrangement over xorg.conf at every session start.
Settings entries that fought the MultiTaction tools. The stock Display and Audio dialogs each overrode the tool meant for the same job, and now open the MultiTaction one instead.
Approval by release name, which meant an appliance could never be offered a newer release of an application — including one that fixed licensing. It now approves the product and resolves the current release itself, so this does not need doing again.
Magewell capture cards with no driver. Where the appliance permits unsigned kernel modules, the driver is built and installed. Where module signatures are enforced it reports that and stops, because an unsigned driver would install, report success, and never load.
An appliance that goes dark when restarted. Where the graphics driver had been handed the text console alongside the display, a restart could deadlock against it and take the logging service with it, so the machine stopped with nothing written down explaining why. Switching it off at the wall and on again always cleared it, while restarting from the desktop always brought it back, which made it look random. The boot configuration is corrected in place.
A keyboard that types the wrong layout. Earlier images carried the layout of the machine the image was captured from, and the stock Xfce Keyboard dialog only changed the session it was opened in — so the login screen and the text console kept the old layout and the choice was lost at the next restart. The appliance gains a tool that sets all three together, reachable from Settings > Keyboard.
An administrator password that reverted at every boot. The password seeded during installation was re-applied on every restart, silently replacing one the customer had set, and the credential stayed on the appliance indefinitely. It is removed, and a password already changed is kept.
Menu installs that failed while everything reported success. The corrected package tools were installed where the desktop does not look for them, so the Software menu kept running the version the appliance shipped with. Checks inspected the corrected copy and reported no problem, while a first install from the menu still failed. Both locations are now updated.

Run it with --check first and read what it reports. On an appliance running Showcase or Canvus Server, run it during a maintenance window: moving application data requires the desktop session to be stopped.

Build 2026-08-11 adds, over 2026-07-31. This build is largely about what earlier images shipped by accident: a golden image is captured from a real appliance, so whatever that appliance accumulated while it was qualified is otherwise copied into every machine built from it.

Audio works. 2026-07-31 carried the capture machine's chosen sound output, stored as a PCI address. No other appliance has hardware at that address, and the audio service re-applies the stored choice on every change and falls back to a silent output when it cannot resolve it — so affected appliances were permanently silent, and the desktop sound dialog would not hold a correction. Both that setting and the place PipeWire itself persists it are now removed when the image is sealed.
The desktop and the applications directory are present. On an appliance using the separate Application Data filesystem, the operator's home directory and /opt are mounted from it, and the capture stopped at that boundary. An image built that way installed and came up with no panel, no desktop entries and no applications. The capture now crosses those mounts and refuses to produce an image with an empty home directory.
Secrets belonging to the capture machine are gone: SSH and Teleport private keys, the Secure Boot module-signing key, the previous password hashes left in the shadow backup files, and a per-host firmware-update keypair. Every appliance built from an earlier image shared them.
Hardware-specific leftovers are gone: one sound card's mixer settings, a keyboard receiver's MAC address, and the capture machine's name in the hosts file.
MT Applications are no longer present. They are installed after deployment as Approved Packages, and an image carrying them contradicts that.
Applications are approved by product name, not by release. An appliance can be offered a newer release as it is published, rather than being fixed to whatever existed when the image was built.
Magewell capture cards are supported where the appliance permits unsigned kernel modules. The driver source is carried on the medium, so a site with no route to the vendor can still build it, and installation happens automatically on a machine that has the cards. Appliances enforcing module signatures report that and do nothing, because an unsigned driver would install, report success and never load.
Settings opens the MultiTaction tools for display layout and audio output. The stock dialogs each overrode the tool meant for the same job.

Preview installation modes

This preview offers Factory Reset and a live diagnostics environment. Factory Reset erases the operating system and all Application Data, then creates a clean MT disk layout. The installer verifies the signed golden image byte for byte before writing the target.

Repair Installation is planned for the qualified Installer USB but is not available in this preview.

Install the Base Image

Write the Installer USB image to an empty USB drive of at least 8 GB using the linked Rufus or Linux instructions. Writing the image erases the USB drive.
Leave Secure Boot enabled and boot the Hydra Appliance from the USB in UEFI mode.
Select Factory Reset from the boot menu. It starts automatically after 30 seconds if no option is selected.
Select the target internal disk after checking its model, capacity, and serial number. Factory Reset erases all data on that disk.
Set the customer-owned administrator password when prompted, or allow the 60-second timeout and set it later through Teleport.
Wait for the installer to report completion. Do not power off or remove the USB while it is writing or verifying the target.
Power off the appliance, remove the Installer USB, and boot from the internal disk.

The installed system auto-logs in as multi and opens the configuration and diagnostics environment. Connect the required network interfaces, complete Deployment Configuration, and install the required MT Applications as Approved Packages. Launcher becomes the normal appliance interface when its package is installed.

Everything a technician needs is under MultiTaction in the desktop menu:

Install Apps installs Showcase, Canvus and Launcher, in that order.
Update Software checks for and applies updates to the MT software already on the appliance.
Technician > Display Layout writes xorg.conf, screen.xml and config.txt together for a standard wall — single screen, 3x1 or 5x1 portrait, 3x2 or 3x3 landscape — assigning NetBridge addresses from 10.77.84.101 left to right then top to bottom. It restores the previous configuration automatically if the wall does not come back or the change is not confirmed.
Technician > Tools opens each product's configuration file and log directory.
Diagnostics exports a support bundle and shows service state and system logs.

The medium carries no network credentials. Join the appliance to its network at installation.

MultiTaction Base Linux Image - Ubuntu 18.04 (UEFI boot)

MT Base Image Build 31030 (2021-12-09)

Old version, using legacy boot:

MT Base Image Build 22652 (2020-01-21)