On Wed, May 22, 2013 at 03:39:00PM +0200, Bernd Schubert wrote: > On 05/22/2013 04:50 AM, Uoti Urpala wrote: > >Lucas Nussbaum wrote: > >>I went through the various init systems threads again during the last > >>few days. My understanding of the consensus so far is the following: > >>- Both systemd and upstart bring many useful features, and are a > >> clear improvement over sysvinit. > >Yes, both are an improvement over sysvinit. > Hrmm, I have not tested systemd yet, but personally I'm not conviced > about the advantages of upstart: > - Stops booting *somtimes*, does not provide any information why. I > didn't report a bug yet as an almost black screen won't help in any > way how to figure out why it stopped. Already that stops without any > further information why and where is a sufficiently big design > issue, imho. > (Btw, in the mean time I belive this issue is related to /etc/mtab, > but I'm not sure yet.). Sorry you ran into trouble with upstart. Probably related to /etc/fstab, rather than /etc/mtab... Due to incomplete upstart integration of plymouth in Debian at present, if there are problems in /etc/fstab, mountall won't always be able to display any prompt to the user asking what to do (cf. http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/). Whereas sysvinit would eventually give up on trying to mount filesystems in /etc/fstab if they were missing at boot and continue booting without them, upstart takes the design decision that this is an error that the admin needs to deal with directly. This ensures that the system always boots reliably in the face of "slow" disks, which become more of a problem now that your init system is so fast that it can boot before your hardware has been probed. Feel free to file a bug report against the upstart package (with a copy of your /etc/fstab attached) so we can look at this further. > - Updating/install programs in a chroot fails with weird messages > that those programs (afaik for example X) cannot connect to upstart. > Well, it is a chroot, what does it expect? This is bug #685779, which will be fixed in the next upload of sysvinit to unstable. > - Personally I'm using unionfs-fuse as very first init script to > mount /etc and /var and others on my development systems. So no need > to modify an initrams, but a very simple approach and controllable > using a boot script. But specifying a script to be run *before* > anything else is not possible (yet?). I'm skeptical of the value of such a design in place of just using an initramfs, but the 'friendly-recovery' package in Ubuntu gives an example of to do this. You create an upstart job that's 'start on real-startup-event', runs your necessary pre-setup, and at the end calls 'initctl emit startup' to call into the rest of the boot sequence; then you pass '--startup-event=real-startup-event' to init on the kernel commandline. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature