Zorin OS 18.1 Core (Ubuntu 24.04 LTS "Noble Numbat" base)
ASUS X441UA laptop
Kernel: 7.0.0-34-generic
A note on my background: I have basic Linux knowledge and have been using Claude AI to help diagnose this step by step and write up this report, so I'm happy to run any further diagnostic commands, just may need clear copy-paste instructions rather than assuming I know the internals.
Issue:
Settings > About, /etc/os-release, hostnamectl, and lsb_release -a all report "Ubuntu 24.04.5 LTS" instead of "Zorin OS 18.1". The system otherwise runs and updates fine — this looks like a pure identification/branding issue caused by an apt repository problem, not a broken install.
It's not just base-files — zorin-appearance, zorin-os-overlay, and zorin-os-default-settings show the identical pattern in apt policy (only /var/lib/dpkg/status, no repo candidate), and apt install --reinstall on any of them fails with "Unable to reinstall, could not download."
This isn't a local misconfiguration: /etc/apt/sources.list.d/zorin.list is a standard, correct setup (deb https://packages.zorinos.com/stable noble main, same pattern for patches/apps/drivers), and apt-get update --print-uris confirms apt is targeting the right URLs. The Ubuntu-side repos (main/universe/restricted/multiverse across noble, noble-updates, noble-security, noble-backports) all fetch normally — this seems isolated to Zorin's own stable component (haven't directly curl-tested patches/apps/drivers, but apt shows the same symptom for packages from all four).
My /etc/apt/preferences.d/ already has the correct Zorin origin pins (priority 999, above Ubuntu's 500), so once the repo serves a real package index again, a normal apt upgrade should pick up the correct Zorin packages on its own without any extra steps.
This has persisted for several days now across repeated apt update, a full /var/lib/apt/lists cache wipe + refetch, and multiple reinstall attempts — hasn't resolved by itself yet.
Questions:
Is this a known/ongoing issue with packages.zorinos.com/stable for noble?
Any idea when the Packages index might be republished?
Anything else I should check or post in the meantime?
yeah Packages.xz on Index of /stable/ (and patches) 404s from here too rn. InRelease is fine so apt sees the suite but cant pull the index. thats on zorins mirror
os-release showing Ubuntu is just base-files falling through to the ubuntu package cuz the zorin overlay candidate vanished with that 404
nothing to force locally til they publish binary-amd64 again. keep the zorin.list pins. when Packages.xz comes back:
-sudo apt update
-apt policy base-files
should show a zorin candidate, then reinstall base-files / zorin-os-overlay
worth pinging zorin support w/ those curl -I results
Thank you for taking the time to reply, but I use this system for work and a Python application I use stopped working, so I decided to reinstall the system. There might have been a better solution, but my knowledge of the OS and Linux in general is very basic, and I needed the fastest solution accessible to me.
Reinstalling Zorin OS Core brought its identity back to normal and left the system almost exactly as it was before. However, unfortunately, I couldn't fix an issue with the Python application I use for work. I tried everything and made countless attempts to get it running, but I couldn't, and the terminal wouldn't give me any error messages either. Since I needed it urgently and didn't want to go back to Windows, I installed Debian 13 GNOME, and now I'm working on Debian. But I miss Zorin like crazy, so I guess I'll let some time pass and try again later.
That's a separate Python application I run for my private practice (unrelated to Zorin itself) — the package is called Flet (pip install flet, plus flet-desktop for the native-window client; it's built on Google's Flutter).
To be clear, I don't have confirmed evidence that this was caused by the Ubuntu/base-files issue above — they happened around the same time, but turned out to be a separate problem. To add some context: the Flet package itself wasn't related to the original Ubuntu-branding issue, but the timing lines up — around the same time the Ubuntu/base-files problem showed up, and while I was working through troubleshooting it, my Flet-based Python application also stopped opening its window properly. I don't have direct proof the two were connected, but it's worth mentioning since they happened close together. Perhaps I broke something while trying to fix the first issue, but even after reinstalling Zorin OS, the Python problem persisted. Since it works perfectly fine on another distro, it rules out any hardware-related issues. The Flet issue turned out to be its own separate problem: the native window would appear as a blank black window with no functionality (or sometimes it wouldn't appear at all), which later forced me to kill the process manually, even though the terminal showed no errors at all. However, I can no longer run further tests or troubleshoot this specific behavior, as I am no longer using Zorin OS.