Jon Nettleton wrote:
I just read somewhere somebody saying that rhgb was a horrible idea and that a nicer boot process will come once kernel mode- setting exists. Funny how some things kick your brain in such a way you actually look at things a little different. This was the kick I needed after staring blankly at my bootlog charts trying to figure out how to shave more time off the process (I have maxed out at 40 seconds). My problem is that you have to take the speed hit of starting an X server eventually. Kernel modesetting just isn't going to help that. Well then all the pieces fell together and this is what I have hacked together so far. 1) Add an option to rhgb so it doesn't fork and daemonize 2) patch /etc/gdm/Init/Default so it checks that rhgb is executable and the file /var/lock/subsys/rhgb doesn't exist. If those two qualifications are true then run rhgb -n -f -u :0.0 3) modify rc.sysinit with the gdm-early-login patch, so gdm is started right after the root filesystem is mounted rw. What this gives me is boot up, as soon as / is rw start up gdm. Gdm starts rhgb using it's own X server. As soon as rhgb is done gdm launches the greeter using the same X server. No flashing or switching back and forth to consoles, etc etc.
Sounds very cool to me.
What the next step is to make this really slick. 1) Get these patches into the kernel http://fedoraproject.org/wiki/StatelessLinuxCachedClient 2) have mkinitrd make a small writable snapshot of / ( this is needed for gdm to start). 3) Have the entire rc.sysinit run using a rw snapshot.
If I understand this correctly, it would require that the rootfs have a devicemapper layer of indirection.
If you can somehow convince fedora/rh to do this, I would be both impressed and appreciative.
The "rebootless live media installer" that I posted a few weeks back utilizes this as well, although after booting the livecd, and installing (i.e. live migrating) to disk, when the user reboots, the devicemapper layer of indirection is removed so that the system is completely normal.
In my own tests, I have not yet noticed a (serious?) penalty for having an extra (linear) devicemapper layer of indirection on the rootfs or elsewhere. (though the complexity of such devicemapper tricks seems to be slowing down review and acceptance of my turboLiveInst patch which improves livecd installer speed by ~20%).
Another reason I would love it if the rootfs was permanently a devicemapper layer (even outside the LVM case), is that it would allow you to at any point in the lifetime of a system, to either live migrate it's rootfs to another disk, or just raid1/mirror-ify it live.
4) After all the fscking and such is done use the above patch to merge the sysinit snapshot back down the actual filesystem 5) continue the init process. This shaves the other 10 seconds I needed off my altered boot process to get a 30 second boot time on my desktop. However those changes are for another e-mail ;-)
I actually have a plan (coming in a future email) to cut the boot time of the f8 livecd in half or more, and that plan might also be able to shave a few seconds off of normal disk boot time as well. Maybe we are thinking of the same thing ;) We'll see what my and your other e-mails look like ;)
-dmc
I would love to hear any comments, or criticisms of this method for graphical booting. Jon
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
