Partitioning personas
Redesigning the UI for something as complex as an OS installer has the potential to be disruptive to some classes of users, so in designing and re-designing and re-re-designing the partitioning screens for Fedora’s installer, we’d like to make sure you’re going to be covered.
Do any of these cases describe you, and if not, can you let me know how you use the partitioning functionality of Anaconda or really any OS installer so I can account for your use case?
The partitioning UI thus far
What are we doing to the installer’s partitioning UI to bring us to ask such questions? What is all this redesigning that’s going on? Well, let’s talk about partitioning as it works today in Anaconda.
Note that this is a screenshot of Red Hat Linux 8.0 from 2002, almost 10 years ago now. Aside from the online help / release notes pane on the left which has long since been dropped, this partitioning screen does not look much different today.
Our partitioning UI is currently very technology-centric. I suspect users care a lot more about the mountpoint layout of their OS with the technology underneath having a less primary role for them. (What the technology does for them, such as give them redundancy for their data via mirroring or increased performance via striping, I think they *do* care about, though.) Above is a screenshot from Fedora 15 showing part of the workflow in creating a partition. Before you can create a mountpoint layout or configure your filesystems, you have to create partitions and choose what technology to use with them.
Creating partitions is a means to an end of staking out some space for your files; if what the users really want to do is arrange their filesystem as they’d like it, why don’t we let them do that first, and guide them amongst the technology choices based on what it will do for them and their files later on?
“Wait,” you may ask, “are you trying to say that the goal of a user in a partitioning UI isn’t to create partitions?” Yep, basically I am. An illustration of how configuring RAID in the current UI may help explain:
Say I did a bit of reading and decided that for me, the best way to store the data in my home directory would be to set up RAID mirroring and striping between two physical disks (AKA RAID 10). If I set out to do this, what kind of workflow would seem most natural? Would it make sense to create my home directory, dictate the (when-all-is-said-and-done) capacity I want for it (let’s say 100GB), and apply the appropriate RAID level to it afterwards?
That’s what I thought. That’s not how it works in our UI right now, though. Right now, here’s the basic convoluted workflow:
- Delete the auto-part layout since it’s all LVM and you want to use RAID on top of physical partitions. Click click click click click click click!
- Create a RAID Partition; Give it the capacity you ultimately want (100 GB). Make sure it’s on hard disk #1.
- Create another RAID Partition, identical to the other, 100GB. Make sure it is *not* on hard disk #1 but is on hard disk #2.
- Create a ‘RAID device’, and add the two RAID partitions you just created to it.
- Set ‘/home’ as the mount point of your ‘RAID device’ and set the RAID level you’d like.
That seems a little backwards to me. You create the partitions first, then the device. Why can’t the partition manager create the partitions for me based on my specifications for the device? It also seems a bit error prone, because I think it’s pretty easy to forget to create the two partitions on two separate disks. If you don’t, your mirroring doesn’t make sense since if the hard disk fails (what mirroring is meant to protect against), both of your copies are dust in the wind! The RAID device creation UI doesn’t state which physical disk each partition is in, either, so it’s easy to miss if you did make the mistake. The other thing this doesn’t protect against is that you could quite easily, without any complaint from the interface, mirror RAID together a 1 MB partition with a 1 TB partition, and lose 1 TB – 1 MB worth of space since the partition with the least capacity dictates the capacity for the device in mirroring. Sigh.
So a while back I went over in detail our buffet-style, technology-based mockups for partitioning – we had a sense that it was not the right approach but had whiteboarded and wireframed the mockups so I thought posting them would generate some feedback on a better way. And it did, of course, because the folks who find the time to read this and provide feedback are smart and helpful. Here’s a quick snapshot of one of those mockups as a refresher (the technology-focused tabs across the top is what I consider a ‘buffet’):
A new, mount point-based hope?
This is kind of what we’re leaning-towards now. After a few iterations, I call it the RPG partitioning UI. On the left, we give you a sane default mount point set up (dictated by either your particular spin or the install class, so if you’re using a desktop you get a desktop-focused one; for a server, a server-focused one; etc.) and let you modify as you like. By default for Fedora, we’ll have a btrfs set up (not reflected here.)
Notice how there’s selectors for each mount point where you can choose the partition type (physical, btr, LVM) and you can add on options, choosing the technology you’d like for each. RAID and LVM both offer mirroring. If you have a preference as to which one you’d like to use, there’s a spot for you to dig into that. However, we present mirroring as the feature you can opt into; we don’t present the technology at a primary level anymore here.
There’s also a cost associated with some options. If you choose to mirror a 100 GB home directory, for example, you’re going to need 100 GB x 2 or 200 GB to have that 100 GB mirrored. So there’s a ‘cost’ in terms of capacity for different options. What makes this the ‘RPG’ design is that as you add or remove features from how your file system is set up, the cost (or savings) in capacity are outlined right next to each option.
The general idea we have here is that if you don’t have sufficient hardware / capacity to choose a particular option, it will not be presented to you at all. No bait ‘n switch by offering it up front and then erroring out later.
Where this mockup needs work is how we allow the user to hook up their mount point setup and filesystem configuration to physical drives in their system. And that is why I’m showing the personas to anybody who will listen to try to make sure we understand where users are coming from when they do that hook up, so we don’t lock anyone out of essential functionality they need.
So that’s that.
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.
Home preserver definitely, but with a twist: I have two root partitions, always. One in reserve for when I need/want to upgrade. The new version on the reserve partition, so the old install is safe for when the new version turns out to break something I rely on.
I’m mostly a ‘home preserver’ but as I’m also an early adopter, usually, I keep two root partitions — depending on the release cycle phase, one for Fedora n or Fedora n-1 and the other for Fedora n+1 or n. So I guess I’m kinda between home preserver and dual boot use case. Anyway, nice work!
The only problem I see in general philosophical terms here is that you’re strongly distancing the user from the technology used to implement their choices. Which to an extent is okay, but has negative consequences as well as positive ones. The current workflow for setting up RAID is odd from a UI design perspective, sure, but the fact that it quite closely follows *how RAID actually works* has two major benefits:
1) if you don’t know a damned thing about RAID, you might learn something
2) if you *do* know a damned thing about RAID, it’ll seem like a good UI because it’ll follow your expectations
I do worry about the experience of people in category 2) there when it comes to the new UI. I can see the forum posts along the lines of ‘why can’t I just damn well tell it what partitions I want on each disk and create my own RAID devices? Why does it think it knows what I want better than I do?’
Hey Adam,
I don’t think it’s software’s place to ‘educate’ people on the underlying technology behind it. I can certainly want my data to be redundant without having to know all the details about how RAID works in order to achieve that goal (similar to how I shouldn’t have to know all the details behind how my furnace works but I should still be able to keep warm in winter.)
I have great respect for people who do understand all the underlying specifics, but in the end you cannot know details behind every single technology, and when the software relies on you knowing it or learning it, it’s really distracting you from the things you’re more useful for in life. I do think technology is a form of literacy to an extent. That being said: if technology is basic reading skills, deep knowledge of how RAID works is really a PhD thesis. It’s akin to a clubhouse or an IQ test to expect people to know how x and y technology works to enjoy its benefits, and that really bothers me at a deep level.
If you used the current anaconda RAID UI as a ‘teacher’ to ‘learn’ about RAID, you’d certainly learn some pretty wrong and awful things, like the example I gave in the post about RAIDing together a 1 MB partition and a 1 TB partition in a mirrored device. The UI certainly doesn’t give any indication that this may be an incredibly wasteful thing to do, so how can you learn from it?
I do know a damned thing about RAID. I know enough about RAID that I wish I didn’t. Even so to me our current UI really does not make sense, even with an understanding of RAID. I have talked to people who are in fact (independently verifiable) storage experts who treated some of the RAID levels as being akin to trivia because they aren’t often used or are only used in certain scenarios. E.g., I understand you need multiple RAID partitions to create a RAID device. Why must I create each partition manually before I create a RAID device? How does this give me some greater understanding or meet my expectations given my knowledge any better than allowing me to create a RAID device and asking me how many partitions of what capacity I would like all in one step? The computer is supposed to compute for me, not the other way around.
If you know of any RAID fans who would find this mockup problematic, would you point them my way? So far I’ve talked to several and with some reservations (which we’re hoping to address in the next iteration) they liked it better.
I completely agree, Máirín, and it’s refreshing to meet this view in the free software world, which is otherwise so fixated on “do it yourself”.
I see three basic approaches one can take:
1. You can throw the user in at the deep end and yell: “You wanted Linux? This is Linux, son!” (This is what the current UI does.)
2. You can lie to the user. (This is what Windows tends to do.)
3. You can enter a dialogue with the user and help them translate their human goals into technical primitives. (This is what I hope the free desktop will do.)
Maybe, to address Adam’s concerns, the installer could present a more detailed (but not intimidating) view after the ‘user friendly’ view. I.e. “given your choices, this is the actual setup we recommend.”
The left hand bar contains “goals” (mount points).
The center pane contains details.
Why not put a right hand bar for the “resources” ?
(think wide screen).
By default, this may contain only the “Available/Free
space” bars. While a power user may expand this
to see the details (disks / physical partitions).
If we only had to support GUI install, we may model
resource assignment to goals by drag-n-drop.
(a-la google+ “circles”, but right to left).
I.e: a power user may drag existing disks or
physical partitions from the right bar to the
center pane (or specific lines on the left bar).
Looks good to me (I’m in camp #3, but I usually select ‘custom’ b/c I’m installing a laptop so no raid/lvm/etc.) The one bit I think might be missing is the ‘all of it’ space selector.
I have fiddled with partitions sometimes and a lot of times not. What I have always wanted, which wouldn’t have to be part of anaconda, was something that explains someone’s rationale for some particular partitioning scheme. The separate /home concept is easy to get (but really, functionality sometimes suffers, or you miss out on some new stuff if you keep all your settings forever).
But what are the advantages that these various personas see in this scheme vs that? Other than some esoteric manifestation of their personality.
I tried reframing your question as: what is preventing me from installing Fedora? I currently run a setup where my Ubuntu volume is installed as a file on my Windows partition (done with Wubi). This works surprisingly well.
I am concerned what would happen with my data if I used the Fedora installer. My limbic response was: “Bad things will happen, it will destroy the boot configuration leaving you with no way to access the data, forget about it.” On second thought, there probably is some way to mount the file as a loopback device after the installation, but it’s too murky that I am not going to bother.
It’s #6 for me. I always like to be in controle and be aware what actually does happen. I hate systems that pretend to think for me as most of the time they don’t do things the way I want them to be done.
somewhere between #7 and #8 I sit; riding ponies in the cloud
I fit user profiles 1, 3, and 6. I think. Here’s my layout (because I think it may help):
Disk 1:
-small physical partition for /boot
-large logical partition called MUSIC
-large logical partition called HOME
Disk 2:
-small physical partition for swap
-large logical partition called MUSIC
-large logical partition called HOME
-large logical partition for LVM
MUSIC is in my home directory tree, but it’s not encrypted because I thought it would be faster… and my music collection isn’t confidential. HOME is encrypted with LUKS. Both of those are software RAID at level 1.
The LVM partition contains everything else, including 4 operating systems (f14, f15, scientific, and Debian). Most of those LVM partitions are also encrypted with LUKS. The /boot partition actually belongs to Debian, because it has GRUB2 and can boot the other three GRUB1 OSes from their LVM /boot partitions. So when I installed Fedora 15, I wiped out then re-installed the Debian GRUB2.
Obviously:
1.) Fedora now has GRUB2, and
2.) If I could somehow save the data on MUSIC and HOME, I could come up with a much more efficient partition scheme… but I didn’t know that three years ago.
Not-obviously:
1.) A well-designed interface, possibly/probably like the second sketch shown above, could have encouraged me to make a cleaner set-up the first time.
2.) What about those people who want to install Fedora/RHEL intentionally as a secondary OS, subject to something else’s bootloader?
And why does Anaconda always ask me if I want to *change* the password for my pre-existing LUKS devices so they’re the same as the new LUKS devices… even though the passwords already are the same? An unrelated thought that you may be able to direct to the right people.
Anyway, I came here to say that I’ve enjoyed watching your work on Anaconda progress, and that overall the proposed new UI looks like a great idea.
Hi Christopher, posting your layout is super-helpful and really helps me visualize your use case, thank you so much for that.
Is there any reason in particular you’ve got swap on the second disk? (For some reason I always put it on the first disk.)
How is your current scheme not as efficient as it could have been if you knew three years ago what you know now?
The LUKS issue I’m not sure, but when I get into the office tomorrow I will try to figure out what’s going on there and point you in the right direction! (Nag me if you don’t hear back)
Could you make is such as when creating a mount point (/home or /my_own) it will give you the option to put it on its own lvm volume ? even its own pd?
When you mentioned that anaconda from 2002, It hit me, I have been using linux for a long time, and yes, it is time for Anaconda to become more intelligent.
Please make sure you leave a back door for those that want to make their own changes. I liked the “right hand bar” idea.
thanks.
Yep, it would be its own volume with this UI if you selected LVM as your partition type in that dropdown – I don’t know how else we could do it for the LVM case. It wouldn’t necessarily be in its own volume group though – is that desirable for you?
What do you mean by ‘pd’? Physical device? The whole disk, not just a partition? The rationale being you could physically pull an entire disk out of your system that has your whole home directory and move it to another machine?
Are there any other changes you’d want to make?
There will always, always be a back door open for folks to do customizations as they’ve always been able to via kickstart. The challenge of the UI is the right balance between letting folks do what they need to do without overwhelming them with too many choices!
I did mean its own vg, and its own pd is just an extension of that concept. Yes, I keep /home and /my_own in separate disks.
Is there metadata in the vgs to tell anaconda what the original config was ?. Imagine I’m upgrading and I say keep my data, anaconda could see that I have /home and /my_own, it could know where they were mounted originally to and automatically configure this for me.
anaconda could also see that /boot is not big enough and that /home is not its own vg and offer the user to increase /boot and separate /home.
This is what I meant, a little check mark in the tool that tells Anaconda I want a separate partition/pv for /home (or /myown)
[root@linux9 ~]# pvdisplay
— Physical volume —
PV Name /dev/sda8
VG Name vg_linux9_home
PV Size 50.00 GiB / not usable 32.00 MiB
Allocatable yes (but full)
PE Size 32.00 MiB
Total PE 1599
Free PE 0
Allocated PE 1599
PV UUID GVuYqz-m3Rt-WmoI-DrN4-oOPn-9LB5-c9a73g
— Physical volume —
PV Name /dev/sda6
VG Name vg_linux9
PV Size 100.00 GiB / not usable 32.00 MiB
Allocatable yes (but full)
PE Size 32.00 MiB
Total PE 3199
Free PE 0
Allocated PE 3199
PV UUID rjm3yc-7g9N-I1Fk-pxsw-WAeH-UW03-SyOnQh
Thanks for the great work.
BTW, how is the new interface coming along ?
In the GUI mockup, what does the “Error Detection” check box mean? I would read error detection as the sort of data integrity checksum found in btrfs.
I’m a combo of #3, #4 although “SAN” could easily be DAS or NAS.
The missing option is “I have disk layout setup in kickstart” 🙂
You’ve got it, error detection is data integrity checksums (I think RAID offers this too.)
Would you mind posting your typical kickstart disk layout? Are you happy with using kickstart only or would a GUI be of interest for configuring something you could later snag the anaconda.ks from and use in your ks?
You missed ‘Traditional Server’ – server with a single internal drive or RAID array, perhaps partitioned
/boot (small physical)
/ (small LVM)
/home (large LVM)
/usr (medium-size LVM)
/var (large LVM)
For servers, preserving user database, Samba configuration, printers, OpenVPN certificates, web site etc. is just as important as preserving the user files in /home. I doubt many people use Fedora this way, but it’s a common use for its descendents such as CentOS.
I posted this to G+ and someone replied with this –
“Seems to be missing ‘upgrader’ who installed the OS some time back and just upgrades when the new version comes out. I realise that upgrades aren’t (?) a feature of Anaconda, but it’s a use case thats not listed”
I did let them know that anaconda is totally able to do upgrades
In the case of upgrades, we don’t need deal with partitioning at all. You just get the installed package set upgraded, and (in the new UI) the entire first hub will be skipped. That’s why you don’t see anything about upgrades here.
I don’t fit in any of those categories.
I install Fedora completely from scratch and let it choose the partitioning (I used the defaults).
#9 standard
Doesn’t care what’s on the disk, doesn’t care about other OS’es, just get the damn thing installed in whatever fashion Fedora deems appropriate.
There’s one minor thing I change though, I remove the insane lv_ and vg_ prefixes. I mean you will _never_ get those mixed, and imagine your file system is full with d_foo and f_bar. No, lv_gwynedd-vg_root does *not* make sense, gwynedd-root does.
I don’t know who thought that was a good idea.
Oh, and sometimes depending on the system I do want /data/public /data/private, so I take Fedora’s default partitioning, and tweak it a bit for that.
/data/private is supposed to be encrypted, but I don’t want the boot process to fail if I don’t type the password; it’s *optional*. This little requirement has made Fedora puke consistently since forever, specially now with systemd my system rarely boots, so I was forced to disable this partition and mount it manually when I need it.
Good thing that you are redesigning anacoda… it’s much needed 🙂
Home preserver with a side of dual booting. I keep windows around for some software, but don’t intend to ever have more than two OSes installed at a time. That’s what VMs are for.
However, the tweak-o-maniac options are important for me. If your installer’s home preserver setup doesn’t work for me for whatever reason, I’d rather be able to set things up my own way than have to conform to your standard.
Awesome work, well done.
It makes creating a RAID/LVM array so simple that even I could do it! 🙂
I am personality #{last()+1}: Cautious Upgrader. I keep unused space on my disk specifically for upgrading, so that I can keep my old / and /var filesystems alongside the new, until I’m sure the upgrade was a success. I preserve /boot (in addition to /home) so that I can boot to either release.
In theory that should put me close enough to #3, but most upgrades don’t go that smoothly and I usually find myself nudged over to #6. For example, it used to be that 100MB /boot was enough for anybody until Dracut came along, forcing me to dive in with parted so that I wouldn’t have to repartition the whole disk in the course of upgrading.
As a person who has multiple personalities as #3, #4 and #7 depending on what I’m doing, this is really awesome work 🙂 Much more logical.
First, quick question: When setting up a RAID, can you set which disk receives which partition (useful if, say, three or more disks are present)?
Current partition layout (scrounged 100 GB drive, not what I want, really, but I’m making do):
sda1: 1 MB bios partition
sda2: 500 MB /boot for F16 (eventually F17)
sda3: 500 MB /boot for Rawhide (it will permanantelly be Rawhide)
sda4: 4 GB swap (shared)
sda5: 10.7 GB / for F16
sda6: 5 GB / for Rawhide
sda7: 80 GB /home (shared)
The seperate boot partitions are mainly to make my life easier when I break things (inevitable, considering my constant testing).
Just for the record, I am a hybrid between the /home preserver and the SSD enthusiast.
Your assumption that SSDs are primarily used “for /home and only for /home” feels completely alien to me: the *system* is what I want to accelerate! My apps need to launch instantly, not my files (those don’t need super fast seek times, they just need lots of space).
I therefore have the following:
– An SSD for / and with a second partition on it for some edge cases (like my software development folder)
– A traditional HDD to store everything else in /home.
But then I do video editing on Linux, that alone means I’m probably nuts.
yep, the SSD comment in the diagram is exactly backwards. sorry about that, i’ll correct it when i have a chance.
Same for me, I wanted to report that 🙂
We also depends more in RAM in that case (don’t want /tmp in the SSD, for example).
I moved many things to tmpfs.
IMHO, there’s a use case you’re missing, and that’s #6 without your last sentence.
I absolutely distrust any kind of automatic partitioning, I always used the customized partitioning in Anaconda, and I definitely don’t expect to have to set the partitions up before even starting it because otherwise I get only some strange wizard which doesn’t display the actual partitioning layout it’s setting up. :-/
If you get the unicorns working, let me know.
The proposed design seems to either underappreciate, or explicitly ignore, the stackability of block devices and how it is actually used. Even without understanding the actual technology it’s quite important to understand the stack.
For example, it’s fairly common to use RAID for LVM pvs and build LVM over that. So its 2 disks – 2 partitions – _1_ RAID volume – _1_ LVM group – 2-3 LVM vgs – 2-3 LVM filesystems. Expressing this stack with varying “width” at each level without making each level manageable individually is quite a challenge.
The “Buffet” approach makes that pretty much trivial – choose disks, build RAID on disks, build LVM on RAID, and so on. It could even be a wizard instead of a tabbed dialog.
The “mount-point-based” approach is just not able to fit the layering into a single screen reasonably; and “I want RAID 10 with $options” is fairly often a single system-wide decision, not something that should be specified per-mountpoint.
I can imagine the “buffet”/wizard approach reversed to start with mount points – i.e. mountpoint -> LVM -> RAID -> physical disk; this would also allow more checks (“the RAID partitions must have the same size”).
(Ignoring LUKS encryption in all of this, current anaconda already manages to make it more or less transparent.)
I’m not represented there, so I’ll chime in; Essentially, I want to install Linux either to play around or as a system for an old machine, and I’ve probably got some other install on my drive, but I don’t really care about any of the data, so what I mostly want to do is:
1. Wipe the drive.
2. Have a clean install.
That said, if I’ve got a linux system there, I probably want the same partitions as I’ve already got; the two possibilities look like this:
1. Wipe previous Linux install that covers the whole disk, partition my disk however I decided to do it last time.
2. Wipe previous Linux install that’s dual-booting with Windows, keep the partitions the same as whatever I did last time.
[…] been having a bit of a Anaconda custom partitioning UI thrown down the past couple of days in #anaconda to try to make some more progress on […]
[…] the custom partitioning UI. The designs for how this UI ended up getting implemented in Fedora 18 was posted to this blog in December 2011. I really wish we’d received the level of feedback we received post F18-Beta and post F18-GA […]