Bug#494001: debian-installer: /etc/mtab must be a symlink to /proc/mounts with linux >= 2.6.26
> [please CC the submitter as well as the bug number, or else they don't > get a reply!] Oops, sorry. For now, it's To: you plus cc to BTS. Should I cc debian-boot as well? > Do you have any examples of packages which use /etc/mtab in this way? No. But... > I checked KDE 3.5.5 and it seems to be working fine. Note that inotify > is very new, is Linux-specific, and all of the common desktop > environments are portable to many different platforms and hence will > detect changes using mechanisms other than inotify. IMO this is not > a stopper for moving to a symlink. ... inotify is probably going to stay with us. Being better than polling, many packages might just consider switching to inotify (since it is a new thing). Not the huge ones like KDE and Gnome and the like (they have dbus/hal). Smaller packages which do not want to use dbus/hal would have little choice after this change. It's not only that inotify was imho introduced just to deal with this kind of things, but the kernel developers are also considering to move away from atime. Plus, support for mount/umount events was dropped from udev... Aside from Gnome/KDE/..., I guess it isn't so much of a problem of inotify being Linux-specific, many of the smaller packages often don't even think of being portable to other kernels. I perfectly understand your reasons, but please do consider waiting with this change, speaking to the kernel people about inotify support in (parts of) /proc, or... whatever. I admit, I don't have a really good solution ready. Regards, Radim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494001: debian-installer: /etc/mtab must be a symlink to /proc/mounts with linux >= 2.6.26
On Thu, Aug 07, 2008 at 02:19:33PM +0200, Radim X. wrote: [please CC the submitter as well as the bug number, or else they don't get a reply!] > Are you sure that this won't break things elsewhere? Yes; the whole point of this change is to stop breaking things that are currently broken, including a whole plethora of bugs in mount(1). > Other packages > might use /etc/mtab with inotify to watch mount events (especially for > removable media). They would have to switch to a different method, > since /proc does not support inotify and udev doesn't help either. Do you have any examples of packages which use /etc/mtab in this way? I checked KDE 3.5.5 and it seems to be working fine. Note that inotify is very new, is Linux-specific, and all of the common desktop environments are portable to many different platforms and hence will detect changes using mechanisms other than inotify. IMO this is not a stopper for moving to a symlink. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#494001: debian-installer: /etc/mtab must be a symlink to /proc/mounts with linux >= 2.6.26
Are you sure that this won't break things elsewhere? Other packages might use /etc/mtab with inotify to watch mount events (especially for removable media). They would have to switch to a different method, since /proc does not support inotify and udev doesn't help either. Radim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494001: debian-installer: /etc/mtab must be a symlink to /proc/mounts with linux >= 2.6.26
Package: debian-installer Severity: important /etc/mtab can be either a regular file updated by mount/umount, or a symlink to /proc/mounts. Currently, it is a regular file, though the user can change this by hand. With linux < 2.6.26, /proc/mounts lacks information present in /etc/mtab such as additional mount options. Thus a symlink breaks things like discquotas which rely on parsing the additional mount options. As a result, we are mostly all still using it as a plain file. With linux >= 2.6.26, /proc/mounts contains all of the information in /etc/mtab, plus more. The mount system call can now pass all of the mount options to the kernel, so no information is missing in /proc/mounts. This has obviously useful benefits such as read-only root, and the state in /etc/mtab never gets out of sync with reality (there are a number of open bugs against mount where this occurs). Additionally, with the addition of per-process namespaces with CLONE_NEWNS to clone(2), each process has its own set of mounts, and as such a system-wide /etc/mtab is useless: it's only valid in one of the potentially many namespaces and can quickly get into a horrible mess. At this point, /etc/mtab *must* be a symlink to avoid breakage. Note that /proc/mounts is now a symlink to /proc/self/mounts for this reason: each process has potentially different mounts. After discussion on #debian-devel, we came up with these points: - we could detect the kernel version on boot, and set up a file or a symlink as needed. However, this breaks read-only root. - we could change on upgrades rather than boot, but because it's dependent upon the kernel version, breakage could result if an older kernel is booted. - doing it at install time if a kernel >= 2.6.26 is installed is the most robust solution. I had a look at a number of sources (debootstrap, base-files, debian-installer), but I have yet to find the code that initially creates /etc/mtab (if any). Some of the init scripts will re-create it if not present (and these could do with updating too for Lenny+1), but ideally if d-i installs a kernel >= 2.6.26, it should just ensure that /etc/mtab is a symlink during the install. If we could get this change made for Lenny, that would be great. Thanks for your time, Roger -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.20.3-bytemark-uml-2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
