I added the sources updates and security, I main I had added lastly. Now I have about 800 packages, which I have to upgrade in batches again. For example freecad makes problems.
I ran into those as well. My workaround was to remove mutter, update, and re-install mutter. This has worked for me;
sudo apt remove mutter && sudo apt update && sudo apt full-upgrade && sudo apt install pureos-gnome && sudo apt --purge autoremove
Ok, did an upgrade today (removed mutter inbetween) and switched from pureos-gnome to vanilla gnome and apart from a few extension errors etc. - everythings fine!
1 Like
I just did the update from amber to byzantium after today’s blogpost (Byzantium arrived).
I had to reinstall 2000+ packages, of those were 90 new ones and I had to deinstall some 80 packages afterwards. All was done automatically by apt and worked like a charm.
I now run Linux 5.3.0-3-amd64 with the latest Gnome shell. Looks super nice and feels awesome, too, to be on the cutting edge again.
Thank you for your and your team’s hard work, @jeremiah
Have some well deserved holidays.
P.S.: I run a Librem 15 v3
5 Likes
Nice! I have done the upgrade as well, it couldn’t have gone smoother (ThinkPad T430). After upgrading the amber installation, rebooting and then changing the apt sources.list to access byzantium repos:
apt update, apt upgrade, apt full-upgrade and finally apt auto-remove
Thanks, pureos team.
2 Likes
There are now ISOs being built for Byzantium: https://downloads.puri.sm/byzantium/gnome/2020-01-06/
Please note they are experimental at this point.
2 Likes
I would like to ask a dumb question: It is my understanding that a “rolling release” means that the system is continually updated and that the idea of “point releases” does not apply. The advantage is supposed to be the absence of disruption in the upgrade to a major point release. The downside is a series of minor incompatibilities and instabilities that motivated point releases in the first place.
OK, so what do you call the difference when every update in PureOS requires a double reboot and every update in MX Linux happens without any reboot, including kernel and init updates?
Whatever we call that (eg, “sans reboot updates”) is what I want.
most updates in the GNU/Linux world don’t require a restart/reboot but there are some who do …
- Not a dumb question.
- Yes, you’re understanding is correct. (Or at least similar to my understanding.
- I don’t know much about MX Linux except that it appears to be based on Debian Stable. This means that they likely don’t update the kernel to newer major versions. New kernels will need to be booted, at least if you want to use them, otherwise you can just update and keep on working. The same is true for many daemons on the system, they need to be restarted, but you can either do that on the fly with systemctl or you can wait for reboot. The only caveat with waiting to restart system services is that you may have received a bug fix so restarting services might offer greater security.
If you’re looking for high availability, then there are other architecture approaches, like using a container or a Virtual Machine, but even those need reboot occasionally. You can look at Criu if you need something even more robust.
1 Like
Another (possibly dumb) question:
In ArchLinux you always execute pacman -Syu and the whole system gets upgraded. No editing of config files. So in what sense is PureOs rolling ? Does the above addition (of the lines in /etc/apt/sources.list) means that one has to wait for a new announcement from you? Or having the byzantium repos the distribution will roll always without adding more lines to sources.list ?
The editing of config files is a one-off process to change from Amber (stable) to Byzantium (rolling) i.e. change from one repos to another.
In either case, Amber or Byzantium, no further action is required on the part of the user in order to see updates automatically as they become available. Regardless of repos, the same apt commands will apply whatever updates are available using the command line when explicitly requested if the user prefers that.
The difference between Amber and Byzantium will be in
a) the relative timing of updates if both repos get the same update, and
b) the scope of updates - Amber will typically only get bug fixes including security fixes on a day to day basis
Ah, thanks. That is great. So any time I can now upgrade my system. But then how are the names Amber and Byzantium chosen. If they are always the same (Amber=stable
and Byzantium=rolling) the choice of names sounds strange. Why it is not “stable” and “rolling”. This is what confused me. I thought I had to expect another code name in the future.
I’m asking about “sans reboot” updates for PureOS. Why do I have to enter my encryption password twice and my login password once to update an app that isn’t even running?
My comment about MX Linux was simply to indicate that other distros don’t demand instant reboots, even though some updates, such as kernel updates, won’t take effect until a reboot (thanks, Jeremiah).
I shutdown my Purism laptop every couple of days, I can wait for a kernel update, or reboot manually. But don’t force reboots to update a library I don’t even use.
Politely now, I ask “Could we have “sans reboot” updates in PureOS like some other distros do?”
Understanding that this doesn’t require rolling releases. (MX Linux is a point release distro.)
2 Likes
Just go into the terminal and type
sudo apt update
and
sudo apt upgrade
This will update all packages that can be updated and not force a reboot. It will tell you if a reboot is needed for an update to take effect if needed.
The reason the graphical updater requires a reboot for updates is that it is considered “safer” and/or “cleaner” to update packages in a specific environment designed for updates.
3 Likes
I think you need to refer that question to Purism. I could speculate but in this case I don’t think speculation from me is helpful, particularly as it might relate to whether these names will always remain the same in the future.
That of course is your decision to make but a wise decision is difficult to make because it depends on knowing the consequences of not getting the update immediately.
I usually peruse the description of the change (the changelog) and if it gives a CVE number, follow the link to the CVE description - to decide whether to reboot immediately or leave it until the next normal reboot.
If it says “allows unauthenticated remote attacker to do arbitrary code execution with privilege escalation, being actively exploited in the wild” 
then I would say “reboot immediately”.
Perhaps best to put your comment here: livePatch service? if that is what you have in mind.
Does it actually enforce a reboot or merely give the user hassle about choosing to reboot now or reboot later?
Ubuntu seems to a) know which updates even require a restart and b) give the user the choice of now or later.
1 Like
[quote=“antonis, post:37, topic:7723, full:true”]
But then how are the names Amber and Byzantium chosen. If they are always the same (Amber=stable
and Byzantium=rolling) the choice of names sounds strange. Why it is not “stable” and “rolling”.[/quote]
They appear to have chosen a rock theme for the names of their releases and are working their way through the alphabet for versions (I’m curious if Cobolt will be next) much like the tree theme for the phones (Aspen, Birch, Chestnut, etc)
Amber tracks the current Debian Stable (Buster), Byzantium tracks the current Debian Testing (Bullseye), there is currently nothing tracking Debian Unstable (Sid). With this said, I don’t consider Byzantium to be a rolling release, but rather the early adopter testing of the next release. This does get new features sooner but at the potential cost of some stability.
Based on what I’ve seen, Amber will retire with Buster, Byzantium will become “stable” with Bullseye, and there will be a new name for the next testing version…
True, this is speculation/a guess, but it is a guess based on observation and current evidence; as such, I think most will be able to follow my logic.
4 Likes
Many different issues intertwined here 
Arch is a rolling release, just to clarify things. And if things change, you will have to edit config files there too :-).
As for amber, byzantinum: only purism can say why they chose these specific names. But for debian and derivatives it is pretty common to give the various dists code names, such as wheezy, bullseye, or warty warthog :-). In Debian one has the choice of running a rolling release (testing, sid, byzantinum) or choosing a stable one (amber).
As for the “sans reboot” updates, this is completely orthogonal to the stable/rolling discussion. It is perfectly possible to update a computer (with basically the exception of the kernel unless one live-patches) while running. And this is typically done with servers. However on graphical desktops the system often recommends reboots: the reason is that processes that are running are not being updated even if the underlying files are being deleted and updated. So eg. when your graphical desktop has a security issue in xlib.so and and an update provides a newer xlib.so, the old one will still be used until the library is unloaded and reloaded. (google lsof DELETED to find out more about deleted but still opened files).
And as it is pretty tricky to find out which services need to be restarted in order to get rid of obsoleted but still opened files, and reopening these e.g. within the running graphical desktop might even be impossible, many desktop distributions simply recommend (or require) a reboot after something crucial has been updated.
3 Likes
I didn’t realize I had that option. Simple enough for me.
Cobalt you say? Hmm . . .
2 Likes