All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
To: Rene Mayrhofer <rene.mayrhofer@gibraltar.at>,
	linux-kernel@vger.kernel.org
Subject: Re: pivot_root seems to be broken in 2.4.21-ac4
Date: Tue, 22 Jul 2003 09:24:47 +0300	[thread overview]
Message-ID: <200307220622.h6M6MTj20460@Port.imtp.ilyichevsk.odessa.ua> (raw)
In-Reply-To: <3F1C52B7.3040308@gibraltar.at>

On 21 July 2003 23:53, Rene Mayrhofer wrote:
> Hi all,
> 
> [Please CC me in replies, I am currently not subsribed to this list.]
> 
> I am currently using 2.4.21-ac4 (with a few other patches, but none of 
> them seems to touch pivot_root in any way) on a VIA EPIA M6000 board, 
> with works pretty fine and seems more stable than the previsouly used 
> 2.4.21-rc2. However, there is one problem that I am unable to solve:
> 
> When switching the root filesystem on the fly basically with:
> 
> <prepare the new root fs, which is in fact a cramfs>
> mount -t cramfs /dev/rd/0 $mntpoint
> cd $mntpoint
> mount -nt proc none proc/
> mount -nt devfs none dev/
> /sbin/pivot_root . mnt <dev/console >dev/console 2>&1
> <snip, some further preparations on the new root fs>
> /usr/sbin/chroot . /sbin/telinit u <dev/console >/dev/console 2>&1
        btw you probably have to remove leading / ^^^
> <snip>
> exit 0

Hm... I thought you are running with pid 1 and have to do

exec chroot . /sbin/init <dev/console >/dev/console 2>&1

or the like as a final command.

> it no longer works as expected. I should probably note that the 
> redirections to /dev/console were not necessary for 2.4.21-rc2, I tried 
> them with 2.4.21-ac4. While the above commands did the trick for 
> 2.4.21-rc2, with 2.4.21-ac4 the kernel processes leave the console on 
> the old root fs open:
> 
> lsof -n | grep mnt
> keventd     2   root    0u   CHR        5,1               16  /mnt/dev/console
> keventd     2   root    1u   CHR        5,1               16  /mnt/dev/console
> keventd     2   root    2u   CHR        5,1               16  /mnt/dev/console
> ksoftirqd   3   root    0u   CHR        5,1               16  /mnt/dev/console
> ksoftirqd   3   root    1u   CHR        5,1               16  /mnt/dev/console
> ksoftirqd   3   root    2u   CHR        5,1               16  /mnt/dev/console
> kswapd      4   root    0u   CHR        5,1               16  /mnt/dev/console
> kswapd      4   root    1u   CHR        5,1               16  /mnt/dev/console
> kswapd      4   root    2u   CHR        5,1               16  /mnt/dev/console
> bdflush     5   root    0u   CHR        5,1               16  /mnt/dev/console
> bdflush     5   root    1u   CHR        5,1               16  /mnt/dev/console
> bdflush     5   root    2u   CHR        5,1               16  /mnt/dev/console
> kupdated    6   root    0u   CHR        5,1               16  /mnt/dev/console
> kupdated    6   root    1u   CHR        5,1               16  /mnt/dev/console
> kupdated    6   root    2u   CHR        5,1               16  /mnt/dev/console
> kjournald   7   root    0u   CHR        5,1               16  /mnt/dev/console
> kjournald   7   root    1u   CHR        5,1               16  /mnt/dev/console
> kjournald   7   root    2u   CHR        5,1               16  /mnt/dev/console
> scsi_eh_0  81   root    0u   CHR        5,1               16  /mnt/dev/console
> scsi_eh_0  81   root    1u   CHR        5,1               16  /mnt/dev/console
> scsi_eh_0  81   root    2u   CHR        5,1               16  /mnt/dev/console
> 
> Does anybody have an idea what might be wrong here ?

I don't know for sure but it seems like kernel daemons share fds with pid 1.
On my system:

COMMAND    PID  USER   FD   TYPE     DEVICE     SIZE      NODE NAME
init         1  root  cwd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
init         1  root  rtd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
init         1  root  txt    REG        0,8    19688     77715 /app/util-linux-2.11p/sbin/init (172.16.42.75:/.rootfs/.std)
init         1  root  mem    REG        0,8   832636      8248 /app/glibc-2.3/lib/ld-2.3.so (172.16.42.75:/.rootfs/.std)
init         1  root  mem    REG        0,8    69355      8254 /app/glibc-2.3/lib/libcrypt-2.3.so (172.16.42.75:/.rootfs/.std)
init         1  root  mem    REG        0,8 16153080      8249 /app/glibc-2.3/lib/libc-2.3.so (172.16.42.75:/.rootfs/.std)
init         1  root    3u  FIFO        0,6                405 /dev/initctl
keventd      2  root  cwd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
keventd      2  root  rtd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
keventd      2  root    3u  FIFO        0,6                405 /dev/initctl
ksoftirqd    3  root  cwd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
ksoftirqd    3  root  rtd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
ksoftirqd    3  root    3u  FIFO        0,6                405 /dev/initctl
kswapd       4  root  cwd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
kswapd       4  root  rtd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
kswapd       4  root    3u  FIFO        0,6                405 /dev/initctl
bdflush      5  root  cwd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
bdflush      5  root  rtd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
bdflush      5  root    3u  FIFO        0,6                405 /dev/initctl
kupdated     6  root  cwd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
kupdated     6  root  rtd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
kupdated     6  root    3u  FIFO        0,6                405 /dev/initctl
rpciod      16  root  cwd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
rpciod      16  root  rtd    DIR        0,8     1024     65282 / (172.16.42.75:/.rootfs/.std)
rpciod      16  root    3u  FIFO        0,6                405 /dev/initctl

See? fd 3 is open to /dev/initctl in init AND in kernel daemons.
I conclude that daemons simply share fd table with init.

So you might try to do the exec chroot . /sbin/init trick
and see whether that works.
--
vda

  reply	other threads:[~2003-07-22  6:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-21 20:53 pivot_root seems to be broken in 2.4.21-ac4 Rene Mayrhofer
2003-07-22  6:24 ` Denis Vlasenko [this message]
2003-07-22  6:50   ` Rene Mayrhofer
2003-07-22 17:37     ` Jason Baron
2003-07-22 17:40       ` Alan Cox
2003-07-22 18:03         ` Rene Mayrhofer
2003-07-22 20:00           ` Alan Cox
2003-07-22 20:37             ` Rene Mayrhofer
2003-07-22 21:54               ` Alan Cox
2003-07-23  6:23                 ` pivot_root seems to be broken in 2.4.21-ac4 and 2.4.22-pre7 Rene Mayrhofer
2003-07-22 22:14             ` pivot_root seems to be broken in 2.4.21-ac4 Mika Penttilä
2003-07-22 23:38               ` Alan Cox
2003-07-23  6:30                 ` pivot_root seems to be broken in 2.4.21-ac4 and 2.4.22-pre7 Rene Mayrhofer
2003-07-24  2:24                   ` Jason Baron
2003-07-24  7:11                     ` Rene Mayrhofer
2003-07-22 18:25         ` pivot_root seems to be broken in 2.4.21-ac4 Mika Penttilä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200307220622.h6M6MTj20460@Port.imtp.ilyichevsk.odessa.ua \
    --to=vda@port.imtp.ilyichevsk.odessa.ua \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rene.mayrhofer@gibraltar.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.