Graphical Boot and Live Images

One of the goals for Fedora 10 is to replace the aging rhgb that has been used for graphical boot since Red Hat Linux 8.0. rhgb is implemented using an X server which started in rc.sysinit relatively early during the boot process and then some feedback is provided to the user. With some of the improvements underway for Fedora 10 we should hopefully have kernel modesetting in place at least for some drivers which will let us set a native resolution graphical mode as opposed to requiring either text-mode, an X driver + server or the use of a framebuffer.

Given this, enter plymouth — a new graphical boot implementation which will be taking advantage of that infrastructure. And since we don't need the X server or anything that's really complicated, we can even include plymouth in the initrd and provide that nice graphical experience earlier in the boot process. The bits landed for the regular initrd a couple of weeks ago and I finally got around to looking at integrating things for the live initrds the end of last week and finished it up yesterday. So now, we should have the new graphical booting hotness for livecds as well. And once the kernel modesetting pieces land in rawhide (I'm looking at you krh :-), that should be easily hooked up also making things quite nice in time for the Fedora 10 alpha.

Now on to the next thing on my todo list…

7 thoughts on “Graphical Boot and Live Images”

  1. My $.02

    I don’t think it’s a good idea to dump RHGB – X server supports far more hardware than kernel/Plymouth will ever be able to support.

    And I don’t believe open source ATI/NVIDIA will catch up their hardware counterparts in the nearest future.

    That’s all just my opinion. I just don’t want Fedora 10 to be as broken as Fedora 9 (where KDE 4.0.x – is the culprit).

    // Artem S. Tashkinov

  2. Re: My $.02

    There’s a fallback to a text-based graphical boot which will support even more hardware than X 🙂 And there’s always the “no graphical boot at all” option.

  3. Re: screenshots and videos

    I don’t think this is that simple. If kernel modeset is required for this new graphical boot this will mean it will be opposed to the user after the boot process and still the modeset is not perfect, for one on i965 (which should be supported really) some corruption of the screen is observed when composite is used ( with compiz and with metacity composite) while both (compiz and metacity with composite) work fine without the kernel mode set. So leaving pretty much all users who demand stable X environment with text boot is probably not such a good idea.

    btw the corruption I mentioned is in f9 updates, not in rawhide, if the modeset is to be considered stable for f10 then I think it will be better to try this new thing so more ppl can tests it on more hardware and for f11 hopefully it will be working:)

  4. Re: screenshots and videos

    The goal is that we shouldn’t have regressions in functionality between modesetting and not. Unfortunately, the code that went into F9 was a bit … early. And there’s been a pretty significant overhaul since including switching out the memory manager.

    krh is working on getting an updated patch so that we can start getting it tested and thus get the problems ironed out sooner rather than later. And by making it the default path, it’ll help us to find things.

  5. What is the current status on this? I read that users are currently not able to easily test this. I have tried out kernel modesetting and I am keen on giving plymouth a whirl (Besides, I am too impatient to wait for F10)

    Finally, where can I run to for help if I have some issues in setting up plymouth along the way?

Comments are closed.