/usr迁移后Fedora无法登录

Date:  2015/3/21   Sort:  Linux&开源 2838 Views / 0 Comments 

  昨天帮朋友解决了一个问题,涨姿势的同时也再一次体会到文档的重要性。

  朋友使用的系统是Fedora 21 Workstation,之前安装时因为分区太小导致使用一段时间后出现磁盘空间不足。遂按照一般的挂载方法,把/usr(应用程序的文件主要存放于此)复制到了一个新的ext4分区中,然后修改/etc/fstab,重启。结果登录界面可以正常显示,但无法登录(普通用户、root都不行)。第一反应是权限问题,于是查看了原始/usr和新分区中的文件权限,但没有发现问题。

  在网上查了很多解决办法,包括调整/etc/fstab的参数、启用rhshell等,均无果。一怒之下直接禁用SELinux(内核参数selinux=0),再次启动,居然可以登录了!查看系统日志(systemd的日志真是蛋疼啊,放着纯文本不用非要用二进制,结果Ubuntu下journalctl根本读不出来T_T),注意到上一次未能登录的时候audit给出了一些奇怪的信息:

    3月 20 20:02:04 localhost.localdomain kernel: audit: type=1131 audit(1426852924.050:432): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-tmpfiles-setup-dev" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
    3月 20 20:02:04 localhost.localdomain kernel: audit: type=1131 audit(1426852924.051:433): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-remount-fs" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
    3月 20 20:02:04 localhost.localdomain kernel: audit: type=1131 audit(1426852924.052:434): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-readahead-replay" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
    3月 20 20:02:04 localhost.localdomain kernel: audit: type=1131 audit(1426852924.053:435): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=' comm="systemd-readahead-collect" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

    等等。这更加让我确定是SELinux惹的祸。所以再次重启并启用SELinux,结果卡在了这一步:

    *** ■■■ SELinux targeted ■■■

    *** ■■■■■■■■■■■■■■■■■■

    *** ■■■■■■■■■■■■■■■■■■

    是的你没看错,不是浏览器编码问题,而是蛋疼的终端不支持UTF-8扩展但脚本偏偏用中文输出Orz!等了一会没见反应,于是重启,结果依旧。只好又搜索“SELinux targeted”,结果在“最不可能”找到解答的地方找到了解答:4.4. Enabling and Disabling SELinux。重启后等待了5分钟左右,系统自动重启,然后——一切恢复了宁静……

  由于个人对SELinux的运行机制不甚了解,故想了很久还是没能弄明白原因,只是大概知道系统文件迁移后SELinux上下文(context)发生了变化(与“ls -Z”所看到的上下文不同,这个属性不能用“chcon --reference”来复制),必须让SELinux重新对系统文件进行labeling(打标签,也就是认证的过程)。而禁用SELinux后再启用,恰恰是触发re-labeling的关键操作!


  现将挂载点迁移后无法正常启动的解决方法汇总如下(均为个人经验之谈,若导致任何损失本人不承担相应责任):

    1、检查挂载点是否存在或已被占用:根目录下必须建立同名的目录,且为空目录(建议迁移后将原来的文件夹重命名,而不是直接删除,以防万一);

    2、检查/etc/fstab下分区编号是否正确:一般用/dev/sdxN均可,推荐用UUID=XXX的格式(可用blkid查看UUID);

    3、检查新分区中的文件是否正确复制,包括:

        (1)文件大小是否一致(有些文件可能由于权限原因未能被正确复制;或者为特殊文件如块设备、字符设备等);

        (2)文件权限是否一致(一般为root,有的可能还需要可执行权限;建议使用-a参数复制);

        (3)安全上下文是否一致(若不一致,使用chcon --reference进行统一);

    4、若以上操作均不能解决问题,则:

        (1)重启,在引导参数中修改内核参数,于末尾添加selinux=0;

        (2)正常登录;

        (3)再次重启,切换到滚动日志,应当能看到上述"SELinux targeted"的过程。耐心等待5-10分钟;

        (4)完成后系统会自动重启,然后就可以正常使用啦!


后记(2015.04.25)

  今天编译安装clonezilla的时候各种mount、unmount,结果到了下午发现无法自动认证了,比如文件管理器中执行挂载命令,不会弹出窗口提示输入密码,而是直接提示“You are not authorized to perform this operation: Not authorized to perform operation"。一开始以为是yum升级导致的问题,查了一些polkit的文档后将polkit降级,无果;将selinux-policy降级,亦无果。后来在启动日志上看到“audit.service"失败,联想到可能又是selinux蛋疼的问题,所以重复以上relabeling步骤,结果就好了o(╯□╰)o……个人认为是udisk或polkit本身的bug所致,在频繁(非正常)认证操作过程中将权限设置文件的安全上下文信息毁坏了,所以就无法识别了,所以就没法自动sudo了(开始菜单里连重启关机的选项都木有了好不好!)。

所以捏,尽管权限控制是个好东东,但是出了问题也是会要命滴……

转载本站文章请注明,转载自:WTZ的小博[ http://wiblog.net/]
知识共享许可协议 本作品采用知识共享署名 4.0 国际许可协议进行许可。

更多