rhgb and gdm-early-login two great tastes?

[Douglas McClendon]

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
> 
>