It allowed you to do a few things:
- Opt out of installing a bootloader at all.
- Specify whether you want the bootloader to install to the MBR or to /boot on the first-order physical disk. (You could go back to disk selection and change the order if you wanted to install the bootloader to a different physical disk.)
- Set a password for your bootloader.
There’s a few use cases for why you’d want to configure the bootloader:
- I have three disks in my system, but only two are bootable – that’s all my BIOS will support. These folks need to know which disk is set as the boot disk, and they need to change it in case a non-bootable disk is set as the boot disk by default. Sure, they could crawl under their desk and play with hard drive jumpers if they can’t change the boot disk, but what if they don’t have physical access to the system? Or if it’s hardware made by a manufacturer who doesn’t make it easy to open up? (I won’t name names.)
- I want the thing I just installed to boot, without making my Windows install unbootable. These folks are likely not up for manual bootloader configuration and troubleshooting. They should be able to access both their Fedora and Windows install without having to configure the bootloader.
- I have a carefully-configured chainloaded multi-OS boot system. The argument for having a setup like this is that you don’t want multiple OSes owning the bootloader and helpfully updating it or changing it, confusing the other OSes. Also, if one OS gets a kernel update, you want to be booting into the latest kernel without manual intervention. If my understanding here is correct, with chainloading you can have a central, kind of agnostic bootloader that points out to the bootloaders of all your other OSes, which keep themselves updated as needed and don’t clobber each other.
- I want to dual-boot using the bootloader of my primary OS, and I don’t want to chainload. I guess if you don’t want to bother with chainloading, and maybe only have two OSes, this is a good option.
- I want the thing I just installed to simply boot. These folks aren’t doing any fancy multi-booting, they are just trying to install a functional Fedora system, maybe for a VM. They might be curious though, so if they click on the wrong checkbox and get an unbootable system, they might not know what to do.
So today Adam Williamson asked, in the world of the new Fedora installer, how will we accommodate these cases? We had a discussion in #anaconda and came up with the following:
- Three disk case – We’ll have a visible indicator in the disk selection UI to show which disk is set as the boot disk. By default, the first disk you select is set as the boot disk. You will be able to right-click the disk in the widget, or click on the disk summary link at the bottom of both the disk selection screen and the custom partitioning screen to view and change the boot disk. (Mockups below.)
- Windows dual-booter – GRUB2 automatically detects other OSes and adds entries for them, so this use case should be handled nicely out-of-the-box without any bootloader config or other manual intervention required.
- Multi-OS chainloader – You’ll need to pass an argument to anaconda when starting it to indicate that you don’t want the bootloader to be installed to the MBR. It’ll install the bootloader for Fedora to /boot, which should be convenient for you in this case.
- Multi-OS but no chainloading – Again, you’ll need to pass an argument to anaconda when starting it to indicate that you don’t want the bootloader to be installed to the MBR. It’ll install the bootloader for Fedora to /boot, which is really of no use to you, but it shouldn’t hurt anything.
- Just want it to boot – There will be no checkboxes in the UI, tempting you with their inscrutable potential, serving as a ‘make this not boot’ button. So you should be good.
Does this make sense? Did we miss anything?
This is covered in Fedora bug #860430.
A common thing folks do when installing and reinstalling Linux is creating a separate partition for /home, and then after their initial install, re-installing a new version of Linux while leaving /home untouched and mounting it to the new system. It’s a way to ‘upgrade’ your system without having to back up and re-copy over your data.
This should be possible in the new Anaconda UI. David Lehman has some patches to make it possible pending. What the workflow will roughly be:
- Select the disks of interest.
- Go to the custom partition UI.
- In the mount point directory on the left, open up the section of the tree from your old Linux install. Delete all of the partitions except for the /home.
- In the mount point directory on the left, in your new Fedora tree, add the partitions you want and drag your old /home into it.
Assigning Partitions to Disks
Another thing that’s come up in Anaconda new UI testing is whether or not it will be possible to indicate which specific physical disk you’d like a given mount point to live on. The primary use case here is that you might want particular partitions to be on faster disks, e.g., you might want your / directory to live on your SSD disk and your /home to be on a larger but slower disk.
This is definitely in the design; it might not make beta, but you’ll be able to select the mount point in question
in the list on the left side of the custom partitioning screen and click the ‘gears’ button on the bottom of the list to bring up the dialog displayed below, which will enable you to choose a preferred disk for that mount point:
OMG you’re redesigning the anaconda installer?