pitti, I already had looked at this with sarvatt for a while yesterday.
While it results in the user ending up in failsafeX, it's not a bug in
failsafeX but rather in whatever is causing it to fall into failsafeX.
I gathered from the logs sarvatt had collected (which don't appear to be
attached to this bug report - sarvatt you should upload them here) that
gdm was trying to launch X on tty7 which was being held open by whatever
was running the fsck so gdm gave up. failsafeX is less picky about what
vt it fires up on which is why it was able to come up successfully.
My guess is that some sort of magic in the gdm upstart script (or even
prior to this) is required in order to serialize startup when fsck is
proceeding. For instance, gdm maybe should wait and retry if tty7 is
temporarily unavailable before trying to start X on it, or else allow
gdm to fire up X on a different tty if you really do actually want X to
come up while fsck is proceeding in the background.
** Changed in: gdm (Ubuntu Lucid)
Assignee: Bryce Harrington (bryceharrington) => (unassigned)
--
fsck on boot triggers failsafe x 100% of the time
https://bugs.launchpad.net/bugs/496796
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
