我在EC2微型盒上运行亚马逊linux。 最近我跑sudo yum update --security ，希望它会修补Heartbleed。 不幸的是我在更新过程中耗尽内存，有些软件包没有成功修补。 我试图通过重新启动然后运行sudo yum clean然后sudo yum update来解决这个问题，如下面的pastebin所示，但依赖性问题仍然存在。
我怎样才能解决这个问题，而不会破坏什么？
这里是从yum输出的剪辑：
Error: initscripts conflicts with util-linux-ng-2.17.2-13.17.amzn1.i686 Error: initscripts conflicts with util-linux-ng-2.17.2-13.17.amzn1.x86_64 Error: Package: glibc-devel-2.12-1.107.43.amzn1.x86_64 (@amzn-main) Requires: glibc-headers = 2.12-1.107.43.amzn1 Removing: glibc-headers-2.12-1.107.43.amzn1.x86_64 (@amzn-main) glibc-headers = 2.12-1.107.43.amzn1 Updated By: glibc-headers-2.17-36.81.amzn1.x86_64 (amzn-updates) glibc-headers = 2.17-36.81.amzn1 Available: glibc-headers-2.17-36.80.amzn1.x86_64 (amzn-main) glibc-headers = 2.17-36.80.amzn1
以下是完整的控制台日志： http : //sebsauvage.net/paste/? e0f7235450f97bae#qq6QKe/ Co+jR2T4FXfGo4w2H8aw7xZkE4z+iZXdMpQ8=
重新安装失败RPMS
我看到这个问题发生在RPM事务中失败的时候。 RPM数据库可能会与系统不同步。 因此，系统实际上具有什么以及RPM认为安装了什么。
提示：在做任何这些之前创build一个AMI图像，以便您可以很容易地恢复，如果事情完全失败。
您可以使用rpm -qa --last获取最近安装的RPM列表。
然后重buildrpm数据库， rpm --rebuilddb 。
然后，您可以使用yum reinstall安装任何失败的交易的一部分包。
这也应该拿起任何依赖性问题，并试图纠正它们。
在某些情况下，我必须通过下载rpm yum download并使用rpm来执行安装来手动解决冲突。
如果您必须恢复到使用rpm进行手动安装，请保留详细的注释，特别是涉及到glibc时。
build议
我强烈build议您在AWS上部署操作，以便轻松启动新的EC2实例，而不用担心这些问题。 如果您为您的数据使用专用的EBS卷并将您的configuration文件存储在其他地方，则通常可以启动一个新实例并比debugging这样的RPM问题更快地恢复运行。 当我们遇到像这样的EC2问题时，我们通常会从自定义的AMI中部署一个新的实例，重新映射IP并完成它。 如果需要的话，我们可以在发生故障/损坏的系统上进行根本原因分析，而不会影响生产操作。