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

[Thomas Hood]

Petter Reinholdtsen wrote:
> The installation system installs everything in a chroot.  So do the
> LTSP and lessdisks installation.  The maintainer scripts are expected
> to install properly in chroots.


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
it sees that a foosrc process is already running, even though this is a process
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.

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.

(chroot)$ cat /etc/mtab
proc /proc proc rw 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,gid=5,mode=620 0 0

(standard root)$ cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw 0 0
none /proc proc rw,nodiratime 0 0
[...]
proc /mnt/hda6/proc proc rw,nodiratime 0 0
sysfs /mnt/hda6/sys sysfs rw 0 0
usbfs /mnt/hda6/proc/bus/usb usbfs rw 0 0
tmpfs /mnt/hda6/dev/shm tmpfs rw 0 0
devpts /mnt/hda6/dev/pts devpts rw 0 0

(My chroot in on /mnt/hda6.)

I see that this will cause a problem if umountn?fs.sh are run and if there is
an /etc/mtab in the chroot but no /proc/mounts, since umountn?fs.sh look at
/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 just tried bind-mounting /proc to /mnt/hda6/proc. Here is what /proc/mounts
contains when read from the chroot:

(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:

(chroot)$ cat /etc/mtab
proc /proc proc rw 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,gid=5,mode=620 0 0

(so long as it was a separate file to begin with and not bind-mounted from the
standard mtab file).

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.
-- 
Thomas