mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ph. Marek" <philipp.marek@bmlv.gv.at>
To: linux-kernel@vger.kernel.org
Subject: Problem substituting /proc/mounts for recovery
Date: Fri, 7 Apr 2006 12:24:31 +0200	[thread overview]
Message-ID: <200604071224.31851.philipp.marek@bmlv.gv.at> (raw)

Hello everybody!

During recovery I'm running off a chroot (booted via knoppix); 
I'm trying to fake a mount table, so that the output of mount 
and df can be correctly parsed by the boot loader installation 
(in the chroot the "df -k /boot" returns no device).

But that is nowadays (2.6.14-1-686-smp (Debian 2.6.14-2)) a problem, 
since /proc/mounts is a symlink.


Observe:
        # cat /proc/mounts > /tmp/mymounts
        # vi /tmp/mymounts
        # mount --bind /tmp/mymounts /proc/mounts
        # ls -la /proc/mounts
        lrwxrwxrwx 1 root root 11 2006-04-07 12:13 /proc/mounts -> self/mounts
        # mount
        ...
        /tmp/mymounts on /proc/17496/mounts type none (rw,bind)
        # ls -la /proc/17496
        ls: /proc/17496: Datei oder Verzeichnis nicht gefunden
        # umount /proc/17496/mounts
        umount: /tmp/mymounts: not mounted
        umount: /proc/17496/mounts: not found
        umount: /tmp/mymounts: not mounted
        umount: /proc/17496/mounts: not found
        # umount /tmp/mymounts
        umount: /tmp/mymounts: not mounted

It seems not to be a simple userspace problem:
	# strace -e umount umount -f /proc/17496/mounts
	umount("/proc/17496/mounts", MNT_FORCE) = -1 ENOENT (No such file or directory)
	umount2: Datei oder Verzeichnis nicht gefunden
	umount: /proc/17496/mounts: not found


So the following questions come to my mind:
- Is that a kernel bug, ie. the dentry of /proc/17496/mounts is not 
  kept in memory for releasing? (along with /proc/17496)
- Should the mount be automatically release if there's no 
  possible user left?
- Should "mount --bind" not follow symlinks, but replace them? That's 
  what I'd need here, to fake the mount table.
- Is there a better way to achieve that?

Also I remember that /proc/mounts was filtered in older kernel versions, 
ie. mounts not visible in the chroot would not be shown. Maybe that would 
be enough to solve my problem of device detection.


Kernel version:
	# cat /proc/version
	Linux version 2.6.14-1-686-smp (Debian 2.6.14-2) (horms@debian.org) (gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3)) #1 SMP Tue Nov 1 16:06:13 JST 2005



Please keep me CC'd, as I'm not subscribed.

Thank you for all answers!


Regards,

Phil

             reply	other threads:[~2006-04-07 10:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-07 10:24 Ph. Marek [this message]
2006-04-11 12:17 ` Ph. Marek

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=200604071224.31851.philipp.marek@bmlv.gv.at \
    --to=philipp.marek@bmlv.gv.at \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®