Bug 151952

Created attachment 112277 [details]
proposed patch  v1

OK, comments:

What's with console_show and console_hide? There is no bootsplash yet. :)

/tmp/.prefdm-started is such a hack. The display manager should really have
some sort of 'exit-quietly-if-already-running flag'. Moreover:

+if [ -f /tmp.prefdm-started ]; then
+    exit 0
+fi

This will get respawned every thirty seconds :/

...
 exec kdm $* >/dev/null 2>&1
 exec xdm $* >/dev/null 2>&1
 
+rm -f /tmp/.prefdm-started
+
 # catch all exit error
 exit 1

This doesn't catch the case where the display manager runs-but-fails.

Not sure why your a)-d) sequence says it's screwed on a network mount
any more than 1)-3) does. In either case, it will break horribly.

I don't like randomly starting services X,Y,Z from inside another service's
startup script. This should be done with dependencies and ordering. :)

(Oh, and hardcoding a start of acpid is crack - think other platforms.)

> What's with console_show and console_hide? There is no bootsplash yet. :)

No, not yet, but likely to get done for fc4 (gentoos bootsplash impl is good and
mainline seems to like it cf. lkml)

> <stuff about prefdm hack>

Sure, do you have a fix for this in the FC4 time frame?

> Not sure why your a)-d) sequence says it's screwed on a network mount
> any more than 1)-3) does. In either case, it will break horribly.

The idea is that start-desktop-services will check if /usr is mounted (by e.g.
checking that /usr/bin/gdm is available). If it's not we just fallback to normal
init scripts. So, how 1)-3) breaking as horribly as a)-d)?

> I don't like randomly starting services X,Y,Z from inside another service's
> startup script. This should be done with dependencies and ordering. :)

The very way initscripts works today is already crack :-)

> (Oh, and hardcoding a start of acpid is crack - think other platforms.)

We don't do anything else for other platforms in the default install apart from
maybe apmd; just add this to the hackisk initscript that I've proposed.

Eventually HAL will take care of this, we just need to port the UI stuff over to
it (and I may have a patch for battstat applet for the FC4 time frame).

I'm not attached to this patch at all, if there is a better solution go ahead
propose it. But I'd rather put this FC4 than not doing anything at all.

OK, some other questions:

- How well tested are the various desktop components for
start-before-various-services? (Things like cups-config-daemon before cups,
network shares in nautilus before network, etc.)

Re: bootsplash - cc'ing davej for his opinion. :)

As to when it starts, I think we should probably shuffle some other services
around, and not necessarily have this one be first. In particular, it should
come after syslog.

> - How well tested are the various desktop components for
> start-before-various-services? (Things like cups-config-daemon before cups,
> network shares in nautilus before network, etc.)

Not sure about the cups (mclasen?) but nautilus/gnome-vfs should be good without
network.

> Re: bootsplash - cc'ing davej for his opinion. :)

FWIW, I've already talked a bit to davej about the bootsplash. Another thing is
that this is not really something that this bug is dependent on though.

Homepage for fbsplash is here: http://gentoo-wiki.com/HOWTO_fbsplash
Patch for 2.6.12-rc1: http://dev.gentoo.org/~spock/projects/gensplash/current/

> As to when it starts, I think we should probably shuffle some other services
> around, and not necessarily have this one be first. In particular, it should
> come after syslog.

Certainly. I'd love to completely revamp how booting works but until now the
attached patch is my best bet. I'm positive that there is a better way to do
this, I just sent a patch to get the discussion going.

David

So I have a few comments:

* This should all be optional (and off by default) for FC4.  I think around FC5
we can talk about making this on by default and integrating a boot splash, etc,
for the more complete solution.  Probably the easiest way to make this optional
is by making it depend on a "early-login" kernel command line option or
something.  If early-login is set then rhgb doesn't get run and gdm gets started
earlier.

* The general flow of things during early-login should be: start services gdm
depends on (syslog, xfs, etc) -> start gdm in --wait-for-bootup (block login)
mode -> start services the user needs to be able to login and have a working
desktop -> tell gdm that the user is allowed to login -> start services that the
user doesn't need right away. 

* In the near to middle term, networking should be a service required to be up
before login is attempted.  We don't want to try to authenticate over pam when
the network isn't up.  It will just block and break things.

* gdm shouldn't be able to be run twice.  In the early-login flow it's going to
get invoked twice.  Once right before most of runlevel 5 is started, once right
after runlevel 5 is started.  /usr/bin/gdm is actually a shell script that
invoked gdm-binary. We can make it exit if gdm-binary is already running to
guard against gdm being started more than once.  

* The problem with the above is the init table has gdm set to respawn on exit. 
Bill, do you know the reasoning behind that?  GDM already respawns the actual
login processes itself, so afaict, the only advantage respawn gets us is
protection against daemon crashes.  If that's all we're after, we can add some
foo to /usr/bin/gdm to handle restarting on crash.

So, what I think needs to be done to make this all work:

1) hack up /usr/bin/gdm to exit early if gdm-binary is already running
2) hack up /usr/bin/gdm to restart gdm-binary if gdm-binary crashes
3) modify /etc/inittab to not respawn gdm automatically
4) sprinkle some if !strstr $cmdline "early-login" ... in /etc/rc.sysinit to
disable rhgb if we're in early-login mode.
5) create a /etc/init.d/gdm-early-login script that gets started early on in
runlevel 5, just after xfs and syslog.  This script would start gdm in a
restricted mode that allows the user to type a username and password, but
doesn't actually authenticate those credentials until given the go ahead.
6) create a /etc/init.d/gdm-allow-login script that gets run after essential
services for a functional desktop have been started.  It would basically just do
echo "BOOTUP_COMPLETE" > /var/gdm/.gdmfifo, so that gdm won't block the user's
login attempts anymore.

A few points:
- I vaguely remember hearing somewhere that starting gdm in an initscript (like
I mention in 5) is a bad idea.  Bill, do you have any idea what sort of problems
it might cause that we wouldn't have if we started gdm in inittab?

- We probably should dump prefdm, kdm, xdm, etc, and just use gdm.  I don't
think we gain much by having 3 display managers in Fedora Core.

- The list of "essential services for a functional desktop" mentioned in 6 can
be "all services" for now and we still get a considerable boot time improvement
because we don't start two X servers. Also, the apparent boot time drops, too,
because the user sees the login screen sooner.

(In reply to comment #6)
> * gdm shouldn't be able to be run twice.  In the early-login flow it's going to
> get invoked twice.  Once right before most of runlevel 5 is started, once right
> after runlevel 5 is started.  /usr/bin/gdm is actually a shell script that
> invoked gdm-binary. We can make it exit if gdm-binary is already running to
> guard against gdm being started more than once.  

gdm-binary *already* exits if there's one already running, as far as I know. I
don't think any additional code is needed here.

> * The problem with the above is the init table has gdm set to respawn on exit. 
> Bill, do you know the reasoning behind that?  GDM already respawns the actual
> login processes itself, so afaict, the only advantage respawn gets us is
> protection against daemon crashes.  If that's all we're after, we can add some
> foo to /usr/bin/gdm to handle restarting on crash.

I belive the other display managers may not have the same behavior.

Also, there are cases (relatively often) where on an X server exit, gdm
doesn't properly respawn it, and you have to whack gdm-binary by hand. I
suppose that's a gdm bug. :)

> A few points:
> - I vaguely remember hearing somewhere that starting gdm in an initscript (like
> I mention in 5) is a bad idea.  Bill, do you have any idea what sort of problems
> it might cause that we wouldn't have if we started gdm in inittab?

All VTs must be initialized before the DM is started, otherwise,
there's collisons on which VTs it uses before X.

This is actually a non-issue since we have to init all VTs early in
rc.sysinit b/c of unicode.

> - We probably should dump prefdm, kdm, xdm, etc, and just use gdm.  I don't
> think we gain much by having 3 display managers in Fedora Core.

He. He. He. Oh, that's gonna be a fun one.  I'm assuming that gdm's network
support is up to snuff these days?

> gdm-binary *already* exits if there's one already running, as far as I know. I
> don't think any additional code is needed here
Ah yea. Okay that problems solved.

> I belive the other display managers may not have the same behavior.
We can still remove respawn from inittab and add the restart-on-crash behavior
to /etc/X11/prefdm instead of /usr/bin/gdm then.  One downside to this is we
have to keep prefdm in memory.

> I'm assuming that gdm's network support is up to snuff these days?
No clue.  There was an issue fairly recently with it not using the correct
address from xdmcp packets so it was breaking accross NATs.  There are probably
other issues with it.  Maybe we should just keep the other display managers
around for now.

so, we have a little dependency problem with gdm, syslog and network.

syslog is started after network (presumably for remote logging scenarios)
gdm needs syslog
we really want to start gdm before the network is up

The syslogd man page talks about retrying if it can't resolve a hostname for
remote logging, so I did a little experiment with remote logging today. But either 
I am doing something wrong, or syslogd is not very tolerant to flaky networks.
When I started syslogd before network, I could not get any remote logging to
happen. Event kill -HUP did not change this. 
When I started syslogd after network, and then stopped the network, logged a
bit, and turned the network back on, syslogd did not start remote logging again
until I sighuped it. And it did not try to deliver the messages which were
logged while the network was down.

So it appears that in remote logging scenarios, there is no way to start syslog
before network, and have it start remote logging once the network becomes
available. The only option would be to restart syslogd once the network is
available, to switch from local to remote logging.

Or maybe I am missing something.

I suspect that syslog code is dumb. It's pretty ancient, after all. I wonder if
newer logging daemons handle this better.

Created attachment 112600 [details]
initscripts changes to support early-login

here's a patch for initscripts that:
 - disables rhgb if early-login is passed to the kernel cmdline
 - changes the init table to not respawn prefdm automatically
 - change prefdm to respawn itself automatically
 - change prefdm to exit early if in early login mode and gdm is already
running.

Okay so for this to work we also need at a minimum to start xfs before
gdm-early-login.  For testing, i've put syslog at priority 7, xfs at priority 8
and gdm-early-login at piority 9.  Since network syslog breaks if we put it at
priority 7, maybe we should just live without log messages for now until syslog
can be fixed/replaced.

So for now let's just get xfs changed.

Assuming we get everything to work, any reason we shouldn't set this as default
and retire rhgb for FC4? I know that our X guys really want to see rhgb gone as
having two X servers at the same time messes with the hardware.

As a non-developer and not knowing if this is relative or functional, but what
about using GDM (or another boot splash) to start as a boot splash *without* the
login fields, until it's ready for a login?  Or is that basically what is going
on now with rhgb + gdm?

Hi Mike,
One advantage of the new approach is that the user can type in their login
information early, walk away, and gdm will log them in when it can.  If we don't
show the login fields then we lose that feature.

rstrode,

I read mike's comments differently to you (I think)

What it seemed to me that Mike was suggesting was that on start-up (for runlevel
5) you would see the gdm 'view' instead of the rhgb 'view', except that there
would be no login fields.

However, at such a time that the use could log in, the fields would appear
(perhaps fading in to look really sweet) and the user could log in while the
rest of the initialization continued on in the same window.

Given that the rhgb view really is just a small box with start up status, it
could be easily merged into the gdm style display and offset to leave room for
the login fields to appear.

Some though about how to handle 'more information' about the boot process would
need to be done, but I'm sure that again, this could be merged into the 'gdm'
style display (perhaps by leaving some space down one side of the 'console' view
for the time, login fields and other stuff.

Rodd...

Correct, that is what I was suggesting.  If they need to wait until a certain
time, due to certain services to start before logging in, then what will display
until that time and what will it do?

So if you go by what your doing now, rhgb then gdm, why not just change rhgb
bootsplash to gdm's with out the login fields until the login is ready?

Basically, you reboot/start up computer, go to grub, then straight to the gdm
interface (minus the login), then the login fields appear (however that will
be), where the user can login.  Maybe during the intial gdm bootsplash (without
the fields), there could be a small *something* that shows the system is booting
up until the login is ready (such as a fedora circling or turnning a 360 or
something).

Anyway, I think you get my drift hehe.

Ok, I followed your instructions on testers-list and rebooted.  Didn't receive
any errors during the new early login procedure :)

Only thing I saw, as stated in my last post, is you see the initial process
start up, up until the network service (I think) then the gdm starts, login,
then see the message bout starting up and not doing anything or whatever until
finished.

What I would suggest, is the gdm bootsplash to start up sooner even without the
fields, or however you want to do it.  Then once you get the fields, login, then
instead of the message, maybe the fields disappear and it tells you "Login
process initialized....", or "Loading system settings/services/whatever...." and
maybe something showing the system is working, like blinking lights, rolling
round circles, lights or something going back and forth (left to right, right to
left) or whatever to show progress? (Hrm, just thought, think some of my ideas
are from how XP starts LOL, obviously we would want to be diff/unique though)

Sorry if I'm being picky, not trying to be.  Just trying to help in whatever way
I can and so far your on the right track and it looks great.

In lieu of Comment #16 and Comment #17, please consider the following musings  
about this posted in January: 
https://www.redhat.com/archives/fedora-devel-list/2005-January/msg00531.html 

Hi Mike,   (reply to comment #17)

rhgb was created for a few reasons.  It was created to make the boot
process look more professional and visually attractive, and also
to speed up the boot process a bit.  It was a first stab at making
the userland side of OS startup look more appealing to the masses.

rhbg did succeed in making the bootup much more asthetically
pleasing, but it created some problems of it's own which we needed
to solve.

One problem is that it started the X server right after init, prior
to filesystems being mounted read-write.  This is a problem because
the X server requires read-write access to the filesystem for a
certain few things to work properly.  This and other reasons mandated
that once rhgb was done, it would have to start the second "real"
X server after the system was up and filesystems mounted read-write,
so that normal system operation and X would function as expected.

Initially rhgb started the second server sequentially, but shutting
down the first server, then starting up the second one as soon as the
first one exited.  This created ugly video mode switch flicker as the
one X server restored the state of the VT back to text mode, exited,
and the second X server started up, and reinitialized the graphics
hardware back into a particular video mode again.  This display flicker
was declared to be unsightly, and in need of removal.

Various options and ideas were explored for removal of the flicker,
but most of them ended up requiring rather large design changes to
the X server and/or kernel which would be far larger redesigns than
the problem warranted spending time on.  A simple solution was needed,
and so rhgb attempted to solve that problem by starting the second
X server on a different VT, before the first X server died.  That
way, a single VT switch would occur from one server to the other,
and there would be much less flicker.  It's important to realize, the
number one goal was to remove the flicker.

The problem with this solution, was that XFree86/Xorg does not
really handle having 2 or more X servers running at the same time
on the same video hardware flawlessly.  It works on some hardware,
and not at all on other hardware.  It introduces a whole new set
of race conditions and problems that would never occur if only a
single X server was ever started.  Upstream X server and driver
testing does not generally test multiple X server invocations on
all hardware, so it is not a recommended thing to do if stability
is desired.  It may or may not work, no guarantees, but risks of
instability are definitely higher if running more than one X
server.  While that was known at the time, it was decided to take
the risks and find out if it would prove to be stable enough.

After doing this, several issues were shown to exist when multiple
X servers were started.  Over time it has been shown that the
increased instability on many systems, in particular Intel i8xx
systems makes starting multiple X servers simultaneously a generally
bad idea.

Additionally, rhgb actually causes bootup time to slow down
significantly.  Disabling rhgb may actually speed up bootup anywhere
from 10 seconds to 60 seconds or more on a given system.  Since
rhgb intends to make the startup process look nicer to make the
wait less unpleasant, it doesn't make sense for it to also make
the wait take 3-5 times longer.  ;o)

Rather than making kludges to rhgb and/or the kernel and/or X to 
hack around the problems that arise, we decided to take a few steps
back and look at the goals that we want to accomplish again.

- make all aspects of boot time faster
- make boot sequence from grub up until gdm login screen look visually
  appealing and professional, with no unappealing artifacts or glitches
- be user friendly, providing indication to the user that something is
  happening while they wait, perhaps providing status of some sort

There are probably other goals as well, but these are the ones I
remember.

Since gdm has to get started anyway (or some other dm, but we'll use gdm
for the discussion anyway), it would be nice if we could start both the
X server and gdm as soon as possible in the boot sequence and then just
keep them running after that for the real login to use.  This eliminates
a lot of wasted time starting up another server, switching between them,
etc.  It also eliminates the various overhead of starting up everything
rhgb needed to run, thus cutting down boot time significantly.

I think it's safe to say that most users would rather have their systems
start up in 5 seconds with boring but pleasant looking screens, than to
look like a Pixar movie but take 3 minutes to start up.  ;o)

So now we've decided that the idea of rhgb was worth the time to explore,
and learned some things from the experiment, and are now evolving to the
next experiment.  ;o)

Both gdm and the X server need some enhancements for it to work as we
think we'd like it to, and over the next few OS releases we'll be trying
to get things working in this direction.  Since the X server and gdm
both have to run anyway eventually (in runlevel 5 anyway), by eliminating
other extraneous processes, we simplify things, and hopefully end up
with a more robust solution in the end.

Hope this helps understand the evolution of boot time graphical
startup a bit more.  ;o)






The reason for getting rid of rhgb, is because it is a suboptimal
solution to various boot time problems, and it actually creates some
new problems which are difficult and complex to solve.

rhgb runs 2 X servers, either sequentially, or starting the second
one while the first is still running.

The original rhgb did this by running 2 servers sequentially, which
caused an ugly display flicker in between the time the one server
shuts down (from running on read-only filesystem) to the time the
next server starts up on read-write filesystem.  The elimination
of that flicker was considered a critical thing to resolve for
FC3 for asthetic reasons.

TX servers at the same time, which is a very bad idea as has been shown.

H!!!!! (had to do it hehe).

I understood and partially knew all that, and thanks for whatever parts I didn't
already know :)

As far as gdm/rhgb or anything else, it doesn't really matter to me that much. 
Ok a tad, but nothing major.  The main thing is that this is a system that is up
and ready to be played/worked with, with no errors, and to be in that state as
fast as possible.  Whatever it takes to get there and how it looks isn't as
important.  As long as that is realized, then the rest is gravy.

So my suggestions/comments are to help in whatever way possible.  Whatever you
all agree/get to work, I'm all for it, and am sure it will get tweaked/changed
for the better as time/releases go on.  (In case my reasoning didn't go through,
in summary it's, I'll test/report bugs/suggest/comment on it as it goes, and
whatever is decided works for me (I'm for nor against it, just like trying to
help in whatever little way I can).

Anyway, hrm, now where do I file those bugs hehe :)

Oh yea, I did discover one bug up to this point.  If you select auto login, it
does do it, but only shows a blue background screen and no writing or anything.
 Then as it boots on up and you get to your gnome desktop, I noticed my desktop
background (connects to a file via nfs mounted dir) wasn't there.  I had to
logout and back in to get it.

Hope this helps.

Hi Mike,
Thanks.  I was just talking with Matthias yesterday about how we didn't think
about the autologin case.  It's nice to know that that's something we need to
investigate more.  

Comments on Ray's patch:

- rc.sysinit part is fine, although I'd prefer rhgb to die sooner rather than
later :)
- prefdm has some problems:

  1) it assumes gdm for early login, it should probably have cases for all three DMs
  2) can't use which (adds a dependency, which ends up causing a RPM dependency
loop)

- inittab part is incomplete, it needs a mechanism to add this on update in
%post (yuk)

Created attachment 112997 [details]
newer version of the patch

This (theoretically) does something sane with xdm/kdm, and handles fallbacks
without which. Might even work - untested here.

I was asked (a few weeks ago) to comment on a problem that will arise:
With GDM all over the display, how do you see if a service etc. fails? Will it
fail silent (bad)? What if the failed service is vital to the GDM login working?
(say, how can GDM ever login over a network if the network cable is loose? How
can you tell? Waiting and guessing (the way to diagnose "network link OK, but no
DHCP" in Windows is if it hangs at the "welcome" screen... RH Linux also hangs a
long time during bootup, but it acctually *tells* you)?

Which brings me to another problem (a bit off-topic, but anyway...) - if there
is a loose network cable, how can a *user* (no root involved) easily fix this
without rebooting? netplugd isn't really configured "on" by default - should it,
or is it the admin of such a network's responsibility to activate this service?)

You probably want to put yourself on the CC lists of bug 154423 and bug 154425
to watch our progress wrt to feedback about the boot progress on the login screen.

For me gdm doesn't seem to care about the allow-login stuff, it logs me in even
if gdm-allow-login isn't run. I have gdm set to login me automatically upon
bootup, I guess this is a special case that needs handling in the gdm patch?

The latest gdm in rawhide should handle early login for automatic logins as well,
by showing a wait cursor and the blue background until it gets the allow-login
signal. 

Ok. I'm not much into these things, so I hope this isn't too obvious to everyone
else here, but why don't just copy code from rhgb to the gdm-early-login-patch
so that the early-login-mode shows the same information (and in the same way) as
rghb does?

(In reply to comment #30)
> Ok. I'm not much into these things, so I hope this isn't too obvious to everyone
> else here, but why don't just copy code from rhgb to the gdm-early-login-patch
> so that the early-login-mode shows the same information (and in the same way) as
> rghb does?

That would more or less defeat the purpose of removing rhgb to speed up
the boot process.  

rhgb was brought to life originally mainly for the goal of making
the init part of the boot process more visually attractive, and one
of the reasons for that is that it takes a fair amount of time to
boot up, so making it prettier would lessen the amount of time spent
in text mode waiting for X to start up and do something.

It was a useful experiment.  One of the lessons learned is that doing
what rhgb did, actually slowed down the boot process significantly
to begin with.  Slowing the boot process down with unnecessary
graphics is rather counter to the goal of making the boot process
as fast as possible.  Taking the code out of rhgb that did this,
(all python I believe) and putting it into gdm (all C I believe)
seems rather at odds towards the current goals of getting the system
up to a login as fast as possible, and getting the running desktop
up as fast as possible.

rhgb is basically dead code at this point.  I think it is best to look
at the specific goals for boot time initialization, and focus on each
goal one at a time, finding the best solution for each problem that
arises, and keeping the long term strongly in mind.  Short term hacks
that cause dramatic performance slowdowns should be avidly avoided.

Ultimately, it would be nice to have no progress meters or indicators
at all because the system starts up so fast that such indicators don't
have any useful purpose.  If your system could start up in say 5 seconds
to an X desktop, wouldn't that be superior to graphical progress meters
and other eye candy slowing the system down and taking 40 seconds to
start up?

Microsoft does this fairly well currently and in many cases can get
the full desktop up and running after BIOS POST in 5-10 seconds, with
nothing more than a pulsating palette rotation or similar.  I think we
could do the same or better, and I hope we get to that point by FC5
or so.  ;o)

So there are still a number of issues that didn't get resolved in time for
test3.   This means that it is very likely we won't be shipping early-login by
default for FC4.

Update: xfs starts up now at level 8 in 6.8.2-29

Mike: that just broke anything with nfs /usr. :)

The better fix would be to build the fixed font into the X server.

Bill:
That sinks a nail into things.


Matthias:
What metric are you using for "better"?

We need more than just the "fixed" and "cursor" font to have a working
system however, as people expect core fonts to work, and to have more
than one single crappy font available.  ;o)

More importantly, very large important customers have ancient
applications that use core fonts which they expect specific
fonts to always be there and work.  If we only provide "fixed"
font, then we'll receive massive number of bug reports from every
person who has any reliance on apps that are dependant on the core
font system.

While KDE/GNOME use Xft now, core fonts may not be the choice API
for new development, but there is 15 years of established X11 apps
out there that use the core fonts system, and it'll be years before
they vanish.  So we need to make sure we don't regress the core
fonts system if at all possible.

If we have a secondary initscript which connects the running X server
to an xfs that is started later on, perhaps that might work.  Perhaps
gdm's startup can connect the X server to xfs using 'xset' once xfs
is running.

Thoughts?

ah, I kind of expected that the X server would just pick up a font server that
gets started later, as long as the font server is listed in the fontpath

but using xset would probably work as well

Not to throw a wrench into this idea, but if the xfs server can not be
started because /usr isn't mounted, then the X server can not be started
either, so the point is kindof moot I guess.

Both binaries live in /usr/X11R6/bin

No early login if you're using /usr over NFS.  Simple solution.

What is the status of early-login lately?  I tried it out again after FC4, and
it seems that if you have autologin enabled, you *still* have to login again. 
Don't know if any chkconfig settings need to be changed or not.

The early-login stuff has been back burnered for now.

So the early-login developpement is achieved enough to see it enabled by default
in FC5 ?

No, 'back-burnered' means it's not currently being worked on.

Is stateless Linux also back-burnered?

fedora-devel-list is a better place to ask general purpose
questions about the direction of Fedora Development.

For a visual "what's happening" status during the proposed replace rhgb with
actual gdm, I reckon a visual timer countdown would be really useful.

Sort of like a seconds to blastoff kind of thing: then you know quickly whether
you have time to make a coffee before the machine is ready to rock! (especially
for those people with slower hardware etc.)

I also noticed the new desktop background for FC5t1 updates, perhaps some of the
fedora bubble graphics could bubble up, like a kettle approaching boiling point
(ready to use). I have no idea whether it would be possible; and I would agree
that causing readiness to be delayed would not be ideal.

Hello,
I'm from Fedora Forum and though of a possible solution, I'm not sure if it's
feasable but was told to post it here, so here it goes.
I got thinking about the NFS problem, and why not setup the init order like this:
--> Init starts, udev, sets hostname, fs check, remount / in r/w mode, etc
--> syslogd, kernel + system logger
--> HAL
--> eth0 internet start
--> mount network filesystems, if needed
--> xfs (eth is started already now, so /usr is OK)
--> gdm-early-login
--> the rest
Although this will slow it down a little for those not using NFS, at least it
will work out okay for everyone.
I'm sure something similar has already been thought of, but I'm just throwing it
out there...
Firewing1

<QUOTE>
- We probably should dump prefdm, kdm, xdm, etc, and just use gdm.  I don't
think we gain much by having 3 display managers in Fedora Core.
</QUOTE>

I think you should think very carefully before dropping kdm.

I, for one, use KDE as a desktop (I don't think I'm alone :-).
If you ditch KDM you will lose KDE login integration.
Not nice for KDE users.

Graham.

(In reply to comment #46)
> Hello,
> I'm from Fedora Forum and though of a possible solution, I'm not sure if it's
> feasable but was told to post it here, so here it goes.
> I got thinking about the NFS problem, and why not setup the init order like this:
> --> Init starts, udev, sets hostname, fs check, remount / in r/w mode, etc
> --> syslogd, kernel + system logger
> --> HAL
> --> eth0 internet start
> --> mount network filesystems, if needed
> --> xfs (eth is started already now, so /usr is OK)
> --> gdm-early-login
> --> the rest
> Although this will slow it down a little for those not using NFS, at least it
> will work out okay for everyone.
> I'm sure something similar has already been thought of, but I'm just throwing it
> out there...
> Firewing1
this could be done even better just check fstab for nfs mounts if there are any
do what you posted, if not boot like it did in fc4.

Exactly! That way NFS still works, and for the non-networked /usr people we can
still have early login...
Firewing1

So is there any news on gdm-early-login? I really liked in in FC4 and now we're
almost at FC6 with no changes. Is it possible to make this a priority for FC6?
As "need real name" posted, a simple fstab check could solve the problem of
network drives and XFS.

Stewart (On the 'net I'm known as Firewing1...)

Well, there's been no replies to the suggestions, but...

If I were to try to create a patch that worked w/ network - Would I need to
patch only GDM or also initscripts?

Is this still back burned until sometime in the future, or is this closed and
something totally new will be tried/used?

There has been movement in both directions actually:

http://blogs.gnome.org/halfline/2007/06/09/graphical-boot-up/

and

https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00412.html

Neither is going to get into Fedora 8.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Closing this for now; will reinvestigate for Fedora 10.