Learning about Partitions and How to Create Them for Fedora

Operating system distributions try to craft a one size fits all partition layout for their file systems. Distributions cannot know the details about how your hardware is configured or how you use your system though. Do you have more than one storage drive? If so, you might be able to get a performance benefit by putting the write-heavy partitions (var and swap for example) on a separate drive from the others that tend to be more read-intensive since most drives cannot read and write at the same time. Or maybe you are running a database and have a small solid-state drive that would improve the database’s performance if its files are stored on the SSD.

The following sections attempt to describe in brief some of the historical reasons for separating some parts of the file system out into separate partitions so that you can make a more informed decision when you install your Linux operating system.

If you know more (or contradictory) historical details about the partitioning decisions that shaped the Linux operating systems used today, contribute what you know below in the comments section!

Common partitions and why or why not to create them

The boot partition

One of the reasons for putting the /boot directory on a separate partition was to ensure that the boot loader and kernel were located within the first 1024 cylinders of the disk. Most modern computers do not have the 1024 cylinder restriction. So for most people, this concern is no longer relevant. However, modern UEFI-based computers have a different restriction that makes it necessary to have a separate partition for the boot loader. UEFI-based computers require that the boot loader (which can be the Linux kernel directly) be on a FAT-formatted file system. The Linux operating system, however, requires a POSIX-compliant file system that can designate access permissions to individual files. Since FAT file systems do not support access permissions, the boot loader must be on a separate file system than the rest of the operating system on modern UEFI-based computers. A single partition cannot be formatted with more than one type of file system.

The var partition

One of the historical reasons for putting the /var directory on a separate partition was to prevent files that were frequently written to (/var/log/* for example) from filling up the entire drive. Since modern drives tend to be much larger and since other means like log rotation and disk quotas are available to manage storage utilization, putting /var on a separate partition may not be necessary. It is much easier to change a disk quota than it is to re-partition a drive.

Another reason for isolating /var was that file system corruption was much more common in the original version of the Linux Extended File System (EXT). The file systems that had more write activity were much more likely to be irreversibly corrupted by a power outage than those that did not. By partitioning the disk into separate file systems, one could limit the scope of the damage in the event of file system corruption. This concern is no longer as significant because modern file systems support journaling.

The home partition

Having /home on a separate partition makes it possible to re-format the other partitions without overwriting your home directories. However, because modern Linux distributions are much better at doing in-place operating system upgrades, re-formatting shouldn’t be needed as frequently as it might have been in the past.

It can still be useful to have /home on a separate partition if you have a dual-boot setup and want both operating systems to share the same home directories. Or if your operating system is installed on a file system that supports snapshots and rollbacks and you want to be able to rollback your operating system to an older snapshot without reverting the content in your user profiles. Even then, some file systems allow their descendant file systems to be rolled back independently, so it still may not be necessary to have a separate partition for /home. On ZFS, for example, one pool/partition can have multiple descendant file systems.

The swap partition

The swap partition reserves space for the contents of RAM to be written to permanent storage. There are pros and cons to having a swap partition. A pro of having swap memory is that it theoretically gives you time to gracefully shutdown unneeded applications before the OOM killer takes matters into its own hands. This might be important if the system is running mission-critical software that you don’t want abruptly terminated. A con might be that your system runs so slow when it starts swapping memory to disk that you’d rather the OOM killer take care of the problem for you.

Another use for swap memory is hibernation mode. This might be where the rule that the swap partition should be twice the size of your computer’s RAM originated. Ideally, you should be able to put a system into hibernation even if nearly all of its RAM is in use. Beware that Linux’s support for hibernation is not perfect. It is not uncommon that after a Linux system is resumed from hibernation some hardware devices are left in an inoperable state (for example, no video from the video card or no internet from the WiFi card).

In any case, having a swap partition is more a matter of taste. It is not required.

The root partition

The root partition (/) is the catch-all for all directories that have not been assigned to a separate partition. There is always at least one root partition. BIOS-based systems that are new enough to not have the 1024 cylinder limit can be configured with only a root partition and no others so that there is never a need to resize a partition or file system if space requirements change.

The EFI system partition

The EFI System Partition (ESP) serves the same purpose on UEFI-based computers as the boot partition did on the older BIOS-based computers. It contains the boot loader and kernel. Because the files on the ESP need to be accessible by the computer’s firmware, the ESP has a few restrictions that the older boot partition did not have. The restrictions are:

  1. The ESP must be formatted with a FAT file system (vfat in Anaconda)
  2. The ESP must have a special type-code (EF00 when using gdisk)

Because the older boot partition did not have file system or type-code restrictions, it is permissible to apply the above properties to the boot partition and use it as your ESP. Note, however, that the GRUB boot loader does not support combining the boot and ESP partitions. If you use GRUB, you will have to create a separate partition and mount it beneath the /boot directory.

The Boot Loader Specification (BLS) lists several reasons why it is ideal to use the legacy boot partition as your ESP. The reasons include:

  1. The UEFI firmware should be able to load the kernel directly. Having a separate, non-ESP compliant boot partition for the kernel prevents the UEFI firmware from being able to directly load the kernel.
  2. Nesting the ESP mount point three mount levels deep increases the likelihood that an intermediate mount could fail or otherwise be unavailable when needed. That is, requiring root (/), then boot (/boot), then efi (/efi) to be consecutively mounted is unnecessarily complex and prone to error.
  3. Requiring the boot loader to be able to read other partitions/disks which may be formatted with arbitrary file systems is non-trivial. Even when the boot loader does contain such code, the code that works at installation time can become outdated and fail to access the kernel/initrd after a file system update. This is currently true of GRUB’s ZFS file system driver, for example. You must be careful not to update your ZFS file system if you use the GRUB boot loader or else your system may not come back up the next time you reboot.

Besides the concerns listed above, it is a good idea to have your startup environment — up to and including your initramfs — on a single self-contained file system for recovery purposes. Suppose, for example, that you need to rollback your root file system because it has become corrupted or it has become infected with malware. If your kernel and initramfs are on the root file system, you may be unable to perform the recovery. By having the boot loader, kernel, and initramfs all on a single file system that is rarely accessed or updated, you can increase your chances of being able to recover the rest of your system.

In summary, there are many ways that you can layout your partitions and the type of hardware (BIOS or UEFI) and the brand of boot loader (GRUB, Syslinux or systemd-boot) are among the factors that will influence which layouts will work.

Other considerations

MBR vs. GPT

GUID Partition Table (GPT) is the newer partition format that supports larger disks. GPT was designed to work with the newer UEFI firmware. It is backward-compatible with the older Master Boot Record (MBR) partition format but not all boot loaders support the MBR boot method. GRUB and Syslinux support both MBR and UEFI, but systemd-boot only supports the newer UEFI boot method.

By using GPT now, you can increase the likelihood that your storage device, or an image of it, can be transferred over to a newer computer in the future should you wish to do so. If you have an older computer that natively supports only MBR-partitioned drives, you may need to add the inst.gpt parameter to Anaconda when starting the installer to get it to use the newer format. How to add the inst.gpt parameter is shown in the below video titled “Partitioning a BIOS Computer”.

If you use the GPT partition format on a BIOS-based computer, and you use the GRUB boot loader, you must additionally create a one megabyte biosboot partition at the start of your storage device. The biosboot partition is not needed by any other brand of boot loader. How to create the biosboot partition is demonstrated in the below video titled “Partitioning a BIOS Computer”.

LVM

One last thing to consider when manually partitioning your Linux system is whether to use standard partitions or logical volumes. Logical volumes are managed by the Logical Volume Manager (LVM). You can setup LVM volumes directly on your disk without first creating standard partitions to hold them. However, most computers still require that the boot partition be a standard partition and not an LVM volume. Consequently, having LVM volumes only increases the complexity of the system because the LVM volumes must be created within standard partitions.

The main features of LVM — online storage resizing and clustering — are not really applicable to the typical end user. Most laptops do not have hot-swappable drive bays for adding or reconfiguring storage while the system is running. And not many laptop or desktop users have clvmd configured so they can access a centralized storage device concurrently from multiple client computers.

LVM is great for servers and clusters. But it adds extra complexity for the typical end user. Go with standard partitions unless you are a server admin who needs the more advanced features.

Video demonstrations

Now that you know which partitions you need, you can watch the sort video demonstrations below to see how to manually partition a Fedora Linux computer from the Anaconda installer.

These videos demonstrate creating only the minimally required partitions. You can add more if you choose.

Because the GRUB boot loader requires a more complex partition layout on UEFI systems, the below video titled “Partitioning a UEFI Computer” additionally demonstrates how to install the systemd-boot boot loader. By using the systemd-boot boot loader, you can reduce the number of needed partitions to just two — boot and root. How to use a boot loader other than the default (GRUB) with Fedora’s Anaconda installer is officially documented here.

Partitioning a UEFI Computer
Partitioning a BIOS Computer
FAQs and Guides For System Administrators Using Hardware

83 Comments

  1. Morvan

    I prefer, whether possible, GPT over old style MBR. There is no restriction over number of partitions, theoretically. Regarding /home, I alwais let it apart. It is very simple to make data backup. On the other side, one does not have to backup these bytes, for system backup purpose.
    And, finally, regarding biosboot, I can not catch is purpose. Nonsense. Happily, Anaconda does it for us, at last resort.

    • Hi Morvan:

      Good point about the biosboot partition. Perhaps I should have gone into a little more detail about it. Essentially it holds extra boot loader code that GRUB cannot stash anywhere else on the drive when the drive is formatted with GPT. With the older MBR format, there was more extra space between the start of the disk and the start of the first partition that GRUB utilized. Because GPT’s tables are larger, that space isn’t available when using GPT and a separate partition must be created.

      For the most part the biosboot partition contains the file system drivers it thinks it will need to access the rest of its code and the kernel and initrd.

      An additional bit of trivia about GRUB’s biosboot partition is that it violates the GUID standard and uses a cipher of “Hah!IdontNeedEFI” for its GUID.

    • jama

      I do recall GPT partition limit is 128. MBR can have a total of 4 or 7 partitions: 4 “primary partitions”, -or- 3 “primary partitions”, with the 4th divided to a total of 4 additional “extended partitions”.

      i.e.

      GPT: 128 “primary partitions”
      MBR: 4 “primary partitions” -or- 3 “primary partitions” along with up to 4 “extended partitions”.

      Before partitioning the disk, you need to set the “disklabel” for the disk, which can either be “mbr” or “gpt”, with i.e. ‘parted’ -tool. (mklabel gpt/mbr)

      Also, I do recall that nowadays -regardless of the partition type- the 1st partition begins from sector 2048. In addition, if I do recall correctly, in the way back the 1st MBR partition used to begin from sector 64.

      With LVM you can increase the number of partitions regardless of the disklabel used, as those are not written to the partition table, but to a separate database instead.

      GPT is a good choice also for the reason that it keeps a backup of the partition table at the end of the disk, while MBR does not.

      • Morvan

        Yes, put “There is no restriction over number of partitions, theoretically…” with a grain of salt or jolly from who has not the {4-7} partitions. Thanks for remembering this.

  2. qoheniac

    Great article! One thing I am missing is a section about encryption. Maybe an informed user could provide some basics in a comment. Thanks!

    • Hi qoheniac:

      I’m certainly not an “informed user”, but I did a little digging and it looks like the Fedora Project does have at least a little documentation available:

      https://fedoraproject.org/wiki/Disk_Encryption_User_Guide

      Hope that helps. 🙂

      • qoheniac

        Thank you! That article answered most of my questions regarding encryption. 🙂

    • jama

      What comes to the encryption, it is also possible to use “double encryption” especially with Fedora and CentOS, which I’ve found to be a bit tricky with some other Linux distributions as those tend to fail to boot.

      The trick is to create a physical partition 1st, then encrypt and unlock it, which after creating a VG in it along with a few LVs. Now, you can, again, encrypt the individual LVs!!!

      Just unlock the LVs, create a filesystem in those and voilá! You’ve double-AES-encrypted filesystem(s) to keep your personal files completely hidden from others.

      It is possible to use/enable this “double encryption” already during the Fedora and CentOS installation process by ticking the ‘Encrypt’ and setting the password.

      In a nutshell:

      — cryptsetup -encryption command WILL DESTROY / DELETE EVERYTHING —
      — AT THE MOMENT IT IS NOT POSSIBLE TO ENCRYPT EXISTING DATA —

      1) create a NEW partition (or LV) to a disk. Let’s assume it’s 8th partition, i.e. sda8.

      2) encrypt (format) it with ‘cryptsetup luksFormat /dev/sda8’. Answer ‘YES’, and provide the password, twice. It WILL warn you if there’s a filesystem already.

      3) unlock the encrypted partition with ‘cryptsetup luksOpen /dev/sda8 sda8_open’. Provide the password. A new device, ‘sda8_open’, will be created as ‘/dev/mapper/sda8_open’.

      4) create a filesystem in it, i.e. ‘mkfs.ext4 /dev/mapper/sda8_open’.

      5) mount it with i.e. ‘mount /dev/mapper/sda8_open /mnt’

      6) after you’re done, unmount it ‘umount /mnt’ and close if with ‘cryptsetup luksClose sda8_open’. No path needed when closing a LUKS device.

      I hope this helps.

  3. Jonah Losh

    Is there anyway to expand my Linux Fedora partition “backward”? For instance, I was dual booted, Windows on the front partition and Fedora on the second. Is there any possibility to make the entire disk conform to my single Fedora boot? Thanks for an awesome operating system:)

    • Karlis K.

      You would need to move the partition and then expand it. It can be done quite easily with the GParted GUI utility that takes care of all the heavy lifting (does what you tell it to and has a few safeguards in place to ensure it all happe s successfully). However, I have to warn that moving /boot (on regular BIOS) and /boot/efi (on UEFI computers) will end up unbootable unless grub loader has been reinstalled after the move.

    • doseas

      Yes, I use the Gparted live disc (https://gparted.org/livecd.php ), which is capable of moving and resizing partitions, for this purpose. Always make a full backup of your drive before messing with partitions! 🙂

    • Hi Jonah:

      Reclaiming the space at the start of your device might be possible if you are using a volume manager like LVM or ZFS (e.g. with ZFS you would just enter something like “zpool add root /dev/sda1” to add the space allocated by the first partition on your drive to your “root” pool).

      If the partition contains a a file system like ext4 or xfs, however, it is more difficult. You would have to use a command called “dmsetup” to create a new device that is backed by /dev/sda2 + /dev/sda1 (in that order). Then you could extend your filesystem to reclaim the additional space. You would also have to adjust several configuration files to be sure that the new device is assembled correctly and very early when your computer restarts.

      What I would do for ext4 or xfs is re-format the first partition, copy the files to the first partition, boot off the first partition, delete the second/original partition, and then extend the first partition and its file system into the newly-freed space.

      Typically when I want to do that sort of thing, I do it by copying the content to a second storage drive so that I can just go back to the old one if something goes wrong.

      Hope that helps. 🙂

  4. the LVM volumes must be created within standard partitions. The main features of LVM — online storage resizing and clustering — are not really applicable to the typical end user. Most laptops do not have hot-swappable drive bays for adding or reconfiguring storage while the system is running. And not many laptop or desktop users have clvmd configured so they can access a centralized storage device concurrently from multiple client computers. LVM is great for servers and clusters. But it adds extra complexity for the typical end user. Go with standard partitions unless you are a server admin who needs the more advanced features.

    So… why Fedora graphical installer still uses LVM by default instead simple classic partition layout?

    • @Tomasz: Several reasons — first, many people do use Fedora as a hybrid desktop + server environment, where LVM is more useful. Second, one of the reasons Fedora exists is to give users the ability to learn and be exposed to innovative technologies. I have used LVM for years on desktops and laptops, and it does come in handy. For instance, I often change my mind later on the space I want to reserve for specific uses like virtual machine storage, databases, or web apps that I’m trying out. LVM lets me do that pretty easily, while still allowing me to “blow away” the system with a fresh install while retaining data that’s important for me. I wouldn’t call my case a “typical end user,” but many Fedora users are similarly atypical and might find LVM useful for their case.

      • @Paul, @Tomasz et all:

        A lot of what I wrote in this article is personal opinion. People’s use cases are different and it is difficult to say what “most” people need/want. The goal of the article is more to explain some pros and cons and let the end user decide.

        There are some trade-offs/costs to having an LVM-based installation by default though. As illustrated by this recent post by a user who could not get Fedora to work in part because he could not figure out the kernel parameters that LVM needs:

        https://discussion.fedoraproject.org/t/newbie-dual-boot-issues/13263

        The other part of his problem was that he could not figure out GRUB’s config file syntax. GRUB somewhat confusingly names the variable that should point to the boot partition root 🤦.

        edit to fix link

  5. Nathan

    I believe that your reference to /efi is incorrect, and should be /boot/efi

    • Good catch Nathan! The error is probably too minor to trouble the editors to correct, but hopefully people will see your correction in the comments. Thanks.

  6. Lukas

    Great article! I’m sure I’ll be coming back to it often. As for me, I use LVM. I have two physical volumes merged in one volume group, which is divided into several logical volumes (root, home, swap etc.). Somehow I’ve never paid attention to boot partitions. I did what I had to do without going into details. Well, It’s time to change that. 🙂

  7. Norbert J.

    Many thanks for this comprehensive article. As I am going to replace my oldest PC, it helps to have an up-to-date overview about the different partitioning schemes and bootloader configurations and their pros and cons. It is also good to know that there is a lean alternative to grub2 with systemd-boot.

    • Andrzej

      Do you have any thoughts on how to partition your system with more than one drive? I have 256GB SSD and 1TB HDD disks. The Fedora installer suggests to put it into a single logical volume with LVM, but that doesn’t seem like a good idea. So I put root and home on SSD and I just mount HDD at boot.
      It bugs me that I don’t have my every file under home, but I don’t see a better way to cope with it.

      • Morvan

        Hi. I have a NVME SSD and I put all the System partitions into it, but HOME, once it is an user one and provokes to many read | write accesses. I manage fstab to point home to a HD partition, after install, of course, to gain time at all. SSD´s are not, yet, reliable to suffer so many accesses as a HOME user uses to do, exactly because of this.

      • Hi Andrzej:

        It is a bit complicated, but you might be interested in dm-cache:

        “… One solution to providing improved disk I/O performance would be to combine the capacity offered by spindle based HDDs with the speed of access offered by SSDs. …”

        I agree with you that going with the Fedora installer’s defaults probably isn’t a good idea. I’m not sure what exactly it would do, but consider some of the possibilities:

        A. It might create a linear volume with the SSD at the end such that it would never get used.

        B. It might set up a stripped volume such that your actual performance would be 2 x the slowest drive (i.e. a 250 MB/s drive stripped with a 2.5 GB/s drive yields one 0.5 GB/s drive)!

        C. It might create a linear volume with the SSD at the beginning such that which files got the speed benefit of the faster drive would be semi-random (e.g. your first install of Firefox would load quickly, but after an update, the new version would load much slower just because it ended up on the slower part of the volume).

        Personally, I think Fedora is hurting the typical end user by having LVM enabled by default and people would be better served to just use standard partitions. Putting your root partition on the SSD and your home partition on the spinning rust as you did yields a much better end result — programs will load from /usr at the full 2.5 GB/s and plenty of storage for all those files you put in your /home/andrzej/{Music, Videos, Downloads, etc.} folders.

        Just my 2 cents.

      • jama

        I have the same setup, i.e. SSD and HDD, in my laptop.

        As there are so may writes when using Fedora, especially what comes to the updates and the upgrade, I put the whole Fedora OS in the HDD to prevent the SSD wearing out.

        This is my opinion.

        I assume you’ve EFI -partition in the SSD?

        During the Fedora installation, point the EFI to the EFI partition in the SSD.

        Create the Fedora /boot -partition to the HDD, as well as the rest of the partitions if you don’t want to use LVM.

        Again, this is my opinion, to use the HDD only.

        It does not take that long to boot Fedora from the HDD, compared to some other closed-source OS.

  8. Leslie Satenstein

    Your expository (post) is very well done. Congratulations.

    I thought that a UEFI installation requires a disk that is formatted as gpt if they were 1 terrabyte or larger in size. Today, even if the disk is 128gig, gpt is preferred.

    About 5 years back, UEFI based systems became the norm. Bios boot systems are normally used with hardware that is 10 years old, but still functionning well.

    Regarding swap partitions, their presence causes a 100 millisecond delay while it is opened as a swap partition. Thereafter swap is not used, unless ram memory is overcommitted. It is also used for system suspend ,

    • Hi Leslie:

      “Your expository (post) is very well done. Congratulations. …”

      Thanks.

      ” … I thought that a UEFI installation requires a disk that is formatted as gpt if they were 1 terrabyte or larger in size. Today, even if the disk is 128gig, gpt is preferred. …”

      I’m not sure if that is meant to be a question, but I will take it as an opportunity to expound on a few more of GPT’s virtues … 🙂

      In addition to supporting larger drives and more partition table entries, GPT maintains a “secondary” copy of its partition table at the end of the drive, partition type GUIDs, and up to 36-character unicode partition names.

      The secondary/backup copy of the partition table can come in especially handy in this day and age because it is not uncommon for users to run commands like:

      $ sudo dd if=FedoraXX.iso of=/dev/sdY

      Where “Y” is supposed to be the letter of one’s USB drive. Did you miss-type that last letter? … Maybe you tab-completed it and got your main system drive by mistake? … Uh oh …

      GPT’s secondary header to the rescue! Use the “c” option on gdisk’s recovery & transformation menu to restore GPT’s main header from the backup copy. If you are lucky, that accidental “dd” only overwrote easy-to-restore partitions like boot or swap and didn’t go as far as to destroy the contents of your root or home partitions. This is a good reason to always put boot at the start of your drive by the way (i.e. make sure that the device name ends in “1” when you create your boot partition in Anaconda).

      As for the partition type GUIDs, I made use of those in the “Partitioning a UEFI Computer” video demonstration at the end of this article. The astute observer may have noticed that I did not specify a “root=…” kernel parameter when I demonstrated how to install the systemd-boot boot loader. I was able to get away with that because I set the “8304” partition type GUID. I had a secondary reason for doing it that way — GRUB and systemd-boot don’t get along all that well and if you leave GRUB installed, then it will corrupt the BLS entry files in such a way that the kernel parameters will get substituted with a variable that is unresolvable by systemd-boot. Consequently, NO kernel parameters will be available when systemd-boot attempts to load the kernel. Because GPT supports partition type GUIDs, however, the system can still boot — even when NO kernel parameters are passed! How cool is that!

      The 36-character unicode partition names are pretty cool too. They make it easier to discern what is what in your partition manager and give your fstab entries something nice to key on even when the file system doesn’t support nice labels (e.g. something like PARTLABEL=root can be used rather than UUID=XXX).

  9. Paweł

    Thanks for another useful article 🙂

    Also, I’d like to point out that the overall design of the Fedora Magazine is very good in my opinion. Header/thumbnail images, formatting, fonts and the fact that articles are usually well laid out an easy to read, makes a difference.

    Great job! 🙂

  10. Camin

    One of the main reasons why /var parititon was separate (at least in the old days) was to reduce file access overhead by mounting certain partitions read-only (e.g. /usr). This was especially true for thin clients that remote mount other partitions. It was actually faster to access server files that are cached over the network than to access from the local disk. I’ve never heard of the possibility of file system corruption as the primary reason.

    • Hi Camin:

      That’s Cool. Thanks for the contribution!

      Another reason I’ve heard for the usr partition/filesystem is that it was originally created because faster storage tended to be more expensive and smaller and by creating a secondary /usr/… hierarchy, critical and frequently-used binaries could be put under the faster-but-smaller / while everything else could be moved to /usr.

      As for the file system corruption problem, old versions of ext had a tendency to “cross-link” files; particularly after a power outage. From https://www.ibm.com/support/pages/how-do-you-use-fsck-file-system-consistency-check:

      “… If the files are cross-linked, that means that a piece of one file points to the same place that belongs to another file, but it is impossible to know which file is the original “owner” of that piece – so, one file is damaged and in that case it is impossible to tell which one unless you look into their content. …”

      If you deleted the cross-linked file (e.g. /var/tmp/whatever), you were playing russian roulette with pretty much any other random file on the same partition (files never cross-link across partition boundaries). So there was actually a decent chance that when you deleted /var/tmp/whatever, you actually deleted that essay you spent the last five hours writing.

      But yeah, if the corruption was very bad, most people probably just backed up /home and re-installed the OS.

  11. gianluca

    how about a raid install ???

    • Hi gianluca:

      You (and others) can find some example documentation for setting up RAID here: https://fedoramagazine.org/mirror-your-system-drive-using-software-raid/

      By the way, in that earlier article on RAID, I demonstrated how to perform the configuration with GRUB. GRUB made the setup much more complex than it needs to be though. If I had it to do over again, I might suggest using systemd-boot and not mirroring the /boot partition but using rsync in a startup script instead. Because /boot is small and updated infrequently, rsync is sufficient for maintaining a secondary copy of it.

  12. svsv sarma

    A very useful, extensive and informative article indeed and so are the comments. So much in the background during installation! I must thank Anakonda. I usually leave it to it in auto and it never failed me.

  13. JCjr

    So with all of this information at hand, I question some of the decisions in Fedora. Like, why does Fedora/Anaconda still insist on creating a separate /boot partition from the /boot/efi partition on UEFI systems? On Fedora Workstation, it defaults to EXT4, as does root, but on Fedora Server, it defaults to using XFS to match the root filesystem.

    And then there’s this nugget: “The main features of LVM — online storage resizing and clustering — are not really applicable to the typical end user. ”

    Then why does Fedora Workstation default to using LVM.

    I’d like to see F2FS support in Anaconda given the increase in SSD availability, but common benchmarks show that even XFS is faster than EXT4 and includes reliability improvements not present in the latter. Fedora Server uses it by default. Why not Workstation too then?

    Lastly, there seems to be little benefit to using a dedicated swap partition anymore. Why not support systemd-swapd?

    • Hi JCjr:

      Please understand that “all of this information” is not “all information”. There may well be factors that you and I as end users are unaware of that drove the decisions.

      That said, sometimes the factors that drove the decisions are no longer relevant and change is appropriate. It is fine to say, “Hey, I think ABC should be XYZ instead”, but it is best not to be critical because there is far too much that we just don’t know.

      It is not Fedora/Anaconda that insist on creating separate partitions for /boot and /boot/efi. It is GRUB. The problem is that Fedora/Anaconda insists on using GRUB.

      I think I saw a post somewhere where someone said the motivation behind using GRUB was to “get away from having to configure so many different boot loaders”. Which, as I understood it, meant that the people making the installer were just trying to simplify their jobs. Unfortunately, I have not been able to track down that post.

      One of the great things about the Fedora project is that it is supposed to be “community driven”. If enough people say “I want XYZ!”, historically, the Fedora project has been quite good about complying where possible and practical.

      • JCjr

        Oh I’m starting to see some of what you’re mentioning.

        Does Fedora still use efilinux to chainload grub? I read that on the Wikipedia page for systemd-boot. What is the reasoning for that? Just easier to unify all the install images on grub instead of ripping it out and replacing it?

        What part of the bootloader process is digitally signed for Secure Boot support?

        • Hi JCjr:

          “… Does Fedora still use efilinux to chainload grub? …”

          I don’t think Fedora uses efilinux. I think Fedora uses shim instead.

          “… What part of the bootloader process is digitally signed for Secure Boot support? …”

          The digital signature is a sort of “checksum” that is tacked onto the end of a binary. Essentially, if the binary is “hashed” with the key/certificate, the result should match the “checksum” at the end. If it doesn’t, it indicates that the binary has been tampered with and it should be rejected.

          Ideally, every binary on the ESP that is part of the boot sequence should be signed. For Fedora, that would be shim->{grub/systemd-boot/syslinux/whatever}->kernel. If you put the initramfs on the ESP as well, then it too should be signed. This can be done by merging the kernel and initramfs into a single binary and then signing the whole thing (see the –uefi option to dracut).

          Secure boot isn’t something that I have much experience with, but I think it (and the complications that come with it) are part of the reasoning behind Fedora’s inclination to use GRUB.

          Apparently Ubuntu made a halfhearted attempt to implement secure boot that did not include/sign/verify anything beyond its first-stage boot loader (GRUB). It may be that Fedora is attempting to get secure boot implemented “correctly” but there appear to be some complications with regard to distributing the “secret” key under the GNU public license.

          Again, this is just my quick reading/interpretation of the situation. I could be quite wrong. I don’t see any obvious reason why the systemd-boot boot loader couldn’t be signed just as all the others are.

          • JCjr

            Someone should update the systemd-boot Wikipedia page. It’s where I read that Fedora uses efilinux, even though when you look at the boot partition, you can clearly see shim there:

            https://en.wikipedia.org/wiki/Gummiboot_(software)

            I think as a whole, UEFI makes a lot of things pretty complicated, what with needing firmware integration of bootloader entries. I guess it could be worse though: ARM is just a big mess. The ARM platform doesn’t have a standardized boot process. Lots of common chips require special flashing tools just to get a bootloader into it. I mean, when it comes to ARM, you tend to get really good upstream kernel support but weird bootloader configuration, or the reverse, but rarely ever both.

            When Fedora 32 ships, I’m probably going to switch over to doing manual bootloader configuration with systemd-boot as per your video above for the partition simplicity, and look at using systemd-swap.

        • P.S. An interesting blog post about the current situation with regard to secure boot:

          https://blogs.gnome.org/hughsie/2020/01/27/hunting-uefi-implants/

          It looks like secure boot is a bit of a lost cause at the current time due to poor vendor implementation. It probably isn’t something worth worrying about at this point in time.

      • Andrey

        Hi Gregory,
        “It is not Fedora/Anaconda that insist on creating separate partitions for /boot and /boot/efi. It is GRUB. The problem is that Fedora/Anaconda insists on using GRUB.”

        Even then, I don’t understand why /boot should be on a separate partition.
        On Slackware, I have /boot just as a directory on my BTRFS root partition, and /boot/grub is just a symlink to a EFI ESP partition which is VFAT.
        By the way, Grub can work with BTRFS so it’s not a real problem either.

        • Hi Andrey:

          I’m not advocating that there should be a third partition. There need only be two — the one for the boot loader (traditionally called “boot”, not “efi”) and the one for the rest of the OS (traditionally called “root”).

          The problems with the configuration that you are suggesting — moving the kernel+initramfs from the boot partition to the root partition are:

          a) It makes the kernel inaccessible to the UEFI firmware.
          b) It requires the boot loader to contain continuously up-to-date file system drivers for every possible file system that the root partition could be formatted with.
          c) It potentially renders the recovery tools in the initramfs inaccessible if the root partition is unavailable or corrupted.

          Item “b” is of particular concern to zfs users because the zfs file system allows for “feature updates”. However, GRUB’s zfs driver does not support zfs’s latest features (and in practicality there is no way it could keep its custom implementation of zfs in-sync with the real zfs file system driver). Consequently, the setup that you propose would require a third/intermediate partition for the kernel+initramfs when using zfs if you also want to use the latest zfs file system features on your root partition.

          Your suggested configuration is more complex. The goal is simplicity. Only two partitions are required — boot and root.

          • Andrey

            “Your suggested configuration is more complex. The goal is simplicity. Only two partitions are required — boot and root.”

            The question is not in my setup (it’s just trade-off for Slackware which is not BLS-compliant), it’s about why Fedora installation seem doesn’t allow /boot mount point to be any other than ext fs (I tried BTRFS and VFAT for that)?
            Grub could deal with these others fs happily.

            The second question, if we pursuit 2-partition setup: /boot should probably point to ESP VFAT partiton (or it’s alternative), as it suggested by BLS, but it currently can’t, because it leverages symlinks which VFAT doesn’t support. And BLS directly prohibits the use of symlinks in /boot.

            Does it all means that Fedora is not fully BLS-compliant still?

            • Hi Andrey:

              “The question is … why Fedora installation seem doesn’t allow /boot mount point to be any other than ext fs (I tried BTRFS and VFAT for that)?”

              Fedora allows /boot to be formatted with vfat (I demonstrated just that in the UEFI partitioning video of this article).

              “Grub could deal with these others fs happily.”

              Actually, GRUB is the problem here. It is what is requiring symlinks on /boot. A simple solution is to not use GRUB.

              “The second question, if we pursuit 2-partition setup: /boot should probably point to ESP VFAT partiton (or it’s alternative), as it suggested by BLS …”

              Yes.

              “… but it currently can’t, because it leverages symlinks which VFAT doesn’t support. And BLS directly prohibits the use of symlinks in /boot.”

              So don’t put symlinks in /boot. It is not BLS that prohibits symlinks, it is UEFI because it is UEFI that requires vfat.

              GRUB is the problem here all around. It is obvious from the string that the GRUB developers encoded in the UUID for their “biosboot” partition — “Hah!IdontNeedEFI” — and from other things they have done that they have been trying to sabotage UEFI. The solution is to not use GRUB.

              • JCjr

                The fact that we have all these arguments over “which is better” just proves that the situation is complicated, but x86 shouldn’t be this complicated. Between BIOS, UEFI, and now options like Coreboot where you can load the kernel as a payload, etc., it’s kind of a mess, and delving into ARM platform complexity where there is no standardized firmware interface.

                I like that you recognize that GRUB is a “problem”. If you could replace GRUB with some other bootloader in Fedora Project images, what would you use? Would you try to use something that’s compatible with the majority of platforms out there, or would you change the bootloader depending on the target platform? For x86 UEFI, I think systemd-boot is a good option, but it doesn’t work with legacy BIOS, and ARM stuff is just all over the place.

                BTW: Why did you choose vfat instead of EFI System Partition in Anaconda in the UEFI video above (time: 1:44)? I don’t quite follow that. Isn’t /boot the ESP? What does the ESP filesystem option in Anaconda do differently?

              • Hi JCjr:

                “If you could replace GRUB with some other bootloader in Fedora Project images, what would you use? Would you try to use something that’s compatible with the majority of platforms out there, or would you change the bootloader depending on the target platform?”

                I’m not passionate about the alternatives. I’m just a little annoyed with GRUB. Practically speaking, it would probably be necessary to vary the bootloader depending on the technical details of the platform. SYSLINUX works for most of the older stuff (and there is an up-stream patch for BLS support). And systemd-boot should work for the newer UEFI systems. I don’t do any work with ARM, so I don’t know what the best option is there.

                “Why did you choose vfat instead of EFI System Partition in Anaconda in the UEFI video above (time: 1:44)? I don’t quite follow that. Isn’t /boot the ESP? What does the ESP filesystem option in Anaconda do differently?”

                Yes, /boot is the ESP. I don’t know if Anaconda does anything special if “EFI System Partition” is selected. But I didn’t want it to do anything special/fancy. That is why I just selected vfat. It might work if you select “EFI System Partition”. I deleted everything under /boot before installing systemd-boot anyway, so I doubt that it matters.

              • Andrey

                Thanks Gregory, seems I didn’t read the article carefully.
                Need to repeat your solution for Fedora Silverblue, seem there would be some alterations in the procedure.
                I might need a consultation, in that case – could we discuss it further in Fedora forum or by other means, to not pollute the comments here?

              • Hi Andrey:

                Sorry, I’m not familiar with Silverblue. I use Workstation. My understanding of Silverblue is that it is just a fork of the Workstation edition that makes /usr a read-only partition. I didn’t really understand the point of doing that, so I never made the switch. Hopefully you and others can figure it out and, if not, I would probably suggest that you just stick with the Workstation edition. If you are very lucky, you might be able to get hold of me on the #fedora channel of freenode. But I’m usually too busy to monitor it.

      • Hello Greg, great article BTW. The GRUB thing as far as I remember it, came about from frustration with LiLo way back when. LiLo’s inflexibility with some OS’s precluded multi-boot scenarios, for many this was a show-stopper at the time. Plus, in Fedora terms, I would think at the time since Fedora is GNU/Linux based GRUB was logical. Just my two cents worth.

  14. Morvan

    “… Silverblue is that it is just a fork of the Workstation edition that makes /usr a read-only partition….
    Is this the only difference, then? I pass SilverBlue, indeed, after this; the only thing | benefit is to make Directory and its files less prune to corruption, Rootkit away.

    • Yes. Basically that is all that Silverblue does. See Colin Walter’s comment on the original Silverblue announcement and his blog post here. Locking part of the file system does nothing for security. It only frustrates the end user who needs to install or uninstall a few packages.

      • Morvan

        Thanks.

      • Hello Greg, et al with concerns around Silverblue. I run Silverblue daily, and am happy with it’s capabilities and usability. From my simplistic user perspective, I find I can set up my system very much as I did with Workstation, layering ZSH for my shell preference for example, and using my former WS dot files without change. When I mess things up I can dial back to the last know good state and recover easily. To pull a quote from Colin’s blog you referred to Greg …”rpm-ostree allows you to use yum/apt/zypper style workflows,, and still get the benefits of image-like approaches. Such as known-good “base image”, transactional updates and “offline” updates.” That’s cool, but there is more for me. It is a workstation variant that is here to stay (I’m certain it will outlast GRUB in Fedora land, but I’m also a lousy gambler, so …) and I like the focus on container based workflows with rootless containers via Podman/Buildah/Skopeo tools. So to me, having a known proven usable base image that I layer my desires onto is a valuable backstop against my conflicting needs of stability and my desires to use the latest and greatest from the near bleeding edge.

        • Hi Stephen:

          Thanks for contributing your insights to the discussion. Part of the problem, as I see it, is that you and many others seem to only be focusing on adding to what you call a “known-good” base image. It is not always the case that the base image is “good” though.

          GRUB provides a convenient example of this problem. Right now, systemd-boot does not work (properly) if GRUB is installed because GRUB “corrupts” the BLS entries with an unresolvable variable on the kernel options line. I must uninstall GRUB in order to use systemd-boot but I cannot because ostree will not allow removing packages from its so called “known-good” base image.

          Just to re-enforce the point, I’ll provide a second example. I run a server that students remote into to develop gnu C++ applications. Some of the students like to develop with VSCode. I’ve enabled access to the VSCode IDE through x2go (x2go seems to provide lower-latency interactivity than VNC). However, VSCode does not currently work with x2go without a slight modification to the system files. The required modification is very simple, it is the following:

          sed -i 's/BIG-REQUESTS/_IG-REQUESTS/' /usr/lib64/libxcb.so.1

          With ostree, that library file is “locked” by a read-only /usr file system and I cannot modify it — even with root privileges. Consequently, I cannot run VSCode over x2go if ostree is being used.

          These are just a few examples, but there are many, many more of how ostree irreversibly breaks functionality.

          Also, not having to reboot your computer every time you want to update something has always been a hallmark of Linux. I find it quite unacceptable that ostree/silverblue requires reboots to perform updates.

          My two cents.

          • Andrey

            “sed -i ‘s/BIG-REQUESTS/_IG-REQUESTS/’ /usr/lib64/libxcb.so.1”

            Gregory, you just don’t need that hack in your rootfs. But in Toolbox I think you can do whatever you want, and without reboot.

            • I’m not sure what you mean by I don’t need it in my rootfs. I could make a copy of the library in the directory where the vscode executable resides, but that too is under /usr. But part of the point is, even when it is possible, ostree makes things that were formerly very simple much more complicated, time consuming, and requires more disk space.

              I have to admit that I don’t know how the toolbox thing works. I have seen a LOT of complaints about it being broken though.

              • Andrey

                “I’m not sure what you mean by I don’t need it in my rootfs.”

                I mean you can install vscode and all it’s dependencies in Toolbox, with usual rpm command. And then change the lib there.
                So /usr in Toolbox would be isolated from /usr in rootfs.

                Toolbox is a tool to emulate classic workflow for those who need it, AFAIK.

              • “… you can install vscode and all it’s dependencies in toolbox …”

                Ah, I think I get it. So toolbox is just a container with a copy of everything. “All its dependencies” could easily be almost a whole new copy of the operating system. I don’t like that solution at all. WAY to much of a space requirement and now I essentially have twice the number of operating systems to update and manage. Seriously, I want to be able to just tweak a “system” file once in a while when I have the need.

          • Hello Gregory,
            If the base image has something that you cannot tolerate in it, you can override it with rpm-ostree to downgrade for example, if that is required, or disable it entirely. This does happen sometimes when upstream components of the base OS, are not in sync with the release cycle and something breaks. As you can imagine, this was more common in “the beginning” around F28 or so. These overrides remain active until and only if you reset them, so as you update, the overrides remains. Also there is a way to make the initramfs local for instance, or even compose your own tree to your liking. It is more flexible than you are giving credit I think. I had to rethink how I use my workstation when I first started using it, now it is more comfortable to me than going back to standard Fedora Wrokstation.

            As for VsCode, it is availabe as a Flatpak, and many dev’s seem to like it that way.

            Stephen

            • OK, if ostree still allows me to remove individual packages and override dependencies (i.e. rpm –nodeps –erase $packagename) then it is not nearly as bad as what I gathered. I didn’t think it was possible to do that sort of thing with ostree.

              As for the flatpak, are you saying that, if I install vscode that way, the library that I need to tweak will be in the flatpak and I will be able to alter that individual file within the flatpak so that vscode will work with x2go?

              • Andrey

                Gregory, FYI, Flatpak is OSTree-based also 🙂
                So changing files there is a no other way as changing files in your main OSTree OS.
                I think to change the files you need “commit” them as I wrote earlier, but now I’m not sure, maybe there is another way..

              • “Gregory, FYI, Flatpak is OSTree-based also 🙂
                So changing files there is a no other way as changing files in your main OSTree OS.”

                That’s a great example of what we call re-curse’n in Computer Science — you curse and then re-curse and re-curse and …

              • Hello Gregory,
                Silverblue uses rpm-ostree which is built using libostree. There is also ostree installed along with that library, and some cli tools for it. It is rpm-ostree which allows the mutation of the OS, since ostree is immutable. To achieve this they also incorporate libdnf for package management.
                As for flatpaks, there are a few ways to expose extra libraries to them, the least elegant may be installing the library/or dependency, in the ~/.var/app directory or the ~/.local/share directory of the user. There is also the ability to write into /etc for config stuff specific to the host. For faltpaks, if it is something like a JDK for example, I look for an extension to one or more of the runtimes and install that. GCC, Openjdk, and others provide extensions on the freedesktop.org runtimes which allow any flatpak that is looking for such things to find them, but the flatpak app has to be open to using it. also, you can install the necessary lib’s into the home dir of the system (/var/home) as sudo as /var is writable (as sudo) or as the user in their owned directories (such as /home which is actually /var/home/userdir). Also, you can run the faltpak with specific options to allow it access (ro/rw) to any writable area you choose, or for that matter give it more host access if desired. Sorry, there are several POV discussions around sandboxing and flatpaks that deserve more/different place to talk about them. I’ll get hexchat going later and amybe we can chat a bit about it.

              • That’s alright. Thanks for your feedback, but in a way I think you are making my point for me whether you realize it or not. 😛😉

              • Andrey

                “That’s a great example of what we call re-curse’n in Computer Science”

                Speaking of Science, you are better learn about OSTree before 😉

    • Andrey

      “… Silverblue is that it is just a fork of the Workstation edition that makes /usr a read-only partition….
      Is this the only difference, then? I pass SilverBlue, indeed, after this”.

      Morvan,
      of course not, it’s not at all that difference to speak about.
      The main advantage is the leverage of OSTree technology, which should bring system maintenance to a new level: robust and easy upgrade/rollback to any previous “pinned” state, well-defined solid rootfs with custom package layers, etc.

      I’m going to try it just for that (never used Fedora before).

      • Silverblue may have its uses. I think what you are calling “solid rootfs” is what I am calling frustrating package management though. I think upgrades have always been easy with the Workstation edition and for rolling back the OS, I prefer to format my root partition with zfs and perform snapshots on every reboot (or at least after every kernel upgrade). Since I have a snapshot of my entire root partition, I trust the rollback to be more consistent and stable than the partial rollback that ostree does. To each their own though. Just don’t try to force me to use Silverblue.

      • Morvan

        Thanks.

  15. leslie Satenstein

    Grub or no Grub.

    I am waiting for Fedora32 in order to switch to SilverBlue (SB). I got a taste of SB functionality from testing Intel’s “Clear Linux” distribution. With the latter, when first installed, there was no /etc/fstab. There was no grub. I had to add my own /etc/fstab for my own partitions.

    Why do I have 3 default distributions on my computer? I am a retired IT software engineer with strong C language skills. For the code I author, I compare the compiled output from gcc and clang for each distribution. There are significant differences in the sizes of the executables between distros.

    One reason I will not be standardizing on Clear Linux, is that this distribution does not use grub or a grub alternative. You boot directly to the current kernel. The system is ready in 5 seconds and you are able to log into the system.

    I am hoping that SilverBlue 32 may emulate CLR_Linux and boot directly, I would actually like to do that with Fedora 31, skipping grub. With SB, I am expecting containers to be the downloaded objects.

    Regarding /var
    I do have other thoughts about the /var partition. With Fedora 31, I discovered excessively large dnf and other log files. Because Fedora 31 has a high software update rate, log files grow rapidly, which leads to “large” dnf log files. The largest I found was 500+megs. I do regular pruning. I am contemplating to relocate /var/log to a hard disk (spinner). I am contemplating this action so that I limit the writing done to my SSD devices.

    Why bother?

    In normal SSD use, reading from the SSD has no “wear” impact to it. Writing /var/log writes to my nvme drive does impact the wear. I keep 20% of each SSD unallocated. I think that with a weekly fstrim against the SSD’s, my SSD’s will outlive the hard disk on my system. That hard disk serves as my backup drive. That is why I mentioned “contemplating”.

    Is there a way to skip F31’s grub and for the computer bios to transfer control directly to F31 kernel? sudo grub2-mkconfig is a slow process when there are 3 distributions installed. Booting with a 1 second delay is relatively slow too.

    • Hi Leslie:

      “Is there a way to skip F31’s grub and for the computer bios to transfer control directly to F31 kernel? sudo grub2-mkconfig is a slow process when there are 3 distributions installed. Booting with a 1 second delay is relatively slow too.”

      I’ve heard that in the past it was possible to write the linux kernel directly to the first sectors of a disk (or even a “floppy” disk when a working linux kernel could be compiled down to a size of about 1MB). Then when you set the BIOS to boot from a disk, linux would load without any boot loader. In some respects the older systems seem to have had some advantages.

      I don’t think the linux kernel supports that anymore, but there is something similar that can be done with UEFI and dracut. I haven’t tried it myself, but have a look at the –uefi and –kernel-cmdline options in the dracut man page.

      Supposedly you can generate a single .efi binary that includes the kernel, initramfs, and command line by passing those options to dracut. Once you have generated the file, something like:

      efibootmgr -c -d /dev/sda -p 1 -l "$(find /boot -name kernel.efi -printf '/%P\n' -quit | sed 's!/!\\!g')" -L "My Kernel"

      should register the generated .efi with the system’s UEFI BIOS so that it will be selected the next time the computer restarts.

      Of course, once you figure the process out, you would want to drop a script to automate it in /etc/kernel/install.d.

      Good luck and thanks for your feedback. 🙂

  16. JCjr

    I think the reason for Silverblue is more about pushing agendas (bad or good) towards a particular type of system maintenance over anything else, i.e. getting people used to “container-izing” everything in the system, as you can do already with Flatpak apps. Sure, you could have all your applications in Flatpak apps on Fedora Workstation, but “why not go the extra mile and do it for your system OS too?”. I may be misreading this, but it seems that a lot of operating systems are moving in this direction. Chrome OS already does this, and it’s looking like Windows 10X is going to do this as well (which, let’s be honest, Windows could benefit from it due to all of the update issues with it).

    But I agree with you that it shouldn’t be forced on users. There are a lot of scenarios where using snapshot-based read-only OS updates just don’t work on Linux. It’s just a shame that the setup for it couldn’t be simpler wherein the OS installer and package manager couldn’t just be switched over to that method of operation. I mean, wouldn’t it be ideal to just be able to give RPM an optional extra parameter to build and deploy an application as a container automatically for a user? The current method of having additional dependency container layers that the user may already have redundancy for in their host OS seems to be pretty inefficient, especially considering existing package managers already do dependency resolution. And the update mechanism for those underlying container layers also relies on independent container repos with read-only and often outdated images.

    • I think you are on to something JCjr. I think this PCWorld interview with Matthew Miller gets to the true origins and motivations behind what is now “Silverblue”:

      One OS, three flavors: How Fedora 21 is splitting up to double down on focus

      A few particularly revealing excerpts from that interview are:

      “… Most people who have a computer don’t want a computer. Most people want the things you can get by having a computer … Having a computer is a horrible nightmare they put up with …”

      and

      “… The desktop is going to take a long time to die … There are always going to be people who want more than a tablet or a stripped-down computing experience like Chrome OS provides. These people are everyone from software developers to advanced users who want to customize things and have more control of the system. …”

      Unfortunately, Silverblue is turning Fedora into exactly that kind of “locked-down tablet” that the traditional power users despise.

      I think this video clip of Brian Kernighan explaining pipes illustrates well what Linux is supposed to be all about:

      AT&T Archives: The UNIX Operating System

      In partitular, at about 10:30 he states “This is why the system is so productive … I can take programs and stick them together to get the job done …”.

      When you start restricting what bits and pieces people can “stick together” like legos as Silverblue is beginning to do, you start restricting the sort of creativity and freedom that Linux has traditionally been good about allowing.

      This is why I don’t like Silverblue. … That and all the bugs they are finding with their partial rollback system (e.g. https://github.com/coreos/rpm-ostree/issues/233). The github repo lists 578 bugs, 235 of which are still open! I wouldn’t touch Silverblue with a ten foot pole!

      • JCjr

        If you don’t like Silverblue, don’t use it. Red Hatters and other Fedor-ites have said that they don’t plan on defaulting to Silverblue right now. It may make sense for the “average PC user”, but traditional Fedora users generally use it for development and advanced computing, hence their decision to stick to Workstation.

        I just wish there was a better merge of having the option to create containers of applications, i.e. have it done automatically by the system for when you need it instead of having to “build” containers with terminal commands. I mean, look at how GNOME Software works: you have different downloads for Flatpak packages (in Silverblue, you have no choice). Ideally, I’d like to see the option to take any RPM package and have the system automatically create a container for it. It should be as easy as just clicking a checkbox: “install in a container”. But also, that container system should be better at calculating dependencies so that you don’t have redundant copies of baseline image layers like having a duplicate layer of GNOME Software Environment when the host OS already has that. This problem is why you have Flatpak applications that take up over a Gigabyte in size for an app that is less than 100MB. If the host OS already has the resources, it shouldn’t be downloading a dependency layer that contains the same thing (or an older version when the current one is compatible).

        • “If you don’t like Silverblue, don’t use it.”

          And as long as that is possible I really have no problem with it. My concern is the “What is the future of standard Workstation?” section of the original announcement that states “There is a possibility that the Silverblue will replace the regular Workstation.”. I am complaining loudly in hope of scuttling that “possibility”. 😉

          • JCjr

            Until they work out the problems they concede and you expressed, it’s going to be a long way off, as they also state in the same paragraph. That statement was said “in [their] point of view” too, which I would presume is coming from the Silverblue team, and take it with a grain of salt until FESCo says otherwise.

            I think some kind of immutable OS is alright, but the issues you get with layering RPM’s on top results in added servicing complexity. RPM-OStree works, sort of, but it’s like putting a band-aid on a sword wound. I’ve tried layering preloaded applications from a common Workstation install on Silverblue and ran into numerous stability problems with updating because of the image changes from what is the “normal” baseline. And then the size requirements for Flatpaks drove my storage demands sky-high so I went back to Workstation, which runs fine. I run Fedora on a pretty cheap computer (a thin client box with a 32GB SSD), and Silverblue takes more space to do what I need the platform to do than this hardware can afford.

            Just a thought: maybe the big problem with Silverblue is that whole directories/mount-points are read-only. If there was a way to just make system files read-only as some sort of virtual filesystem on root with an rw overlay so that files could be written into directories that also contain the read-only parts, maybe that would make things better.

            • “Maybe the big problem with Silverblue is that whole directories/mount-points are read-only.”

              That is a big part of what I “don’t get” about Silverblue personally. If you have rollbacks, then why do you need to “lock” anything such that not even a user with sudo privileges can make needed changes? If the change causes a problem then just roll it back. That is precisely how I operate on my systems that use zfs on their root partition — something goes horribly wrong, no big deal, I just reboot and rollback the whole rootfs from the dracut shell and voilà my system is back to golden no matter how badly it was corrupted.

              • Andrey

                “If you have rollbacks, then why do you need to “lock” anything such that not even a user with sudo privileges can make needed changes?”

                Because every change must be tracked, otherwise the state of your system would be undetermined.
                It’s the same way how Git works, just “work tree” is read-only, because changing it on a running system might influence it’s behavior, and e.g. your bug report would be inaccurate.

                But, of course you can change your system, in the same way you do it in Git – by “commiting” your changes to OSTree. It’s just implemented currently in the way that reboot is needed so your changes actually appear, but again it’s for consistency and only for system parts.

              • Interesting analogy. With zfs, I can change my running system and still get an accurate report of all changes for bug reports by running “zfs diff”. And I don’t need to reboot to make changes. Nor does anything have to be authorized with “OSTree”. Does all that mean that zfs is superior to ostree? Maybe I need to get a chant going — “Don’t use ostree. Use zfs instead!”. 😛

              • Andrey

                “Interesting analogy. With zfs, I can change my running system and still get an accurate report of all changes for bug reports by running “zfs diff”. ”

                Greg,
                actually you can’t. As long as no one able to reproduce your “zfs diff”, which is impossible since you don’t have determined base rootfs image.

                Of course, you could attach your snapshot to the bugreport, if someone willing to download it 🙂

              • No one has to reproduce my “zfs diff”. I can send diffs of individual files. I can indicate exactly which bits in the files are different if needed.

                I do have a determined base rootfs image. It is the snapshot that I made immediately after the last install/update.

        • Andrey

          ” Ideally, I’d like to see the option to take any RPM package and have the system automatically create a container for it. It should be as easy as just clicking a checkbox: “install in a container”. ”

          JCjr, it would make no sense. The idea of the containers is that you got exactly the same experience as developer of the app had. Since your system is unique, devs have no access to it, that is why the containers stick all the libs with itself and have no dependencies. But that is no big problem actually, since they share their identical parts of runtime. So that Gigabyte in size Flatpak app actually a tiny app + runtime which is shared and keeps on your system only once.

          There is no way to use your host’s libs in the containers since again every system has it’s own libs but containers must be identical on any system.

          • JCjr

            Um….what?

            You already have dependency checkers with traditional package managers.

            Container managers should check the system for runtimes already. What I find most inefficient is that there are huge GNOME/GTK and KDE/Qt runtime image layers of various versions installed on systems for pretty much any application wherein if you were using a traditional package for the same application, it would just use an up-to-date runtime that’s already there, or else request missing packages from the repo. What these container platforms seem to push is the notion that the application developer should provide binary container images because the distro maintainer doesn’t know enough about how to compile the source and build binary packages for their own distro. If you look at Flathub specifically, they allow closed-source applications in their repo, and that’s just not a good thing.

      • Andrey

        Gregory,
        “Unfortunately, Silverblue is turning Fedora into exactly that kind of “locked-down tablet” that the traditional power users despise.”
        AFAIK, neither Silverblue nor OSTree restrict you to change your base system.
        You could to it almost the same way as earlier since we have package layering .

        “The github repo lists 578 bugs, 235 of which are still open!”
        That is good. It means, people are working with it 🙂

        But I can tell you more when I actually try it 😉

        • “AFAIK, neither Silverblue nor OSTree restrict you to change your base system.”

          That’s not what I gather from what I’m reading. There is stuff marked “read-only” all over the place and all sorts of forced dependencies. I doubt it would even let you uninstall the GRUB boot loader.

          I haven’t actually used it either though, so my criticisms should be taken with a grain of salt.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions