OnITRoad - 常见问题
如何重新平衡 BTRFS 文件系统 以释放磁盘空间
如何重新平衡 BTRFS 文件系统 以释放磁盘空间 问题 BTRFS 文件系统已在服务器上填满，因此需要在其上释放一些空间。 btrfs 中有一个重新平衡功能。 重新平衡功能的主要目的是将块组分布在所有设备上，以便它们匹配由相应配置文件定义的约束，这是在 btrfs 需要重新平衡以解决块不平衡的问题时完成的。 解决方案 由于 btrfs 设备不会重新平衡块并且文件系统因此而变满，因此 bt
Views：0 2020-09-17
如何从 CentOS/RHEL 中启用的存储库重新创建 yum 缓存（强制获取缓存数据）
如何从 CentOS/RHEL 中启用的存储库重新创建 yum 缓存（强制获取缓存数据） 这篇文章简要说明了如何重新创建 yum 缓存，或者换句话说，强制从启用的 yum 存储库中获取缓存数据。 启用的 yum 存储库是以下文件 /etc/yum.conf 或者以下文件夹 /etc/yum.repos.d 中的那些，它们的“启用”设置为“1”，例如 ： # vi /etc/yum.repos.d/
Views：0 2020-09-17
如何重新创建 Yum 缓存， 强制获取已启用存储库的包列表
如何重新创建 Yum 缓存， 强制获取已启用存储库的包列表 这篇文章简要概述了如何重新创建 yum 缓存，或者换句话说，强制从启用的 yum 存储库中获取缓存数据。 启用的 yum 存储库是以下文件 /etc/yum.conf 或者以下文件夹 /etc/yum.repos.d 中的那些，它们的“启用”设置为“1”，例如 ： [public_ol6_latest] name=Oracle Linux
Views：0 2020-09-17
如何在 CentOS/RHEL 7 中使用当前内核为 Rescue Kernel 重新生成 initramfs 和 vmlinuz
如何在 CentOS/RHEL 7 中使用当前内核为 Rescue Kernel 重新生成 initramfs 和 vmlinuz 我们想在 CentOS/RHEL 7 系统中为 Rescue Kernel 重新生成 initramfs 和 vmlinuz。 如何使用启动系统的当前内核来完成此操作？ 在启动过程中，当内核镜像和 initramfs 镜像被加载时，initramfs 启动系统上的第
Views：0 2020-09-17
在 CentOS/RHEL/OEL 7 中如何在 MSDOS 分区类型上重建 GRUB
在 CentOS/RHEL/OEL 7 中如何在 MSDOS 分区类型上重建 GRUB 问题： 如何在具有 MSDOS 分区类型的 Linux 服务器上重建 Grub。 (proc) (hd0) (hd0,msdos5) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1) 在 Grub 提示符下执行以下命令以设置根设备并加载引导镜像并初始化引导加载程序。 >
Views：0 2020-09-17
如何在 CentOS/RHEL 6 和 7 中使用多路径重建“initramfs”
如何在 CentOS/RHEL 6 和 7 中使用多路径重建“initramfs” initramfs 包含启动所需的所有硬件的内核模块，以及进入下一启动阶段所需的初始脚本。 在 CentOS/RHEL 系统上，initramfs 包含一个完整的操作系统（可用于故障排除目的）。 有时，initramfs 镜像也可能会损坏。 如果发生这种情况，我们将无法将服务器引导至正常操作模式。 要在启动到救援环
Views：0 2020-09-17
如何在 CentOS/RHEL 5,6 中从救援模式中恢复被损坏的根分区
如何在 CentOS/RHEL 5,6 中从救援模式中恢复被损坏的根分区 这篇文章提供了有关如何恢复损坏的根文件系统的分步说明。 启动服务器失败，根文件系统损坏，如下所示。 Checking all file systems. [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00 /dev/VolGroup00/LogVo
Views：0 2020-09-17
如何使用 vgcfgrestore 在 LVM 中恢复已删除的逻辑卷 (LV)
如何使用 vgcfgrestore 在 LVM 中恢复已删除的逻辑卷 (LV) 我们不小心从卷组 vg01 中删除了逻辑卷 lv01. 现在我们想在不丢失数据的情况下恢复 LV。 按照下面给出的步骤在 VG (vg01) 下恢复 LV (lv01)。 # lvremove vg01/lv01 Do you really want to remove active logical volume vg
Views：0 2020-09-17
CentOS/RHEL 6 中如何恢复 /etc/shadow 和/etc/passwd 文件中被删除的root条目
CentOS/RHEL 6 中如何恢复 /etc/shadow 和/etc/passwd 文件中被删除的root条目 问题 在 /etc/shadow 和 /etc/passwd 中，'root' 条目被删除。 该如何恢复？ 解决方案 为了能够从 /etc/shadow 和 /etc/passwd 文件中恢复被删除的 root 用户条目，我们需要将系统引导到单用户模式。 按照下面的帖子将系
Views：0 2020-09-17
如何从损坏的 RPM 数据库中恢复（如何重建 RPM 数据库）
如何从损坏的 RPM 数据库中恢复（如何重建 RPM 数据库） 为什么 rpm 数据库会损坏 可能有多种原因导致 rpm 数据库损坏。 由于限制，人们无法准确地确定单个 RCA，因为没有监控 rpm 数据库损坏的机制。 每次管理员/某个进程运行任何 rpm 命令时，都会查询 rpm 数据库。 即使在 yum 事务期间，rpm 数据库也会发生重大变化。 小指针也可能导致这种损坏。 如果 LD_L
Views：0 2020-09-17
如何从 CentOS/RHEL 7 中损坏或者空的 /etc/mtab 文件中恢复
如何从 CentOS/RHEL 7 中损坏或者空的 /etc/mtab 文件中恢复 有时我们可能会在运行 df 命令时收到错误消息，指出 /etc/mtab 文件已损坏或者为空（已删除）。 可能是有人不小心编辑了 /etc/mtab 文件并且数据不正确。 好吧，这篇文章将恢复正确的 mtab 文件。 /etc/mtab文件有什么用 在开始之前，让我们看看什么是 mtab 文件。 /etc/mt
Views：0 2020-09-17
如何在 CentOS/RHEL 5,6 中从损坏的引导分区恢复 GRUB
如何在 CentOS/RHEL 5,6 中从损坏的引导分区恢复 GRUB 问题 系统卡在 grub> 提示符下，如下所示。 如何从这种情况中恢复过来。 解决方案 当我们遇到上述错误时，在大多数情况下，引导分区已损坏。 要解决问题，请从 grub 命令行执行： grub> find /grub/stage1 find /grub/stage1 (hd0,0) 上面的命令将查找
Views：0 2020-09-17
如何使用 vgmknodes 在 /dev 目录下重新创建 LVM 设备文件
如何使用 vgmknodes 在 /dev 目录下重新创建 LVM 设备文件 服务器崩溃或者由于人为错误后，在 /dev 目录下看不到卷组设备文件。 系统崩溃后，可能是由于文件系统损坏,设备文件被从文件系统中删除。 # cd /dev # ls vg01 ls: cannot access vg01: No such file or directory 如果我们检查 lvdisplay 命令的输出
Views：0 2020-09-17
如何缩小 Ubuntu 上的 LVM 卷
如何缩小 Ubuntu 上的 LVM 卷 问题 如何减小现有的 LVM 卷的大小，以在 Ubuntu 机器上释放一些空间？ 备份现有数据 在修改任何系统之前，始终建议先创建备份，因为减小 LVM 大小会增加数据损坏的风险。 在大多数情况下，lvreduce 命令会警告可能的数据丢失并要求确认。 但是，我们不应依赖这些确认提示来防止数据丢失，因为在某些情况下我们不会看到这些提示，例如当逻辑卷
Views：0 2020-09-17
如何使用 yum 重新安装损坏的库
如何使用 yum 重新安装损坏的库 这篇文章将指导用户如何通过 yum 重新安装损坏的库。 一般来说，下面的命令会找到损坏的库属于哪个包： # yum provides \*/[so_file] 在此示例中，我们使用此错误消息“/bin/login：加载共享库时出错：/lib64/libcrypt.so.1：file too short”来识别损坏的库并找到它最初来自的包： # yum provi
Views：0 2020-09-17
如何在 CentOS/RHEL 中无需重启即可删除死的多路径设备
如何在 CentOS/RHEL 中无需重启即可删除死的多路径设备 一旦多路径设备关闭，该设备的 I/O 就会被阻止。 在收集 sosreport 或者扫描/刷新磁盘时，这可能会导致挂起。 死多路径设备的示例如下所示： 360060e80166bac0000016bac000000da dm-49 HITACHI,OPEN-V size=200G features='0' hwhandler='0'
Views：0 2020-09-17