Hi On Tue, Jan 18, 2005 at 04:46:41PM +0200, Lior Kesos wrote: > Hi I've been working lately on a set of scripts that bootstrap a linux > mainframe instance.(although this I believe is a generic linux > question). > They way I accomplish this is to have an extended initrd which sets up > networking on the initrd and then nfs mounts a real disk dumping data > upon it and in the end running init from the new mounted disk. > In kernel 2.4/2.6 pivot_root was introduced to do exactly that and > we've dealt with it. > This is how I'm mounted now..
before the pivot_root? > > /dev/ram0 on / type ext2 (rw) > none on /proc type proc (rw) > none on /sys type sysfs (rw) > /dev/dasdb1 on /mnt type ext2 (ro) > > basically I'm running the next sequence of events trying to leave the > initrd... > > cd /mnt > pivot_root . initrd > exec chroot . /bin/sh -c 'umount /initrd ; exec -a init.new > /sbin/init' <dev/console >dev/console 2>&1 > > This crashes with: > + /tmp/pivot_root . initrd > + exec chroot . /bin/sh -c 'umount /initrd ; exec -a init.new /sbin/init ' 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. Originally there was a problem for init to identify its console and thus it had to get the stdin/out/err explicitly. > 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? The file /dev/initctl is probably simply the first file init tries to access on the root file system. > 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 doesn't get there yet, IIUC > 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? -- Tzafrir Cohen +---------------------------+ http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend| mailto:[EMAIL PROTECTED] +---------------------------+ ================================================================= 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]
