hi
i was earlier on Linux Mint for 3 years and before that over 20 years of Windows. i see fedora is doing updates to the system in a similar manner of Windows 10. Is this way of doing it? as in only installing upon next boot attempt with another reboot after successful install a better way of doing it rather than just “installing” them like Mint does?
Fedora has about (or at least) four ways to install updates.
There are different package managers: dnf and PackageKit.
dnf is a command line tool (sudo dnf update), andThen, there is online updates and offline updates. Online updates install while your system is up and running (on-the-fly). For offline updates the system is booted into a special system update mode, see link. Both dnf and PackageKit can perform offline updates.
For dnf, there is a GUI in Fedora repos called dnfdragora (sudo dnf install dnfdragora). You can also use dnf to install your updates offline, see link2
Here is another topic that may interest you:
Fedora editions such as Server, Workstation and IoT are released on a cadence of twice a year. Throughout the release cycle at any given time there will be a stable, Beta and rawhide version, with rawhide being the next beta, beta being the next stable and stable getting relegated to EOL by the next two release cycles. Maybe MS copied this approach, but Fedora has been done that way since core 1.
I’m sorry, was i unclear with my question? i was asking why fedora only installs updates during the boot of the OS, as in,. if Discover notifies me of updates right now and i click install them. next time i reboot, thats when it’ll install them and then reboot again.
When you are updating packages in place, it’s like replacing parts of your car while driving. Doing it on reboot is like pulling over to the side of the road first.
That may be a little dramatic, but there can be real problems. It’s rare, but when you multiply the number of updates by the number of users, rare things happen.
(And updating the way CoreOS and Silverblue do is like pulling over and getting in a new car, with the old one still there if there’s a problem.)
I’ve also seen that Discover in Fedora 34 started doing only offline updates, while before (F33) they were installed online.
I’ve just stopped using Discover and started using dnfdragora or directly dnf by switching VT with CTRL-ALT-F3 and typing sudo dnf upgrade. I rarely (almost never) had any problem by doing online updates since Fedora 1.
It would be nice if Discovery can switch back to do online updates as default and only defer at the next restart those updates marked in Bodhi as they need a restart or a logout.
There’s really no problem with advanced users doing on-the-fly updates. Those users are most able to cope with any problems (and are probably used to a little weirdness). It’s a good default, though, so things are safer for users who are not so prepared.
When Plasma 5.22 rolls out for Fedora Linux 34, you’ll have the option to switch back if you want.
I can’t speak for KDE, but in Fedora 34 there have actually been a few desktop crashes reported under Gnome when doing live in-place dnf updates… So if you want to be really safe updating at reboot is the safest way (like Gnome Software or rpm-ostree does).
More historical examples:
I’m sure there are more cases I’m forgetting (perhaps issues with lock and unlock?).
Firefox mostly works now (it used to get really upset and not be able to open new windows) but you get weird stuff. Here’s a real-world example from a while ago:
Wow, okay, longer ago than I remembered, and sure, “Flash plugin” isn’t even a thing anymore, but the basics apply still. 
Suffice to say I’m skeptical. You have the old UI process talking to the new render process. When IPC formats change during an update, it’s not going to be pretty. It might be mitigated currently by Firefox’s low process count limit, but that’s going away because it conflicts with site isolation. Also it might be mitigated if Firefox’s IPC changes infrequently, but based on how often we make IPC changes in WebKit, that’s often.
The only way to do this safely is to ensure the old UI process loads only the old render processes, but that’s not really possible when dnf has updated the render processes on disk without Firefox even noticing.
Installing online updates doesn’t apply them automatically in general case.
Related processes keep working with old resources loaded in RAM until user restarts them.
This can lead to all kinds of problems including security implications.
I’ve been doing online updates all along. For updates I always restart afterwards. When installing new software though, I almost never reboot. Usually the new installs are one or two packages whereas the updates tend to be 10s (or 100s) of packages at once.
There are a couple of things I never liked about offline updates that have prevented me from ever using them.
Many of the systems I update are remotely-administered servers and I don’t like “going dark”, crossing my fingers and hoping the system comes back up after ??? minutes. Has it been long enough yet? If I force reboot the system right now will I actually make the problem worse and end up with a half-updated system?
The very few times over the last 1.5 or so decades that the online dnf/yum update has failed, I’ve been able to easily recover from the situation only because I was doing an online update. Basically, dnf failed, dropped me to a command prompt with the error displayed at the end, and I corrected the problem (probably with something like rpm --nodeps -e <whatever> but its been too long since it happened for me to remember for sure) and re-ran the update. With offline updates, none of that would have worked and I probably would have had to physically attend to the system.
The offline updates don’t provide an opportunity to run rpmconf -a after the updates but before the updated service or command is first run. This is probably a minor issue, but I do always run rpmconf immediately after doing updates but before rebooting. Not running rpmconf can lead to security problems. Until very recently, for example, httpd’s ssl.conf contained cipher strength requirements that would not get updated unless you ran rpmconf. One really should reconcile their configuration changes before starting the new version of the software.
Chris Murphy recently mentioned a really neat idea on IRC about how online updates could be done without the concern about a the binaries on the file system being temporarily out-of-sync with their in-memory versions. He suggested that, with btrfs, it should be possible to mount a snapshot of the rootfs, do an online update of that (e.g. dnf --installroot=<snapshot-mountpoint> update) and then reboot to switch to the new snapshot if the update succeeded. FWIW, I think this is a great idea. He also suggested trying to run the updated rootfs in a container or VM to see if it works before rebooting, but I think that is a terrible idea for several reasons (mostly the mess of reconfiguring the host’s networking to do that, but also the myriad problems with determining if the booted system is working as intended).
This will actually be a problem more often because Fission in Firefox means it moves to an IPC-heavy model similar to WebKit2.
There’s a libdnf plugin for automating the model of installing into snapshots, but the implementation is incomplete because it requires some work at the distro-level to really make it useful.