On 05/22/2013 06:19 PM, Steve Langasek wrote:
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
Well, actually this happens on 2 ubuntu systems.
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/).
I really meant mtab. After the issue appeared last time again and didn't
go away on reboots, I booted into recovery shell and noticed that 'mount
-a' didn't do anything. Remouting / rw, deleting /etc/mtab solved it,
also on reboots. I now linked /proc/self/mtab to /etc/mtab and that
solved it.
Might not be an upstart bug at all, but I'm mainly complaining here that
upstart does not provide any way to figure out what it is currently
waiting for. Just opening a shell after some time and writing something
like
waiting on XXX to proceed with ...
probably would be sufficient. Without any logs, screen output and no way
to investigate it just gives the feeling that one now needs to
re-install the system, similar to another famous OS .
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.
Thanks, going to look into this. I also need to work on unionfs-fuse to
properly work from an initramfs. The issue is just missing time for
either of both... I also just wanted to point out that upstart is some
way a regression.
Thanks,
Bernd
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/519f2d5e.2010...@fastmail.fm
