设置/etc/fstab，使系统在启动时像mount --bind命令一样装载目录（/etc/pam.d/sshd默认配置）

25-02-14 16

在这篇文章中，我们将为您详细介绍设置/etc/fstab，使系统在启动时像mount--bind命令一样装载目录的内容，并且讨论关于/etc/pam.d/sshd默认配置的相关问题。此外，我们还会涉及

在这篇文章中，我们将为您详细介绍设置/etc/fstab，使系统在启动时像mount --bind命令一样装载目录的内容，并且讨论关于/etc/pam.d/sshd默认配置的相关问题。此外，我们还会涉及一些关于/boot 分区、fstab 文件、/bin/mount 一次性被误除修复方法、/etc/fstab，/etc/mtab，和 /proc/mounts、/etc/init.d中的脚本不会在启动时运行(Ubuntu 8.10)、/etc/mtab must be a symlink to /proc/mounts的知识，以帮助您更全面地了解这个主题。

本文目录一览：

设置/etc/fstab，使系统在启动时像mount --bind命令一样装载目录（/etc/pam.d/sshd默认配置）
/boot 分区、fstab 文件、/bin/mount 一次性被误除修复方法
/etc/fstab，/etc/mtab，和 /proc/mounts
/etc/init.d中的脚本不会在启动时运行(Ubuntu 8.10)
/etc/mtab must be a symlink to /proc/mounts

设置/etc/fstab，使系统在启动时像mount --bind命令一样装载目录（/etc/pam.d/sshd默认配置）

添加下面的设置到 /etc/fstab

   
   
   
 
    
 
    
    
    # <file system> <mount point> <type> <options> <dump> <pass>
 
    
 
    
    
    /mnt/hdd1/test /home/test/ext none rw,bind 0 0

From WizNote

/boot 分区、fstab 文件、/bin/mount 一次性被误除修复方法

fstab 文件丢失、boot 分区被删、mount 文件被删解决办法

1、解决问题的思路:
a、修复 fatab 文件
b、修复 mount 命令
c、修复 boot 分区

d、安装 grub

准备：将 boot 分区进行格式化
#umount /dev/sda1
#mkfs.ext3 /dev/sda1
#rm –rf /etc/fstab
#rm –rf /bin/mount

完成以上操作后，你发现启动后，会有如下报错：<grub 没了>

在尝试进入救援模式时，又出现以下：<没有 linux 分区，更别说系统了>

实施：
1、进入 linux rescue 模式 <启动网络>
    #、创建一个目录
     mkdir disk
    #进行挂载
    mount /dev/sda1 disk

此时，我们需要查看各个分区的标签，以确认各分区的用途。

#创建 fstab 文件，如果你有 fstab 这会儿你可以恢复了。
vi disk/etc/fstab

#重启系统

2、再次进入 linux rescue 模式 <启动网络>
#如图，找到系统了。因为 fstab 恢复了。如图:

然后安装缺少的包吧
    #chroot /mnt/sysimage
    #rpm -ivh util-linux.XX.rpm --force
    #rpm -ivh kernel-2.6.18-164.el5.i386.rpm --force
    #rpm -ivh kernel-2.6.18-164.el5.i386.rpm –force

    #grub-install /dev/sda
    #vim /boot/grub/grub.conf
        title RHEL5
            root (hd0,0)
            kernel /vmlinuz-2.6.18-164.el5 ro root=LABEL=/ rhgb quiet
            initrd /initrd-2.6.18-164.el5.img

关于缺少的文件，我最近看到有种方法可以将 rpm 解包，然后将其缺少的问题 COPY 到目的地的。我觉得这个不错，在些记录如下：

还是上面一个问题，mount 文件丢失了，我在上一个方法中使用强行安装的方法实现的。

这里使用，解包 util-linux 这个包来做。

#mkdir test

#rpm2cpio util-linux.rpm | cpio –id

#ls

bin etc sbin usr util-linux.rpm

#cp bin/mount /bin

该步骤是直接解包，将 mount 文件 CP 到系统中的。

本文出自 “潜入技术的海洋” 博客，请务必保留此出处 http://myhat.blog.51cto.com/391263/510621

/etc/fstab，/etc/mtab，和 /proc/mounts

现在的 Linux 系统里一般都有这么三个文件：/etc/fstab，/etc/mtab，和 /proc/mounts，比较容易让人迷惑。简单解释一下。

/etc/fstab 是只读不写的，它提供的是系统上挂载设备的静态信息，比如 mount -a 就会挂载 /etc/fstab 里面指定的文件系统。

/etc/mtab 是供 mount/umount 进行读写的，是相对动态的。读的话，比如你在挂载一个文件系统时缺少一个参数，它就会自动去/etc/mtab 或者 /etc/fstab 里去查，如果找到的话，只要一个参数也够。写的话，比如你umount了一个文件系统，umount 就会删掉/etc/mtab 里面的相关记录。

看似上面的这两个文件已经够用了，但是新的情况出现了。Linux 内核引入了一个 mount namespace，是给container用的。因为这个的出现，Linux 不得不引入 /proc/mounts。为什么呢？因为记录 mount 信息的 /etc/mtab 是全局的，也就是说，就算你的某个进程有自己的 namespace，但只要还和外面共享同一个 /etc/mtab，那么，里面进行umount/mount操作的信息也会被记录到/etc/mtab里，外面也会看到！凌乱了！由此可见，我们不能有全局的mtab，肿么办呢？/proc/mounts 出来了，有人可能觉得它也是全局的啊！可你仔细看一下的话会发现，它其实是到 /proc/self/mounts 的一个符号链接！如此以来，container 里面的 /proc/mounts 和外面的当然就不会一样了！聪明啊！

所以，/etc/mtab 已经过时了，应该被抛弃，或者直接符号链接到/proc/mounts。同理，查看系统上挂载的文件系统的话，直接调用无参数的mount也是不妥的，因为那样也是读 /etc/mtab。我们应该使用 util-linux-ng 提供的一个新命令： findmnt，它是读的 /proc/self/mountinfo。

/etc/init.d中的脚本不会在启动时运行(Ubuntu 8.10)

我在Ubuntu 8.10上

当使用sudo /etc/init.d/xbindkeys start从命令行调用脚本时,该脚本将运行.这是它的外观：

#! /bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
case "$1" in
  start)
    xbindkeys
  ;;
  stop)
    ps aux | grep xbindkeys | head -n1 | awk '{print $2}' | xargs kill
  ;;
  restart)
    $0 stop
    $0 start
  ;;
esac

我之前运行了sudo update-rc.d xbindkeys默认值来创建符号链接.为了确保它正确链接,我尝试了chkconfig | grep xbindkeys,返回：

xbindkeys                        2345

但是,重新启动后,我没有看到ps aux |的过程grep xbindkeys.

想法？

xbindkeys需要一个正在运行的X服务器才能工作,这在启动系统的那个阶段是不可用的.您应该将xbindkeys添加到.xinitrc(参见手册页xinit(1))或.Xsession(参见手册页Xsession(5)).

/etc/mtab must be a symlink to /proc/mounts

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.

关于设置/etc/fstab，使系统在启动时像mount --bind命令一样装载目录和/etc/pam.d/sshd默认配置的介绍已经告一段落，感谢您的耐心阅读，如果想了解更多关于/boot 分区、fstab 文件、/bin/mount 一次性被误除修复方法、/etc/fstab，/etc/mtab，和 /proc/mounts、/etc/init.d中的脚本不会在启动时运行(Ubuntu 8.10)、/etc/mtab must be a symlink to /proc/mounts的相关信息，请在本站寻找。

本文标签：