If you’re subscribed to Fedora’s devel list, then you probably noticed this thread about improving Fedora’s boot experience explode over the past two days.
So I have this thing on my desk at Red Hat that basically defines a simple design process. (Yes, it also uses the word ‘ideate’ and yes, it sounds funny but it is a real word apparently!) While the mailing list thread on the topic at this point is high-volume and a bit chaotic, there is a lot of useful information and suggestions in there that I think could be pulled into a design process and sorted out. So I took 3 hours (yes, 3 hours) this morning to wade through the thread and attempt to do this.
1. Define the problem
What problem(s) are we actually trying to solve in the boot process? You have to know what you’re trying to solve – then you’ll know whether or not a given solution will fix the problem, and you’ll also know later on how to evaluate (after the work is done) whether or not you actually fixed the problem.
So what exactly is the problem with Fedora’s boot experience? Here is the high-level problem:
Fedora 18’s boot experience is disjointed and lacks polish. It is not as smooth and seamless as it could be.
Okay, but what is meant by that? What specific polish is it lacking? Where specifically is it not smooth? Let’s dive into this and enumerate out the specific issues folks on the thread identified:
1. Grub2’s theme is out-of-date (it’s based on F17’s artwork.) [mclasen]
Fedora 18 does indeed ship with a graphical grub2 theme that is based on Fedora 17’s wallpaper. Shipping with out-of-date artwork is inarguably not very polished.
2. Grub2 has a progress bar that indicates grub’s timeout to exit the menu; this could be confused with progress for the booting of the entire system. [mclasen]
Can you see how this poses a confusing situation for a user who might confuse grub2’s graphical screen and progress bar with the loading screen and progress bar for starting up their computer itself? If you’ve never seen grub2 before and don’t know what a bootloader is, this is especially the case, I think.
3. The Fedora logo on the login screen (GDM) is very small and doesn’t match the one used by plymouth – it’s the full logo with logotype rather than just the Fedora logomark. [mclasen]
This I think is also a fair point – it would look a bit more polished for the size & position of the Fedora logomark in the plymouth bootsplash to be mirrored in the GDM login screen so one can fade into the other seamlessly. It’s definitely not a life-or-death issue, but it would be a nice touch that would make the transition between the two more seamless.
4. It takes too long a time to load the desktop from GDM login. [Ignacio]
Oddly I can’t link to his post in the devel-list archives, but Ignacio brought up this point which sounds like a valid problem if that is what he experiences. Nobody actually responded to his post, though. I think to understand this issue a bit better, someone needs to take it up and do a bit of research to figure out how long it actually takes on various systems, and maybe do some profiling to see why it’s taking so long.
5. Newly-installed kernels are added to the main grub2 menu rather than placed under the ‘advanced options’ submenu as intended. [Elad]
According to Elad, this is because the kernel package doesn’t use grub2-config – it uses grubby – and the kernel team cites issues using grub2-config as the reason. This seems like a valid problem since the grub2 menu is not functioning as it was designed for Fedora.
6. Braille display users can’t install their systems without help because we don’t have a brltty daemon running at boot startup time. [zan]
Seems like a valid accessibility issue to me.
7. Changing video modes makes the screen flash unnecessarily, especially if the boot time is so fast the mode you’re loading into only shows on screen for a few seconds. [mizmo]
I pointed this out in one of my contributions to the thread – to have the screen flash between video modes during boot up does look unpolished – it’s kind of like when you have a loose cable to your TV or monitor and you get that flashing. Depending on your display hardware, the flashing may be more or less distracting / disruptive. Minimizing this ‘flashing’ would help the boot experience look more polished though, I think.
Lennart suggested the part where if parts of bootup are so fast they display for a super short period of time, you’ll get the flash too. He suggested suppressing any ‘fancy’ plymouth display output until 10s into boot (so you’re not displaying anything unless you’re going to have time for it to show up long enough for the user to see.) Another idea he has was to use performance data to see if it’s worth showing any fancy output at all on the particular system you’re booting on.
8. Early boot options are not (at least not easily) localizable and require the inclusion of half the graphical stack. [Tomasz, mizmo]
Both myself and Tomasz suggested this as an issue with our boot process as it is today. I would argue that it’s definitely a valid problem if you can’t understand English.
9. Some weird grub2 config file errors flash to the screen very briefly during bootup. [Jóhann]
Jóhann brought this one up – it really is just an outright bug. We shouldn’t be flashing error messages so quickly they can’t be read about error conditions that honestly don’t even matter.
10. On some systems, bootup is so fast there isn’t enough time to display anything meaningful. [Lennart]
Lennart cited some benchmarks for this – on laptop systems, BIOS POST takes 500 ms, kernel 1s, userspace 1s. But other folks on the thread with different systems had very different benchmarks. For example, DJ said his system takes 45 seconds to get to grub. Peter Robinson said that he’s used modern EFI servers that take 15 minutes to POST. Lennart also brought up that Windows 8 certified HW, in order to be certified, has to get to POST in less than 2 seconds.
So we have some very slow systems and some very fast systems, and both should have a smooth experience.
11. Grub’s menu didn’t display by default up through Fedora 15. Now it displays by default in single-boot / final release Fedora systems. [drago01, mizmo]
We used to suppress the menu, and now we don’t after the move to grub2. According to Peter Jones, we had patches against grub1 that suppressed the menu and they don’t work in grub2. “If somebody contributes a patch upstream,” he said, “that’d be fine, but it’s unlikely we’d want it by default.”
Is the menu showing up by default a problem? I would argue that for many users who never need to access the menu (and certainly if they have to, it’s not something they have to do often) it not only lengthens their boot process by the timeout (I believe it’s 5 seconds?), but it also displays information that could be confusing. It also requires yet another video mode switch which necessitates a flash of the screen to get into, and a flash of the screen to get out of. The design of the screen also doesn’t fit in with the rest of the system, so from an aesthetics point-of-view it’s unpolished as well.
12. The LUKS password box is confusing. [Mirek]
Mirek pointed out that the LUKS password box that displays during plymouth is confusing. I think a big reason for this is it’s just a blank input box with a lock icon. There’s no text – I don’t think text/translations can be displayed at this point.
13. We may not be adhering to the bootloader spec. [cmurphy]
I think Matthew Garrett brought up this spec in the thread as well: FreeDesktop.org Bootloader Spec. It would definitely improve our compatibility with other distros in multiboot situations.
14. New kernels break things for users frequently. [Jiri]
Jiri brought this problem up, “New kernels bring a lot of regressions and we don’t have enough test coverage to avoid them. The general solution to those problems is to go back to the last working kernel version. But by making it less obvious we make these frequent problems more difficult to solve.”
2. Define the scope
Okay, so now that we have a list of problems, what do we do? Which ones should we solve, which ones are higher-priority, which ones could we let go for a while? I’m going to take a stab at breaking them into three categories – outright bugs, polish items, and bigger issues to work out. Maybe you don’t agree 100% with my categorization, but I think for the most part it shouldn’t be so controversial. It seems like the items in the ‘Bigger Issues’ category are what created the greatest volume of messages on the list, which makes sense – people don’t necessarily agree on what exactly the problem is or how it would ideally work.
Outright Bugs
These are issues that impact functionality or usability negatively and most would not argue don’t currently operate in the most ideal of manners.
- Grub2’s theme is out-of-date (it’s based on F17’s artwork.)
- Grub2 has a progress bar that indicates grub’s timeout to exit the menu; this could be confused with progress for the booting of the entire system.
- It takes too long a time to load the desktop from GDM login.
- Newly-installed kernels are added to the main grub2 menu rather than placed under the ‘advanced options’ submenu as intended.
- Braille display users can’t install their systems without help because we don’t have a brltty daemon running at boot startup time.
- Early boot options are not (at least not easily) localizable and require the inclusion of half the graphical stack.
- Some weird grub2 config file errors flash to the screen very briefly during bootup.
- The LUKS password box is confusing.
- We may not be adhering to the bootloader spec.
Polish Items
These are issues that negatively impact the appearance / look & feel and polish of the experience, but don’t really impact functionality.
- The Fedora logo on the login screen (GDM) is very small and doesn’t match the one used by plymouth – it’s the full logo with logotype rather than just the Fedora logomark.
- Changing video modes makes the screen flash unnecessarily, especially if the boot time is so fast the mode you’re loading into only shows on screen for a few seconds.
Bigger Issues
These are issues that are complex to unpack, and not everyone appears to agree on what the ideal behavior is.
- On some systems, bootup is so fast there isn’t enough time to display anything meaningful.
- Grub’s menu didn’t display by default up through Fedora 15. Now it displays by default in single-boot / final release Fedora systems.
- New kernels break things for users frequently.
So I think categorizing these issues breaks down the scope a little bit. The things that are outright bugs could be filed and their fixes are likely pretty obvious. The things that are design / polish issues should be discussed by the relevant designers and developers and will hopefully end in agreed upon solutions that are then implemented. The bigger issues are where the bulk of the discussion should happen probably. So we went from a list of 14 issues to think about down to 3.
3. Research
So a little bit of research actually came out of the discussion. First, Jóhann provided some links referencing how other operating systems handle this situation:
- Windows & Windows 8 – MSDN Blog post on accessing advanced boot settings on Windows 8 – In summary, they consolidated all the options into a single ‘boot options’ menu. Their solution is instead of triggering the boot options menu during boot, that you click on a button in the desktop UI that reboots you into ‘advanced startup’ mode which shows the boot menu by default.
- Apple OS X – Startup key combinations for Intel-based Macs and Startup Keys – Boot Options – Apple appears to have an entire menagerie of keys you can press during startup to access various modes and controls.
There was also a lot of discussion about various use cases that may need to be handled differently. We should make sure we consider each of these use cases when working through the problems we’re trying to solve. These are the ones I was able to extract from the thread:
1. The single-boot, final release user.
This person only has Fedora installed on their system – no other operating systems, at least, not bare-metal. (They may have other OSes in VMs of course.) They are using a final release of Fedora, not a development build. They want to be able to boot to their desktop quickly and get to work. They are likely using a laptop, and that laptop probably has a very fast boot time.
2. The server user
The major difference between desktop and server users that came up in the thread is that server hardware can take a much longer time to boot.
3. The user whose system can’t boot
It was suggested in this thread that kernel updates can break things, including suspend, network drivers, and audio support. Sometimes the breakage makes it so the system cannot boot at all.
4. The multi-boot user
This person has more than one operating system installed. They need a mechanism to switch between installed operating systems.
5. The encrypted disk user
This user used LUKS to encrypt one or more of their disks and they need a way to input the passphrase to unlock their disks.
6. The developer / tester
This is someone using a development version or test build of Fedora who needs to do a lot of debugging and poking around to investigate issues.
4. Ideate
So let’s go through each of the three major issues identified and the discussion around each. I’ll start with the biggest one – whether or not we should display the GRUB2 menu by default or not.
1. Should GRUB2’s boot menu display by default or not?
I believe the history here is that we used to display grub by default for development & test releases of Fedora and turn it off by default for final releases. This changed with our move to grub2 in Fedora 16.
There are, of course, two major arguments around the display of this menu:
- We should display the boot menu by default.
- We should not display the boot menu by default.
I rather like how Ryan Lerch posed these choices in a recent post to the thread:
“Car with open trunk” by entropy_eater on OpenClipArt.org.
- Remove the hood of the car, and keep it off in case something goes wrong, or to entice new drivers to look in there and guess what is going on.
- Keep the hood of the car on, and if something goes wrong, pop it. If the driver wants to tweak, or have a look around let them pull the lever and pop the hood.
I really like this in that it kind of points out, using a classic free software analogy – nobody is proposing that we weld the hood shut here. So we should get that off the table right away.
The arguments for displaying the boot menu by default
Here are the arguments that support displaying the boot menu by default:
- If the grub menu is suppressed by default, people won’t know how to access it anymore when they need it. [Alec, skvidal, jflorian, Bjorn]
- If the grub menu is suppressed by default and grub goes by too quickly, the window of time to press the key would be too short to hit reliably. [Bjorn]
- We shouldn’t make information secret or hard to discover in order to recruit more professionals into learning and using Linux. [skvidal]
- There isn’t a GUI tool yet available for configuring the boot loader. We should keep displaying it by default until this tool is available. [Hans]
The arguments against displaying the boot menu by default
Here are the arguments that support suppressing the boot menu by default – not displaying it at all:
- Changing video modes makes the screen flash unnecessarily. Not displaying the boot menu by default would eliminate some of this flashing. The video mode changing also screws up how our X setup works and results in unnecessary bugs for users.
- We used to suppress the boot menu by default in earlier releases and its suppression didn’t cause major problems.
- There’s other ways for the user to indicate wanting to enter the menu besides boot-time keypresses – other OSes have methods to enter these menus by rebooting from a running system (systemd is working on this) or automatically loading the menu when an error condition is encountered.
- Not listening for keypresses doesn’t probe USB, meaning not waiting for keypresses will make boot even faster since we won’t have to load/probe USB.
- (Nobody explicitly stated this, but) Displaying information geared towards power users by default is intimidating / confusing to less-knowledgeable users.
So the main concerns from the folks who want the menu displayed by default is that they are worried that when they need it, it will be too difficult discover how to access it and to actually access it even if you knew. The concerns from the people who don’t support displaying it by default are that there are better ways of accessing the menu or even automatically displaying it when a situation where it is needed is detected, and also fall along lines of polish and making bootup look cleaner since the majority of the time you’re not in a condition where you need the boot menu.
To me it seems like both sides’ concerns could be mostly allayed by not displaying the menu by default but also ensuring that it was accessible when needed and making sure it is not difficult to access on demand.
The proposals for the mechanics of not displaying the menu by default fell into a few categories:
- Use a timeout and keypress (or keyhold) combination hit at the right time to opt-in to displaying the menu. Suggestions for what key to press ranged from all keys to a set of multiple keys (shift, enter, esc, various F-keys, etc.)
- Have a label telling people what the keypress is instead of enabling multiple keys to enter the boot menu.
- Have a menu or application in the desktop that would reboot the system into the desired mode.
- If the system cannot boot up until a certain point, automatically reboot and make the menu visible.
- Have the boot menu always display if it’s a multi-boot system.
The most comprehensive proposal came from Peter Jones who is the grub maintainer in Fedora:
The idea would be to have a positive indication from systemd that we’ve gotten to some pre-defined point on the previous boot (say, starting your login manager), and not to show you any menu unless the previous boot didn’t get that far. So when you install a new kernel, the process would look like:
1) install kernel
2) set it to boot once with grub2-set-default
3) upon reboot, set it as default if and only if we get to the “success” point
4) if we see a second boot happen without the success flag set, don’t set it default, and wait the normal 5 seconds for input
This has a number of advantages when booting on some systems. On UEFI systems, which is most new desktops:
1) we don’t need any grub UI whatsoever
2) we don’t need the 5 second timeout
3) we don’t need to indicate to the firmware that we need USB probed unless it’s the device we’re booting from.
Together, these currently represent the majority of time from poweron to login. On new desktop hardware, this would be a dramatically faster boot experience. Note that getting to the system firmware menus or switching kernels would have to be selected before reboot, except in the case where the previous boot failed – in that case, we’d display the menus, probe the keyboard, and wait the 5 seconds.
On BIOS machines I think we can still accomplish #1 and #2 as well, but there’s no guarantee of a way to disable firmware timeouts or “press f2 for setup” screens and loading the usb stack.
He also gave a good list of reasons why relying on keypresses instead to access the menu is problematic:
So, the problems with that when we implemented it on grub1 were numerous, but basically they’re all of one variety:
1) we have to clear the buffer at some point because BIOSes often leave junk in them
2) it’s unclear to the user when the buffers are cleared
3) if the user holds down the key, the BIOS complains that the key is stuck,
4) if the user doesn’t hold down the key, but just presses it, it’s easy to do so too early
So I’d really rather have it so that /under normal circumstances/, if the user wants the non-default kernel or parameters, they tell us so before rebooting.
Kevin also asked about how we could detect error conditions that were a bit more complex, for example, the display manager loads but isn’t displaying correctly. Peter responded that we can always add more logic to define more ways to tell when we think something hasn’t worked right.
Let’s walk through how this proposal would effect each of the user cases we came up with:
- The single-boot, final release user will be able to boot their system faster, they will experience less ‘flashing’ while boot-up happens, and they won’t need to see a screen they don’t understand every time they turn their computer on.
- The server user will be able to boot their system faster, and if they need to access the menu they can reboot into it. If their boot time is exceedingly slow, however, this will make it take longer for them to get into the menu since they’ll have to fully boot just to initiate a reboot. However, there’s no guarantee they would have timed the boot menu keypress trigger exactly right anyway so they may have needed an extra boot otherwise. They are also, of course, better equipped to configure their servers to always display the boot menu by default.
- The user whose system can’t boot will be automatically taken to the boot menu.
- The multi-boot user should be able to boot into their other OS of choice from a fully-loaded Fedora desktop. They could also modify their grub config file to always display the boot menu. (Or, we could always display the boot menu if we detect a multi-boot system.) There’s a few possibilities here.
- The encrypted disk user isn’t really affected either way.
- The developer/tester could probably be fine if we turned the menu on by default in testing/development versions again.
Whether or not this is ultimately an acceptable solution, I don’t know, but it certainly sounds good to me after some analysis.
2. On some systems, bootup is so fast there isn’t enough time to display anything meaningful.
The issue here is that we had posts to the list saying bootup was as fast as a few seconds to taking 45 seconds just to POST. If boot-up is so fast that anything you display to the screen (including the plymouth splash) won’t show up long enough to be visible, it does seem pointless to display it. However, if boot-up is really slow, it does make sense to have progress bars and information on the screen updating so the user knows that progress is being made.
Lennart’s proposal of not displaying the plymouth bootsplash unless it takes at least 10 seconds seems to make sense to enable progress display for slower-booting systems but allow faster-booting systems to skip it all together. I didn’t see other proposals around this issue, but since this one seems to handle both fast and slow machines it seems to make some sense.
3. New kernels break things for users frequently.
Jiri pointed this out, and it’s a real problem. I think we’ve all hit a kernel update that broke suspend or sound or network drivers, and it’s painful to deal with. If there’s a way to reboot a system in this broken state into the boot menu, or even an easy way to set the default kernel from the desktop once you’ve confirmed a particular older kernel fixes the problem – isn’t that an okay way to get around this problem?
Generally, though, how do we prevent this kind of breakage given that we don’t have unlimited QA resources? Is there any way we can avoid it?
Conclusion
Well I hope this makes some sense out of a very long and at times convoluted thread. What do you think?
Thanks to Ryan Lerch for the screenshots!
Also, the LUKS password textfield could appear earlier. I am usually the slowest component of the booting process.
@lzap when i did the screenshots that Mo used here, the LUKS box showed up after GRUB disappears (before the fedora logo that fills up appears)
Where in the sequence are you experiencing the slowness?
cheers,
ryanlerch
I noticed that numlock turns off at the LUKS password; a slight inconvenience for me.
I am definitive not in favor of mclasens idea with the spinner. I think Lennart is right, makes no sense to showing something meaningful but the fedora logo right now let you see that it is fast as it indicates progress.
with the other things I am going with.
My LUKS pw box looking different, I would be very happy if it would look like as on your screenshot. Under my box is written for which disc I have to type the pw in. No fun, the name is taken from the vendor ID so its a really long number, breaks also on my widescreen.
+1 for hiding the boot menu by default, with the easy option to access it. If this gets implemented the right way , it would be a great improvement for the casual user especially. But a graphical utility for advanced configuration of the bootloader should be in the cards.
I don’t find the LUKS password entry “confusing” in the least. It’s a single-line text entry field with a picture of a lock next to it (an archetypal symbol that people everywhere will associate with security). If I put myself into the shoes of a newbie, I don’t imagine it will be difficult to understand that this is a password prompt, and I am required to enter the correct password to proceed with booting.
My single biggest gripe is with the weird config file errors. It’s not a show-stopper or anything, but it gives the boot process a very cobbled-together feel, like we don’t quite have our stuff together.
Ultimately, there is no way in heck to make everyone happy, however Fedora Project chooses to move forward. The factoid about vastly different bootup times makes that clear to me. 🙂
It would be nice to put a HDD under the padlock, making it a bit easier to understand the exact purpose of this password.
Also, regarding the outdated F17 bootloader art, I think it’d be best to settle on something that screams “Fedora” across many releases, and doesn’t have to be changed. Pick something cute and blue, and stick with it. 😛
The user whose system can’t boot will be automatically taken to the boot menu.
===
Actually I am not sure how they are going to accomplish that. Many of the times where the system crashes it is before any kernel plumbing (systemd etc) have gotten working. Heck there may not be anything writable at that point that is not scrubbed when you power cycle to get to the next boot. On the other hand I expect that UEFI has some sort of area that can be written to ..
Actually looking at all the long list of things.. It seemed that most of the problems are faults in grub2 that we didn’t have in the redhat/suse super patched grub1 … maybe that should be the first thing worked on? Getting a better boot manager?
“Oddly I can’t link to his post in the devel-list archives”
Check if it was cross-posted to desktop@, as the original mail was (which has unfortunately resulted in a forked thread). Mails that are cross-posted to multiple Fedora lists only get preserved in the archives for *one* list – you have to poke through all the list archives till you find the one it wound up in. (There may be a way to determine which archive a given mail will wind up in, but I’ve never figured it out – maybe it’s whichever list is specified first in the recipient list? First alphabetically?)
smooge: the obvious answer is that you write something in the *success* case, and show the boot menu if nothing’s written.
@Adam Williamson: >smooge: the obvious answer is that you write something in the *success* case, and show the boot menu if nothing’s written.
The thing is: you have to be *very sure* that you really are in the “success case” to write something otherwise the user with a broken machine cannot (or cannot easily) go to boot menu.
Two possibilities of incorrect success case:
1- the display is garbled
2- the login manager crash just after being started (the proposal say: “starting your login manager”).
And there are probably more cases of wrong “success cases”..
(Apologies if this came through twice – feel free to delete. Note to self: allow scripts more often when writing a message in firefox)
– Progress bar in Grub2: I actually forgot about this because of late I typically (for desktop machine) turn the computer on and take care of some other things and only turn the monitor on when I sit down. I can see that this could be confusing to some people though. I guess either do not show it or make it more obvious what it is doing.
– I stopped using Gnome after Gnome 3 was released so I cannot respond about GDM itself. I can say though that I have (possibly) noticed login being slower (KDM). I don’t know if I would say that is the most fair judgement though because I tend to have a lot of konsole sessions open* (as well as firefox, thunderbird and various other programs) when I shutdown and so those load too. As far as the splash/animation on login that seems a bit slower but I never have actually thought much about it (likely because of the fact I have a lot of programs loading).
*I have typically three konsole windows open and one of them has 15+ tabs at times and that is only one of them.
– The kernel entry being in the main menu or not does not really bother me. I also admit I prefer grub by a lot (reason is simply that grub2 has been a real pain at times).
– The other issues (screen flicker, error messages that are nothing to worry about) are definitely not nice but it could be worse (I’ll refrain from mentioning another OS).
Overall, I agree with Stephen about grub2. It seems to have a lot of issues. When I first migrated to grub2 I had a failed boot (I use lvm and raid1 [and now raid5 in addition]) and while I enjoy troubleshooting/etc. I cannot say I enjoyed this incident. I also have seen other issues since then related to grub2. I cannot remember specifics but I seem to remember that related to grub2 ‘s configuration I at one point had to use a boot disk (as in something like supergrub). To be fair I can definitely take some of the blame on the last one – I have been quite unwell (and exhaustion included) and I should have been more alert at the time (even if I was resolving some bugs that were present at the time). But moving from a grub system to grub2 system was not at all fun. And while experienced users (myself included) were able to resolve it I think it would be much worse for the average user that just wants to try Fedora out and has no background with anything related to Unix (read: a huge turn off of further use).
Oh, and as for the word ‘ideate’: Correct, it is a word and it is the root of the word ideation. I am not sure how common the word is in every-day language but it is fairly common in some medical fields.
Please give weight to *likely* use cases (does no one up there have any metrics?). Every single machine of the dozens of Fedora and RedHat installs I’ve done either dual or triple-booted. I’ve *never* done a single-boot install. So please just don’t go there: “They could also modify their grub config file to always display the boot menu.” Unless you just enjoy the reaction F18 anaconda has gotten.
In 2013, dual and triple boot is not a common use case I’m sorry to say. Free and high-quality virtualization is accessible to everybody. If you understand how to configure a triple-boot that involves using Linux, then you understand how to modify a single line in a bootloader conf file.
I didn’t say I didn’t also virtualize. This attitude or yours is a sad harbinger, that people who know what they’re doing are forced into workarounds just because they know what they’re doing. I sincerely hope this dumbing down strategy actually attracts new users.
A harbinger! Oh, my!
I for one appreciate the strategy of putting the non-hardcore first. I am neither average nor Joe, but when I get too involved with computer use, I get headaches and feel bad. I’m happy with this direction.
The biggest issue I’ve had with GRUB 2 so far is the Windows partition no longer being listed after a fresh installation of F18 … which is more of a feature in my case! I don’t miss it!
Mairin, sorry, but I think that is not true. Configuring Grub -especially the mess that is Grub2 – is a big hurdle for someone unfamiliar with the system, but dual-booting users are probably your mainstream-users. Or – hate to question like that – have you data backing up that assumption (that would indeed be interesting for me, it’s a real question)?
As an aside: If i remember correctly, Fedora’s graphical grub-bootloader was something to try to imitate for a lot of ubuntuusers (in my time as a supporter). I’m a bit surprised that “updating the artwork” and maybe “work on having the right resolution as default, if that is technically possible (shouldn’t it be on UEFI-Systems?), to remove the flicker” doesn’t seem to be your focus.
“Configuring Grub -especially the mess that is Grub2 – is a big hurdle for someone unfamiliar with the system”
Um, well, if you’re going to set up dual boot and triple boot, you’re gonna have to learn how to work with the bootloader either way. I’m unaware of a method of multi-booting OSes on a system that doesn’t involve bootloader configuration, are you?
“Or – hate to question like that – have you data backing up that assumption (that would indeed be interesting for me, it’s a real question)?”
Do you have data backing up your assertion? It’s a real question.
“As an aside: If i remember correctly, Fedora’s graphical grub-bootloader was something to try to imitate for a lot of ubuntuusers (in my time as a supporter). I’m a bit surprised that “updating the artwork” and maybe “work on having the right resolution as default, if that is technically possible (shouldn’t it be on UEFI-Systems?), to remove the flicker” doesn’t seem to be your focus.”
I’m failing to glean any significant meaning from these couple of sentences as necessary to respond. Could you try restating your question in a form that I can understand? I know extremely little about Ubuntu users.
“I’m unaware of a method of multi-booting OSes on a system that doesn’t involve bootloader configuration, are you?”
Well, I had to do it when setting up a triple-boot-system with a developer version which failed to setup grub automatically. But apart from that, the Installation of my Linux-system always took care of that for me – auto-detecting Windows and configuring grub accordingly.
“Do you have data backing up your assertion? It’s a real question.”
Only empirically, and a few statements in magazines and websites stating that dual-booting is the most popular setup. I remember all the threads about finally having achieved a familiarity with Linxu to be ablo to no longer dual-boot which popped up in our forum all the time.
That’s why that was a real question: If you really have cause to believe that dual-booting is uncommon now, I’d totally understand your conclusion to hide the grub-menu when the boot worked alright. If not, that seems quite harsh to me, neglecting what I perceived as the majority of Linux users – and therefore such data would be quite interesting, especially if Fedora has a special place there.
“Could you try restating your question in a form that I can understand? ”
Sure. In essence: Fedora having a graphical bootloader was something I, coming from the outside, thought to be cool and know that other thought to be cool (some years ago, granted) and as a big part of the perceived graphical polishness of Fedora – and I wanted to state my surprise given how fast the discussion seemed to come to the conclusion to ditch that asset. Doesn’t need an answer, not a real question, just felt right to mention that.
“Well, I had to do it when setting up a triple-boot-system with a developer version which failed to setup grub automatically. But apart from that, the Installation of my Linux-system always took care of that for me – auto-detecting Windows and configuring grub accordingly.”
You have to do the installations in a very particular order (depending on how ‘friendly’ each OS is to others, the more ‘friendly’ it is the closer to the end you have to install it) and even then this automatic setup is extremely-error prone. I’m guessing you have an older BIOS system and your multi-boots are being configured via MBR? When you upgrade to EFI hardware, any automagicalness you may have been the lucky recipient of in multi-booting won’t work if I understand correctly.
“Only empirically, and a few statements in magazines and websites stating that dual-booting is the most popular setup.”
Citations please.
“I remember all the threads about finally having achieved a familiarity with Linxu to be ablo to no longer dual-boot which popped up in our forum all the time.”
Anecdotal.
“Sure. In essence: Fedora having a graphical bootloader was something I, coming from the outside, thought to be cool and know that other thought to be cool (some years ago, granted) and as a big part of the perceived graphical polishness of Fedora – and I wanted to state my surprise given how fast the discussion seemed to come to the conclusion to ditch that asset. Doesn’t need an answer, not a real question, just felt right to mention that.”
Fedora has never been seen as being more graphically polished than other distros because of its graphical bootloader – we were using grub1 up until Fedora 16 which was limited to a 14 color palette while SuSE and Ubuntu had been using grub2 which offers a full color range for artwork for years before us.
“You have to do the installations in a very particular order ”
Sure, Windows first. I am aware of that.
“I’m guessing you have an older BIOS system and your multi-boots are being configured via MBR?”
Nothing else existed at the time 😉
“Anecdotal.”
Of course it is. But it’s a hint for you: My experience is different than the one you are using as your design-foundation here – but sure, you don’t know me or my background and can’t judge whether that means anything or not (I’m not even sure whether I should trust my experience there when I would try to design such a system). Just wanted to give you a data point in an area i find interesting. Take it or not, ignore it or try to get the data, it’s your call.
“Fedora has never been seen as being more graphically polished than other distros because of its graphical bootloader”
Maybe. It’s possible i mix things up after all those years, or mix the bootloader with plymouth (wasn’t Fedora first in that area?) and so on. But https://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/sn-boot-menu-x86.html, depicting a Fedora 13 beta bootloader (maybe that was never the default?), sure looks a lot nicer than the white-on-black bootloader I’m used to.
“Nothing else existed at the time”
Good luck when you upgrade your hardware.
“Just wanted to give you a data point in an area i find interesting. Take it or not, ignore it or try to get the data, it’s your call.”
The very fact that you gathered this data in a forum full of people interested enough in discussing Linux that they spend significant time there rather than doing other things rather slants the data. Not that I’ve actually experienced the same anecdotally in the forums I frequent – virtualization (mostly using Virtual Box on top of Windows or OS X) is far more common (and much less risky) than multi-boot.
“It’s possible i mix things up after all those years,”
Why are you providing feedback on something in 2013 based on knowledge that old?
” But https://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/sn-boot-menu-x86.html, depicting a Fedora 13 beta bootloader (maybe that was never the default?), sure looks a lot nicer than the white-on-black bootloader I’m used to.”
That’s syslinux. That’s not grub. You only see that if you’re running livemedia or the first time you put the install DVD on the drive. You couldn’t have seen that on boot of an installed version of Fedora 13.
” If you understand how to configure a triple-boot that involves using Linux, then you understand how to modify a single line in a bootloader conf file.”
(Probably splitting hairs here.) I often have Windows, Fedora, and Ubuntu listed in my bootloader. The linux distributions edit the bootloader for me when I install them.
4. It takes too long a time to load the desktop from GDM login. [Ignacio]
I have reported this issue a long time ago: https://bugzilla.gnome.org/show_bug.cgi?id=678221
Mairin, please take a look at the investigation I’ve done here: https://bugzilla.gnome.org/show_bug.cgi?id=645756
I’d be very glad if someone finally looks at this. After GNOME 2’s optimizations in 2005-2006, this issue has stayed mostly unchanged to this day.
Good post.
I’m not sure about postponing the Plymouth splash for 10 seconds. 10 seconds is a long time. Why not 2-3 seconds?
What happened to the various initiatives to have flicker-free boot? I remember blog posts about this, with work going on in KMS driver land to enable this.
I read the original discussion and this post is very impressive – fair, open minded and a really good summary of what I read.
[…] Duffy has put together a lengthy summary of the current discussion within the Fedora project on how to improve the bootstrap experience. […]
the LUKS password should really be the user password, on single user systems. then we could simply move the login earlier in the boot process — like MacOS does with File Vault. no additional passwords to remember, and no additional chances of screwing security up by choosing a weak/shared password because you don’t want to keep two strong ones in mind all the time.
Jef Spaleta suggested the same in the Twitter comments – it is a good idea! The only issue is how to handle for multi-user systems, but I think notting suggested a way to do that in the Twitter convo. Let me try to link to it:
https://twitter.com/mairin/status/311586971258613760
https://twitter.com/jspaleta/status/311600211388690432
https://twitter.com/jspaleta/status/311609691245518848
https://twitter.com/jspaleta/status/311610170008535040
Ugh Twitter breaks threads a lot doesn’t it? 🙁
I respectfully disagree. My LUKS password is a super annoying but secure 17 characters passphrase that I don’t want to type more than a few times a month.
My system’s user password is a much, much simpler and weaker password – because I don’t exactly expect forensic experts to try to bruteforce my lockscreen (the hard disk’s encryption, however, that’s something else) and because I have to type it a dozen times a day just to sudo/deal with packages.
Basically, I consider my machine compromised if they can get through the disk encryption. The system user passwords are weaker because they have to allow some sort of convenience in daily use.
I was thinking similar. The idea that was proposed is more or less the same as using a password on more than one site. The only difference is this would be using the same password for more than one use on the same system. And while the system may be only used by one user (as a person) the fact that Unix and all its derivatives (which includes Linux distributions) are not single user environments suggests that the logic is flawed. You have root, system accounts and user accounts too. So in that case why not have root use the same password as every other password required?
I don’t understand your point at all.
if your user password is weak or simpler than your LUKS one, then in theory people can simply break into your laptop while it’s running, instead of breaking into your disk while not running.
it’s probably better to make your password (or passphrase) secure and ask it once, instead of asking two wildly different passwords; first because *most* people will not use a very secure password if they have to chose two, especially if one of the two is going to be asked relatively less often.
anyway, I’m not suggesting to force this behaviour and never allow selecting a separate password: I’m suggesting to do this stuff as a reasonable default.
That’s not really fair. Breaking into a running system presents other challenges (like rate limiting, lack of exposed services, etc.) which significantly mitigate the risk of brute-forcing. The LUKS password, on the other hand, is the *only* line of defense against someone who has unsupervised physical access.
It’s also worth pointing out that this isn’t just a configuration issue. Password managers (well, gnome-keyring at least) hook into PAM and use your user password to decrypt your keyring, but this doesn’t work with auto-login for obvious reasons. I don’t know about you, but I’m not psyched about the idea of giving user-space programs access to my LUKS password.
FWIW, you can’t find Ignacio’s post in fedora-devel because it only went to the desktop list. The conversation is a little fragmented by cross-posting and then not all members are subscribed to all lists. I dunno, maybe hyperkitty can fix this. 🙂
Oh and I see Adam beat me to this comment. Never mind. 🙂
On F18 (at least I don’t remember seeing this on <= F17) the LUKS prompt also times out after a while (several minutes) and the system boots a recovery console. If you reboot the computer then go do something else you end up coming back to a recovery console with no explanation of why, which can be quite confusing if you don't know what's going on. My father encountered this issue a while back and thought his computer was broken.
I don’t know if Virtualbox is partly to blame here, but I installed an F18 guest and noticed something (it was pretty obvious once it dropped to a root shell, but still):
The luks password box can be in the wrong keyboard layout. I asked the system to be Dvorak at install time, and the display manager and desktop were both Dvorak; but that password box was still US (qwerty). Which makes it really hard for me to type long passphrases at speed.
[…] Duffy has put together a lengthy summary of the current discussion within the Fedora project on how to improve the bootstrap experience. […]
[…] from replies to his email, responses have also come from Ryan Lerch and Máirín Duffy. The email replies, the articles by Ryan and Máirín, and the comments in those articles have all […]
So I think one of the absolutely worst offenders in the boot process is the little thing that happens to mean at least 1-2 times yearly. And that is unlcean unmount leading to being dropped into a shell telling you to run fsck on some device where it doesn’t tell you even what device it is. Imagine a user that is confused at the LUKS prompt (orders of magnitude less confusing) being dropped at this.
I’ve filed several bugs about this, but it never ever is addressed and the bugs get closed and ignored. Because apparently it “isn’t supposed to happen”, though it does (due to either kernel, hardware, or other bugs, or unsafe handling of the laptop battery, and happens all that more frequently with LUKS). It’s basically a bricking the box for a non technically savvy user.
The check could be done semi automaticallly in a far more user friendly way. See how windows has done it for ever. It might look scary, but people will get through it. But for example my wife (and it happened several times to her on linux) can’t get through it so it always requires me.
[…] sure, Fedora 19 will look awesome & beautiful. We’ll have an awesome default wallpaper, a reworked boot process, and a guaranteed nice set of supplemental […]
I like how Máirín has broken the issues down into digestable bytes. I see a lot of good suggestions which, overall, I am in favor of. I especially like what Peter Jones wrote.
The gnome 3 desktop has been loading fairly fast on all the machines I’ve used or tried fedora 17 & 18 on. Although, I suppose there is always room for improvement. In general, if changes are made that improve overall performance without unpleasant side-effects (potentially subjective, admittedly), I’m all for that.
Marius Gedminas makes a good point regarding Lennart’s plymouth 10 seconds suggestion. People don’t want to wait to see a progress indicator, they want to see how fast their machine is progressing right now. Maybe give power users with super fast machines the option of optimizing their boot time even further by completely disabling all boot messages and graphics, which would otherwise be too transient and unnecessary for their purposes.
I couldn’t agree more with the importance of the whole “professional” and clean look, especially during boot. I might also add during shutdown, as well. My thinkpad displays service shutdown messages that aren’t even left-justified on my screen during shutdown, albeit relatively briefly. Not having the screen flash, performing smooth transitions, not displaying text (potentially confusing or otherwise), cool looking graphics. Most would agree that these things are quite important. Like andrew89 said up above, pick something good and stick with it. People tend to gravitate towards consistency, especially if it’s consistently good / nice.
I don’t currently have a problem with the LUKS password box as it stands. However, if it can draw a lock, I suppose drawing some concise, explanatory text could also be helpful.
My primary problem in general with fedora over the years has been, and continues to be: breakage, regression bugs, and unnecessary changes that amount to steps backward just for the sake of change. The kernel update breakage issue touches on this as an example, but the whole topic will be a rant for another day. Sorry if this comment got too wordy.
You assume the user space starts at all when a kernel breaks. That’s a step too far.
I agree with Glen here.
Not only that but its possible for the user space to load and be inaccessible still.
Also how does one reset a root password on a server if the kernel options can’t be modified without attaining userspace access to reboot into a grub menu?
The grub 2 error that quickly flashes in fedora 18 can be fixed by running this command:
cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub2/locale/en.mo
(taken from the arch wiki beginner’s guide, and slightly modified to work on f18)
Wow.
Now that is what I call an extremely well performed analysis of the problem.
This is going to be my default example to show to future project managers and developers as the kind of excellent analysis they should be aiming for.
I love the idea of the fantasy user that would know exactly how to use the bootloader menu if only he/she knew how to invoke it.
Seriously?
Isn’t that the first, and simplest thing you learn about such things?
After reading a number of comments that seemed quite hostile to the f18 installation process, I brought up 18 in a VM and thought the install quite enjoyable compared to 16 and earlier. I was pleased to find it easy to not install LVM, which is extraneous in a virtuall machine environment.
So, please allow me to thank you for improving my favourite operating system’s install preocess.
Regards,
Jeffrey Marans.
What about “single user” ? I know whenever the system can’t boot fully because either kernel problem, problem with Xorg or DDX causing system issues, where I boot into single user mode, use yum to rollback a RPM for example.
As long as we can edit the grub2 menu options as normal.
I would like to add that the case where Fedora is the secondary OS needs more consideration.
With the above proposal, if the boot menu is hidden and another OS is the main booting OS, how will the grub settings be changed to boot Fedora?
(So some (secret) keypress combination would be appreciated.)
This is a likely case for someone just dabbling in Linux and wanting to learn without moving over to it completely, but once the person has set the default boot option to another OS, unless the person has specifically also allowed for the boot menu to show, it would be as good as Fedora not being installed.
For the long/short boot times maybe on first boot have systemd-analyze running and if total bootup time on first real boot (not firstboot) is less than 5 seconds then totally disable plymouth?
Otherwise other users will see no input for 5 or even 10 seconds and have plymouth popup for the last 6 seconds of boot.
I find it interesting that your problem definition omits the single biggest problem with the Fedora process, that being the complete lack of information being shown to the user. Showing a progress bar in the form of a slowly revealing Fedora logo is braindead beyond belief. It’s sort of fine when it works, but about as bad a UI experience as I can imagine when it doesn’t.
I’ve seen the boot hang at just a blue background screen with a splodge in the middle. I’ve seen it hang with a partially filled in splodge (usually due to sendmail starting slowly, FWIW). In neither instance is the user shown anything. No indication of what’s hung. No indication that anything abnormal has happened. No indication of how to find out anything more. I’ve seen this problem manifest many times on many different machines, and confuse several users. Apparently, when something doesn’t work as expected, it’s supposed to drop back to the text bootup screen. I’d say this only happens perhaps 1 time in 3 when there’s a problem with the boot process. The rest of the time, the screen just hangs leaving the user tearing their hair out.
IIRC correctly, I logged a bug about this ages ago, but I’ve pretty much given up on doing that these days, as the Fedora project doesn’t seem interested in fixing the vast majority of problems with the distribution. Sadly, I’m actually being serious about that, and I don’t believe it’s just a manpower problem. I think there’s something fundamentally wrong with the mindset of the project 🙁
[…] v zápisku Improving the Fedora boot experience. Původní diskuse v […]
12. The LUKS password box is confusing. [Mirek]
Capslock state indicator would be very nice to add, both during the boot process. Additionally, during an install, when setting up LUKS. Having a netbook, which lacks a capslock LED indicator, one can easily arrive at the point where the wrong case of a password may be entered.
Fedora 19 does appear to adopt the mobile mindset of displaying the password, one character at a time, which might be a viable alternative.
Other distros appear to be able to move smoothly from GRUB2 to Plymouth to GDM/KDM without mode switching, or at least without mode switch flicker, as long as GRUB, Plymouth and the display manager are all running in the same mode. The problem is solvable.