更新glibc版本-GLIBC升级有风险,操作前最好请预先写好离职申请书

博主在尝试升级GNU C Library (glibc)到2.25版本时遇到问题,导致系统命令无法使用。通过从另一台正常虚拟机挂载磁盘并恢复旧版glibc,最终成功修复了损坏的虚拟机。此过程中涉及到磁盘挂载、依赖库的替换等操作,博主分享了恢复方法和经验教训。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

花几分钟记录一下这次事故,起因是这样的,我在用openssl工具生产证书的时候,提示我要用GNULIBC版本2.25
以上的版本,但是我看了下我的系统的GNULIBC的版本是2.17的,于是一顿操作猛如虎,我自信地开始了我的升级
之旅,但是到make install那儿的时候,我发现失败了,于是我用另一个终端打开准备看看怎么回事,但是非常
残酷的现实就是这时候pwd,ls等命令都不可以用了,于是我强制关了机,试图用重启大法来结束这一场失败的升
级,但是厄运才刚刚开始,我已经不能打开我的虚拟机的,我的心要碎了,慌得要命,这个虚拟机上有我平时写的
很多珍贵的测试程序和学习的痕迹,于是我在搜索很多帖子没有进展的情况下,在一个技术群里将情况描述了以后
问如何才可以恢复,好心人们和我简单说了下,大概有以下两种:
(1)用快照恢复(但是我没有存快照);
(2)再建一个虚拟机,把原来的磁盘挂载上,把glibc改回来,或者直接看提示一步一步修改。

根据我的实际情况,很显然第二种方式是符合我这次的恢复方案的,于是我加了提出第二种方式恢复环境的大哥的
微信,再说一下我拥有的机器的背景:
(1)机器A,机器B,A和B都是由同一个centos7的镜像安装的;
(2)机器A是被我升级弄坏的那台机器,机器B完好无损.

于是在大哥的帮助下,我登录了B机器,然后开始将A机器的磁盘挂载到B机器下,让B机器对A机器中的相关glibc
库进行恢复,开始的时候只恢复了libc.so.6的指向,让其指向libc-2.17.so,但是将盘重新挂回A机器的时候,
A机器仍然不可以重启,百思不得其解,但是此时,我最起码可以保证我的A机器中的盘的内容可以保存下来不会
丢失了,剩下的就是我对A机器上各种安装的软件的执着,我一定要重启登录A机器,大哥离我而去了,这位大哥
真的是个好心人,我和他素昧平生,真真实实的感谢他。之后,我开始了孤独之旅,我重新通过B机器去访问A机
器中磁盘上的内容,发现我的A机器那个/usr/lib64目录下在经过编译2.25版本的glibc之后还生成了其他的动
态库和静态库,我在想是不是它们的原因,我lld了一下libc-2.17.so,对其依赖库进行了分析,然后把所有新
生成的库都用B机器的原装的老库进行更新,大概好几十个,我慢慢坚持了下来,然后奇迹发生了,我再次登录
A机器的时候,出现了最后一个图片的样子,我可以登录了!!!激动。这就是我本次的glibc的升级惨痛教训,
我已经放弃升级了,也掌握了这种情况下,如何恢复一个虚拟机的方法,感谢!!

我的机器最初的libc的版本是2.17 

Linux升级glibc_坡度爱好者的博客-CSDN博客_升级glibc

../glibc-2.25/configure  --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
[root@localhost opt]# echo $LD_LIBRARY_PATH
:/usr/local/lib
[root@localhost opt]# export LD_LIBRARY_PATH=
[root@localhost opt]# echo $LD_LIBRARY_PATH
 
[root@localhost opt]# ./glibc-2.14/configure 

高危操作,我GG了,pwd,yum都不能用了 

高危操作引导符

阅读链接

B机器对A机器的盘进行挂载及卸载的命令

[root@wknode exdata]# mount /dev/sdb1 ./sdb1
[root@wknode exdata]# mount /dev/sdb3 ./sdb3
[root@wknode exdata]# umount /dev/sdb1
[root@wknode exdata]# umount /dev/sdb3

[muten003@wknode lib64]$ ls -lrth | grep "Mar 16"
-rwxr-xr-x   1 root     root      847K Mar 16 18:43 ld-2.25.so
-rw-r--r--   1 root     root       253 Mar 16 18:43 libc.so
-rw-r--r--   1 root     root      4.1K Mar 16 18:43 crt1.o
-rw-r--r--   1 root     root      7.0K Mar 16 18:43 gcrt1.o
-rw-r--r--   1 root     root      1.2K Mar 16 18:43 Mcrt1.o
-rw-r--r--   1 root     root      4.1K Mar 16 18:43 Scrt1.o
-rw-r--r--   1 root     root      2.6K Mar 16 18:43 crti.o
-rw-r--r--   1 root     root      2.4K Mar 16 18:43 crtn.o
-rwxr-xr-x   1 root     root       20K Mar 16 18:43 libBrokenLocale-2.25.so
lrwxrwxrwx   1 root     root        20 Mar 16 18:43 libBrokenLocale.so -> libBrokenLocale.so.1
-rw-r--r--   1 root     root       22K Mar 16 18:43 libBrokenLocale.a
drwxr-xr-x.  2 root     root      8.0K Mar 16 18:44 gconv
-rw-r--r--   1 root     root       141 Mar 16 18:44 libm.so
-rwxr-xr-x   1 root     root      4.1M Mar 16 18:44 libm-2.25.so
-rw-r--r--   1 root     root      3.0K Mar 16 18:44 libieee.a
-rw-r--r--   1 root     root      7.6M Mar 16 18:44 libm-2.25.a
-rw-r--r--   1 root     root       102 Mar 16 18:44 libm.a
-rwxr-xr-x   1 root     root       96K Mar 16 18:44 libdl-2.25.so
lrwxrwxrwx   1 root     root        10 Mar 16 18:44 libdl.so -> libdl.so.2
-rw-r--r--   1 root     root       53K Mar 16 18:44 libdl.a
-rwxr-xr-x   1 root     root       48K Mar 16 18:44 libmemusage.so
-rw-r--r--   1 root     root       11K Mar 16 18:44 libmcheck.a
-rw-r--r--   1 root     root      2.8K Mar 16 18:44 libg.a
-rw-r--r--   1 root     root       22M Mar 16 18:44 libc.a
-rw-r--r--   1 root     root       73K Mar 16 18:44 libc_nonshared.a
-rwxr-xr-x   1 root     root      9.8M Mar 16 18:44 libc-2.25.so
lrwxrwxrwx   1 root     root        20 Mar 16 18:46 libasprintf.so.0 -> libasprintf.so.0.0.0
lrwxrwxrwx   1 root     root        21 Mar 16 18:46 libgettextpo.so.0 -> libgettextpo.so.0.5.4
lrwxrwxrwx   1 root     root        12 Mar 16 18:46 libm.so.6 -> libm-2.25.so
lrwxrwxrwx   1 root     root        13 Mar 16 18:46 libdl.so.2 -> libdl-2.25.so
lrwxrwxrwx   1 root     root        23 Mar 16 18:46 libBrokenLocale.so.1 -> libBrokenLocale-2.25.so
lrwxrwxrwx   1 root     root        10 Mar 16 18:46 ld-linux-x86-64.so.2 -> ld-2.25.so
drwxr-xr-x.  2 root     root        92 Mar 16 18:46 gettext
lrwxrwxrwx   1 root     root        21 Mar 16 18:46 libgettextpo.so -> libgettextpo.so.0.5.4
lrwxrwxrwx   1 root     root        20 Mar 16 18:46 libasprintf.so -> libasprintf.so.0.0.0
lrwxrwxrwx   1 root     root        12 Mar 16 21:36 libc.so.6 -> libc-2.17.so

卧槽~~~还好没放弃~~~~~~~~~流下激动的眼泪~~~~它回来了

谢谢好心人帮我!!!

<think>好的,我现在需要帮助用户解决如何在Linux中安全升级GLIBC的问题。首先,我得回想一下自己之前学过的关于GLIBC升级的知识,以及相关的步骤和注意事项。 首先,用户提到了参考内容中的引用[1]和[2],里面提到了升级glibc 2.25.90版本,以及升级过程中需要处理Python、make、gcc等依赖。这说明升级GLIBC并不是一个简单的过程,可能需要先更新其他工具链的组件。我需要确认这些依赖是否必须,以及正确的升级顺序。 接下来,我需要考虑用户的环境。用户提供的系统信息是Ubuntu 14.04,内核版本3.19.0-25-generic,这是一个较旧的版本升级GLIBC可能会影响系统稳定性,特别是如果系统中有很多依赖于旧版本glibc的应用程序。因此,安全升级的关键在于不破坏现有环境,可能需要使用chroot或容器技术,或者在测试环境中进行。 然后,按照引用[2]中的步骤,升级过程包括下载软件包、解压、检查依赖、升级Python、make、gcc,然后编译安装新版本glibc。但需要验证这些步骤是否正确,是否存在潜在问题。例如,升级gcc可能需要先安装较新版本的编译器,而编译glibc可能需要特定的配置选项,比如--prefix=/usr,这可能会覆盖系统原有的文件,导致系统无法启动。因此,是否应该将新版本glibc安装到单独的目录,并通过环境变量如LD_LIBRARY_PATH来引用?或者使用符号链接?但这样可能有风险。 另外,用户提到的“安全,高效,优雅”的方法,可能需要使用非侵入式的方式,比如在容器中安装新版本,或者使用动态链接库的路径来加载新版本,而不替换系统默认的glibc。例如,使用patchelf工具修改可执行文件的库路径,但这可能比较复杂。 还要注意,编译glibc需要满足其构建依赖,比如GNU make、bison等,这些是否已经安装?用户是否需要先安装这些工具? 在步骤中,可能需要详细说明每个步骤的具体操作,例如如何下载正确的glibc版本,如何配置编译选项,如何运行make install,以及安装后的验证步骤,如运行ldd --version或检查/lib/x86_64-linux-gnu/libc.so.6。 此外,用户可能需要了解如何回滚,如果在升级后出现系统问题,如何恢复原来的glibc版本。这可能需要备份原有的库文件,或者在安装时保留旧版本,但实际操作中可能困难,因为glibc是核心库,一旦替换可能无法轻易回退。 另外,是否建议用户直接升级整个系统到更新的Ubuntu版本,比如16.04或18.04,因为这些版本可能已经包含了较新的glibc,从而避免手动升级风险?这可能是一个更安全高效的方法,但用户可能因为某些原因不能升级系统,所以需要提供手动升级的方法。 最后,生成的相关问题需要围绕升级GLIBC的注意事项、依赖管理、验证步骤以及替代方案等方面展开,帮助用户全面理解可能遇到的问题和解决方案。</think>### 如何在Linux中安全升级GLIBC版本 GLIBC(GNU C Library)是Linux系统的核心库,直接升级存在较高风险。以下为**安全升级步骤**及注意事项: --- #### **一、准备工作** 1. **备份系统** 使用`rsync`或创建快照,避免升级失败导致系统无法启动[^2]。 2. **检查当前版本** ```bash ldd --version ``` 输出示例:`ldd (Ubuntu GLIBC 2.19-0ubuntu6) 2.19` 3. **下载GLIBC源码** 从[官方仓库](https://www.gnu.org/software/libc/)下载稳定版本(如2.35),避免使用开发版[^1]。 --- #### **二、解决依赖问题** GLIBC编译依赖较新的工具链: 1. **升级Python** - 下载Python 3.7+源码,配置时指定独立路径(如`/opt/python3.7`),避免覆盖系统默认版本[^2]。 - 编译命令: ```bash ./configure --prefix=/opt/python3.7 make && sudo make install ``` 2. **升级GCC** - 下载GCC 6+源码,编译时使用`--disable-multilib`减少兼容性问题: ```bash ./configure --disable-multilib --prefix=/opt/gcc-12 make && sudo make install ``` - 更新环境变量: ```bash export PATH=/opt/gcc-12/bin:$PATH export LD_LIBRARY_PATH=/opt/gcc-12/lib64:$LD_LIBRARY_PATH ``` --- #### **三、编译安装GLIBC** 1. **解压并配置** ```bash tar -xzvf glibc-2.35.tar.gz cd glibc-2.35 mkdir build && cd build ../configure --prefix=/usr --disable-profile ``` - `--prefix=/usr`:覆盖系统路径(高风险!建议测试环境操作) - 或使用独立路径(如`/opt/glibc-2.35`) 2. **编译与安装** ```bash make -j$(nproc) sudo make install ``` 3. **验证安装** ```bash /lib/x86_64-linux-gnu/libc.so.6 | grep "GNU C Library" ``` --- #### **四、安全建议** 1. **使用容器隔离** 通过Docker或LXC部署新GLIBC环境,避免污染宿主机[^2]。 2. **回滚方案** 保留旧版本动态库,通过`LD_PRELOAD`临时切换: ```bash export LD_PRELOAD=/old/glibc/path/libc.so.6 ``` --- #### **五、替代方案** - **升级Linux发行版** Ubuntu 20.04+默认提供GLIBC 2.31+,避免手动升级风险---
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值