Hi Mark, I followed exactly the second example as well - the -a init.new just names the proccess init.new - don't totally know why (I'm maintainign scripts I haven't written initially). Thanks for the direction.. Lior.
On Tue, 18 Jan 2005 12:42:23 -0500, Post, Mark K <[EMAIL PROTECTED]> wrote: > I notice that you're not following the second example exactly as they have > documented it. Instead of doing: > sh -c 'umount /old_root; exec /sbin/init' \ > <dev/console >dev/console 2>&1 > > You have: > /bin/sh -c 'umount /initrd ; exec -a init.new /sbin/init' \ > <dev/console >dev/console 2>&1 > > > Why are you using "exec -a init.new" instead of just "exec"? The error > message you're getting: > Usage: init.new 0123456SsQqAaBbCcUu > Seems to indicate something is happening that init doesn't like. > > Mark Post > > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Lior > Kesos > Sent: Tuesday, January 18, 2005 9:36 AM > To: [email protected] > Subject: initctl issues while initrd hacking - SLES9 - S390X > > Hi I've been working lately on a set of scripts that bootstrap a linux > instance. > 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.. > > /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 ' > umount: /initrd: device is busy > Usage: init.new 0123456SsQqAaBbCcUu > VFS: Cannot open root device "dasdb1" or unknown-block(0,0) > 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). > 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. > > 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? > > respectfully > Lior. > > -- > Peace Love and Penguins - > Lior Kesos > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- Peace Love and Penguins - Lior Kesos ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
