After trying Arch linux, I decided to switch to Fedora again. My main reason is that I like the concept of Fedora: it keeps previous kernels to boot seamlessly while it’s problematic on Arch linux. I believed that using snapper, grub-btrfs and snap-pac(a package to take snapshots automatically when I install, upgrade or remove packages) would be helpful to restore if any problem appears within an update. However, I was wrong. Arch doesn’t keep previous kernels so restoring snapshots that include a previous kernels’ packages is impossible ( it cannot boot). I need a complete, stable and reliable KDE workstation. So I made a decision to use Fedora KDE spin. Recently, there was a bug with brightness after waking up from sleep in the previous kernels, so there were unusable, who knows such problems won’t happen in the future? Any suggestions to make my workstation stable and reliable? I am going to use btrfs, with root and home subvolumes, snapper to backup/restore. Any better suggestions? Like creating other subvolumes or using something else? Also please tell me, should I create an ext4 partition for /boot and fat32 for /boot/efi or fat32 /boot for both?
There was a workaround for that issue which is to set the power profile to ‘performance’, since the issue appeared to be related to a problem with powersaving (iirc).
Apart from that you have the option to temporarily freeze the kernel packages from updating. If you have a good working kernel then you can edit /etc/dnf/dnf.conf and add:
excludepkgs=kernel*
You can then keep using the same kernel for a while for stability.
Well if it’s only about the kernel, there are a couple of methods (like the one mentioned by @litemotiv above) of keeping a specific kernel.
If the issue is about other parts of the system as well, then you might want to take a look at Fedora’s atomic desktops (for KDE Plasma this would be Kinoite). Here you can keep (pin) a specific “snapshot” of the system installation (called deployment of an OSTree image)[1] and never worry that a future upgrade would affect the system. There are some differences, as well as some limitations, as compared to traditional systems, but you can check the Fedora documentation for atomic desktops for an introduction.
The contents of
/etccould be backed up for additional security. ↩︎
If you have sufficient space in /boot, I suggest to rather increase the number of installed/retained kernels to always get updates on time (in order become aware of them, test new kernels immediately about needed fixes [if the kernel is new, much more people will review reported new and persisting issues about it], and to not forget about the manipulation to avoid running obsolete kernels for long periods) while still retaining those kernels that work properly:
How to here:
The problem happens only if you have boot in a separate btrfs volume, which you shouldn’t do if you take snapshots.
Restoring snapshots with previous kernels work, if you configure btrfs volumes correctly.
Oh nice! So I could stop Thunderbird from downloading 100MB updates every week using the same dnf.conf.
How to create correct subvolumes then? I usually create @ and @home, while /boot is seperated from btrfs (ext4)
I need a full system without immutability. I just want to keep previous kernels to boot If I find anything wrong with a new one. And also, I wonder how correct subvolumes are allocated to backup/restore snapshots properly
How much space is sufficient to keep more kernels? I usually allocate 1024MiB
Don’t separate /boot, that’s all.
I was reading about it. So can I use Windows’s efi partition for fedora and the root filesytem for /boot too? If so, grub and kernel files would be saved within btrfs partition.
That’s right!
Fedora names those root and home (without the @).
On a default installation this can easily be seen in /etc/fstab.
There are advantages to staying as close as possible to Fedora’s default configuration, if only to avoid having to explain and debate customizations. If you need to increase the size of /boot, gparted can shrink btrfs partitions to make room for an increase in the size of /boot.
I also have it usually at around 1024 MB. I have for years 5 kernels retained. That always worked out, and there is still place for more. Atm, my major installation has a /boot with 973 MB and with 5 retained kernels, and it still has just 58% used.
I suggest to not do that. Keep in mind that email clients belong along with browsers and other tools to the software that are exposed to untrusted inputs (malicious content in emails or so). You should keep such software updated. Keep in mind that these updates include security updates.
However, keep in mind that you can also use any dnf update command with the --security option to only include security-updates. (Note: This applies only partly to the kernel as there, all updates are security relevant and also old kernels are no longer considered by maintainers and most testers, while only explicit/major issues are classified explicitly as security updates, other kernel updates not. Kernels should be used after updates have been released only if they don’t work, and then it is also just a temporary measure - on the long term, it would get dangerous both for security and stability)
Welcome back to fedora! 
I wear a hat, btw!