A recurring question that goes around the internet is why Fedora Linux has to restart for updates. The truth is, Linux technically doesn’t need to restart for updates. But there is more than meets the eye. In this short guide we’ll look into why Fedora Linux asks you to restart for offline updates.
Offline Updates
The process of restarting, applying updates, and then restarting again is called Offline Updates. Your computer boots into a special save-mode, where all other systems are disabled and where network access is unavailable. It then applies the updates and restarts.
Why Offline Updates exist
Offline Updates is there to protect you. Computers have become way more complex in the past twenty years. Back in the day, it was possible to apply updates without too much worry since the system itself was smaller and less interconnected. Multitasking was also in its infancy, so users were not actually using the computer and updating it at the same time.
The Linux Kernel can change files without restarting, but the services or application using that file don’t have the same luxury. If a file being used by an application changes while the application is running then the application won’t know about the change. This can cause the application to no longer work the same way. As such, the adage that “Linux doesn’t need to restart to update” is a discredited meme. All Linux distributions should restart.
How Offline Updates work
For Offline Updates to work, there are a few components collaborating under the hood. First, there is the package manager that downloads updates and then stores them. It won’t actually apply the updates directly, but it will tell the next system that there are updates to be applied.
The second part is done by systemd. When systemd starts, it will see if the package manager has prepared any updates. If that’s the case, then systemd won’t go into a full system start-up, but will instead start the package manager and apply the updates. Once the updates are completed systemd will then restart the machine a final time.
Software update pending for Firefox. See how the Flatpak version of Firefox does not need to restart since Flatpaks are designed with reliability in mind.
Where Offline Updates comes from
This problem was first realized in 2009 and the early whiteboard discussions are still visible. Once a possible solution was designed, it was put in development.
Still, it required multiple components to work together. Changes had to be made to systemd to support this special start-up flow and package managers had to understand the process as well. After that, it was important for users to have a supporting UI, which was included with GNOME Software Center in 2012 and with KDE Discover in 2021.
Fedora 18 official artwork. Very wild, but also very reliable.
Finally, the feature was officially deployed in Fedora 18, making Fedora Linux the first distribution that does everything it can to ensure that your system is reliable and stable. It was a long road, but this functionality has now been with us for almost 10 years.
Doing live updates
Now that you’ve been told about Offline Updates and their importance, you’ll of course never do them again… but what if you do? Fedora Linux will not stop you and since we’ve all used DNF at some point, it might be good to talk about live updates as well.
Nothing bad happens
First, there is a good chance that nothing bad happens. Perhaps it’s just a minor update, or the application that it affects is not running at the moment. There will be little issue updating SDL for example, when you’re not running a game.
Do keep in mind that running systems may still have the exploits that a previous version of the program might contain. If you update an application without restarting the application, then you’re still running the old version with its vulnerabilities.
Many expert Linux users, like those who professionally maintain servers, will often instinctively know what application can be updated without any risk. For this specific purpose, you can also only install security-updates, which is discussed in another article. For larger updates, even professionals are encouraged to use dnf offline-upgrades through the terminal.
Firefox restart required
The most common sign of instability is Firefox warning you. When Firefox detects updated packages, it will force you to restart the browser. Firefox can’t reliably run without completely restarting and it will therefor force you to restart.
This also highlights a happy recovery: A complex and security-critical application like Firefox will help you, shielding you from potential crashes or vulnerabilities. While many might consider this a big nuisance, it could be far worse.
Demonstrated with Ubuntu 20.04.3 in GNOME Boxes. I tried to trigger this error using Fedora Linux 34 & 35, but in both cases it completely crashed Firefox. Just to drive the point home: this recovery scenario is a fluke.
Crashes
Not every application can recover so gracefully, though, since most will just crash. Firefox might also still crash. While many of you will be familiar with Firefox gracefully terminating, this is still an exception to the rule.
If the system in question is the X Window Server, or the GNOME Shell, then your screen might turn completely black. In many cases, you’ll still be able to complete the updates, but there is no way to know that for sure. Now, the best course of action is to switch to a terminal view.
You can use Ctrl‑Alt‑F3 to enter a text-only instance of Fedora Linux. Once you log-in here, you can use a terminal application like top to see if the update has completed. You might then shut-down all processes and restart the computer.
In top you can filter for certain processes by pressing ‘O’ and then typing a filter like ‘COMMAND=dnf’
Blackouts
At this point, there is still hope. Start your computer and see if the system comes back to life. If the system boots into a graphical environment, everything will likely be fine. If not, you’ll have to enter the text-only interface (TTY) and you should look at the history of DNF and see what happened underneath the hood.
$ dnf history list
$ dnf history info {LAST ITEM}
$ dnf history redo {LAST ITEM}
Additional information can be found in the DNF Documentation. There is no guarantee that repeating the last update-action won’t cause the same problems, but it’s the best you can try at this point. Removing third-party drivers (like those from Nvidia) might also help, as this is a known to cause updating-related issues.
System bricking
Finally, you can hard brick your system. If the system that crashes happens to be DNF or systemd, then it might not be possible for the system to continue its update process. When this happens, even restarting the machine will not be enough to restore it.
There is no one answer about what to do now. First, you should get a USB-Stick with Fedora Linux. You could then try to recover the system using systemd-nspawn but that is highly technical. Regular users might just as well reinstall Fedora Linux and start from scratch.
Keep in mind that all your files are still safe. Booting from a USB Stick will not damage them, and if you make sure that you don’t overwrite your existing /home partition, then all your personal data will still be there afterwards.
Closing words
Direct updates are a roll of the dice, and while you might get lucky a lot…. We tend to overestimate ourselves and the chances we have. Many of you have never experienced a system bricking, but on the whole those stories are very common on social media. As such, it’s important to spread the word. Encourage others to restart their computer to apply offline updates, and be careful yourself when you apply updates directly.
In the future, problems like these might go away entirely. Systems like Flatpak and Fedora Silverblue have technologies that make these kinds of crashes nigh impossible, and the Linux Desktop is slowly moving into that direction. The future is bright, but for the time being we should make do with a progress bar, just like some other operating systems.
Got any personal update-related horror stories? Feel free to share them in the comments. I would also like to point out that I like memes just as much as the next guy… but they should be jokes, not technical advice.
laolux
Offline updates may be robust, but can be slightly annoying. Would be great if I would not have to unlock my luks devices twice for one update. I start the update, wait for my system to reboot, enter the password, go do something else during the update, enter my password again and need to wait for the computer to start completely. Could save quite some waiting if no complete reboot would happen and the disk would stay unlocked, especially on my rather old hardware.
For me it would be ideal if I would just run updates at the end of my work day, shut off my computer and turn on an updated system in the morning. Or maybe even wait for the updates to start (enter my password), but leave before they are done and my computer turns off after the updates. Can I tell Fedora somehow to shut down after the updates are applied instead of rebooting? Don’t want to waste energy all night until I come back in the morning or sit in front of my computer waiting for the updates to finish only so that I can turn it off afterwards.
For online updates I had good experiences using screen, especially when using flaky connections such as ssh.
David Strauss
This is a major reason why I use Silverblue.
Rafał Baran
You can download the updates in Gnome Software and then just shut down the computer like you would do normally and it will ask you if you want to apply updates before shutdown.
The linux guy (since kernel 1.x)
That’s great. I either do that or just dnf update. Both have advantages.
dnf update show the download size and nice progress.
Gnome Software show more info about the updates.
Steven Rosenberg
I don’t think it works this way in Silverblue, which is what I’m using. I’d like to be wrong. Ideally we could shut down Silverblue and then apply the updates on the next boot.
Steven Rosenberg
But maybe it works if you do:
$ rpm-ostree update
Benjamin
Well, I have a rather standard Fedora Desktop installation and that’s what happens. Maybe you’ve got a different setup? [1]
When I power off my computer, given an update is available, then Gnome simply asks if I’d like to install updates. If I agree, it reboots, installs updates and finally shuts down; no energy waste. The next day, it starts normally; no productivity waste.
Of course, it has never ever done it without my explicit consent.
+1
I can’t agree more here!
If you’ve got your /home partition LUKS-encrypted, the system will require your passphrase to unlock it, before applying offline updates. This really is an annoyance. I always wonder why does the system need to access the home partition to apply updates?
[1] TBH, I thought dnf-plugins-extras had an option to perform an offline update on a shut down rather than a complete reboot… but it looks like it’s not supported. I could only find this feature request to run an action after a completed update: https://bugzilla.redhat.com/show_bug.cgi?id=1995349
Truster
i use a Keyfile on an USB Key, so the unlock process for my entire drive is transparent and touchless™. As a fallback, i have an extra slot configured with a very long string stored in a keepass file in case the key is unusable.
laolux
Thanks for your input. Nice to know that Gnome Software can apply updates on shutdown. Unfortunately I cannot use Gnome Software, because it refuses to work with the awful proxy I currently have to use here. And it has updated some flatpak app’s permissions behind my back without giving any warning (flatpak update does warn nicely). It is also missing features such as provides. So simply put, Gnome Software is some nice software, but I do not belong to its target group. Can’t complain, happy with command line anyways, only there I cannot select shutdown after applying offline updates 😐
James
You could just sudo dnf update from a terminal and reboot once.
Jesse Pollard
works best. I do it within a “script” recording so if I have questions I can do a quick look to see what went on.
Shawn
It also bothers me. Maybe someone can write about how to replace the reboot with kexec.
Jocelyn
Using kexec will have a much better user experience IMHO. Particularly when you have encrypted partition, or slow BIOS/UEFI.
Don’t know if that’s hard to do.
Torkin
Since the article quotes offline updates good qualities only (to which I agree), I’d like to point out a major bad one in my opinion: damaged productivity.
Linux distro, differently from some other OS, often runs on older devices, which could happen to have an HDD instead of SSD. If the distro also happens to be a very often updated one (i.e. Fedora Linux) updates can be the size of GBs daily. When a user boots up its device, it’s usually because it needs it to work, and doesn’t want to spend time waiting for it’s machine to apply updates + double restart every time a random component of its system needs updating.
I think that we need a more complicated solution than this. This kind of updates was one of the most important reasons that made me do The Switch, and I think i’m not the only one. System stability is surely very important, but I don’t think that we should settle with sacrificing user productivity this much in order to achieve it.
Brief version: In my opinion, offline updates are good, but many people dislike them. We should not force them to adapt, and instead further researching a solution which goes in favor of both stability and productivity.
Gregory Bartholomew
FWIW, a few people have brought up the idea of having the update manager take a snapshot of the root file system and then do an online update on that. The user would still have to reboot to get the updated system. But it would eliminate any problems with individual applications seeing different libraries depending on when they were (re)started. Online updates also have the advantage that you can intervene manually in the rare case that something goes wrong during the update. I think most people reboot at least once per day (if not more). So that small window of vulnerability in the case of a security update doesn’t really seem like much of a concern. (It likely took days to write the patch and get it distributed to the mirrors. So if the end user waits a few more hours before rebooting, it hardly matters.)
Rohan Mishra
This seems similar to the A/B updates that Android does but with a different implementation. This would be much faster as well if the updates could just be done in background when system is not in use or idling and connected to power.
I wonder what changes might be needed. For one: we would need to know if system is in active use. updates should go through if you are plugged in and have the update screen up or doing a light task but pause when on battery or running a intensive workload.
Also space used by updates might be of a concern
Gregory Bartholomew
There is another feature called RPM CoW that is being experimented with that might help with the space concerns. It is highly experimental at this stage though. So it might be a while before that makes its way to be something that is available for the end user.
https://www.youtube.com/watch?v=-qYgkcs6Uxk
Chris Murphy
There’s a decent number of ducks that need to get into a row to get there. It’s analogous to the effort of rpm-ostree based installations, and openSUSE transactional updates (and MicroOS). And there is potential for scope creep, because reorganizing anything has a tendency to touch so many things that it can become apparent that lightweight changes don’t go far enough. For example: https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslayout.md Conversely it’s possible changes can be too many and too soon.
But we do have some ideas what it could look like having updates that “happen along side” a running system. Snapshot the system, run the update process in a container on the snapshot. If anything fails: power failure, crash, the user merely wants to reboot or shutdown for any reason, that container just goes away and later we can clean up the partially updated snapshot by just deleting it. The “update in progress” snapshot is completely disposable up to the point in time when it’s certain we want to boot it by default. Also, containers are subject to cgroup resource control, so we can seriously throttle the update process by giving it only spare cpu, memory, and IO. It’ll get max performance if you aren’t doing anything else, but quickly the user’s preferred tasks (the ones they’re using in the desktop environment) get resource priority, on-demand. Also I expect the updates process will be among the top candidates for being oomd killed, because again, it’s a completely disposable event. Unlike now, where we’re applying updates to a running system, and having it die in the middle of the update can mean all kinds of hilarity ensues (except, it’s not that funny).
Phoenix
“I think most people reboot at least once per day (if not more).”
Working in an IT helpdesk, I have my doubts about this statistic. While there are users rebooting their computers, either out of necessity (e.g. it crashed or caused some other instability) or to actually save energy, others are a) update-lazy and b) hate restarts as they need to rearrange their application windows after each reboot. The latter are a surprisingly large number of users. While I do not know the percentage, I would estimate those to be at least 50%.
Gregory Bartholomew
Saving energy is a good point to highlight. People aren’t physically capable of operating computers continuously. We all have to sleep sometime. IMO, if people aren’t shutting their PCs down when they are not in use, they should be shamed into doing so. Routinely rebooting a PC is also a necessary part of maintaining a healthy system. Long-running processes should be run on server systems that are designed for longer up-times.
Jackson
This is what S states are for. And most Linux users are certainly not rebooting their computers every day, that’s insane lol.
Jesse Pollard
There is no such thing as a desktop PC, they are ALL servers. – with destop applications added.
So I treat them all the same. From a Raspberry PI to a dual quad server that is used as a desktop.
Mark
And I thought users hating reboots because they have to spend 30 minutes re-arranging the windows to be “in the exact place they’re used to them being in” was just something at my organisation.
Ed
It’s probably universal.
It’s not just windows out of place, either. For me, the issue is, “What was I working on?” I use screen and have 10+ shell sessions going on per terminal window. It’s relatively easy to “save state” by just making a new session, and get back to it when I’m done with whatever distracted me. Theoretically speaking, of course. That’s all lost every reboot.
Using screen is niche, but the same is true for most applications, if I’m not mistaken. Web browsers are pretty good at saving your state and tabs, but most other applications are not.
I’d kind of like to have some general way to restore the states of the processes you were running after a restart, but when you’re restarting for updates, there’s a lot of opportunity for that to not be easy. I’d expect it would probably be like vim swap files: some updates will make the old state files unusable, and it requires diligence on the part of the people making updates to keep those sorts of updates rare.
Jesse Pollard
I reboot only for kernel updates. otherwise I have found there is no need.
Thijs
“When a user boots up its device, it’s usually because it needs it to work, and doesn’t want to spend time waiting for it’s machine to apply updates + double restart every time a random component of its system needs updating.”
I really never had this happen to me with fedora, or linux in general. The computer always is finished updating when I boot. When I shut down or reboot, it asks me to install downloaded updates. Usually it reboots only once, but always when shutting down, never when starting work. When I reboot the computer, and want to resume work quickly (and how many time does this really happen?), I can just uncheck the box, and it won’t do an offline install, and it will ask me again next time.
A perfect solution for desktop, I think. For laptops, that you most of the time want to put somewhere with the lid closed, the solution is less ideal, because you’ll need to wait until updates are done before putting it away, as far as I know. But that’s always better than having updates apply at startup.
More specifically:
What distro are you running that applies updates at startup, and needs to reboot multiple times? That is really bad update design that should not exist. I sound like something that is specifically made to annoy you.
Fast storage devices, like a usb thumb drive, can be bought for a price less than a single home cooked meal for 2. Some SSDs are also really cheap. IMHO, there is really no reason to boot from a mechanical disk. I have some in my NAS, where speed is not important and storage space is, but for PCs, just replace those drives.
Ed
How difficult would it be to configure the software so it would temporarily disable the suspend on laptop closed, only to last for the remainder of that shutdown, and have the reboot to apply updates ignore the lid status? That way, we could still close our laptops and have it all finish just fine.
Patrick O'Callaghan
I use dnf for updates, with python3-dnf-plugin-tracer. That tells me when I need to restart certain apps, just log out, or reboot the system. I haven’t had any problems with this.
Benjamin
Same. I had no idea that offline updates was even a thing.
once every week or two:
dnf update; reboot;
Fax
Lol more Fedora copium. Can’t deal with the fact this OS is getting more Windows-like and over-controlling with less freedom every day. If your software breaks by just updating it, your software is trash. Simple fact.
Fred Weigel
Fax: This is “baked in”. Dynamic linking is used to share common libraries. Even if the library is erased, if a reference is open because it is in use by an application, the disk space is not reclaimed. This means that a new copy can overwrite the old copy (“reboot not needed after update”)… but… the old copy is still in use. Let us say that one of these libraries needs a security update. But a running application is still using the old copy — your system is STILL vulnerable after the update. Until the application is restarted! Which is wh Firefox demands a restart… No Fedora does NOT need the restart. But, it is safer.
Fred Weigel
Robby Callicotte
+1 Fred!!
Mark
A correction, it is not “baked in”. It is perfectly possible to compile an application with static linkage rather than dynamic linkage; and I personally believe static should be used for anything you want to keep running.
OK, it may save a little disk space; disk space is cheap.
Having said that as you mentioned using dynamic linking does allow security updates to be implemented into a library without changing an app, until the library changes and breaks the app anyway with the dreaded xxxx.so file not found message.
But it’s not “baked in”, its up to whoever compiles the application to decide whether dynamic or static is best for the app and deciding whether getting possible security updates or keeping the app running (including just copying the binaries to a completely different distro which may have different library versions and having it run) is more important.
Khalid Abu Shawarib
“Your software”, as if Fedora maintainers themselves developed every single application they ship in the repository. They only told you the truth about the state of most FOSS software not being able to withstand live updates and you’re shooting the messenger.
Some Ed
There’s three parts of linking a program. Others have talked about the first two.
At compile time, the compiler performs static linking. This isn’t afflicted by this problem so long as either the updated version is installed with a new inode (the normal way updates happen in Linux) or the running program does not mmap the code rather than loading it in its entirety.
At run time, the linker performs dynamic linking. This isn’t affected by this problem as per above.
At various times during the execution, programs can load plugins to execute even more dynamically provided software. You run into problems when you try to make use of a plugin after the update that you didn’t have loaded (or possibly you had, but you then did something that caused it to unload.) Sometimes, you’ll be able to get away with it, as many updates won’t change any plugin API things and won’t depend on the new or old functionality. But other times? Anything that can happen within the context of a computer could happen.
Many programs will store version specific information in their internal databases. The update process transforms the database to what the new version expects. If the old version is still running, you’ve more or less just gaslighted it, and it probably won’t know how to handle it.
oslinux
I have been using Fedora since the beginning and didn’t know offline updates were a thing. I have always done my updates from a terminal and only reboot after a kernel update. so far never had any issues with updates. when software gets updated I restart the software. on my old system that was the faster option but now that I have an ssd a reboot is just as fast but annoying to do after an update.
like others have said, If you need to reboot after an update (kernel update being the exception but if setup correctly the kernel can be configured for online updates.) your doing it wrong.
ManOnFire
“I have always done my updates from a terminal and only reboot after a kernel update.”
Same here.
“didn’t know offline updates were a thing”
Same here. In fact, I’m still not sure how I do an offline update, even after reading this article. Did I miss something?
rafal06
You have to download it trough Gnome Software. It will then show you the restart button (or you can just shut down the computer and it will ask you if you want to apply updates before shutting down).
Edward Campbell
how do you find out which packages are updated if you do it this way???
AsciiWolf
You can do them from a GUI (GNOME Software’s “Updates” tab).
Renich Bon Ćirić
You can try of of:
dnf offline-distrosync
Steven Rosenberg
That’s a good one!
Tim
try it for a laugh. It’s funny. You get a vim update, but you have to reboot to apply it.
Darvond
Seems like it’s another questionable feature that’s exclusive to those living in the crystal spires of Gnome.
So I guess us helots who prefer desktops like i3 and NsCDE can just pack mud in our Anarcho-Syndicalist Communes, while some madman claims they got a sword from a strange woman in a pond makes them the king.
Leslie from Montreal
Thank you for your informative posting. I am a very long time (15 years) Fedora user and have a good appreciation about realtime updates.
I noted the applications that are active, and then compare them to the list presented by dnf. If there are no conflicts, I just let dnf do it’s thing, and I continue happily. Otherwise, I reboot Fedora to insure that ram modules get refreshed
Todd Lewis
I too have been running Fedora boxes since before the RHEL/Fedora split, and I didn’t know about offline updates until a few months ago when I inadvertently built a VM with the GNOME image. Besides all the other annoying things about GNOME that convinced me to abandon it years ago, it had sprouted this reboot-to-upgrade feature. I can see where it could be attractive for certain users. I’m not one of them.
Glenn Junkert
Thank you. Very informational. Very well written!
Tom
Thanks for the great article. I run Fedora KDE 35 on multiple devices and every once in a while, the offline update via Discover does not work (simply reboots without updating) and I have to run it a second time. Any ideas why this is the case?
Allen Weiner
I run Fedora KDE 35 on my desktop PC which has an Intel NVME SSD for its sole secondary storage. Over 80% of the time, the automatic reboot (after the offline updates have been applied) seems to not find the SSD and ends up with the “Intel Boot Agent” unsuccessfully searching. My PC is standalone. I have no idea why this happens. The restarts that I manually start always succeed.
Ryan
Like many others in the comments here, I:
a) have been running Fedora since the beginning
b) don’t use offline updates
c) use KDE
d) use dnf from the terminal for updates
I always:
a) check running applications and compare against what’s being upgraded
b) restart if there’s a kernel/systemd/plasma/mesa/graphics driver update
c) run sudo needs-restarting or sudo dnf needs-restarting to determine if there’s anything that I can restart manually before having to reboot (this utility is from dnf-utils)
d) reboot if necessary when I am ready to do so
Productivity is usually more important to me than rebooting immediately after updating firefox (as per the example here). I would much rather close firefox and other user space applications that might be leveraging the backend libraries and then run the update to ensure there are no conflicts and then reboot later. This is especially important to me on my work workstation.
To be honest, the only way I see this kind of forced reboot being beneficial is in a system like Fedora Silverblue or Fedora Kinoite where you have to reboot to get the updates anyway, especially for an advanced Linux user who already knows what is being updated all the way down to where the files are situated and how DNF will perform the update process and whether or not anything will actually need to be restarted because I already know exactly what the majority of packages are actually doing (dnf info ).
re: ‘update horror stories’
The only times I have any update related issues are typically from kernel updates. I actually contribute to Fedora by testing kernel updates and other update packages at the point they arrive in the test updates repo. I file bug reports when I have issues and I test them on a live system from the time they are available for testing.
The biggest issues I’ve had are booting into a black screen after the upstream Kernel team updated the way parts of my hardware were handled within the kernel. I worked with both the Fedora kernel team and the upstream Kernel team (even compiling the kernel from source) to make sure that the issue was resolved. That issue was resolved after about a week and a half of troubleshooting with them, and in the meantime I just booted into the old kernel until it was resolved.
Often resolving an update related horror story means just uninstalling or downgrading a package to the previous version. One of the issues I had after an update was after updating nsswitch changed some integral symbolic links with pam and meant I couldn’t authenticate properly into my system. I had to boot into a live cd and chroot into my filesystem so I could resolve that one and after filing a bug and working through it, we ensured this update didn’t make it to stable before a fix was in place.
Mehdi
Wow, thanks Ryan.
Now I realize how valuable the work of early beta and kernel testers is.
Occasionally, I get update notifications in the Software application and I let it download updates. Then, it ALWAYS reboots to install the updates.
However, I often use dnf update live and the only thing that complains is Firefox to be restarted, and the system gets a bit slow during updates when I am doing something else at the same time. Other than that I never knew the Fedora system needed restart. Actually it concerned me a bit, so I might have to be more careful when doing updates.
Shy
After running:
sudo dnf upgrade
I run:
sudo lsof | grep -E ‘ DEL .*(lib|bin)’
to show programs that are still using the old shared libraries and binaries which have been replaced by the updated.
lsof reports DEL for files which have been replaced (deleted).
If a file is deleted, the file handle remains open and can still be used (This is not what some people expect). The file will not really be deleted until the last handle is closed.
Renich Bon Ćirić
Thank you for the trick! Will try. 😀
A-team
Is there a way of specifying which updates are system updates that require restarting, versus application updates that only need the restart of the application? In KDE Discover, it insists on using offline updates for everything, even if something like Firefox or LibreOffice is being updated and nothing else. So it needs me to restart for Firefox and LibreOffice, even if no system packages are affected.
ivanhoe1024
Came here for the same comment; I am not an expert (so no idea on how easily this could be done) but, to square the circle, the ideal would be restart the whole system for system updates, and just restart the applications or the services app updates… maybe a simple session/gdm restart? somehow this is what can be achieved by using silverblue and flatpak (reboot for system updates; no need to reboot for flatpak apps updates).
A-team
I have found that using Flatpaks for ordinary Fedora also has this same effect. Flatpak-installed applications are treated like regular software instead of system software, no restart required.
Silverblue seems promising, and I tried Kinoite although it’s near impossible to remove all that akonadi bloat. I’m hopeful that Kinoite 36 will iron out a lot of issues.
berend
Reasons I do on-line updates, and don’t reboot unless there are security updates:
* Headless servers
* Desktop apps remain open, so work continues. Who removed gnome’s session management in 3.8?
* On-line updates can be cron-ed. This means no user involvement (reboots, luks passwords) and user time is more valuable than pc time.
* Anecdotally, off-line updates have bricked machines 3 times in the last few years, and on-line updates never
** systemd update timeout causes reboot, update again, timeout, reboot…
** grub update brick
** arm firmware brick (on-line would have bricked too, except I didn’t reboot)
Hobbes
In my experience GNOME software has always been extremely unstable, especially in how it handles updates. It usually needs a full restart to reliably list available updates. It’s been like this since the early versions and I haven’t seen any improvements throughout the years.
But all it does is serve as a frontend to PackageKit, so if you don’t run GNOME, or don’t want to deal with GNOME Software, you can schedule offline updates through the command line:
This will schedule the packages to be updated on the next reboot. You can list pending offline updates with:
And see the result of the last offline update:
This works in any distro that uses PackageKit. Like Systemd it’s meant to abstract a lot of the low level stuff and provide a simple cross-distro way to manage packages and updates (which is why GNOME Software and a lot of other package management frontends use it). I’m surprised the article didn’t explain the underlying PackageKit mechanism, which is really what does all the heavy lifting. There’s nothing GNOME-specific about this.
GeorgelT
this “feature” has been there for many years and was also one of the main reasons I avoided having Fedora on any of my main machines. When I did use or try it I would always use dnf and reboot as necessary. This whole post is just an excuse for why it’s the default. I haven’t found an easy way of turning this “feature” off in Gnome. Thankfully KDE people are nice and added a checkbox to turn this off.
philipe
Why does this need to be more complicated than
? If you’ve got things you need to restart that you can restart, then restart them. If you’ve got things you can’t restart (drivers, kernels, firmware, shell, etc.) then it’s up to you if it’s worth the reboot or not. I usually perform system updates daily and only reboot if 1) I run into an issue 2) there’s a major security bulletin, or 3) I need a new kernel feature, which is quite rare nowadays, maybe months in between reboots on my workstation.
Jesse Pollard
exactly.
Curtis M
The worst update failure I’ve ever encountered was upgrading my desktop from Ubuntu Jaunty to Ubuntu Karmic (9.04 to 9.10), back in college. Not only did the system boot to TTY, but for some reason unknown to me, it was… “blinking.” The display would black out for about a quarter second, every second, and while the display was blank, the system did not respond to any input.
It was fine otherwise – or at least, I was able to log in and shut it down, as long as I watched out for the black out periods – but I didn’t even attempt a repair; I reinstalled from scratch.
Darvond
Here’s my update horror story: Trying to go from Mint 18 to 19. Got stuck in a loop because their dependency resolver pulled a stupid. There’s no eject or way to drop out of the upgrade process when it’s started, but there wasn’t a transaction test either. My solution was to nuke the system and replace it with Fedora.
Dimz
But when the kernel is updated the updated doesn’t run until a restart has happened. Granted I am using Garuda, which is arch based, but unless I’m mistaken kernel updates require a restart to be used.
Thijs Janssen
Linux does support live kernel updates since 4.0.
https://wiki.archlinux.org/title/Kernel_live_patching
Joe
linux is not windows. Please don’t copy the bad things from windows.
A-team
Nothing wrong with getting the good bits of Windows though.
Fedora Linux offline updates:
1. Download updates.
2. Reboot to install updates.
3. Reboot again after installing updates (automatic).
4. Boot into desktop.
Not bad, but windows does it better:
1. Download updates.
2. Reboot, or shut down. Install updates upon shutdown. If necessary, finish updates off while system comes back just before desktop.
3. Go right into the desktop.
So, there’s still room for improvement on the Linux side, but hey, at least Linux doesn’t have… the registry!
When system components are updated it’s good to restart to keep the running copies of libraries and programs in sync, so an offline update stack is a good thing.
Joe
sometimes I just want to reboot and windows force me to update and wait for several hours if not stuck and can’t work work immediately. I think should let the user choose to update or not, Sometimes users just want to reboot and won’t to do anything else. Thanks
Thijs Janssen
That is exactly what fedora does. It does install at shutdown, not at startup. And yes, it also install updates on reboot, but it always asks. You want to reboot with and continue working, just uncheck the checkbox. You want updates installed and ready for work tomorrow, just press shutdown and leave the checkbox checked. Fedora will reboot and then shutdown after updates are installed, so it will be ready to boot quickly.
Joe
Can Fedora won’t automatically install updates on reboot? If the user want to update tye os can just run ‘sudo dnf update’ or click a popup to install the updates and prompt him to reboot at the end? That seems like linux way
A-team
This never happens with me (Fedora 35 KDE at the moment). When using Discover, it just downloads the packages and waits until I reboot the system to begin the update process. Then it has to reboot again. Running the updates during shutdown would be a better solution.
Could this just be KDE? I notice the update system isn’t integrated very well. Clicking the Update icon brings up Discover instead of bringing up the little pop-up which quickly allows the user to start downloading or check for updates, like most KDE installs should.
Thijs Janssen
That must be it. It would explain why I see so many contradicting comments here. I think it is KDE or fedora’s implementation of KDE. Although I base this only at comments here, I have 0 experience with the KDE spin.
Regular (gnome) fedora workstation installs at shutdown or reboot, and always asks if it should install updates (yes by default), and I can’t remember when, if ever, I had to wait for updates when I start the system.
Sebastian
I use a vanilla Fedora 35 installation with Gnome and all offline updates are installed after a reboot.
If I want to shut down and select “install updates” the system does in fact reboot to install updates and then shuts down after that. This is really bad UX because you have to enter your LUKS passphrase before shutdown.
I think offline updates would be tolerable if they got installed right before shutdown, without an extra reboot. But right now I prefer to have them disabled.
Jesse Pollard
Linux also doesn’t mandate reboots either.
Szymon
I’m going live only. When installation finish I just restart my PC and that’s all. It’s not a DB server or something which may be sensitive to some online changes. Even if I have this, I’d like to stop my services manually, perform update and reboot only once. Anyway, this mode is a cool option for people who want to be sure, that everything will be OK after installation.
daveome
How does “dnfdragora” fit into this, is it safer than just “dnf update”. I don’t mind rebooting if I didn’t have to wait for “containerd-shim” to die on f35.
Darvond
DNFdragora is literally a visual frontend for DNF. It’s doing the same commands in the backend, but with a slight graphical flair.
Milad Sharifi
Hi
I’m a little confused by this. Does this mean that it is a good practice to update a fedora OS by gnome-software instead of using “dnf upgrade” in a terminal?
If this is right, why fedora doesn’t integrate offline updates into dnf package manager?
Is this the reason for having many rpm output warnings and error messages during the execution of “dnf upgrade”?
This is just opposite compared to upgrading to the new fedora release where it is a good practice to use dnf package manager instead of gnome-software.
Thank you all.
Renich Bon Ćirić
It did. Try one of these if you want to use them:
dnf offline-upgrade
Milad Sharifi
Thank you. What are differences between ‘distrosync’ and ‘upgrade’?
Darvond
DistroSync will ensure that all packages are exactly as Fedora packages them; this means if you installed a named package from an external source, it could be upgraded or downgraded. Personally I think of it as a vestigial command.
For example, if I were to run DistroSync, I’d get NsCDE downgraded, because Fedora only has NsCDE 1.4.1, whereas the github version is up to 2.0.3.
Gabriel G.
My 2 cents would be that this is an amazing feature for most of my device but one; The one that need a dkms driver for wifi; Any kernel upgrade will hang (Stall at X% indefinitely) in this “offline update mode” and, since the initramfs isn’t built, will prevent you from boot normally afterward.
I need to download the updates with the software center, then uninstall the wifi driver, reboot and update, then re-install the driver to get wifi back. It’s not that long, but not that fun to do every time ^^’ So a dkms support would be nice in the future for this feature (Like, remove then re-apply automatically. but then you enter in a whole new world of handling any error while re-building the drivers with the new kernel… so I can understand it’s not really doable with the current intend (“just let it update and then shutdown/restart”).
In any case, it’s still a good feature for my other devices ^^’
Jesse
All Linux distributions should restart.
NOT if the administrator knows his stuff. Only services receiving updates need be restarted. Other than that a reboot is unnecessary unless you are performing a test before passing the updates to a large number of systems and that is part of the standard operating procedures of the site.
Single systems have never been so sensitive.
alexB
I NEVER use GNOME software for updates, or system upgrades. Especially the upgrade system via GNOME software leaves much to be desired, no feedback, no way of knowing if it got stuck or how far it got, (Take note RedHat and GNOME developers, this is not following good GUI standards programming)
I had to abort gnome software upgrade once, because it was sitting there for 30 minutes, frozen. Rebooted, still recovered, did it from comand line.
I use fedora for work, so it’s a full work day. I do my updates in the terminal wth pkcon or dnf. then I’ll decide If I think a reboot is needed, depending what was updated. It’s faster too.
The above has proven very reliable for me.
alexB
I should add, you get progress bar when doing upgrades, but before that.
Also the upgrade bar didn’t move for 3 – 4 minutes (sat at 0%) starting an upgrade before it indicated it was doing anything (Fedora 34 – 35 upgrade in fact) _ this is also breaking the rules of giving user feedback, that’s far too long. The inpatient would likely have pressed reset thinking it had frozen.
Renich Bon Ćirić
First of all, please, change “System Bricking” to something else. Bricking applies to phones that become unrecoverrable; usually by interrupted firmware updates or such and would render them, effectively, a brick.
I see your point and, somewhat, agree to a degree. I don’t think the current implementation is the best, though.
Usually, restarted the application that you updated solves the problem you mention. Going for a full restart, IMHO, is not always necessary. In fact, in most cases, it isn’t necessary.
I’ve noticed that dnf has a “needs-restarting” plugin.
https://dnf-plugins-core.readthedocs.io/en/latest/needs_restarting.html
I think we can do a much better job at determining what, exacly, needs restarting and inform the user about it and, maybe, offering to restart them automatically. A reboot, again, is overkill, IMHO.
And, quite honestly, I never use offline upgrades and never had such issues. If I see glibc or the kernel being updated, naturally, I reboot.
That said, for the kernel, we have live patching. A quick search shows many projects (livepatch, ksplice, etc).
STiAT
I was actually positively surprised that Fedora has this feature, even in the KDE Spin.
I’ve been using Linux since 1998, and it’s (really) my first time using Fedora as a workstation, more likely coming from RHEL on Servers and several distros on the desktop (SUSE (1998-200?), Gentoo (200?-2004), Arch (2004-2017), Solus (2017-2021), Neon (2021-2022) – pretty much in that order) on the Desktop, and my past dives into Fedora were not that .. good to be mild, but it was the early days of Fedora to be fair, I just never gave it a shot again.
Due to my colleagues really highly recommending to try it again – I did so, and I was really surprised how good Fedora Worksation actually is by now.
For the offline updates – I had issues on other distros here and there where things do not work after updates, and I think the best solution to that is (for a workstation) to actually reboot and install upgrades on reboot instead of while you’re still using the session. It’s hardly a difference on Servers either, you probably do not need to reboot, you’ll very likely do so anyway, so I see no reason to upgrade while running the system.
I like the concept of not having to reboot because I installed updates, but that the updates install once I’m ready to reboot. Call me selfish, but my work needs go before the needs of my system. And since it’s a workstation, it’s very likely rebooted daily anyway.
Tom Wilson
I’ve addressed the two problems (crash during boot, and when to reboot) differently.
Instead of backing up files, I back up partitions. When my system refuses to boot, it’s just a matter of restoring the last backup. (This actually saved my wife’s computer when it was attacked by ransomware.)
I shut down my computer every evening. At 4:00 AM, by bios wakes up the computer. A cron job is scheduled for 4:01 AM that performs the dnf upgrade for the day. At 4:10 AM (or when dnf finishes… which ever is later), the system shuts down. I can review the dnf logs the next time that I power up the system.
Mark
I think Offline update is really just for desktop users. It will often break things but not to the point of turning a machine into a brick (not too often anyway).
Interestingly I personally have never actually tried a DNF rollback to a previous OS history checkpoint prior to an offline update; has anyone, would it work ?. Of course I have never tried a rollback after a distro-sync to a new version either. I feel a test VM coming along.
For ‘servers’ offline update should probably be avoided simply because nobody really wants to read though all the details of what it does. For example does anyone know if it runs mysql_upgrade if mysql/mariadb is installed ?. Will it run upgrade scripts for apps that use tables even if they are package updates. Of course not. Offline update will not get you a working server and probably give you a broken one.
For a server 90% of the work is after the upgrade not the upgrade itself so why take the long offline time on top of all that..
There was a mention in earlier comments of the need to restart the entire machine in order to force running apps to pick up changes; that is obviously Desktop environments again where killing the desktop environment would be a bad user experience. The well written packages stop/start services during package updates so online updates on a server are fine in most cases; although I personally reboot after any kernel update (and always after a distro-sync to a newer release).
My only objection to Offline update on desktops is the way it has become like windoze and you get to sit there for hours watching a progress bar (or tap esc and watch a package list scroll by). I switched to Linux to avoid having to put up with that.
tim
I’ve used dnf rollback once on my laptop (to fix a mistake by me). It was great. dnf is a very impressive package management system.
Jesse Pollard
I always use the online update. then reboot at leisure.
Tim
The greatest astonishment to a Fedora user coming from the Debian family is the update behaviour. I laughed in shock the first time I saw it. Based on my personal experience of using deskop linux for > 20 years and of running I guess hundreds of linux servers, this is solving a problem which doesn’t exist, or if it exists, in the same way that an asteroid strike may destroy your install too.
Offline updates are “compulsory” for updates which absolutely don’t need them because this almost religious approach is taken to extremes (a shutdown to update a text editor? Seriously? This is a joke, it is indefensible) The ubuntu approach is to recommend a reboot when required. It’s much better. Like most Fedora users, I avoid the offline updates, and I’ve never had a problem. And the Ubuntu/Debian approach has never caused a problem. Debian, the most conservative mainstream Linux distribution on the planet, does not even have this problem on its radar. Linux would never have succeeded as a server OS. Fedora Gnome should at least make it configurable (I think it is on KDE; you can opt out of reboot mania, I think).
It is also not very seamless if you have full disk encryption … you can’t just shutdown and walk away … a shutdown update now requires you to enter the encryption password.
Cliff Wells
The issue isn’t that sometimes the system needs to be restarted, it’s the silly updates that it decides must be restarted (for example, updating vim-filesystem or vscode). Were Fedora a bit (a lot?) more discriminating about what requires a reboot, it would be a non-issue.
Also, wrt to using dnf, the safest way to do this is to run it under screen or tmux so that if GNOME happens to crash, dnf can still complete and not leave the system partially updated.
Frankly, I don’t understand why the update isn’t run in a detached process anyway.
lovenemesis
After encountering a few half-way updated situation, I found offline-updated to be a much reliable solution.
And it doesn’t have to be with GNOME or any DEs. It can be done easily in terminal as long as PackageKit is present.
pkcon refresh force # Force packagekit to refresh its repo cache.
pkcon -d update #Ask packagekit to download the updates but installed
pkcon offline-trigger #Ask packagekit to schedule an offline-update