On Tue, 24.08.10 13:28, Bill Nottingham (notting@xxxxxxxxxx) wrote: > > Matthias Clasen (mclasen@xxxxxxxxxx) said: > > > BOOTUP > > > - System boots successfully to GUI, when configured. > > > - System boots successfully to text mode, when configured. > > > - System properly handles being passed [1-5], 'single', 'S', 's', '-s', > > > booting to the appropriate 'runlevel' (0 and 6 can still work, > > > but they're sort of pointless anyway) When booted in this manner, > > > '5' will bring up a GUI, and '3' will not. > > > > You mean 'being passed on the kernel cmdline', I assume ? > > Yes. > > > Do we consider interactive boot essential (I think not) ? > > This seems rather complicated, given the parallel nature of how systemd > starts things. You can actually use systemd.confirm_spawn=yes on the kernel cmdline. This should work fine for an interactive boot and things are synchronized via tty ownership. However, I am not sure how useful this all is, given that we starte gdm pretty early (which then owns the console tty and hence makes it impossible to ask any further questions which then timeout) and this options asks a confirmation question for *everything* we start, not just sysv services. That means you get even asked on shutdown, and when we activate bus services. systemd.confirm_spawn=yes is a debugging tool, but I don't think this is useful for a broader audience or ever could be made useful for a broader audience. Unless we introduce some kind of interactive UI that somehow doesn't clash with gettys or gdm being active on a tty I don't hink we can ever make interactive boots work again. > Yes. The idea is that if someone writes a systemd unit file today, they're > not going to need to change its syntax, or where they put it, or how they > enable it in future releases, unless they're changing it to use *new* > features of systemd. My plan is to stay compatible with the file format used in the final F-14 for subequent releases. While we might rename an option or make an option redundant we will continue to read the old configuration then and do the right thing. > I meant 'as booting in upstart on the same release'. It's still an option > in the F-14 branched tree. > > > > -- The services shall function the same. > > > > This is again not really much of a systemd requirement. > > It's a place where systemd can cause regressions due to the change in > how services are started. See the current (now fixed?) NetworkManager > problems. Grmbl, let's also note one thing: if LSB headers of init scripts are incorrect of arbitrary packages I don't want to be held responsible for that either. The LSB data must be "more correct" than it used to be. But that's not a bug in systemd... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
