Coming in Fedora 21: more installer partitioning improvements

So I’ve been running some installs with Rawhide images lately, and the anaconda team has already landed some really nice changes to the partitioning workflow which I think will make some of those unhappy with newUI…less unhappy. So here, take a look at them!

Modified disk selection screen, with partitioning choices

Here’s the first shiny new change: this is the ‘disk selection’ screen, the first one you see after clicking Installation Destination. You can see that we’ve merged in most of the choices that used to be on the Installation Options pop-up after you finished this screen.

So what happens?

If you pick Automatically configure partitioning, don’t check the I would like to make additional space available box, and you have sufficient space on your chosen disks, then when you click Done you’re really done: we’ll go ahead and configure automatic partitioning to the free space on your selected disks.

If you do the same but you do check I would like to make additional space available, you get the Reclaim Space dialog as usual, where you can delete or shrink existing partitions. If you don’t check I would like to make additional space available, but you don’t have sufficient space for an install, you’ll see a simplified version of Installation Options which just advises you of the problem and offers to let you go to Reclaim Space, or cancel back out and maybe change your software selection or pick a different disk.

If you pick I will configure partitioning, you’re now on the highway straight to custom partitioning: I would like to make additional space available gets greyed out as it’s a no-op (you have complete control in the custom partitioning screen), and when you click Done, you’ll be taken straight to the custom partitioning screen.

I’m a big fan of this change – it keeps the basic workflow and all the choices you previously had, while making the whole thing more efficient, and solving the problem we had where people were looking at this screen and wondering where the partitioning choices are. I know some people hate that the button is labelled Done, and we’re still considering whether to do something about that, but hopefully the fact that the partitioning strategy choices are right here on this screen now makes it obvious what’s going on.

But wait! There’s more!

Error checking in custom partitioning screen

This one I’m a really big fan of. Previously, if you did something wrong in custom partitioning and managed to come up with a layout we thought was invalid – which happens rather more than it used to, now people are getting used to the ins and outs of UEFI – what happened was a bit baroque. The custom partitioning spoke would let you out without a complaint, but when you landed back at the hub, you’d see that the Installation Destination spoke was in an error condition, saying “Error checking storage configuration” – but it still didn’t tell you what the error was. You had to click to go back into the spoke, then click on an orange bar at the bottom of the screen, and then it told you what the error was. It all seemed a bit like Where’s Waldo. In theoretical terms it all made sense – the idea was that error checking was done async and always indicated through the spoke status – but it felt rather weird in this particular case.

Now, the storage validity check is run when you click Done on the custom partitioning screen, and if it hits a warning or an error, it pops up an orange bar right away – just as you see in the screenshot. You can click on the orange bar to see the errors right there, without all the running around in circles.

Now, ten points to anyone who can guess what the intentional mistake here was without looking at the next screenshot…

…yep, that “test_uefi” in the window title is the giveaway. This is a UEFI virtual machine, and if you didn’t fall asleep halfway through that last blog post, you’ll no doubt have noticed that the layout I created is missing an EFI system partition.

Now to toot my own horn a bit…if you’ve ever walked into this bear trap yourself, you may remember that the error message Fedora gave you (once you found it) was a bit…unhelpful. It said “you have not created a bootloader stage1 target device”. This was technically correct, but pretty difficult to interpret.

Let’s take a look at what it says now! Here’s what you see if you fail the custom partitioning test and click on the error bar:

Rather more helpful missing ESP error

That’s a bit better, right? Of course, this error is UEFI-specific – you only see it if you’re doing a UEFI install. We can write specific error messages for each of the other ‘platforms’ anaconda recognizes too, explaining the most likely cause of stage1 bootloader failure on those platforms.

The fact that anaconda isn’t visible in the background is some kind of Rawhide bug I need to get around to investigating – whenever some kind of dialog pops up over anaconda in current Rawhide images, anaconda itself disappears until you close the dialog.

There’s also some cool work going on with the keyboard spoke right now, and all sorts of other things. I’m getting excited for Fedora 21 already!

8 Responses

  1. Evaggelos Balaskas
    Evaggelos Balaskas January 30, 2014 at 2:21 am | | Reply

    Great respect on you, your work (at mandrake,redhat,fedora) and on your blog.

    That said, the UX on fedora installer is still shit (at 20 and at 21) and it’s incredibly difficult to understand the steps.

    and i am using linux as a primary distro (desktop/laptop/work) from 2002 !

  2. Neville A. Cross
    Neville A. Cross January 30, 2014 at 7:12 am | | Reply

    In the previous versions, I often got lost at the disk selection. Clicking Done was kind of weird when you need to do partitioning. This is really what I was looking for. Great work.

  3. Sylvia
    Sylvia January 30, 2014 at 10:12 am | | Reply

    Finally!! THANKS!!!

  4. cmurf
    cmurf February 2, 2014 at 10:50 am | | Reply

    RHBZ# 1022316. Even in custom partitioning we shouldn’t make users create necessary partitions. Consider the messiness that ensues when setting up bootable raid1 on UEFI. Oh I can’t create an ESP on each disk because I can only create one /boot/efi on one disk. Oops. And then we have the problem with a custom grub.cfg on each ESP needing to be updated, but it won’t be because not all of the ESPs are mounted at /boot/efi, only one is. RHBZ# 1048999.

  5. D. Charles Pyle
    D. Charles Pyle February 2, 2014 at 4:33 pm | | Reply

    Does it still try to blow off your other partitions on the same disk? Or, has that been fixed as well? The last time I tried to use the new UI it blew off the NTFS partitions on my primary hard disk, too, before crashing before it was finished. My system was trashed and I ended up using the Fedora 17 network disk I made a while ago to install Fedora 20 because Fedup failed as well before the above attempt. Luckily, I had a backup and system images for the NTFS partitions.

  6. Andrew
    Andrew February 11, 2014 at 4:16 am | | Reply

    Out of curiousity, why does anaconda force /boot/efi for the partition location ? That is, why not allow the use of just /boot as the ESP ? It seems to simplify things for a single-OS system, unless I’m missing something. I use this on another laptop running arch (with gummiboot), after I couldn’t figure out why anaconda didn’t like it.

Leave a Reply

Your email address will not be published. Required fields are marked *