这个问题的动机是我不再能够在我的Red Hat机器上使用debootstrap创建一个正常运行的chroot。大约一年,许多红帽更新前我能够。
sudo debootstrap --arch amd64 trusty trusty http://archive.ubuntu.com/ubuntu
sudo chroot trusty
结果:
groups: cannot find name for group ID 0
groups: cannot find name for group ID 1027
I have no name!@wsdev66:/#
这是意外行为,以及非功能性chroot。预期的输出是root @ wsdev66:/#。谷歌让我相信运行/ debootstrap / debootstrap --second-stage会解决这个问题,但是那里不存在具有该名称的脚本或二进制文件。有一个名为debootstrap.log的日志文件,其内容为:
gzip: /usr/share/debootstrap/devices.tar.gz: Permission denied
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
似乎是失败的chroot的来源。
ls表示所有人的读取权限:
ll /usr/share/debootstrap/devices.tar.gz
-rw-r--r--. 1 root root 3518 Apr 6 09:33 /usr/share/debootstrap/devices.tar.gz
检查ACL,即使不存在ACL,从上一个命令的结果判断:
getfacl /usr/share/debootstrap/devices.tar.gz
getfacl: Removing leading '/' from absolute path names
# file: usr/share/debootstrap/devices.tar.gz
# owner: root
# group: root
user::rw-
group::r--
other::r--
所有父目录都由root:root拥有,并具有权限:drwxr-xr-x。
cp /usr/share/debootstrap/devices.tar.gz ~
cp: cannot open `/usr/share/debootstrap/devices.tar.gz' for reading: Permission denied
我认为这是不正确/意外的。 为什么我不能复制此文件或成功创建chroot?
系统信息:
Linux 主机名 2.6.32-431.11.2.el6.x86_64#1 SMP Mon Mar 3 13:32:45 EST 2014 x86_64 x86_64 x86_64 GNU / Linux
LSB版本:: base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing -4.0-noarch
分销商ID:RedHatEnterpriseWorkstation
描述:红帽企业Linux工作站6.5版(圣地亚哥)
发布:6.5
代号:圣地亚哥
安装:
/ dev / mapper / vg_ngdw-lv_root on / type ext4(rw)
答案 0 :(得分:1)
我可以通过停止所有McAfee服务来解决此问题:
sudo /opt/isec/ens/threatprevention/bin/isectpdControl.sh stop
sudo /opt/isec/ens/esp/bin/isecespdControl.sh stop
参考:https://kc.mcafee.com/corporate/index?page=content&id=KB88223
答案 1 :(得分:0)
RHEL 6.5不正式支持McAfee VSE for linux 1.9。
dmesg显示:
linuxshield module is older than RHEL 6.2 ... applying fixups
McAfee' linuxshield'内核模块导致此问题。奇怪的是,它无法使用modprobe卸载,因为尝试这样做会导致modprobe无法找到' linuxshield'模块,尽管lsmod输出中存在确切的名称。通过停止钉子来移除它。服务解决了这个问题。
也可以通过手动运行khm_setup -c来重新编译内核模块来修复此问题。