[Tickets] [Initng] #824: Request for procless, socketless boot mode (bootstrap boot mode)

[Initng]

#824: Request for procless, socketless boot mode (bootstrap boot mode)
--------------------------------------------+-------------------------------
 Reporter:  thekevinday                     |       Owner:                
     Type:  enhancement                     |      Status:  new           
 Priority:  normal                          |   Milestone:                
Component:  Feature Requests Initng Source  |     Version:  initng-0.6.10 
 Severity:  normal                          |    Keywords:  boot bootstrap
--------------------------------------------+-------------------------------
 To better explain this feature request let me explain my current issue.

 while booting, the initng scripts I have will mount /proc, /dev, /dev/pts,
 /sys, /tmp, /var/log, /var/run, /dev/shm, /proc/bus/usb, and /var/tmp as
 temporary filesystems (tmpfs) because the boot filesystem is a read-only
 device.
 /dev is also mounted tmpfs because it's needed for udev.

 My initial work-around was to send a hangup (SIGHUP) to initng from initng
 and suddenly the socket gets re-created and userspace tools suddenly work
 again (like ngc). Sending hangug ended up causing some very unusual and
 rare or uncommon issues that caused system loggers and servers to fail to
 start and the boot process to collapse on itself.

 I then fixed the problem entirely by writing a two stage init process.
 That is, I have a simple /sbin/init that will mount /proc, /dev, and  /sys
 and then call exec on /sbin/initng.

 What I am asking for is an implementation that will not use a socket or
 any automatic write operations until a rule passes some command (lets say:
 end_bootstrap).
 And then from that point on the normal initng operations would happen.

 The idea is that I would like initng to be able to handle the mounting and
 setting up of the boot process.

 This would, in particular, even allow me to use initng in an initrd and
 perform pivot_roots (with a begin_bootstrap rule command) in such a way
 that the initrd filesystem could be unmounted following the pivot_root.

 I could also use this to have the initrd mount /dev, start udev, and have
 it auto-hotplug devices prior to performing a chroot and a pivot_root such
 that the entire initrd process could be dynamic.

 This could be useful for encrypted rootf's as well.

 If the pivot_root is stretching this idea, then I would still settle for
 the end_bootstrap option that allows me to do basic operations without any
 writes to a particular device/filesystem.

-- 
Ticket URL: </ticket/824>
Initng <>
The next generation init system