2014-07-10
利用inotifywait 实时监控文件变化并自动同步至百度云

之前一直利用VPS 手动下载一下zip 的文件再利用百度云网盘的离线下载功能同步至国内网盘,期间还需要检查zip文件的完整性,再区别文件名上传至不同的百度云网盘中,综合起来需要手动处理的流程大概是这样的:

获取zip 文件下载地址 -> ssh 登陆到VPS建立下载任务 -> 不定时检查任务下载进度 -> 下载完成后获取zip 文件属性(预览及md5 校验) -> 登陆1号百度云建立离线任务 -> 登陆2号百度云建立离线任务。

通过linux 的inotify 东拼西凑写了个shell脚本,自动处理后简化任务为:

获取zip 文件下载地址 -> ssh 登陆到VPS 建立下载任务

Read More

2014-02-22
Ubuntu 不小心删除当前内核后的恢复

真不好运,昨晚在更新kernel 的时候没留意没有更新成功,然后直接把当前正在使用的内核给删除了,爽快地把机子重启后,直接崩溃了… 幸好曾经将GRUB FOR DOS 添加到BCD 中,所以直接进入Live CD。 chroot 过去检查一下内核的安装情况:

fdisk -l
sudo mount /dev/sda7 /mnt
chroot /mnt
dpkg –get-selections | grep linux

发现确实是删除了内核,只好重装linux kernel 了。 挂载必要的东东(root 分区上面已经挂载到/mnt):

exit #退出chroot
sudo mount /dev/sda10 /mnt/home #因为自己手动将/home/username/Package/ubuntu/archives ln -s 到/var/cache/apt/archives,小水管宽带,没办法,所以保留deb 包(也是挂载/home 分区的原因了)。
sudo mount –bind /proc /mnt/proc #绑定当前进程到/mnt下的proc
sudo mount –bind /dev /mnt/dev #绑定设备文件到/mnt下的dev
sudo chroot /mnt

安装 linux kernel

apt-get install linux-image-3.***-generic

重启系统,恢复正常。

Read More

2013-08-05
重装Windows7或重置MBR后修复Ubuntu的Grub2引导

之前在《openSUSE Tumbleweed (Linux Kernel 3.10)安装Nvidia 显卡驱动》后面记录了openSUSE 引导的修复方法,今天将工作笔记本Windows 7 重装后,也需要修复原来的Ubuntu 引导,在修复过程中遇到不少问题,所以还是一如既往地写下本文作为备忘了。 习惯来说,在安装Windows7时,无论是32位还是64位,都独自分出一个512M的活动分区来存放启动管理器,因为这样不会那么容易导致在重装某一系统时格式化系统目录会完全丢失原来的引导信息。因为破坏了笔记本的分区表,Ubuntu 13.04 是首先通过刻入内存卡的live CD 再安装的,整个硬盘的分区也是在live cd下完成,但不是很熟悉linux 分区是对活动分区的处理,也不知道安装时到底有没有讲引导信息写入那个512M的分区,所以重启后无法进入系统,可能遗留了什么。 使用unetbootin 刻录了ubuntu 13.04 的镜像到TF卡,启动至live cd后,执行grub 的安装:

sudo mount /dev/sda7 /mnt
sudo mount /dev/sda8 /mnt/boot
sudo grub-install –boot-directory=/mnt /dev/sda

结果在最后一步“sudo grub-install –boot-directory=/mnt /dev/sda”中报错,具体就是个32 sector?这个有点困惑了,重启后进入grub 的维护界面,于是乎希望通过以下方式启动硬盘的ubuntu:

set root=(hd0,7)
set prefix=(hd0,8)/grub
insmod (hd0,8)/grub/i386-pc/normal.mod
normal

可是在“insmod (hd0,8)/grub/i386-pc/normal.mod”时,amd64的ubuntu是没有i386-pc这个目录的,normal.mod文件存放在x86_64-efi中,本以为“insmod (hd0,8)/grub/x86_64-efi/normal.mod”是正确的方法,结果报错。 常规修复无解,只能在live cd中通过安装boot-repair修复之。 然后继续通过Win PE安装装Windows7后,这个时候貌似windows 将其引导写入了MBR,启动管理器也是win7自带的,所以就需要重新修复Ubuntu 的引导了。 很奇怪,Win7 的bcdedit 在增加了GRUB4DOS 的启动项后重启就失效了,不知道是不是对那个512M的活动分区处理不正确的或者是上面的boot-repair原因,为了保护该分区,当时没有隐藏该分区,而是直接删除了卷标,因为在DiskGenius隐藏该分区或者取消该分区的隐藏都会导致分区表的变更,担心会导致以后Ubuntu的启动会被破坏,所以就仅仅是通过删除卷标来保护该分区,同时在Windows 下管理该分区也仅需要加上卷标就可以了,虽然DiskGenius也是可以直接操作这些分区的文件。 既然无法手动通过bcdedit 正确修改系统的引导信息,那就只能找工具了,easybcd是个不错的玩意,但很奇怪的是easybcd读取系统的bcd信息与bcdedit获取出来的是完全一致的,当然通过bcdedit 添加的启动项也在重启后莫名其妙地失效了。不过easybcd有个不错的功能,可以手动选择bcd文件进行编辑,那就直接加载那个放在512M活动分区的bcd文件了,路径:/boot/bcd,此时读取出来的启动信息仅有Windows 7一项,应该是正常了。随便添加一个GRUB 启动项,重启后在启动选择界面也显示出来了。后来干脆那512M的活动分区加上卷标,再阅读GRUB4DOS的README文档,手动通过bcdedit 创建了“GRUB 4 DOS”的启动项,相关文件也就是grldr grldr.mbr menu.lst一起放置在512M活动分区中,menu.lst 也在原基础上添加上Ubuntu 13.04 live CD 的相关信息:

title Install Ubuntu root (hd0,2) kernel (hd0,2)/Fuying/OS/linux/ubuntu/vmlinuz boot=casper iso-scan/filename=/Fuying/OS/linux/ubuntu/ubuntu-13.04-desktop-amd64.iso ro quiet splash locale=zh_CN.UTF-8 initrd (hd0,2)/Fuying/OS/linux/ubuntu/initrd.lz

具体这个 (hd0,2) 可以在GRUB 4 DOS 中,进入grub> 随便输入:root (hd0, 然后按tab键来查看所有分区信息。 很奇怪的是硬盘启动Ubuntu 13.04 live cd 会死在initramfs,百科后得知可能是硬件的各方面问题,估计无解,唯有将Grub 写入内存卡(穷~没有U盘,拿个TF卡代替了),同样加入grldr grldr.mbr menu.lst ubuntu-13.04-desktop-amd64.iso 文件及修改了menu.lst,这样才可以正常进入Ubuntu Live CD。 进入了desktop ,剩下的工作就干脆很多了。 gnome-terminal 执行:

sudo mount /dev/sda7 /mnt
sudo mount /dev/sda8 /mnt/boot
sudo grub-install –boot-directory=/mnt /dev/sda

因为在安装Ubuntu时,使用了boot 分区,所以上面需要同时挂载/boot 但是不能使用update-grub,可能是在live cd中的缘故,重启后意料之中地进入了grub 维护界面,然后开始进入硬盘中的ubuntu:

set root=(hd0,7)
set prefix=(hd0,8)/grub
insmod (hd0,8)/grub/i386-pc/normal.mod
normal

这里很奇怪,因为是64位的ubuntu,上面提到,与32位“insmod (hd0,8)/grub/i386-pc/normal.mod”不同的是64位为“insmod (hd0,8)/grub/x86_64-efi/normal.mod”,但这个时候却变成了i386-pc,所以执行过程无报错,并且熟悉的grub2 引导界面出现了,或许是boot-repair作了更改。进入ubuntu后执行update-grub ,所有工作完成。

Read More

2013-07-13
openSUSE Tumbleweed (Linux Kernel 3.10)安装Nvidia 显卡驱动

之前在《万恶的Windows 7 卡LOGO 及安全模式停顿在CLASSPNP.SYS 的侦错过程》中解决了Windows 7 的\Windows\system32\drivers\classpnp.sys 问题,最后是把openSUSE 的启动项给弄掉了,结果需要重新修复。经过一番折腾,终于是较为完美地解决了,谁知openSUSUE 无法进入桌面,表现的错误为:

X server died during startup. X server for display :0f cannot be started, session disable.

可能是某此使用的过程中,Tumbleweed 再次更新了kernel,结果没及时重新执行Nvidia 驱动的重新安装。本以为一切都像以前那样简单,事实上在重新安装Nvidia 的驱动时出现了错误:

ERROR: Unable to build the NVIDIA kernel module. ERROR: Installation has failed. Please see the file ‘/var/log/nvidia-installer.log’ for details. You may find suggestions on fixing installation problems in the README available on the Linux driver download page at www.nvidia.com.

查看日志:

cat /var/log/nvidia-installer.log

提示我尝试通过下面的步骤来解决:

cd /usr/src/linux
make oldconfig
make prepare

结果在make prepare 的时候出现错误,于是把kernel-source 给安装上去:

sudo zypper in kernel-source

然后make prepare 顺利通过了。重复执行Nvidia 显卡驱动的安装:

cd /usr/local/src
sh NVIDIA-Linux-x86_64-319.32.run

结果问题一样。无法,Google 之,发现这是Nvidia 驱动无法支持最新的linux 3.10 内核,所以安装过程出错!需要通过patch给驱动程序打补丁!

参考:

因为我的显卡为GT 520M,所以使用的最新Nvidia 驱动程序为NVIDIA-Linux-x86_64-319.32.run。补丁文件取自《Building nvidia driver on kernel 3.9.0》及《Mailinglist Archive: opensuse-factory (667 mails)》,文件名为:pastie-7942599.diff。然后给此驱动程序patch 上补丁:

  • 解压NVIDIA 驱动程序
  • patch -p1 <$PATCHFILE
  • 安装驱动程序

sh NVIDIA-Linux-x86_64-325.08.run –extract-only
patch -p1 <$PATCHFILE
./nvidia-installer

至此在linux 3.10 内核上安装NVIDIA 显卡驱动程序顺利完成,不过在中途依然提示一错误:

File ‘/usr/lib64/xorg/modules/extensions/libglx.so’ is not a symbolic link.

但我无视之。重启,机器正常使用中。附上操作系统信息:

ying@linux-uwkx:~> uname -r 3.10.0-16.g3dcd746-desktop

ying@linux-uwkx:~> cat /etc/issue Welcome to openSUSE 12.3 “Dartmouth” - Kernel \r (\l).

ying@linux-uwkx:~> cat /etc/lsb-release LSB_VERSION=”core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64”


顺便记录下启动修复的过程:

重要工具:grub4dos-0.4.3 阅读GRUB4DOS and Windows Vista bcdedit 的使用说明,加入名称为“GRUB for DOS”的启动项,menu.lst 相关内容为:

title Install OpenSUSE root (hd0,5) kernel /OS/linux/opensuse/linux vga=791 initrd /OS/linux/opensuse/initrd boot

解压openSUSE-12.3-DVD-x86_64.iso 至一fat32 分区,即上面的(hd0,5) 中,文件夹名称为opensuse。 准备工作完成,重启计算机,启动进入“GRUB for DOS”,选择“Install OpenSUSE”,其实就是一个openSUSE 的硬盘安装操作! 进入后,出现三个选项,大概意思为:

  • 安装或者升级openSUSE
  • 启动已经安装的系统
  • 修复模式

当时选择启动已经安装的系统,发现在启动的过程中无法扫描 / root 分区的信息,错误为:

fsck failed with error code 4

估计是在《解决万恶的Windows 7 卡LOGO 及安全模式停顿在CLASSPNP.SYS 》修复硬盘坏道时变更了磁盘信息,而选择“启动已安装的系统”,根分区已经挂载,所以fsck 不能执行,所以自动修复失效(那个修复模式,需要登陆?却提示密码错误?不会使用) 修复思路就是卸载/,然后使用fsck修复 选择“安装或者升级openSUSE”,安装介质当然就是Hard Device(又忘了名字?),输入上面准备在(hd0,5) 中的opensuse 文件夹,进入openSUSE 的安装引导,结果花屏,继续无视,ctl+atl+fx 进入Terminal,用fdisk 及mount 找到root 分区,执行fsck 修复! 完成! 启动openSUSE,安装grub 至mbr?并更新启动信息写入/boot/grub2/grub.cfg

grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg

输出:

ying@linux-uwkx:~> sudo /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg root’s password: Generating grub.cfg … Found theme: /boot/grub2/themes/openSUSE/theme.txt Found linux image: /boot/vmlinuz-3.10.0-16.g3dcd746-desktop Found initrd image: /boot/initrd-3.10.0-16.g3dcd746-desktop No volume groups found Found Windows 7 (loader) on /dev/sda1 done

终于,电脑的整体修复工作彻底Over!!这次真是幸好有Google 及 openSUSE Forum & NVIDIA Developer Forms 的各位朋友!另外,一些资源也必须通过代理才能取得,感谢GAE 《Linux下用goagent使用Google GAE代理》。

Read More

2013-03-03
htaccess中RewriteRule的301重定实现跳转不要带参数Querystring值

在做htaccess 中 rewrite规则时,其中301跳转,发现跳转后的网址自动加上了参数传递,也就是Querystring。 如这样的规则:

RewriteRule ^oldsite/product/productname.aspx http://subdomain.newsite.com/product [L,R=301]

当遇到这样的网址时,就自动带上参数

RewriteRule ^oldsite/product/productname.aspx?=QUERYSTRING http://subdomain.newsite.com/product [L,R=301]

会变成这样的网址:

http://subdomain.newsite.com/product?=QUERYSTRING

最根本解决htaccess中RewriteRule的301重定实现跳转不要带参数Querystring值的方法是使用这样的RewriteRule:

RewriteRule ^oldsite/product/productname.aspx?=QUERYSTRING http://subdomain.newsite.com/product? [L,R=301]

也就是后面加了个问号就解决问题了。英语好的朋友可以参考下原文

Read More

2013-02-16
简单总结下安装openSUSE后的一点配置

我接触linux 就是从openSUSE 开始的,那时候openSUSE 应该是11.0版本,默认的桌面还是kde 3.×。学生哥,对什么新奇的玩意都充满了激情,当初喜爱openSUSE 仅是因为她那完美的3D 效果,现在使用linux比较长的时间后,对这些的兴趣已经渐渐淡化,也仅因日常工作需要而保持使用linux ,毕竟她真的是太方便了! 目前最新的openSUSE 应该就是12.2了。12.3应也快到来了吧,现在也正在使用12.2中:

ying@linux-uwkx:~> cat /etc/issue
Welcome to openSUSE 12.2 “Mantis” - Kernel \r (\l).

ying@linux-uwkx:~> lsb_release -a
LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
Distributor ID: SUSE LINUX
Description: openSUSE 12.2 (x86_64)
Release: 12.2
Codename: Mantis
ying@linux-uwkx:~>

嗯,每次都扯得很遥远。不废话了,说下自己安装完openSUSE 12.2后的一些简单配置吧。 首先,当然是ADSL的网络连接了!安装完系统,打开YaST 控制中心,在左侧选中网络设备,后侧点击打开网络设置,然后在全局选项中设置“网络设置方法”,点选“通过 NetworkManager 的用户控制方法“,我习惯了用这个,传统的ifup我没用过,不知道效果怎么样。 第二部,右键任务栏,选择添加部件,看到“网络管理”部件,双击该部件即可添加到任务栏右下角,然后熟悉的设置界面又回来了。选择你的网络类型,如DSL,添加上帐号和密码,设置为系统连接并开机启动,如果这个时候都没有作用的话,那就删除Wired 的网络链接吧,当然,前提是你的连接是需要DSL拨号的!没作用?重启下网络服务:

sudo /etc/init.d/network restart

这个时候,网络连接应该正常了。 设置好网络,那就需要配置软件源了。openSUSE 官方的软件源速度中规中矩,我还是添加上了163的软件源和几个openSUSE 的社区软件源,当然包括Packman的了。至于软件源,openSUSE的中文主页已经介绍得很详细了:软件源介绍。 基本需要配置的东西差不多比较重要的也就是这两个了,发现openSUSE 每个版本的专题页做得确实不错,基本的问题也可以轻易找到解决方法了。openSUSE 12.2 常见问题介绍openSUSE

Read More

2013-02-11
收集整理了一下linux下find命令的用法

之前在《自动清理OpenShift 的日志文件 解决 file write error (Disk quota exceeded) 错误》提到可通过find命令来搜索某段时期的文件来做统一删除,因为本人也是个linux 菜鸟,对于find 的认识确实是一知半解,在我执行了

find . -type f \( -name access_logs-\ , -name error_logs-\ \) -mtime +3 -exec rm {} \;

后,发现仅是删除了以error开头的文件,而access 的日志文件完好无损,后来我就通过:

find . -type f \( -name access_logs-\ , -name error_logs-\ \) -mtime +3 | xargs ls;

来列出日志目录的文件,发现确实仅是列出了符合要求的error 开头的文件,access 文件被无视了。看来是“,”并不符合我的要求。看了看find 命令用法,得知一个关于逻辑运算符的使用方法,将上面的“,”替换为“-o”,即“或”后,成功列出了符合条件的access和error 日志文件。为了方便以后使用,还是讲find 命令的常用方法贴了上来。 首先是find的语法: find [起始目录] 寻找条件 操作 还有种表述方式:find PATH OPTION [-exec COMMAND { } \;] 因为find命令会根据我们给的option,也就是寻找条件从我们给出的目录开始对其中文件及其下子目录中的文件进行递归搜索,所以我觉的这个地方说是“起始目录”是非常好的。 该命令中的寻找条件可以是一个用逻辑运算符 not、and、or 组成的复合条件。逻辑运 算符 and、or、not 的含义为: (1) and:逻辑与,在命令中用“-a”表示,是系统缺省的选项,表示只有当所给的条 件都满足时,寻找条件才算满足。例如:

find –name ‘tmp’ –xtype c -user ‘inin’

% 该命令寻找三个给定条件都满足的所有文件 (2) or:逻辑或,在命令中用“-o”表示。该运算符表示只要所给的条件中有一个满足 时,寻找条件就算满足。例如:

find –name ‘tmp’ –o –name ‘mina*’

% 该命令查询文件名为’tmp’或是匹配’mina*’的所有文件。 (3) not:逻辑非,在命令中用“!”表示。该运算符表示查找不满足所给条件的文件 。例如:

find ! –name ‘tmp’

% 该命令查询文件名不是’tmp’的所有文件。 需要说明的是:当使用很多的逻辑选项时,可以用括号把这些选项括起来。为了避免Shell本身对括号引起误解,在话号前需要加转义字符“\”来去除括号的意义。例:

find \(–name ‘tmp’ –xtype c -user ‘inin’ \)

我觉的现在我应该说下出了查询条件,在find中的option的内容了: 在option中,具体有参数: -name ‘字串’ 查找文件名匹配所给字串的所有文件,字串内可用通配符 、?、[ ]。 -lname ‘字串’ 查找文件名匹配所给字串的所有符号链接文件,字串内可用通配符 、?、[ ]。 -gid n 查找属于ID号为 n 的用户组的所有文件。 -uid n 查找属于ID号为 n 的用户的所有文件。 -group ‘字串’ 查找属于用户组名为所给字串的所有的文件。 -user ‘字串’ 查找属于用户名为所给字串的所有的文件。 -empty 查找大小为 0的目录或文件。 -path ‘字串’ 查找路径名匹配所给字串的所有文件,字串内可用通配符*、?、[ ]。 -perm 权限 查找具有指定权限的文件和目录,权限的表示可以如711,644。 -size n[bckw] 查找指定文件大小的文件,n 后面的字符表示单位,缺省为 b,代表512字节的块。 -type x 查找类型为 x 的文件,x 为下列字符之一: b 块设备文件 c 字符设备文件 d 目录文件 p 命名管道(FIFO) f 普通文件 l 符号链接文件(symbolic links) s socket文件 -xtype x 与 -type 基本相同,但只查找符号链接文件。 以时间为条件查找 -amin n 查找n分钟以前被访问过的所有文件。 -atime n 查找n天以前被访问过的所有文件。 -cmin n 查找n分钟以前文件状态被修改过的所有文件。 -ctime n 查找n天以前文件状态被修改过的所有文件。 -mmin n 查找n分钟以前文件内容被修改过的所有文件。 -mtime n 查找n天以前文件内容被修改过的所有文件。 -print:将搜索结果输出到标准输出。 例子:在root以及子目录查找不包括目录/root/bin的,greek用户的,文件类型为普通文件的,3天之前的名为test-find.c的文件,并将结构输出,find命令如下:

find / -name “test-find.c” -type f -mtime +3 -user greek -prune /root/bin -print

当然在这其中,-print是一个默认选项,我们不必刻意去配置它。 我们再看一下exec选项: -exec:对搜索的结构指令指定的shell命令。注意格式要正确:”-exec 命令 {} \;” 在}和\之间一定要有空格才行; {}表示命令的参数即为所找到的文件;命令的末尾必须以“ \;”结束。 例子:对上述例子搜索出来的文件进行删除操作,命令如下:

find / -name “test-find.c” -type f -mtime +3 -user greek -prune /root/bin -exec rm {} \;

find命令指令实例:

find . - name ‘main*’ - exec more {} \;

% 查找当前目录中所有以main开头的文件,并显示这些文件的内容。

find . \(- name a.out - o - name ‘*.o’\)> - atime +7 - exec rm {} \;

% 删除当前目录下所有一周之内没有被访问过的a .out或.o文件。 % 命令中的“.”表示当前目录,此时 find 将从当前目录开始,逐个在其子目录中查找满足后面指定条件的文件。 % “\(” 和 “\)” 表示括号(),其中的 “\” 称为转义符。之所以这样写是由于对 Shell 而言,(和)另有不同的含义,而不是这里的用于组合条件的用途。 % “-name a.out” 是指要查找名为a.out的文件; % “-name ‘.o’” 是指要查找所有名字以 .o 结尾的文件。 这两个 -name 之间的 -o 表示逻辑或(or),即查找名字为a.out或名字以 .o结尾的文件。 % find命令在当前目录及其子目录下找到这佯的文件之后,再进行判断,看其最后访问时间 是否在7天以前(条件 -atime +7),若是,则对该文件执行命令 rm(-exec rm {} \;)。 其中 {} 代表当前查到的符合条件的文件名,\;则是语法所要求的。 % 上述命令中第一行的最后一个 \ 是续行符。当命令太长而在一行写不下时,可输入一个 \,之后系统将显示一个 >,指示用户继续输入命令。

Read More

2013-02-06
自动清理OpenShift 的日志文件 解决 file write error (Disk quota exceeded) 错误

最近,有个应用每隔几天就502,提示错误信息 “error: file write error (Disk quota exceeded)”,看来又是挤满了空间,超出了配额。后来发现是因为程序的不完善,php 给出了很多的警告,并将这些信息写入到目录~/php-5.3/logs 里面。所以隔了一段时间应用又会到达配额限制,而解决方法就是手动清理这些庞大的日志文件。 既然知道了问题,那么就好解决了,为了偷懒,还是动用OpenShift 的定时任务吧,之前不是提到《小记配置OpenShift 网站数据和Mysql 数据库到Dropbox的自动备份》吗,那么我们只需按照同样的思路制作一个定时清理日志的cron即可。 首先添加一个cartridge (rhc app cartridge add -a $app -c cron-1.4 ) 到应用下,然后添加一个日常任务到.openshift/cron/daily/cleanup-old-logs 就可以了。 下面是脚本内容,例子中是保存180 天内的日志文件,这个根据需要可以自己修改:

cd $OPENSHIFT_PHP_LOG_DIR

find . -type f \( -name access_log-\ , -name error_log-\ \) -mtime +180

Add this to the above command to backup as a gzipped tarball: | xargs tar -czvf backup-logs-$(date +%Y%m%d).tar.gz

Add this to the above command to delete ‘em: -exec rm {} \; or | xargs rm)

如我的设置为:

find . -type f \( -name access_log-\ , -name error_log-\ \) -mtime +3 -exec rm {} \;

关于find 的语法,需要的朋友可参考《收集整理了一下linux下find命令的用法

Read More

2012-12-10
Ubuntu 启动出现 failed to load file amd-ucode/microcode_amd.bin

其实也不是第一次了,之前使用ubuntu的时候一直都有这个错误,也忘记这个东西是怎么出现的了,看来与AMD有关…AMD官网有说明:http://www.amd64.org/support/microcode.html “AMD provides microcode patch support for processors belonging to AMD processor families 10h, 11h, 12h, 14h, and 15h”

ying@ying-desktop:~$ dmesg | grep micro
[ 11.046778] microcode: CPU0: patch_level=0x03000025
[ 11.124894] microcode: failed to load file amd-ucode/microcode_amd.bin
[ 11.124913] microcode: CPU1: patch_level=0x03000025
[ 11.126471] microcode: failed to load file amd-ucode/microcode_amd.bin
[ 11.126496] microcode: CPU2: patch_level=0x03000025
[ 11.127912] microcode: failed to load file amd-ucode/microcode_amd.bin
[ 11.127930] microcode: CPU3: patch_level=0x03000025
[ 11.129155] microcode: failed to load file amd-ucode/microcode_amd.bin
[ 11.129270] microcode: Microcode Update Driver: v2.00 , Peter Oruba

安装amd64-microcode :

ying@ying-desktop:~$ sudo apt-get install amd64-microcode
[sudo] password for ying:
正在读取软件包列表… 完成
正在分析软件包的依赖关系树
正在读取状态信息… 完成
下列【新】软件包将被安装:
amd64-microcode
升级了 0 个软件包,新安装了 1 个软件包, 要卸载 0 个软件包,有 0 个软件包未被升级。
需要下载 27.9 kB 的软件包。
解压缩后会消耗掉 97.3 kB 的额外空间。
获取:1 http://ftp.cuhk.edu.hk/pub/Linux/ubuntu/ quantal/multiverse amd64-microcode amd64 1.20120910-1 [27.9 kB]
下载 27.9 kB,耗时 0秒 (144 kB/s)
Selecting previously unselected package amd64-microcode.
(正在读取数据库 … 系统当前共安装有 177823 个文件和目录。)
正在解压缩 amd64-microcode (从 …/amd64-microcode_1.20120910-1_amd64.deb) …
正在设置 amd64-microcode (1.20120910-1) …
Using per-core interface to update microcode on online processors…
update-initramfs: deferring update (trigger activated)
正在处理用于 initramfs-tools 的触发器…
update-initramfs: Generating /boot/initrd.img-3.5.0-19-generic
ying@ying-desktop:~$

安装amd64-microcode 后,系统相关启动日志如下:

ying@ying-desktop:~$ dmesg | grep micro
[ 1.494958] microcode: CPU0: patch_level=0x03000025
[ 1.547460] microcode: CPU0: new patch_level=0x03000027
[ 1.547579] microcode: CPU1: patch_level=0x03000025
[ 1.551557] microcode: CPU1: new patch_level=0x03000027
[ 1.551668] microcode: CPU2: patch_level=0x03000025
[ 1.552870] microcode: CPU2: new patch_level=0x03000027
[ 1.552983] microcode: CPU3: patch_level=0x03000025
[ 1.554223] microcode: CPU3: new patch_level=0x03000027
[ 1.554380] microcode: Microcode Update Driver: v2.00 , Peter Oruba
ying@ying-desktop:~$

有时间的话回头看看是什么东西- -!

Read More

2012-12-10
Ubuntu禁用Plymouth 换成启动过程文本显示

最近Ubuntu 换上了Nvidia的专有驱动,总结下遇到的一些问题。 安装驱动前,依赖是必须补上来的,否则重启开机的时候桌面会什么东东都没有,不过可以使用 ctrl+alt+T启动Terminal来解决问题。如firefox 然后 google - -。 安装Nvidia 专有驱动前需要安装的依赖。

sudo apt-get install build-essential pkg-config xserver-xorg-dev linux-headers-`uname -r`

然后直接在系统软件源的附加驱动中选择第一项(tested)然后应用即可。 如果想去掉在登录屏幕出现之前的NVIDIA标识,你需要在Xorg配置文件中做些手动修改。

sudo nano /etc/X11/xorg.conf

PS:找不到xorg.conf文件的话,先使用

sudo nvidia-xconfig

创建一个。 在Device部分找到Driver “nvidia”这一行 在这一行后面,加上:

Option “NoLogo”

保存文件,退出。 关闭所有程序,然后重启X服务器。如果NVIDIA标识没有了,应该是起作用了。 或者

sudo nvidia-xconfig –no-logo

如果想禁用Plymouth,换成启动过程文本显示。

sudo nano /etc/default/grub

相应字段改为

GRUB_CMDLINE_LINUX_DEFAULT=”splash=verbose”

更新Grub2

sudo update-grub

如果需要更改显示的分辨率,只需加上vga 的值即可,如:

GRUB_CMDLINE_LINUX_DEFAULT=”splash=verbose vga=791”

可以通过hwinfo –framebuffer 命令查看自己显卡支持的模式。 1、安装 hwinfo

sudo apt-get install hwinfo

2、查看自己显卡支持的模式

sudo hwinfo –framebuffer

或者更简要的模式输出

sudo hwinfo –framebuffer | grep Mode

选择你自己需要的分辨率,我个人选择1024*768,即vga=791。 附上我机器上的VGA(屏幕分辨率和色彩)模式对照表,主要自己备查,有需要的也可以参考下。

ying@ying-desktop:~$ sudo hwinfo –framebuffer | grep Mode
[sudo] password for ying:
process 4408: arguments to dbus_move_error() were incorrect, assertion “(dest) == NULL || !dbus_error_is_set ((dest))” failed in file ../../dbus/dbus-errors.c line 282.
This is normally a bug in some application using the D-Bus library.
libhal.c 3483 : Error unsubscribing to signals, error=The name org.freedesktop.Hal was not provided by any .service files
Model: “NVIDIA GF119 Board - 13100000”
Mode 0x0300: 640x400 (+640), 8 bits
Mode 0x0301: 640x480 (+640), 8 bits
Mode 0x0303: 800x600 (+800), 8 bits
Mode 0x0305: 1024x768 (+1024), 8 bits
Mode 0x0307: 1280x1024 (+1280), 8 bits
Mode 0x030e: 320x200 (+640), 16 bits
Mode 0x030f: 320x200 (+1280), 24 bits
Mode 0x0311: 640x480 (+1280), 16 bits
Mode 0x0312: 640x480 (+2560), 24 bits
Mode 0x0314: 800x600 (+1600), 16 bits
Mode 0x0315: 800x600 (+3200), 24 bits
Mode 0x0317: 1024x768 (+2048), 16 bits
Mode 0x0318: 1024x768 (+4096), 24 bits
Mode 0x031a: 1280x1024 (+2560), 16 bits
Mode 0x031b: 1280x1024 (+5120), 24 bits
Mode 0x0330: 320x200 (+320), 8 bits
Mode 0x0331: 320x400 (+320), 8 bits
Mode 0x0332: 320x400 (+640), 16 bits
Mode 0x0333: 320x400 (+1280), 24 bits
Mode 0x0334: 320x240 (+320), 8 bits
Mode 0x0335: 320x240 (+640), 16 bits
Mode 0x0336: 320x240 (+1280), 24 bits
Mode 0x033d: 640x400 (+1280), 16 bits
Mode 0x033e: 640x400 (+2560), 24 bits
Mode 0x0345: 1600x1200 (+1600), 8 bits
Mode 0x0346: 1600x1200 (+3200), 16 bits
Mode 0x034a: 1600x1200 (+6400), 24 bits
Mode 0x034b: 1280x720 (+1920), 8 bits
Mode 0x034c: 1280x720 (+3840), 16 bits
Mode 0x034d: 1280x720 (+7680), 24 bits
Mode 0x0360: 1280x800 (+1280), 8 bits
Mode 0x0361: 1280x800 (+5120), 24 bits

以上Mode 中的数值是十六进制的,自己转换即可,如1024*768 16 bits 的0x0317 转换十进制结果为791。

Read More