After having my current Fedora installation (constant upgrade) since version 32, it’s time for a clean install. Most importantly because I am doing a full PC upgrade. My current setup is dual boot to windows 10 and windows + linux partitions are on the same SSD drive. The other disks I use are for data storage and I just mount them.
The new setup will be Fedora + Windows 11, both on their own dedicated SSD drives.
Since it’s a long time that I did the full installation, I would like to double check with you guys the steps I’ll be doing:
Install Win11 on it’s own disk
Install Fedora on it’s own disk
If I remember correctly, after the installation is done in this order, GRUB should come at boot.
And the second point I would like to check is: Do we need to split the Fedora installation on multiple dedicated partitions? Is there any point to it?
My current linux drive looks like this:
Fedora creates a slightly more complex three-partition layout by default. Whether it is worth the effort to fight the system to achieve a two-partition layout is up to you.
Edit: You don’t need a swap partition anymore. That was changed to ZRAM in release 33.
Fedora’s current default install creates several partions.
Default Disk Layout
By default, a Workstation installation has the following disk layout:
Role
Filesystem
Mount Point
EFI System Partition
FAT 32
/boot/efi
Boot Partition
ext4
/boot
Root Subvolume
Btrfs
/
Home Subvolume
Btrfs
/home
The first two partitions are common to all Fedora installations, and are required for booting the system. The root subvolume contains the system installation, and the home subvolume contains user data and settings.
So, theoretically, I can just leave Fedora to install itself with the recommended setup on the dedicated disk and that’s it. GRUB should detect Win11 on the other disk.
I think so. I haven’t done this recently myself though. I gave up completely on Windows a long time ago. I think there have been issues with secure boot and getting grub to load windows, but I haven’t followed the issue closely. (Windows 11 now has a hard requirement that secure boot be enabled.)
If you select Custom Install, annaconda will allow you to chose an existing empty /boot/efi that was created before the installation began. Unless you require btrfs features, selecting ext4 as the filesystem will make backup/restoration and possible migration to a different disk much easier.
If there is a chance that you may wish to install a newer version of Fedora in the future while preserving the existing one, create two /boot/efi partitions before creating an OS partition. When using ext4 a /boot/efi size of about 90 Mb will be sufficient. Example partitioning follows:
Thank you. Will see how it goes when I’ll start the installation
Win11 and Fedora will be on 2 different disks. So I assume the /boot/uefi partition will be created on the second disk, the one where Fedora will be installed.
P.S. I have no experience with btrfs, I only had ext4 partitions for Linux (ext3 as well way back if I remember correctly).
I don’t think so.
IME a new installation of fedora using the automatic partitioning creates 3 partitions (as already stated) and the btrfs partition is sized to fill the remaining available drive space after the /boot and /boot/efi partitions are created.
I believe you may be misinterpreting this part.
Those subvolumes are just that – subvolumes within one main volume that is the full btrfs partition.
Those subvolumes share, as needed, the entire space of the btrfs main volume and do not have any specific size restrictions for either subvolume. They use, as needed, available space and each can grow individually as data is added until the entire btrfs volume is filled.
Incremental backups are much more efficient (faster, less data transfer) with Btrfs. However, if you are already familiar with rsync, maybe rsync is “easier”. rsync should also mostly work (save maybe extended attributes) on Btrfs though. I don’t see any advantage that ext4 has over Btrfs where backups are concerned. (There are advantages that ext4 has over Btrfs for certain data access patterns, however. VM images will tend to have better write performance on ext4 than on Btrfs unless special tuning flags (no CoW) are set on the Btrfs file/directory.)
Thanks @glb for the explanation.
I already have a collection of rsync scripts where I back-up stuff to different drives and to external hdd’s so I don’t need the incremental backups.
I’ll stick to ext4 then, unless I completely misunderstood you
Different folk have different opinions concerning backup and restoration.
An ill timed electrical interruption can render an entire disk useless if power was lost while the disk file allocation table is being changed so storing copies of a backup on different disks could prove to be a wise choice. Marketing hype often promises that you only require the last incremental backup to do a full restore. This may be true in some cases (Major Cloud providers). It is fine to believe the hype as long as you prove its veracity before you actually need to restore.
Assuming full backups, btrfs requires backing up a FAT, ext4 and at least one btrfs partition while ext4 requires backing up one FAT and one ext4 partition, worse case.
Regardless of which OS file system is used, the FAT signature aka serial number can become an issue when doing a bare metal restore because assigning the specific signature expected in file /etc/fstab is not a straight forward task. Therefore it would be prudent to use a tool like dd to copy the original FAT partition to a same-sized partition on a flash drive.
Restoring the ESP can be a pain. FWIW, I’ve recently discovered in the man pages for the bootctl and kernel-install commands that they take a --image=... option that should mostly automate (re)generating an ESP if all you have is a backup of the root filesystem. I have not attempt such a restoration yet, however. Also, bootctl is (currently) for sd-boot only, not GRUB.
Current mass storage devices are much larger than when ext4 was created, so bitrot is more likely to occur. Btrfs provides some protection from bitrot. Unless you have strong reasons, it is generally best to stick with distro defaults. That provides more eyes on any bugs and makes it simpler for others to understand your setup. Note that btrfs does require periodic “maintenance” for which there are a number of tools that are relatively new, so you will have to decide which tools suit your needs.
My experiences with “eyes” and bug response has been less than ideal. There have been many times when the response to a submitted bug was an invitation to re-submit because the OS version had gone end of life. I reported a bug in early November that has existed since spring of 2023. So much for “eyes”.