更新windos 10 系统

今天照样是懒洋洋的一天，开个电脑，看到系统设置有更新，点击了一下

这更新界面，也太不对调调了吧

从这个更新成功的界面之一，你能想到什么？
恩，不错微软总算有点愿意让系统的界面向本国进行本土化界面向导了，而不是出现n久之前的“请坐和放宽”大笑话。没办法，谁让大中国在现在的时代日益强大了呢！(^_)
but，这样生搬硬套中国传统的文化，真的好么？

更新了majora系统

以为本帅只有一个系统的，就天真了，哈哈！

这个就是界面

其实应该是命令行的，but本帅没截图etc@_@

车祸分割线

windows 10 更新重启遇到grub rescue

第一次遇到grub rescue

一切都是好好的，然后突然给本帅整个这小东西出来！//拖出去斩了
不就是命令行么！捣鼓过多种linux系统的本帅当然先自己玩下咯！
ls有东西嘻嘻

启动的时候居然看到了这个

第二次遇到grub rescue

再一次重启又进入上面那个界面。刚好本帅还在遗憾没有截图来来纪念一下遇到的这个问题！继续玩呗！嘻嘻
然后上网搜了一下：

原因

装多系统的时候，可能会破坏系统的开机启动项，也就是/boot/grub/i386-pc/normal.mod文件
所以需要用命令来重新配置这个文件，好吧！
命令本帅玩得多了去了，总不信能比linux的命令还多！反正多本帅也能学！反正命令的套路都一样！反正最后也没发现有几个！(^_)

相关的命令及解释

set 查看、设置环境变量 （后面没有参数的时候就是查看，后面接参数的时候就是设置）
ls 查看设备
insmod modeName 加载名称为modeName模块
root 指定用于启动系统的分区
prefix 设定grub启动路径

在网上看了不少的教程，再结合自己的亲生实践，安装了系统的盘应该就是(hd0,formatName)，中hd后接0的硬盘，formatName后缀数字最大那个。可以优先测试这个，但是为了保险起见，第一次进入grub的话建议都测一遍！不然就可以考虑继续折腾这个磨人的小妖精了！(^_)

流程截图

完整地解决过程

摁下enter键，完美进入系统。

第三次、四次。。遇到grub rescue

到现在也该差不多了。作为开发人员，直觉告诉本帅，因该再次重启一下，看看是否会再次进入grub界面！
恩，进去了，居然进去了！看本帅帅并一脸蒙逼的表情。

分析多次出现的原因

想想本帅的启动界面是majora的，所以启动系统就是majora的锅咯！遂进入这个祸首解决问题咯！

解决之道

直接的解决办法是更新一下grub的版本，算了还是把系统也更新一下好了！(^_)

一言不合就更新系统。。。

然并卵，照样还要进grub界面
之后才知道之前的命令只是解决不能进入系统的问题，并没有修复grub错误的地方。
看来本帅还是too young too simple，表情都不想做了（肯定丑到死@_@），直接奔向死亡的怀抱好了！(^_)

总结解决之道

ls #查看设备
ls (hd0)/boot/grub #查看(hd0）设备的/boot/grub目录
ls (hd0,gpt6)/boot/grub #查看(hd0,gpt6）设备的/boot/grub目录
....
set # 查看环境变量 
set root=hd0,gpt6 # 设置环境变量 启动系统的分区的变量root
set prefix=(hd0,gpt6)/boot/grub  # 设置环境变量 grub启动路径的变量prefix
insmod normal #加载名称为normal 模块
normal #以normal模块启动grub

linux命令行下

sudo update-grub   #更新grub
sudo grub-install /dev/sda #重新进行安装grub

csdn 更多解决之道参考:error: file '/boot/grub/i386-pc/normal.mod' not found解决方案

潘帅的苦逼总之

今天一天就在用在了更新系统，和折腾grub这个小东东上了，真够浪费时间的！QAQ
莫不是本帅今天偷下懒也报应到本帅电脑的操作系统上面？天道不公啊！
虽然打乱了本帅在amos苦心教导下，好不容易才开始弄好的计划，在执行的第一天就延期了。出师不利！wuwuwu
问题出现了，去解决问题是没有什么问题的！
但是花了很长时间的话，就值得去深究、去思考为什么别人分分钟解决的问题，本帅却要花上一天？所谓羊毛出在养身上，反正不会长在本帅身上。。。
就算面对这样的小问题，也不建议在对问题一知半解或全然不解的情况下，草草解决！至少也需要大概了解其中的原理，否者无知堆积多了就出现本帅现在的无能便无敌状况了，实在是需要去学习了才去了解，时间代价太大。假设本帅n久以前在学装系统的时候顺带把grub的原理也看看，那么这种问题应该是被分分钟解决的！

联想到刚刚在土巴兔。。。犯的错
想想上周amos给本帅做的一个需求，花了本帅2天都没解决；修复一个bug，也反复修了好几次都没有修复；都延期到了周一！前两天的代码部分做了很多无用功。
和今天的错类似，问题总是会像幽灵一样总是出现，并且甩也甩不掉，因为压根不知道怎么甩！虽然本帅也解决了所谓的当前的问题，但却没有做一次解决问题，让这些问题或者延伸的bug不在出现！想想都知道这和本帅是不是学生没有半毛钱关系，有关系的就是本帅个人的能力问题、思考力深度的问题、态度端正与否的问题。++怎么得出都有问题的结论来了！QAQ
假设本帅在修bug的时候能态度能够端正一点，写修复代码的时候再看仔细一点代码、多走下流程，那么就不会出现一个简单的bug一而再再而三地去修了！搞的自恋兼脸厚的本帅都觉得羞愧了！@_@
如果本帅在做需求的时候，能够先找到数据的来源，并且清楚知道在那里更新数据的话，那么就不会出现开发两次无用的功能，而且还是在自测的时候才发现，浪费了大把的时间；而在第一天之后我明明有机会可以发现这个问题的，但是却由于自己的并没有足够重视相关数据的更新和插入的操作在那里实现就贸然地开始码代码，也就不会浪费时间经历不说，对解决问题没有半点帮助。
晚上，趁着amos也在就向他询问了他的开发方式和方法（总是需要个开场白的嘛！）。接着就对本帅的不足进行了分析，以后要积极改进、严谨地对待每一个需求和bug，绝对不能想当然。绝对不能在不完全了解的情况下进行开发和下保证，否则用齐帅的一句话来形容“这就是在扯淡啊！”。
总之，不管是不是做我们这一行，做人做事就需要怀着amos常对我们说的一颗“敬畏之心”。
总之：我们扯了很久！{{(>_<)}}
总之：本帅也学到了不少！(^_)
总之：我还是犯了这个错误！@_@
总之：怎么感觉好像没救了一样！ TAT

所以即使面对这样的小问题，还是需要多查找一些原理和解决方法，熟悉然后比较，最终在掌握原理的情况下分析问题出现具体原因以及得出相应解决的方案，之后采取行动解决！这样才能即能学到原理，同时也有效解决问题，不至于浪费大量时间！
但是生活还要继续，不想因为延期就不开心不是么？再说本帅也不是没学到东西嘛！权当成生活给本帅的小惊喜吧！嘻嘻 (^_)

amos小组成员说过，每天要点输出，这个BB文章就是输出，嘻嘻！
好像写得有点乱！！！

--- 致第一次玩grub