Tzafrir Cohen wrote: > This is basically the 'exec chroot . /sbin/init' from pivot_root(8) with > some extras. A different process name (-a) should probably do no harm. I > don't remember why it was introduced, though.
Running init with a different process name was a way to make sure we run 'init' and not 'telinit'. Now, since init and telinit are both embedded in the same executable, this exec. makes sure that if you run 'init' and it is not the first process of the system, then you probably wanted to run telinit... and then it runs the telinit code (which requires a runlevel as an argument - thus the 'Usage: init.new 0123456SsQqAaBbCcUu' line). So, until sysvinit-2.85, the assertion was either pid=1 or process name='init.new'. In 2.85 the assertion has changed to pid=1 only. With addition to that, the new code has added an option '-i/--init', forcing the exec. to run the 'init' code and not the 'telinit' code. So running init with a diff process name is indeed not a problem (and backward compatible), but for the newer versions of sysvinit, add '-i/--init'. >> umount: /initrd: device is busy >> Usage: init.new 0123456SsQqAaBbCcUu >> VFS: Cannot open root device "dasdb1" or unknown-block(0,0) > > You're supposed to give init a "familiar" environment. Does init expect > /initrd to be unmounted? Or maybe it has the code to unmount it on its > own? /initrd is always busy because some processes are still running from there... when you run lsof, you see opened files under /initrd - like /initrd/lib/libc... > The file /dev/initctl is probably simply the first file init tries to > access on the root file system. That is true, but it's not the problem. What happened here is the code that ran was telinit and not init. telinit tries to open the initctl device to send a signal to its corresponding init process, but it can't because init's not running yet. >> Please append a correct "root=" boot option >> Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0) >> HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 0046CB4C >> >> Now this is very odd because: >> 1. Shouldn't init read the inittab for the chrooted system (it exists >> -default runlevel - 3). >> It should and it does, but when you called /sbin/init, it chose to run telinit instead. telinit's the one who doesn't read the inittab... it requires an argument. >> 2. When I explicitly run init 3 I get a different error mentioning ... >> init.new: timeout opening/writing control channel /dev/initctl >> 3. If I use the pivot_root(8) manpages _first_ example (running sh >> instead of init) it works ok. >> > > What do you see on the root filesystem? Can you actually read files > there? > >> I read about initctl and it (the pipe) exists in the new filesystem. >> I'm pretty much a RTFM kinda guy but I'm a bit stuck here - any ideas? One of the things that init does is listen to /dev/initctl for commands. When you run telinit (to switch runlevels for example), it sends a command through /dev/initctl to the init process, telling it that the superuser has requested to switch runlevels. If there's no init running in the new chrooted environment yet (that's what we're actually trying to achieve), then no one is listening on /dev/initctl. telinit tries to open and to write to /dev/initctl and fails on a timeout because there's no one on the other side. -- Yuval Turgeman ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
