[Pkg-sysvinit-devel] Unexpected problem with /etc/mtab -> /proc/mounts

[Henrique de Moraes Holschuh]

On Sun, 22 Jan 2006, Thomas Hood wrote:
> Well, there are problems related to conflicting services.  E.g., if I install Debian
> foosrv in my Debian chroot then the initscript may fail to start the service because

"Install" chroots have policy-rc.d disabling all actions, and also a fake
start-stop-daemon that does nothing.

So all invoke-rc.d won't screw up anything. I use pbuilder all the time, and
no !@#$ daemon starting out-of-runlevel has bitten me so far.

> running from my Ubuntu standard root.  E.g., when I install Debian Linux image
> packages in my Debian chroot, the initrd build fails.  I was assuming that these
> were problems that we just had to live with, but if I understand you correctly,
> these problems are to be considered bugs.  OK.

No, those are not bugs. You can't try to run two things that want the same
unshareable resource, and that's it.

It is a bug if maintainer scripts screw up on a "install type" chroot (which
already disables invoke-rc.d and start-stop-daemon).

> Anyway, back to initscripts.  When I install Debian initscripts in a Debian chroot,
> initscripts.postinst runs mount{kern,devsub}fs.sh which results in the virtual
> filesystems being mounted again on mount points under the chroot.

WHY are we running this on a postinst?

> /proc/mounts and not /etc/mtab.  I'd say that if /proc/mounts is absent then
> umountn?fs.sh should look at /etc/mtab instead.

I still think it should look at *both* :P

> (chroot)$ cat /proc/mounts
> rootfs / rootfs rw 0 0
> none /sys sysfs rw 0 0
> none /proc proc rw,nodiratime 0 0
> [...other entries that look just like they do from the standard root...]
> proc /proc proc rw,nodiratime 0 0
> sysfs /sys sysfs rw 0 0
> usbfs /proc/bus/usb usbfs rw 0 0
> tmpfs /dev/shm tmpfs rw 0 0
> devpts /dev/pts devpts rw 0 0
> none /proc proc rw,nodiratime 0 0
> 
> So what HMH said:
> 
> > The fact is that /proc/mounts does not reflect the process' namespace.
> 
> is not entirely true.  The mounts into the chroot are listed in /proc/mounts with
> correct chroot-relative paths, but there are also entries there with standard-root-
> relative paths.  On the other hand, /etc/mtab in the chroot is entirely correct:

Yuck, this is EVEN worse... but I stand corrected, anyway.

> One's initial thought is therefore to make umountn?fs.sh read /etc/mtab rather than
> /proc/mounts if running in a chroot.  But I am not sure that this is right.  Why
> does /proc/mounts include entries for mounts outside the chroot when read from
> inside the chroot (and with paths that aren't valid for the chroot too)?   Sounds
> like a kernel bug, as HMH said.

As I said, something is seriously borked here, or we are missing some
important point.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh