Will attach patch for removing rhgb and starting gdm early instead. The idea here is to introduce a new initscript, start-desktop-services, that 1. fires up the users prefererred login manager 2. starts certain services 3. signals the users preferred login manager that it's ready to accept authentication This initscript should only be in runlevel 5 and should be the very first one to be executed, e.g. S00start-desktop-services. We may want to solve this in other ways, e.g. a. put S00startdm that starts the login manager b. move the services the desktop cares about (messagebus, hal, acpid, etc.) to start in S01-S02 c. put S03signal_dm_ready_if_auth_does_not_require_network d. put S21signal_dm_ready_if_auth_does_require_network but that pretty much screws us if /usr is on a network mount. Hence, why I prefer steps 1 through 3. rather than a. through d. Please don't apply this just yet; let's have a discussion on how to proceed. Also, Ray and Matthias got a patch pending for gdm to let it intercept the signal that we're ready to do auth.
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.