Changes between Version 8 and Version 9 of setup_target/bebop2


Ignore:
Timestamp:
Jan 17, 2020, 6:41:38 PM (23 months ago)
Author:
Bayard Gildas
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • setup_target/bebop2

    v8 v9  
    9292}}}
    9393notes:
    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). We could probably set a specific property with the "sprop" command after /data is mounted in /etc/boxinit.standalone.milosboard.rc and wait on that in 99-chroot.rc, but we want the network to be ready anyway so I found the convenient state.wifi property and used it
     94  * surprisingly enough, the events "post-fs" and "post-fs-data" occur in a row right at startup (I was hoping for using "on post-fs-data" to start the chroot after /data is available but it doesn't work). We could probably set a specific property with the "sprop" command after /data is mounted in /etc/boxinit.standalone.milosboard.rc and wait on that in 99-chroot.rc, but we want the network to be ready anyway so I found the convenient state.wifi property and used it
    9595  * 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.