Cannot resize partitions on 2nd installation

Ask Fedora
, ,
1

I’m installing multiple distros on a multi-boot system to experiment. (It has a single NVMe SSD.) I wanted to include multiple flavors of Fedora (Workstation, KDE, Cinnamon, etc). I’ve successfully installed one so far, and free unpartitioned space remains on the disk for more.

I attempt to perform the 2nd installation the same way I did the first, but from a different live CD ISO (e.g. KDE instead of Workstation, but the result is the same for all 3). For Installation Destination, I select the disk, with Storage Configuration = Custom. On the “Manual Partitioning” screen, I “Click here to create them automatically”. It creates the draft list of partitions in the GUI, but it insists on using the entire remaining free space on the disk. The “Modify…” button is greyed out (for all partitions), so I can’t resize it. (It was not greyed out the first time; I was able to resize them then.)

Is this a bug, or somehow expected behavior?

  • If a bug, should I report it somewhere else? And is there a workaround for now?
  • If expected, why?

55d47299722812e663abb78d8a81f50c9b3343ef.jpeg
55d47299722812e663abb78d8a81f50c9b3343ef.jpeg904×1212 77.9 KB

2

Details, if relevant: The target laptop is recent hardware, with UEFI. I’m using Ventoy to run the Fedora LiveCD images.

3

I recently did a bunch of Fedora installs, for various reasons. I found the partitioning section of Anaconda a total nightmare with issues like those you describe.

I ultimately found it easier to let Anaconda do what it wants to, then clean up the mess afterward.

As long as you have another “place to stand” (a bootable USB linux or your earlier install of a variant you don’t want to move), it is quite easy to resize and/or move partitions with gparted (which you can install and use even in a kde spin, and which is a little easier to work with than the similar-purpose KDE program).

I was never quite sure of what was meant by that whole Anaconda partition UI. I understand why it is so inconsistent with a view of the disk such as gparted (to focus on supporting simple situations for ignorant users, who wouldn’t understand gparted). But the combination of not understanding the state it is describing with usually having modify greyed out (and never knowing why) and not knowing what is supposed to be permitted plus inconsistent behavior from one run to the next, has left me helpless for any answer other than clean up afterward.

I did not get stuck on the specific issue you had. I did manage to get Anaconda to accept a smaller size than max for the BTRFS it creates for / and /home. But I don’t think the behavior was consistent enough for me to learn how (as opposed to blunder around until it happened).

I really never understood the intent of Anaconda automatically creating a new /boot and /boot/efi rather than adding files to the existing ones. That makes a mess of your multi-boot disk. The bigger part of cleanup after Anaconda was copying/editing to get all the information from the new /boot merged into the old/boot and then delete the new /boot/efi and new /boot. Like you I was using Anaconda for a new Fedora 37 after /boot/efi was already setup properly, so there is nothing to merge and the only thing to check is that the boot/efi you are keeping has its grub.cfg point to the right UUID for the /boot you are keeping.

One further step, I haven’t tried yet, which I think is appropriate for your situation (definitely is for mine): Move the / and /home of the 2nd+ variants into subpartitions of the same btrfs containing the first. I’m nearly certain that can be done (haven’t yet figured out a few details) and nearly certain it would have the benefits of keeping the variants apart for any and all file collisions, while letting them share free space and I think share duplicate space elimination. I would keep at least one decent install outside of that for that “place to stand” issue (unless you have a bootable USB that is very easy). I was surprised and upset that Anaconda itself wouldn’t let me do that (create new subpartitions of an existing btrfs as the destination of the new install).

If someone gives a great answer to your question, I’ll be very happy to read it and learn myself. Meanwhile, sorry that I can’t do better than cleanup after Anaconda does things wrong.

4

I don’t fully understand the /boot, but /boot/efi is very simple.
Fedora uses /boot/efi/EFI/fedora for all its spins. If you shared the same efi partition for each install the last one installed would be in control and each update would cause competition between which was actually in control – The last one updated would try to control it all.

Similarly /boot would have competition in the content of /boot/grub2 and /boot/loader/entries where different installs would compete – The default for dnf to only save the last 3 kernels would be conflicting.

Experts could manage, but the novice or average user not so easily.

1 Like
5

Bigger picture: what is the recommended way to test drive multiple flavors of Fedora, natively, on the same hardware?

I’m really having to fight the installer to be able to multi-boot multiple instances/flavors of Fedora, which makes me think that’s not a supported (or expected?) use case.

I was going to try this, but it seems that the installer detects the previous btrfs volume by name (“fedora_localhost-live”), and insists on using it for the new install. So I tried renaming it (outside the installer), and I was able to install the new flavor, but it overwrote the contents of /boot/efi/EFI/fedora/, so I couldn’t boot the previous installation anymore.

Fortunately I’d had the foresight to backup the /boot/efi partition, so I renamed the EFI/fedora/ dir, restored the old one from backup (and renamed it, too), then reinstated my primary boot manager, and I’m back in business.

BUT this is a lot of fighting the installer, I’m concerned about breaking stuff (worse), and I want to try more flavors, too… So - bigger question above.

6

That is surprisingly different from my experience.

But whatever it is doing is easy to clean up if you know how things fit together.

  1. Your BIOS level multi-boot selects an efi partition and apparently fedora within that. I’m unclear myself on this level. But things are simple if you leave only one choice.

  2. The file EFI/fedora/grub.cfg in the efi partition points to the boot partition. (Within the system itself, that is normally mounted /boot/efi/ so the whole name is /boot/efi/EFI/fedora/grub.cfg but from a different “place to stand” you need to mount that efi partition elsewhere to edit it.

By default, the uuid is used to identify that boot partition. That is more robust, but I find label easier to work with and I’m careful enough with labels for that to work well. Anyway look at that file after any run of Anaconda and decide whether to change it.

/boot/efi/EFI/fedora/grub.cfg also identifies the directory and name of the next grub.cfg to use, but it is a bad idea to mess with that. Leave it grub2/grub.cfg

  1. Inside the boot partition grub2/grub.cfg is the next file to consider. I edit mine for various purposes (and then must protect it from various automatic edits). But in multi-booting fedora, all versions are likely the same.

  2. For fedora multiboot the interesting part is in the boot partition in loader/entries/
    There is a file there for each fedora install.

That is the most surprising thing you described. I’m not sure what you did wrong. In my experience, a new fedora install creates a new boot partition and in that obviously a new loader/entries/ but within there it creates a file for each other fedora install, not just itself.

But whatever the mess will be, prepare for cleanup by backing up /boot/loader/entries/ then examine/fix it as part of your cleanup.

7

Not surprising when you look at what the contents of /boot/efi/EFI/fedora/grub.cfg are.
That points to the /boot partition (by UUID) for access to /boot/grub2/grub.cfg and related files. If using multiple /boot partitions, one for each flavor installed, then it cannot work with a single efi partition.

The only clean way I know of to install multiple versions of fedora on one disk is to have each with its own /boot and /boot/efi partitions, then for the one used as the “master” for booting chainload the boot loaders in the other installs with custom grub menu entries.

An alternative may be to use 1 /boot and 1 /boot/efi partition shared with all the installs, and do not ever format the /boot partition nor the efi partition. Remembering to always keep a backup of the efi partition for the system used as master and always only do updates of grub.cfg from the master system. Dnf on each system would need to know that it should keep enough kernels to never delete the ones being used in the other systems.

An even easier and cleaner method would be to use a VM for each additional install.

8

You could also try systemd-nspawn. From the man systemd-nspawn you can find examples, for example


       Example 2. Build and boot a minimal Fedora
       distribution in a container

           # dnf -y --releasever=36 --installroot=/var/lib/machines/f36 \
                 --repo=fedora --repo=updates --setopt=install_weak_deps=False install \
                 passwd dnf fedora-release vim-minimal systemd systemd-networkd
           # systemd-nspawn -bD /var/lib/machines/f36

       This installs a minimal Fedora distribution into the
       directory /var/lib/machines/f36 and then boots that OS
       in a namespace container. Because the installation is
       located underneath the standard /var/lib/machines/
       directory, it is also possible to start the machine
       using systemd-nspawn -M f36.

It will use the current kernel, but everything else will be as if you were running the other version.

There are also example on how to run Ubuntu or Arch in this manner.

9

The “surprise” I mentioned was not the fact that having a different boot for a second install requires a different efi. I understood what EFI/fedora/grub.cfg does.

Having done all this multiple times recently, and very similar to what the OP described trying, my experience has been that Anaconda reliably creates entries in the new loader/entries directory for all the other fedora installs on the same drive.

So the surprise was “I couldn’t boot the previous installation anymore.”

Not a bad idea, but I think not that vital. Whatever you install last will almost certainly create an acceptable efi partition in every way, other than possibly the uuid in EFI/fedora/grub.cfg, which is easy to fix afterward if you hadn’t backed it up and had it clobbered by something you expected to not trash it.

But the contents of boot/loader/entries/ and /boot/grub2/grub.cfg get messed up by Anaconda and by dnf and it takes more than a tiny edit to fix them. I think having backups of those is vital. After anything messes with those, I think you want to compare/merge in order to undo all the destructive changes and keep anything that was added or changed for good reason.

When Anaconda does create an entirely new boot then you want to merge some things from there to your old boot (and fix the uuid in EFI/fedora/grub.cfg to get back to using your old boot). Or merge things from the old boot to the new boot and keep the new one and not fix the uuid. But since Anaconda isn’t the only thing messing up the contents of boot a backup of that is still vital.

Have I misunderstood that? In limited experimentation, I came to the conclusion that was limiting the number of kernels kept in one root partition and not the number in boot when boot is shared by multiple root. Of course, when it removes a kernel from root it removes the same one from boot.

But for anyone experimenting with versions or variants in any way (even just early adopter of the next version) the default of 3 is dangerously low. Disk space is cheap (even SSD space). I messed up recently by experimenting without raising that limit. I want it high enough that DNF just doesn’t delete kernels. I’d rather go to the effort to clean those up myself when I’m sure I never want them again. Others probably just want it high enough to delay the automatic removal until it is less likely to be a bad idea.

I hate threads that tell you to do something non obvious, with telling how, so:
Edit /etc/dnf/dnf.conf and find the definition of installonly_limit and change the number there to something safe.