Bootloading
So this is what the Fedora 16 bootloader configuration UI looked like:
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.
Re-using /home
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?
Yes!
- Why oh why are we doing this? Learn here.
- You can read lots more of my scribblings about the project in this blog’s ‘anaconda’ category.
- We also have a Fedora wiki page for the project.
- Drop by #anaconda on irc.freenode.net if you’d like to get involved or simply voice your opinions.
Didn’t see you mention boot loader passwords
Ah good catch! Those are configurable via the bootloader config files, so we didn’t think there was a need to show it in the installer UI.
I like the mockups, looking good-will this be for Fedora 19?
The first cut of the newui will be in Fedora 18. You can see a preview in Fedora 18 alpha, but be careful because the storage part will overwrite your disks.
1) Why release a disk-eating alpha at all ?
You’re inviting negative previews and discouraging testers.
2) Why are so many mouse-clicks required to preserve a /home ?
Hi anonymous person with made-up email address who is an snet/AT&T DSL customer,
1) Alpha releases are for testing, and if you read the numerous warnings about the disk-eating, you can test out the rest of the distro just fine via VM.
2) Overall partitioning is a whole lot less clicks and dialogs than the old-UI, but specifically for preserving home it’s not as complicated as it sounds. A visual would probably help; I can talk to David more about the specifics and maybe put together a little demo.
Cool-I’ll have another look at the alpha. Lots of new features in fedora 18 it seems:)
In my experience chainloading is the only sane way to run a multiboot linux system. Its the only way that each distro can be in full control of its boot parameters, and can update them at the appropriate time.
personally i think that all linux distros should install their grub to their own partition be default. You could then have a simple bootloader on the MBR that offered you a list of bootable partition, or if there was only one bootable partition, chainloaded straight to it.
Who installs the simple bootloader to the MBR, and how?
Interestingly, though, you pretty much just reinvented UEFI bootloading. The fundamental problem with BIOS bootloading is that it’s crap. It’s just a stupid system. Bootloaders in MBRs and partitions chainloading each other in infinite complexity, it’s a terrible terrible system.
This was well understood by the time UEFI came along, and one of the few really good parts of UEFI’s design is how it handles bootloading. It has its own cracky aspects, of course, but the fundamental design is solid and more or less what you describe: the ‘simple bootloader’ is part of UEFI itself. All UEFI firmwares implement a simple bootloader, the UEFI boot manager, which is basically just a list of locations of EFI executables with names. OSes add themselves to the list, with an entry that points to their own EFI-format bootloader, which can do whatever it wants to do. You don’t have different OSes competing over who gets to ‘own’ the master bootloader any more, because none of them do, the firmware does, and each OS just adds itself to the list. It’s a much better system. Once more people are running 100% UEFI-native the bootloading situation should actually get a lot better.
What about if you have only one partition, but want to preserve an existing /home? In that case the installer would have to clean up other folders (/etc /bin /usr etc.) but keep /home intact, and (later) check if the user created has an existing home, and if so reuse uid/gid..
And it’s really not that weird setup, most users coming from Windows would expect it (although I’m not sure if they’d expect installation not to nuke their files, probably not) and there are some edgy use cases like “I like to work with random files in /tmp, play with bootable system chroots that are installed in /ostree and in general I don’t like to guess if I’ve allocated enough space for /”.
I don’t think that’s a situation we can handle. We don’t really want to get into the business of reading the filesystems, going deeper than partition level I think is a lot more complicated. Certainly not for this iteration, anyway. We could consider revisiting this once the initial redesign is out and some of the initial kinks in the fundamental functionality are worked out. (I hope that makes sense!)
I don’t think we would. We’ve never supported that configuration in anaconda and it’s far too difficult to try. The rule is, if you want to re-use /home, it has to be a separate filesystem.
Hi there,
Just a quick comment. I’ve installed every Fedora release since FC3, and RHL well before that. I just installed CentOS on another partition, and I really appreciate the ability to decide to easily replace the bootloader or not (and I did not!). I will deal with passing anaconda a parameter if I have to, but I’d prefer to have it like it is. One of the reasons I like Linux is that I can do what I want, and taking away my ability to easily choose is not my favorite. Just my $.02.
Brad
Passing a parameter really isn’t difficult, you just have to know it exists. There’s no optimal solution here because there’s two differing sets of needs, we just had to pick one and mitigate the other.
Since (U)EFI is becoming more and more popular, I hope the installer will take this into account as well.
Also I just wanted to say that your design blog posts are more or less the only reason why I read Planet Fedora . Keep up the good work!
Oh of course, EFI is definitely going to be handled here. Thank you very much for the kind comments, I really appreciate it 🙂 🙂 I’ll be blogging more again, I took a bit of a break for the past few weeks.
The question doesn’t arise with UEFI’s bootloader design, as there is no ‘installing bootloader to an MBR or partition’ concept with UEFI, it works entirely differently (see above reply to someone else). Fedora handles UEFI bootloading and has for several releases, though it does it quite simply: it just adds an entry named ‘Fedora’ to the UEFI boot manager and sticks its bootloader in the ESP. There are no options. At present it doesn’t have the capacity to handle multiple UEFI-native installations of Fedora.
Personally I am only interested in multi-booting Fedora with Windows, so the current setup which I am running successfully since F16 works good enough for me 🙂
[…] Via | Máirín Duffy […]
Cant we improve the /home re-use a bit and simply have the storage spoke auto detect if /home partition is present and if so offer the user to re-use it?
Something like…
The installer has detected a /home partition would you like to re-use it?
[yes] [no]
Ofcourse the expected user behavior when re-using /home is that he does not have to go through any of the inital setup process and can continue to use his password