使用fedora的live-rescure模式恢复系统

news/2025/1/11 6:17:27/

原因：
之前由于操作不当，使用系统root权限修改了/lib64/libz.so.1的文件名为/lib64/libz.sozw.1 ，导致了之后无法使用sudo，su等之类的需要动态加载系统库的命令，更严重的是重新启动虚拟机后直接卡在了系统初始化里，无法再次进入系统了。

分析：
由于是修改了/lib64/libz.so.1的名字引起了这个问题，再把这个文件的名字恢复回去应该就可以正常进入系统了。
详细了解一下，使用ls -al 查看 /lib64/libz.so.1：

lrwxrwxrwx. 1 root root 13 Sep  8  2015 /lib64/libz.so.1 -> libz.so.1.2.8

其实它是一个符号链接，指向/lib64/libz.so.1.2.8

操作：
使用硬盘上的fedora23镜像已经无法完成初始化进入系统了，那就需要使用其他的方法引导进入系统，然后恢复回/lib64/libz.sozw.1的文件名。
使用的方法是用下载与硬盘版镜像对应的iso文件，然后使用u盘或光驱加载该iso文件，进入live-rescure模式。注意，在操作时不要选中 install to driver，这是重新安装系统了，会覆盖之前的系统文件。
以下为具体的操作。

首先把非系统盘卸载掉。我是从win的虚拟机配置里操作的，以免误操作损坏硬盘文件。
然后查看一下当前系统的挂载情况：


[liveuser@localhost ~]$ sudo fdisk -lWe trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:#1) Respect the privacy of others.#2) Think before you type.#3) With great power comes great responsibility.Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd1e562e0Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048  1026047  1024000  500M 83 Linux
/dev/sda2        1026048 41943039 40916992 19.5G 8e Linux LVM
/dev/sda3       41943040 83886079 41943040   20G 8e Linux LVMDisk /dev/loop0: 12 KiB, 12288 bytes, 24 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/loop1: 1.8 MiB, 1888256 bytes, 3688 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/loop2: 1.3 GiB, 1387098112 bytes, 2709176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/loop3: 6 GiB, 6442450944 bytes, 12582912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/loop4: 512 MiB, 536870912 bytes, 1048576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/mapper/live-rw: 6 GiB, 6442450944 bytes, 12582912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/mapper/live-base: 6 GiB, 6442450944 bytes, 12582912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/mapper/live-osimg-min: 6 GiB, 6442450944 bytes, 12582912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/mapper/fedora-swap: 2 GiB, 2147483648 bytes, 4194304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/mapper/fedora-root: 37.5 GiB, 40269512704 bytes, 78651392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

可以看见有一个sda的硬盘，我在之前安装时划分的分区是/dev/sda1为swap，/dev/sda2为root，/dev/sda3为后来扩展给root使用的。在上面的结果中可以看到。


Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048  1026047  1024000  500M 83 Linux
/dev/sda2        1026048 41943039 40916992 19.5G 8e Linux LVM
/dev/sda3       41943040 83886079 41943040   20G 8e Linux LVM

现在要做的就是把/dev/sda2 挂载到/mnt中去。但是由于它的文件系统为LVM而不是ext4/ext3/ext2之类的文件系统，所以不能直接使用mount /dev/sda2 /mnt这样的操作，这样无法挂载。

LVM是 Logical Volume Manager（逻辑卷管理）的简写，它是Linux环境下对磁盘分区进行管理的一种机制。可以看成它是建立在ext4/ext3/ext2等这些文件系统之上更高一层的文件系统，这么做的实际意义就是可以把一个文件跨分区存放，即文件的一部分存在/dev/sda2上面，剩下的一部分存在/dev/sda3上。而对于用户来说，就要使用卷组这个概念来定位文件了，每个卷组都有自己的卷组名，这可以通道vgscan命令来查看当个前的系统都有哪些卷组。所以此时就不能再说文件1在/dev/sda2上了，因为有可能还有一部分文件在/dev/sda3上。

此时执行扫描的结果为：

[liveuser@localhost ~]$ sudo vgscanReading all physical volumes.  This may take a while...Found volume group "fedora" using metadata type lvm2
[liveuser@localhost ~]$

即系统中只有一个卷组，名为fedora。

下面要做的就是激活这个卷组，然后再挂载它到目录中，就可以读写了。

[liveuser@localhost ~]$ sudo vgchange -a y fedora2 logical volume(s) in volume group "fedora" now active
[liveuser@localhost ~]$

可以看到，激活后的结果显示这个卷组中有2个卷。

下面开始挂载。
我尝试将整个卷组挂载到/dev/sda目录下，但是失败了，它提示/dev/fedora这个路径不是指向一个块设备。


[liveuser@localhost ~]$ sudo mount /dev/fedora /mnt/sda/
mount:  /dev/fedora is not a block device

其实，可以使用ls命令查看一下/dev/fedora

[liveuser@localhost ~]$ ls /dev/fedora 
root  swap
[liveuser@localhost ~]$

即在它下面还有两个节点，这两个节点才是真正的block device，所以需要重新指定需要挂载的设备：


[liveuser@localhost ~]$ sudo mount /dev/fedora/root /mnt/sda/
[liveuser@localhost ~]$ ls /mnt/sda/
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[liveuser@localhost ~]$ ls /mnt/sda/home/
tftpboot  zhangwei  zhumeng
[liveuser@localhost ~]$ cd /mnt/sda/
[liveuser@localhost sda]$ ls
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[liveuser@localhost sda]$ ls -al
total 96
dr-xr-xr-x.  19 root root  4096 Dec 16 02:57 .
drwxr-xr-x.   3 root root  4096 Feb 27 01:45 ..
lrwxrwxrwx.   1 root root     7 Sep 10  2015 bin -> usr/bin
drwxr-xr-x.   2 root root  4096 May 16  2016 boot
drwxr-xr-x.   2 root root  4096 May 16  2016 dev
drwxrwxr-x.   4 root 1001  4096 May 22  2016 .esmtp_queue
drwxr-xr-x. 151 root root 12288 Feb 23 20:42 etc
drwxr-xr-x.   5 root root  4096 May 30  2016 home
lrwxrwxrwx.   1 root root     7 Sep 10  2015 lib -> usr/lib
lrwxrwxrwx.   1 root root     9 Sep 10  2015 lib64 -> usr/lib64
drwx------.   2 root root 16384 Oct 29  2015 lost+found
drwxr-xr-x.   2 root root  4096 Sep 10  2015 media
drwxr-xr-x.   3 root root  4096 May 19  2016 mnt
drwxr-xr-x.   2 root root  4096 Sep 10  2015 opt
drwxr-xr-x.   2 root root  4096 May 16  2016 proc
dr-xr-x---.   6 root root  4096 Dec 16 02:58 root
drwxr-xr-x.   2 root root  4096 May 16  2016 run
lrwxrwxrwx.   1 root root     8 Sep 10  2015 sbin -> usr/sbin
drwxr-xr-x.   2 root root  4096 Sep 10  2015 srv
drwxr-xr-x.   2 root root  4096 May 16  2016 sys
drwxrwxrwt.   8 root root  4096 May 16  2016 tmp
drwxr-xr-x.  13 root root  4096 May 23  2016 usr
drwxr-xr-x.  22 root root  4096 Feb 22 08:38 var
[liveuser@localhost sda]$ ls
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

此时已经挂载成功了，可以读写/dev/fedora/root对应的文件系统了。
后来我把/lib64/libz.sozw.1改为/lib64/libz.so.1之后系统就能自己启动了。

完。


http://www.ppmy.cn/news/819845.html

相关文章

Request

Request

request对象和response对象的原理 通过url访问资源的大概过程，如下 我们需要注意 request和response对象是由服务器创建的。我们只是来使用它request对象是来获取请求消息的，response对象是来设置响应消息的 request对象的继承体系 RequestFacade类…
阅读更多...
不小心删除了双系统的ubuntu分区无法进入ubuntu,出现grub rescure

不小心删除了双系统的ubuntu分区无法进入ubuntu,出现grub rescure

今天本来想在磁盘管理那里把一个没有用的J盘格式化一下,哪成想把J右键格式化并删除卷后，存放双系统ubuntu的几个分区也莫名其妙不见了，合并在一起成了“可用空间”。带着一种不详的预感，我重启电脑进ubuntu，果然进不去了。画面显示…
阅读更多...
Resful

Resful

RESTful：一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。 说到RESTful就必须说下REST；REST描述了一个架构样式的网络系统；REST指的是一组架构约束条…
阅读更多...
grub rescure 解决方案

grub rescure 解决方案

此为收藏，原贴：http://www.linuxidc.com/Linux/2012-07/65249.htm 1. 先使用ls命令，找到Ubuntu的安装在哪个分区： grub rescue>ls 会罗列所有的磁盘分区信息，比方说： (hd0),(hd0,msdos3),(hd0,msdos2)…
阅读更多...
RESTRESRful

RESTRESRful

RESTful API编写指南RESTful架构风格概述REST架构风格 REST 1、什么是REST？ “REST不是一种协议，也不是一种文件格式，更不是一种开发框架。它是一系列设计约束的集合。” --是一组架构约束条件和原则。 REST描述的是在网络中client和serv…
阅读更多...
[Linux]记录一次grub rescure的过程

[Linux]记录一次grub rescure的过程

事情的起因是台式机装的双系统，给Linux分的磁盘满了，于是进PE释放Window的磁盘，但是重启时没有及时把“老毛桃”拔下来，导致grub引导被破坏，于是就有了本篇文章。 另外，本文的第二部分介绍了一下&#xff…
阅读更多...
rescure救援模式

rescure救援模式

rescure救援模式 不知道大家有没有遇到这种情况，当你误删一些文件，导致你的系统无法正常工作呢？这要怎么办呢？遇到这种情况，你可以试一下linux的救援模式。首先说一下什么是linux救援模式。linux救援模式本质就是一个小…
阅读更多...
CentOS Rescure救援模式恢复数据记录

CentOS Rescure救援模式恢复数据记录

一．一个核心业务服务器，系统盘出现故障，症状如下： 所有命令不能用下图是事后在事故机器查到的日志 EXT4-fs error (device sda7): __ext4_get_inode_loc: unable to read inode block - inode10360871, block41419170 EXT4-fs e…
阅读更多...
最新文章

Copyright @ 2022~2023