| 93 | | note: surprisingly enough, the events "post-fs" and "post-fs-data" occur in a row right at startup (I was hoping using "on post-fs-data" to start the chroot after /data is available but it doesn't work) |
| | 93 | notes: |
| | 94 | * surprisingly enough, the events "post-fs" and "post-fs-data" occur in a row right at startup (I was hoping using "on post-fs-data" to start the chroot after /data is available but it doesn't work) |
| | 95 | * it's not possible to launch the standard "init system V" binary on the "chrooted" environment. Hence the init binary behaves differently whether it has pid 1 or not. If it has pid 1 it starts the system (and listen to the pipe /dev/initctl). If it doesn't have pid 1 it will send a command to its pid 1 coutnerpart by writing in /dev/initctl. Since there can be only one pid 1 and it's already running in the original parrot environment, all the "init system V" logic is useless on the chrooted filesystem (it's just bloat that could be removed). That's why we're using the chroot_init script. |
