落红逐青裙

　　昨天面试前想进ubuntu复习一下自己写的shell脚本，却发现引导ubuntu失败了。ubuntu的图标出现后就黑屏，按任意键，屏幕上就出现提示:

　　这个问题上学期曾经碰到过的，当时在网上搜索无果，于是重装了系统。但问题是现在我的ubuntu下已经存了很多代码，就算无法修复，我至少也得把代码给备份回来。

　　于是就开始在网上瞎逛，关于这个问题众说纷纭，有说内核损坏的，有说系统来不及加载驱动程序的，但是感觉都不靠谱。我用实验室电脑上的ubuntu9.10制作了个启动盘，用Palimpsest磁盘实用工具查看硬盘，发现安装ubuntu那一块分区被标注为“未知、无法辨识”了。这种问题我从没碰到过，上网找了个磁盘修复的命令fsck，检查了一遍这个分区 “/dev/sda6″，接着mount到/foo，发现访问没问题，于是赶紧先备份了代码。

　　重新启动以后，ubuntu仍然启动失败，郁闷的是”/dev/sda6″明明可以访问啊……我重新用启动盘挂载了该分区，查看/boot/grub/menu.lst文件，发现有件奇怪的事情，menu.lst中的example的kernel，有一句关于root的信息 “root=/dev/hda2″。而实际启动时，kernel项则把一个很奇怪的叫uuid的字符串给了root。

　　我觉得直接用分区路径来启动是肯定可行的，于是把原来的kernel行注释，加了一行

　　重启后，终于进入了9.10的登录界面！
　　重新用磁盘实用工具检查，ubuntu所在分区还是未知，用命令

查看所有分区的uuid,却发现没有”/dev/sda6″。使用失效的uuid，这就是引导失败的原因所在啊。稍微google了下，据介绍uuid可以不受硬盘中其他分区的变化影响，因此比直接用分区路径安全，但前提是分区大小不能改变。至于怎么把ubuntu所在分区恢复为出问题以前的状态我也不是很清楚，希望能在论坛中尽快找到答案吧。

Update: 在Ubuntu中文社区上找到了答案，用fsck命令扫描并修复文件系统后，ubuntu所在分区就恢复正常了。