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
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.