From: mds@bogus.nodomain.nowhere   
      
   Chris Vine  writes:   
      
   > ChangeLog.txt   
   >   
   > Thu Nov 22 05:56:56 UTC 2018:   
   > "rc.S: Support replacing the /etc/mtab file with a symlink to   
   > /proc/mounts."   
   >   
   > Wed Nov 28 07:25:32 UTC 2018:   
   > "Make /etc/mtab a symlink to /proc/mounts on the installer.  On a   
   > freshly installed system, make /etc/mtab a symlink to /proc/mounts."   
      
   So Pat & Co. are on it but they haven't worked out the kinks.   
      
   Patrick apparently thinks mtab is still a file becuase this creates a   
   file, not a symlink:   
      
      /etc/rc.d/rc.S   
      
      # Any /etc/mtab that exists here is old, so we start with a new one:   
      
      /bin/rm -f /etc/mtab{,~,.tmp} && /bin/touch /etc/mtab   
      
   There seems to be two questions:   
      
   1.  Why do some 15.0 installs have mtab a file and others a symlink?   
       Related: What/where is the code that makes the symlink and what   
       happened to it if there *is* no symlink?   
      
       Different people put together the 32 and 64 bit packages?   
       Oversight? Complexity catastrophy? :-) No real clue.   
      
   2. Given that mtab is a symlink, why doesn't umount work for   
      user-mouted NFS mounts?   
      
      Apparently people using local namespaces [1], containers, CIFS (I don't   
      even know what those are) & systemd inter alia run aground with a   
      corrupted mtab file and urge/demand mtab->/proc/mounts.   
      
      I found a lengthy discussion among Gentoo devs [2] from 2013/14.   
      They seem to have believed at that point that all problems had   
      been dealt with.  The info previously in mtab but lacking in   
      /proc/mounts is to be stowed in utab (/run/utab, /run/mount/utab,   
      /var/utab.  /dev/.mount/utab is mentioned in the libmount source   
      comments) and retieved from there by code that needs it.   
      
          + Canonical location of utab seems to be uncertain but in my   
            Slack 15.0 it's in /run/mount/utab.   
      
          + Mount(8) calls mount.nfs(8) as a helper and it, in turn,   
            depends on libmount.so to attend to the mount/umount details.   
      
          + Slack 15 source for libmount (mount_libmount.c, 2011 Karel   
            Zak ) has cryptic comments suggesting that   
            it's using utab in some way but AFAICT from the C code, it   
            doesn't do anything that's needed: put the fstab data into   
            utab and/or fetch it back.   
      
          + /run/mount/utab  remains empty (tail -f while doing NFS   
            [u]mounts -> nothing.)   
      
   Wizards are invited to pursue this.  It's beyond my very limited   
   hacker skills.   
      
   [1] Namespaces   
      
         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.   
      
   [2] https://bugs.gentoo.org/show_bug.cgi?id=477498   
      
       Debian devs though it was all fixed in 2011.   
      
   --   
   Mike Spencer                  Nova Scotia, Canada   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)