On 06/22/2013 12:07 PM, Pacho Ramos wrote: > After talking with WilliamH yesterday, I have this opinion: > - Playing with /sbin/init (instead of /sbin/einit) has two interesting > advantages: > 1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if > I do a typo, it would fallback to /sbin/init. If /sbin/init is provided > by sysvinit, people running other init providers could have problems. > This wouldn't occur if /sbin/init has been changed to use desired init > system. > 2. Tools like e4rat or bootchart launch /sbin/init, if I switch to > systemd, I would need to edit separate configuration files for each tool > to point to new init. This wouldn't occur if we "play" with /sbin/init > => we would only change init in one place good point. maybe a ton other wrapper of that kind. shouldn't they read /proc/cmdline for init=^H^H^H^H^Hreal_init= , but that takes time.
> - I have two doubts: > 1. Why do we need a wrapper instead of changing symlinks? And a plain symlink has the charm to either resolve (and load and most likely execure the target) or dangles and kernel tries the next one. No late, wrapper bailouts leaving the kernel in "You killed pid 1" panic. === kexec === speaking of panic. I've never actually used it, but newer kernels support kexec and in conjunction with pre-loaded panic-images[1] and corresponding (compiled-in) initramfs, it'd be possible to have an recovery shell. for either /sbin/init mixups, or late runtime crashes. These should have a the decency to respect the panic= timeout to allow automated reboots or idle till to the end of days. [sad enought, that kexec'd kernels don't pick up the process tables/heap of their predecessors and enable real kernel-hotswitching] === more fallback == maybe we could ask Mr. Tovalds to ad another line in init/main.c, say /sbin/init.fallback (but don't mention systemd) or we could abuse /etc/init or /bin/init or /sbin/sh (with an wrapper to test for PID=1) for an recovery-environment. Fabio: did you mean that? === security === Bailing into /bin/sh or whatever can compromise filesystem integrity/reveal root access to an uncrypted rootfs. There is a scenario of vandalism-proof installed computer pools (no physical access except keyboard/monitor) w/ unattended boot that should not end up in root-shell. ;-) Maybe I should fix that on my systems ... [1] sys-apps/kexec-tools http://kernel.org/pub/linux/utils/kernel/kexec/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber <x...@gentoo.org>
