After a long wait, I am so excited to announce that PureOS Crimson is finally released!!
Existing Byzantium devices will automatically receive a PureOS Upgrade toolsoon when installing system updates. New devices will begin shipping with PureOS Crimson pre-installed.
Byzantium users wishing to use this tool today can run: sudo apt install pureos-upgrade
What’s new?
PureOS Crimson brings updates to the foundation of PureOS throughout the entire operating system. Users will find it much more responsive with improved stability and reliability. I invite you to read our advanced readers blog posts to see the details of the many updates within PureOS Crimson!
What’s next?
Purism is already working on PureOS and will keep up the momentum for its release. Much of the work presented in Crimson extended to PureOS Dawn, so we anticipate that the update path will be significantly shorter.
Great news! And kudos to all devs who were involved!
Now that Crimson is released any hope that any of The Purism Freedom Roadmap – Purism will be tagged for Dawn?
Well, the upgrade wasn’t too painful. I had to make sure my battery was at 90% and I had to remove one item the installer found objectionable ( gcc-7-base(7.5.0-5) ) and then it let me start it.
After the upgrade, the settings screen for Display was certainly different. I like to use my docking device sitting at my desk. It took a few tries but I managed to get the desktop displayed on my monitor.
Several apps would not display on the screen. I get a white monitor and it comes up on my L5 screen.
Calendar
both File Browsers
Firefox ESR
Geary
gEdit
Aisle Riot
Lollypop
PureOS store ( which I looked at in hopes of updates to fix this issue, none yet )
Settings
Contacts
Many came up on the main screen, which is encouraging.
Gapless ( which I did not have before ), Bluesky ( a shortcut I made? ), Weather and Weather Underground, Tuba, Usage, VLC, Text Editor, Clementine, Shortwave, Image Viewer, Iotas, L5 Tour, MPV Media, Secrets ( password vault app ), Chromium, Console ( thank goodness )
ReText would not load at all. Can’t remember the last time I used it.
Has anyone else tried to install fresh crimson image? I seem to strike out 0 for 3 with it - it won’t power on after flash. I can still do jumpdrive and flash my backup disc images that work fine, but no life from “'Last stable build ’ from Mon May 18 19:57:06 2026”.
I’ve also encountered a second situation while trying to upgrade from old byzantium (not clean/used) image, where after upgrading to “normal level”, the system is offering upgrade to 11 but apt doesn’t offer it and shows nothing to upgrade (version are still old, so it’s still byz). Sinze I have things that I don’t want to remove (the checklist is [too] strict and prevents use of GUI upgrade) and want to take my chances, I’m stuck. Any ideas, what’s going on, on how to get around this? I’ve tried different apt command variations and clearing caches etc.
Are you using an up-to-date librem5-flash-image? (0.0.5)
It’s not going to offer you any upgrades until you switch the repositories. Follow the usual Debian upgrade procedure if you want to perform it manually.
You can run the upgrade app with --force parameter, but you’re on your own if something goes wrong.
I’ll have to check on the flasher version later. The repo was just too obvious (apparently) - so used to that when one entity (in this case GUI) has updated, all have updated (apt too), I quess.
Ok, using The Force is good, but the GUI could have buttons on (only some of them) asking “Are you sure you think it’s ok to ignore this?”. I mean, if user can’t upgrade with any non-approved modifications (like say, one single extra no-purism repo, maybe a package or two) and even slightest deviation requires going to the console… Isn’t that a bit iOS/Android mentality? That may not be the intention but still.
Btw. why the need for 8 gigs of free space (I can’t remember was that brought up already somewhere)? Is there some part of the process that really needs all that apt only claims the system will need some 1,4 gigs more space? That required to delete several programs and to move all of my personal files (I did backups separately). The GUI app, if developed further could at least offer to run a few cache and unused flatapp clearing command to see the real situation.
Maybe something else to look into: Apt update threw a selection window in console that isn’t very informative and asks to choose from a list what to use as charset for console (“Configuring console-setup”). The list doesn’t match Debian’s, but for most, use “guess”, I quess. For me, I guessed wrong with Latin1 and some of the systems texts and touchkeyboard went funny. For some reason no unicode (“all”) was offered. And if it’s just a litlle wrong, edit configuration file /etc/default/console- setup (via sudo dpkg-reconfigure console-setup or use console-setup and keyboard-configuration packages) would have corrected it but… Unfortunetely for me, it changed the screenlock keypad, so as it took some time, I wasn’t able to get back in - all the characters were wonky symbols (and it doesn’t help to use external kb either). It did finally reboot and luckily numpad was back but now I’m missing console and touchkeyboard for the whole L5.
So, yet another try…
The intention is to support the happy path that the majority of people will be on with the GUI, and force the user to slightly go out of their way if they want to do something that may cause troubles, so we want to make sure they’re aware they’re not on the supported path rather than just blindly tap on “continue” buttons.
This applies to everything else, such as free space, as well (though you need the space to store the downloaded packages in as well, so the actual minimum is significantly higher than 1.4 gigs you mentioned).
If you know what you’re doing you can ignore most of the checks - after all, you need to kinda know what you’re doing to deviate from the happy path in the first place - but you should only do that if you know what you’re doing, in which case you don’t really need the GUI app at all anyway.
Very A&G of you to put it like that. I did not suggest “continue” buttons very intentionally - the norm is that for verification user pw is needed for input and a dialog explains what is the risk they are taking. It matters where the line is drawn on what is too simplistic or what options are given - and what’s offered should not be “accept or be on your own”.
I also wasn’t suggesting free space should be 1.4 gigs but asked why several times more space is needed. Is it a guesstimation or is there a special case that sometimes needs so much? Is there any way to know if it could be just 2,3,4 or 5gigs..? Just oddly big.
What matters is that every failed upgrade can increase support team’s workload which then often spills down to me and I really have better things to do than help fix the fallout from preventable failures for often not very technical customers. Suggesting that it’s “iOS/Android mentality” when the user remains in full power and has every override they would ever need to enforce their will isn’t exactly in a good taste if you ask me.
IIRC the minimal required amount of disk space for typical installation was about 4-5 GB, so I added a few GB to that as a good measure to accommodate for systems with lots of packages installed since at that point in the process the upgrader has no idea how much space it will actually require (it will bail off later if 8GB turns out to be still not enough, but at that point it needs to clean up after itself which increases the chances of something going wrong).
As an aside … Ubuntu in-place upgrades just completely disable all third-party repositories. (Hence it is up to you to work out what to do with those repos and the software from those repos after the upgrade has completed.) So it is not just iOS/Android. It is also Linux.
A sensible approach for a user might be to complete the standard in-place upgrade successfully, then image the disk, then start stuffing around with third-party repos and if something breaks badly, you can restore the image (and not have to do the upgrade again and not have to blame the upgrade for the breakage).
An upgrade process has no real way of knowing what the implications are of just one package from one third-party repo. It might be completely harmless or it might badly break something.
In addition to what dos said, that may be a nett figure after a successful upgrade but a whole lot more disk space is needed during the upgrade process. There’s the downloaded packages (lots of them), then there’s the unpacked package (some kind of container format expands out to actual files), then there’s keeping all the old packages and files around in case something goes badly wrong during the install and the installer has to reverse all the changes.
Then finally the installer can declare victory and potentially then your disk is only up for the nett increase. And sometimes that may only apply after you manually do sudo apt autoremove
As far as an extra GUI button goes … there is a cohort of users who take the attitude … I don’t understand the question, so I will just click OK … and they are often the ones who won’t be able to fix the mess if the upgrade goes pear-shaped.
I suggest that the GUI for enabling the “force” option should be that the user types in literally
I have imaged the disk prior to the upgrade and I will restore the image if the upgrade goes pear-shaped
or
I acknowledge that what I am doing involves risks and may cause the upgrade to go pear-shaped and, if so, I will fix the problem myself without contacting Purism Support
or both.
Personally, I always image both before and after a significant upgrade. That is caution born of experience.
Likewise I saw that gcc-7-base was added to the allowlist.
If @antonis wants to play it safe then it may involve applying updates until the PureOS Upgrade application no longer complains about those foreign packages.
