Petter Reinholdtsen <p...@hungry.com> writes:
> [Bernhard R. Link]
>> Currently we have a system where every user has a chance to debug
>> and fix those problems and make their system work again.
>
> I just wanted to give a small comment on this, as one of the sysvinit
> package maintainers in Debian. The quoted text give the impression
> that the current init.d based boot system is working fine, and that is
> not quite how I see it.
>
> The current sysvinit boot system is not working properly on Linux.
> And it has broken in new and interesting ways the last few years,
> thanks to the fact that the linux kernel developers have removed the
> big kernel lock, causing the kernel to become more event based and
> less sequential during boot.
>
> These problems lead to boot failures when some kind of hardware is
> used (think disks and network cards, but it can happen with any
> hardware), because it is not possible for the current dependency based
> boot system to know when some hardware device is available during
> boot. A well known case is having the user home directory on an
> external USB disk, only to discover that the disk device node isn't
> available when file systems are mounted during boot. There are other
> examples.
>
> To solve this problem the early boot (note only the early boot _need_
> this) need to become event based, and once the file systems, network
> interfaces etc are set up, the later boot can work using simple init.d
> script dependencies.
Alternatively they can become polling. Granted that is a less attractive
solution but works just as well.
But using events or polling it would be quite trivial to insert a "wait
here for xyz to appear" commands into the init.d scripts. I wouldn't
call this event based just because you have a "wait for event" part in
the scripts.
On the note of missing devices: Is it possible to inotify on devtmpfs?
while(device does not exists) {
wait for inotify event on /dev
udevsettle
}
I have / on an usb stick and that often takes too long to appear and
then the initramfs fails to mount /. So I do get your argument.
> I do not know the proper solution to this for Debian, but both upstart
> and systemd seem to provide a working solution with different costs
> and advantages. Personally I hope kFreeBSD and Hurd will get the
> required features used by upstart and systemd, to at least make it
> possible to use these systems on all the architectures handled by
> Debian.
>
> Or perhaps we should just teach sysvinit to handle kernel events and
> thus make it capable of solving the problem of the event based kernel
> internally. No-one so far have volunteered to look at this approach,
> and I have no plans to do so myself, but I am sure it would be
> possible to integrate the nice features of upstart and systemd into
> sysvinit. :)
For block devices there is the device node you can wait for. For others
add a udev rule that touches a file. Then you can poll for the node or
file in the init.d script easy enough.
MfG
Goswin
--
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/87wr7c19m3.fsf@frosties.localnet
