[Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x25 (or later)

解决方法:首先输入exit 然后输入

fsck -y /dev/sd **

这里依据出现的提示输入,例如

fsck -y /dev/sda

然后再输入exit进入系统 顺便可以更新一下 输入:

sudo apt-get install intel-microcode 

或者:

sudo apt-get install amd64-ucode

功能说明:检查文件系统并尝试修复错误。
语  法:fsck [-aANPrRsTV][-t <文件系统类型>][文件系统…]
补充说明:当文件系统发生错误四化,可用fsck指令尝试加以修复。
注意:千万不能在运行的系统上面直接执行fsck,特别是RHEL6.0以下ext3的文件系统,否则100%损坏根文件系统,使用fsck -y /dev/sdb1 修复磁盘时,必须将sdb1分区umount掉
参  数:
-a 自动修复文件系统,不询问任何问题。
-A 依照/etc/fstab配置文件的内容,检查文件内所列的全部文件系统。
-N 不执行指令,仅列出实际执行会进行的动作。
-P 当搭配”-A”参数使用时,则会同时检查所有的文件系统。
-r 采用互动模式,在执行修复时询问问题,让用户得以确认并决定处理方式。
-R 当搭配”-A”参数使用时,则会略过/目录的文件系统不予检查。
-s 依序执行检查作业,而非同时执行。
-t<文件系统类型> 指定要检查的文件系统类型。
-T 执行fsck指令时,不显示标题信息。
-V 显示指令执行过程。
fdisk -l 查看设备号
运行 fsck -y /dev/sdb1 修复磁盘 -y参数为自动确认修复
这条命令也是用fsck修复磁盘是,常使用的命令

特别说明:在EXT3(实际上其他文件系统也类似)无法mount,或者提示fsck时,如果有重要数据,应该慎重对待,千万不可贸然执行”fsck -f -y “这样的自动修复功能。如果可能,先对故障区域做dd全镜像后再执行,或者以只读方式执行,并仔细看修复过程,如果提示大量inode错误、需要重建树、或大小不对等就不可再继续下去了。

Linux ext3 fsck一定要慎用

不管是哪种文件系统,其根本目的都是相同的:如何把文件存在系统给定的区域里,如何有效地管理文件的读与写。为实现这样的目的,驱动层需要完善、周密地应付附加在文件系统上的各种操作。这些操作通常不会是一条指令完成的,如果一个过程需要多条指令完成,在执行这些操作时,全部指令未完成的情况下产生中断,那这个文件系统便会出现一致性错误(或者叫连续性错误)。

为了保证尽可以少的出现一致性错误,现在主流的文件系统都会设计成日志型的。日志型文件系统的主要特点就是把一个操作的所有指令执行过程都另外缓冲下来,如果全部执行完成再清除日志标志,如果操作没有执行完成,可以在重新激活后通过日志回溯或继续完成。

EXT3的日志功能通过在EXT2的设计基础上增加一个特殊的文件(通常是8号节点文件),在这个文件中记录文件系统的操作过程。但EXT系统文件系统本身在节点、间接索引块、目录节点方面没有冗余保护,所以当文件系统除日志外的其他结构并不一致,却又要通过fsck来进行修复,这种一致性有可能将原本正确的结构也错误化。(就像原来是1+2=3,现在错成了1+3=3,也许改完后变成了1+3=4,就完全没办法还原成最早的1+2=3)。

数据恢复领域经常会遇到这类情况:一次RAID出故障后,下次启动系统提示做fsck,但做完后,也无法mount分区或者mount 分区后数据全是错的。需要对这类情况进行数据修复的难度是很大的,从一个完整的结构(fsck后实际上从系统角度看已经是完整的了)再构建另一个完全不同的结构要比修正一个错误的结构更难以下手。其实这类情况,很多是因为RAID5有早离线的盘加入了两个逻辑磁盘组,导致所有的数据流是以新+旧的方式交错组成的,自然会有太多错误。这时候如果做fsck后,有可能数据都无法恢复了。

所以,在EXT3(实际上其他文件系统也类似)无法mount,或者提示fsck时,如果有重要数据,应该慎重对待,千万不可贸然执行”fsck -f -y “这样的自动修复功能。如果可能,先对故障区域做dd全镜像后再执行,或者以只读方式执行,并仔细看修复过程,如果提示大量inode错误、需要重建树、或大小不对等就不可再继续下去了。