☰

由于“输入/输出错误”而无法 chroot - 文件和磁盘似乎正常

tag-icon • tag-icon chroot fsck smartctl
由于“输入/输出错误”而无法 chroot - 文件和磁盘似乎正常

我正在尝试在更新过程中计算机崩溃后修复未启动的 Arch 安装（最糟糕的情况）。然而，chroot失败了。

尝试过这个：

# mount /dev/sdb2 /mnt/arch
# cd /mnt/arch
# mount --bind /dev dev
# mount --bind /proc proc
# mount --bind /sys sys
# chroot . bin/bash
chroot: failed to run command ‘bin/bash’: Input/output error
Exit 126

该文件实际上可以正常读取：

# sha256sum  bin/bash
3695f983ad6a1387826f769b96488f24e3635a1501fe89c96d3eadfa4e04caf7  bin/bash

让我们检查文件系统和磁盘

# umount sys
# umount proc
# umount dev
# cd ..
# umount arch
# fsck -f /dev/sdb2

（没有报告错误）

# smartctl -a /dev/sdb

（没有报告错误）

磁盘是SSD，不是很旧。 dmesg不显示任何相关的内核错误消息。

PS/编辑：

# chroot . bin/bash

和

# chroot . /bin/bash

当他们处理同一个文件时给出相同的错误。它存在（参见sha256sum命令）。

编辑2：@roaima 指出要检查库：

# ldd bin/bash 
    linux-vdso.so.1 (0x00007fff16563000)
    libreadline.so.8 => /lib64/libreadline.so.8 (0x00007f6483600000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f64835f8000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f6483430000)
    libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f64833f8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f6483778000)

然后检查这些/mnt/arch：

# ls -ld ./lib64/ld-linux-x86-64.so.2 ./lib64/ld-2.29.so ./usr/lib/libdl.so.2 ./usr/lib/libdl-2.29.so
-rwxr-xr-x 1 root root  0 Jun 23 10:33 ./lib64/ld-2.29.so
lrwxrwxrwx 1 root root 10 Jun 23 10:33 ./lib64/ld-linux-x86-64.so.2 -> ld-2.29.so
lrwxrwxrwx 1 root root 13 Jun 23 10:33 ./usr/lib/libdl.so.2 -> libdl-2.29.so
-rwxr-xr-x 1 root root 0 Jun 23 10:33 ./usr/lib/libdl-2.29.so

因此，最基本的系统库的大小是 0，因为在可以想象的最不合适的时刻发生了崩溃 - glibc.

答案1

在 roaima 的推荐之后，我检查了我想要chroot进入的 Arch Linux 系统的（共享对象）库，特别是二进制文件使用的库bin/bash。这些都坏了；更具体地说，0 大小的文件等/mnt/arch/lib64/ld-2.29.so。/mnt/arch/usr/lib/libdl-2.29.so

为了恢复损坏的 Arch Linux 中的文件，我（在互联网上）搜索了包含损坏的库的软件包文件的名称。这些文件仍然在软件包管理器的软件包缓存中，即

/mnt/arch/var/cache/pacman/pkg/glibc-2.29-3-x86_64.pkg.tar.xz

chroot我像这样解压缩文件（仍在 ing 之前）：

cd /mnt/arch
tar --wildcards -xvJf var/cache/pacman/pkg/glibc-2.29-3-x86_64.pkg.tar.xz usr/lib/\*

它从包文件中解压与“usr/lib/*”匹配的所有文件。

这之后，我确实可以chroot如愿了。我做的第一件事就是pacman -Syu完成失败的更新。

边注：Arch Linux 使用 BSDtar来打包/解包软件包文件，我使用 GNU tar。这可能（通常）有时会产生问题，因为 GNUtar不处理（解包和设置）BSD tar( bsdtar) 保留/设置的特殊文件属性。不过，由于这些库文件（显然）不需要任何属性，所以我很好。

答案2

难道不应该吗/bin/bash？如果没有，也许某个进程正在使用一些需要的文件，可以通过以下方式检查lsof

相关内容