如何使用 Grub Customizer 设置 Grub 启动菜单

安装 Ubuntu 等 Linux 发行版之后,开机后会出现 Grub 启动菜单用于选择需要进入的操作系统。如果我们需要对 Grub 启动菜单进行修改,除了传统的修改文本配置文件的方法之外,还可以使用图形设置工具 Grub Customizer 进行设置。

Grub Customizer 可以通过 PPA 安装,启动终端依次输入以下命令即可:

启动 Grub Customizer,主界面如下图所示:

Grub_Customizer

在 Grub Customizer 的主界面中,我们可以调整启动项的位置(使用工具栏的向上向下箭头按钮),还可以通过启动项前的复选框控制该启动项是否可见,我们可以通过这种方法隐藏多 余的 Linux 内核选项。如果去除某一类别中“新条目”的复选框,还可以“冻结”该类别,自动探测的新条目将不会被添加到这一类别。

点击工具栏的“首选项”按钮,在此我们可以对 Grub 启动菜单进行进一步定制。

首先是常规标签页,在此我们可以设置 Grub 启动菜单的默认启动项、是否显示菜单、等待时间等等。how-to-configure-the-linux-grub2-boot-menu-with-grub-customizer-02

然后是外观标签页,在此对 Grub 启动菜单的外观进行定制,如调整分辨率、设置背景等等。

how-to-configure-the-linux-grub2-boot-menu-with-grub-customizer-03

最后是高级标签页,如果你不了解这些选项的意义,请不要随便修改。

设置完成之后记得点击工具栏的“保存”按钮保存设置。

原文链接 如何使用 Grub Customizer 设置 Grub 启动菜单

WD MyCloud中设置服务在开机时候自动启动

WD MyCloud中,有时候我们需要某些服务随着开机而启动,而且,我们不希望我们手工添加进去的服务如果不能正常启动,导致系统启动异常。因此,我们把这个放到系统服务启动的最后一句最好了,在WD MyCloud中,应该如下修改

我们可以看到,文件最后附近,有如下语句

把系统的启动服务,放到这些的后面,exit语句的前面

以启动subversion为例子

VLC 2.1 在Windows下字幕和OSD中文显示方框问题

VLC播放器2.0,2.1版本在Windows下字幕中文(或其他非拉丁)字体存在BUG。

如果一个字体的名称是非拉丁/非ASCII字母但是登录项是拉丁/ASCII字母,那么这个字体不能选择用作VLC的字幕字体。

比如你的Windows的系统区域是中国大陆简体中文,你将用不了宋体、微软雅黑等拥有中国大陆简体中文名的字体,只得使用没有中国大陆简体中文名的字体如DFKai-SB,Microsoft JhengHei等(Windows 10下建议选择Microsoft JhengHei)。繁体和日文等也有类似情况。

因此进行如下设置,然后一定要重启 VLC

OSD_Image_VLC_2_1_Simple_Chinese

小米2 32G开发版 无损分区调整

最近小米2 总是报告系统空间不足,一般的应用的安装,升级都搞不定了,网上搜索了一下,找到了无损分区的调整办法,本文对于步骤进行了精简,原文有些过于繁琐了。

    • 准备工作环境工作环境

1.下载Mi2 Repartition 解压到“C:\Mi2 Repartition”下(D盘也可以)。其中含Android命令行工具、WinHex十六进制编辑软件、userdata分区挂载可使用空间调整工具resize_data,以及处理过程中的backup备份文件夹。(精简了DiskGenius,因为实际上是用不到的,原文过于折腾了

2.下载高通 Qualcomm HS-USB QDLoader设备驱动 Qualcomm_HS-USB_QDLoader_Driver 之所以不用小米的 MiFlash ,原因在于驱动里面的qcCoInstaller.dll 经常莫名奇妙的丢失,导致驱动安装不上,一直报错。(注意目前这个驱动已经可以通过Windows Update正常获得,因此不再需要

3.下载支持Linux Ext4格式无损调整分区(前移后挪双向均支持)的软件:Paragon Hard Disk Manager 14 Pro (原作者的百度网盘分享),如果不能正常下载可以使用本站下载

4.如果是64位系统,则重启机器,启动时候按住 F8,选择“禁用驱动程序签名强制”(注意目前这个驱动已经可以通过Windows Update正常获得,因此不再需要禁用驱动签名,更新一下驱动即可正常使用了)

2014072209105448067

5.确保手机电池电量充足,最好是满电状态。

  • 开始调整分区

    1.正常开机状态下,在“设置-其他高级设置-开发者选项”中打开“USB调试”。电脑端按键盘Win+R(限Windows系统。Mac OS请出门左转),输入cmd回车,打开命令行窗口,输入cd C:\Mi2 Repartition回车。然后按顺序运行下图中的三条命令。注意运行命令时手机屏幕上是否提示操作权限,请给予允许:
    #注释:运行命令时手机必须已获得完整root权限。开发版自带完整 root权限,如运行命令时手机屏幕上提示有程序被禁用root权限,进入“安全中心-权限管理-ROOT权限管理”中允许给予root权限再重新运行命 令。稳定版需自行处理获得完整root权限。稳定版系统如何获取完整root权限的方法请论坛自学

如下图所示032535z2tw2pvuvc7w5gzg.png.thumb.jpg

2.关机,按住音量-键,再短按开机键,进入fastboot启动环境。然后运行以下命令:

#注释:本命令在fastboot状态下擦除手机aboot逻辑区块中的数据
#注释:去掉aboot模块后,重开机才能已Qualcomm MMC Storage模式在PC上加载手机内部存储器</span

032536p17x96die67z6n11.png.thumb.jpg

然后长按开机键约10秒,听到USB设备断开并重新加载的声音后松开电源键。此时会安装并加载Qualcomm HS-USB QDLoader设备驱动,让设备进入MMC Storage内部存储模式

#注释:需安装小米手机驱动(MiFlash线刷工具软件中集成),否则无法安装Qualcomm HS-USB QDLoader设备驱动

#注释:如安装Qualcomm HS-USB QDLoader驱动后,在Windows设备管理器中发现此设备前有黄色感叹号无法启动的情况,需在设备管理器中禁用此设备,断开并重新连接USB后, 在设备管理器中启用此设备,即可正常加载。此问题是PC系统驱动环境引起。

3.打开Paragon Hard Disk Manager 14,首次运行出现如下画面,选择箭头指向的按钮点击即可。Paragon_Hard_Disk_Manager_14_First

为了规避出现软件报告调整分区时发现cross-link files而拒绝操作报失败的情况,请按下图所示操作,强制让软件忽略文件系统完整性检查,即可顺利调整分区大小(图为HDM 15版本,与教程中使用的14版操作上无区别)

235012tjjd7zpjpzjqe7qj.png.thumb.jpg

开始调整分区,划出用来合并到系统分区的空闲分区

Paragon_Hard_Disk_Manager_14_Split_Free_Space

然后执行合并系统分区的操作(下图是网络图片,跟上图有些差别,分区信息仅仅作为示意图

Paragon_Hard_Disk_Manager_14_Change_System

同样点击 "Apply"之后等待合并空闲分区完成。

4.打开WinHex,在软件主界面按Ctrl-D打开硬盘克隆功能,严格按下图操作,然后确认写入操作。写入完毕后aboot分区数据即已恢复,可长按电源键约10秒正常开机进入系统了
#注释:“357410”是aboot分区在MMC存储器中的起始扇区号。这个aboot分区起始扇区号357410可在DiskGenius软件中选中aboot分区,在分区参数中看到,可自行验证。2和2S所有型号都相同,都填这个数

WinHex_Disk_Clone

032605j3se0riip6r93dj3.png.thumb.jpg

5.将之前放进sdcard中的resize_data文件移动到根目录/system/bin/,试验中发现,/system 是只读的,无法拷贝进入,此时可以拷贝到 /目录下面也可以,两者分区相同,因此理论上面调整起来应该是一样的。(注意,目前尝试的小米2的特殊版本,到Android 5.0之后,已经不需要这个程序,系统启动后会自动调整分区

参考链接


Mi2(S)系列全机型无差别无损无痛不丢数据重分区教程

如何在Linux上实现文件系统的自动检查和修复

平常Linux管理方面最重要的任务之一就是,检查文件系统的完整性。Linux文件系统有可能在各种各样的情况下受到损坏,比如系统崩溃、突然断电、磁盘断开,或者文件节点(i-node)不小心被覆盖等等。因此,定期检查文件系统的完整性是个好主意,以便尽量减小文件系统受到损坏的风险。而说到检查和修复Linux文件系统,fsck是一款实用的工具。

我在本教程中将介绍如何借助fsck工具,实现文件系统的自动检查。

系统一启动,就触发文件系统自动检查机制

如果你希望系统一启动,就自动触发fsck,那么有一些方法可以设置在启动过程中实现无人值守的fschk,这些方法具体取决于特定的Linux发行版。

在Debian、Ubuntu或Linux Mint上,编辑/etc/default/rcS,如下所示。

# 启动过程中,自动修复出现不一致性的文件系统

在CentOS上,使用下列内容,编辑/etc/sysconfig/autofsck(要是它没有,就创建)。

强制定期检查文件系统

如果文件系统很庞大,你可以强制定期检查文件系统,而不是每次系统启动时检查文件系统。为了实现这个操作,先要借助tune2fs命令,找到文件系统配置。下面这个命令行显示了文件系统相关参数的当前值。请注意:/dev/sda1是文件系统超级块所在的分区。

wKioL1NEqAWAGs_iAAEZzcUI6Zg257

从tune2fs的输出结果中,我们不仅可以看到文件系统的状态(干净与否),还可以看到与文件系统检查有关的一些参数。"Maximum mount count"(最大挂载次数)这个参数是指文件系统检查被触发后的挂载次数。"Check interval"(检查时间间隔)这个参数显示了两次文件系统检查之间的最长时间。在大多数Linux发行版上,这些参数并不是默认情况下被设置的,这意味着并不进行任何定期的文件系统检查。

如果想强制每隔30次挂载就检查文件系统,请运行下面这个命令。

如果想强制每隔3个月就检查文件系统,请使用下面这个命令。

现在确认刚添加上去的文件系统检查条件已正确设置。

强制下一次系统重启时,进行一次性的文件系统检查

如果你想在下一次系统重启时触发一次性的文件系统检查,可以使用这个命令。

一旦你在类似上面的顶层目录(/)中创建了一个名为forcefsck的空文件,它就会在你下一次重启时,强制进行文件系统检查。系统成功启动后,/forcefsck则会自动被清除。

wKiom1NEqKqQMvNoAACpmSYvFUE296

Windows机器上程序崩溃dump(UMDF Crash Dump)

最近接到用户的投诉,在Windows 7 32位的机器上,UMDF驱动频繁崩溃,关键是SetUnhandledExceptionFilter 设置的异常过滤竟然一丁点用都没有,查询了半天,才注意到UMDF框架把UnhandledException接管了,你完全是无力反抗。

然后去MSDN上查询,根据Determining Why the Reflector Terminated the Host Process微软文档,WER会在“%windir%\system32\LogFiles\WUDF”目录下面生成DUMP文件,测试之后发现,是否生成完全依赖WER的心情,捣鼓到后来,干脆完全不生成DUMP文件了,另外他偶尔生成的也都是MiniDump ,作用有限。“Users\All Users\Microsoft\Windows\WER\ReportQueue”目录下面的报告数据,也是时有时无,阴晴不定。

继续Google,微软文档 Collecting User-Mode Dumps 设置如下的注册表

这样设置之后,正常的应用都可以在D:\Temp 下面生成崩溃记录,但是WUDFHost.exe 就是不能生成崩溃DUMP,貌似是WUDFHost.exe 用其他低权限用户账户运行,导致没办法生成转储文件。

继续Google,ProcDump进入视野,着实是个好的工具软件,非常好用。于是写了个批处理文件来跟踪WUDFHost.exe的异常。

应用崩溃的时候,会在当前目录下面生产对应的.dmp文件。

本地下载

下面为简单的用法例子

使用源代码将 Glibc 升级到 2.6

简介

有些软件可能要求系统的 Glibc 高于某个版本才可以正常运行。如果您的 Glibc 低于要求的版本,为了运行这些软件,您就不得不升级您的 Glibc 了 。您可以寻找已经编译好的 rpm 包或者使用源代码的方式升级 Glibc。

使用源代码方式升级 Glibc 是需要小心考虑的事情,因为整个系统几乎所有应用程序都依赖于原有的动态库,升级的时候,执行"make install"命令会打断旧的动态库链接,改为指向新的库文件。在这个过程中,不同的链接指向新旧不同版本的库文件,很容易导致系统崩溃,崩溃后,一般是无法重新启动的。

笔者使用的Linux发行版本是Mandriva Linux release 2006.0,其Glibc版本是2.3.5,内核版本是2.6.12-12mdk。由于某些需要,笔者必须升级原来的Glibc到更高的版本。经过实 践,成功使用源代码的方式安全地把Glibc从2.3.5升级到2.6。使用相同的方法,也能成功升级到Glibc2.4或Glibc2.5。成功升级 后,还可以在新旧不同版本的Glibc之间自由切换。

如果您需要阅读有关升级Glibc的文档,可以阅读Glibc 2 HOWTO文档,该文论述了如何从libc5升级到libc6,但是现在的Linux发行版的Glibc都已经使用libc6,更多的需要是在libc6 的范围内,从低版本升级到更高的版本。另外您可以阅读Linux From Scratch项目有关如何安装Glibc的文档。笔者认为最有必要阅读的是Glibc源程序目录树下的INSTALL和FAQ文档,INSTALL详细 描述了有关各编译选项的具体作用,FAQ回答了很多具体的问题。

升级Glibc的流程

为了安全升级Glibc,在升级前必须做好详细的部署和备份,即使是升级失败,系统也要能够还原为原来的状态。升级Glibc失败后,一般是无法重新启动系统的,必须使用另外一个可以启动计算机的Linux系统启动,挂载升级失败的根文件系统,恢复系统的Glibc为原来的状态。因此,准备另外一个可以启动 的Linux系统,是必需的。

准备好另外一个可以启动的Linux系统后,接下来的工作是编译Glibc。编译前要执行"configure"命令,用户可以根据自己的需要,加入不同的编译选项,编译选项在INSTLL文件里有详细的说明。如果是升级当前的Glibc, 必须使用--prefix=/usr选项,该选项指定当前即将编译的Glibc作为系统的标准动态库,安装的时候,Glibc会修改/lib,/usr等 目录下的文件和链接。如果--prefix不是指向/usr,譬如--prefix=/glibc, 安装的时候,Glibc只会在/glibc目录下生成目录,文件以及链接,安装后的Glibc不会成为系统的标准动态库。如果不指定 --prefix,Glibc缺省认为--prefix=/usr/local,安装后的Glibc也不会成为系统的标准动态库。编译Glibc的时候需 要使用Linux内核的头文件,如果内核的头文件太旧,执行"make"的时候,可能会失败,这时可以在configure的时候,使用--with- headers选项指定新内核的头文件的所在目录。笔者的Mandriva Linux release 2006.0的内核头文件就不能令Glibc2.6成功编译,但是却能令Glibc2.4和Glibc2.5成功编译,使用--with-headers 指向新内核的头文件后,Glibc2.6也能成功编译,下文将会有详细叙述。

Glibc安装的时候,会直接修改/lib,/usr/lib等目录下的文件和链接,为了在升级失败的情况下能够恢复系统的Glibc为原来状态,在安装新版本的Glibc之前必须对一些重要目录进行备份,至于哪些目录需要做备份,下文将会有叙述。

备份好重要目录后就可以安装Glibc了,必须由root用户执行make install命令,不同的Linux发行版,可能会有不同的结果。笔者使用的Mandriva Linux release 2006.0在这个过程中会出现错误,并且输入任何命令都无效,重新启动也无法再次进入Linux系统。出现的这样的错误是由于Coreutils的命令 都是依赖于/usr/tls/目录下的链接文件,这些链接文件都指向原来的Glibc动态库文件,而/lib/ld-linux.so.2已经被改为指向 新版本的Glibc动态库文件了,这些重要链接分别指向新旧不同版本的库文件,导致了执行Coreutils的命令无效。这个时候,就要用另外一个 Linux系统启动,把/usr/tls/目录下的链接修改为指向新版本的Glibc的库文件。

经过上述修改,重新启动计算机,如果能重新 进入原Linux系统,表明到目前为止升级过程都是正确的。这个时候,要再执行一次"make install"重新安装Glibc,正常情况下,这次不会出现任何错误,安装结束的时候,Glibc会给出安装成功的消息。如果修改/lib/tls /下的链接后重新启动计算机仍然不能进入原Linux系统,表明这次升级失败,只能再次使用另外一个Linux系统启动,挂载升级失败的根文件系统,把先前备份好的重要目录恢复为原来的名字,经过这样的恢复,一般是可以重新启动升级失败的Linux系统的。

升级的最后一步是执行"make localedata/install-locales"命令安装时区和地区数据库。

图一:升级Glibc的流程图

image002

注意

本文介绍的方法在升级过程中会出现一次链接错误,系统无法输入命令,重新启动也无法进入Linux,必须使用另外一个Linux系统启动,并挂载原根文件系 统,修正在升级过程中产生的错误链接,然后才能继续升级。因此在升级之前,一定要先确保拥有另外一个可启动的Linux系统。此外,还要备份下文将会论述 的一些重要目录,如果最终升级失败,需要用另外一个Linux系统启动,恢复原Linux系统的Glibc为原来的版本。

建议在升级之前,详细阅读Glibc源代码包内的INSTALL和FAQ文件。

升级过程

本文假设进行编译的用户名字是xyz,用户目录是/home/xyz/,所有源代码都在/home/xyz/build/目录下编译。所有源代码压缩包都已 经拷贝到/home/xyz/build/目录下。升级Glibc的Linux系统的根文件系统使用hda5分区,其文件系统格式为xfs。

1 准备另外一个可启动的Linux系统

准备另外一个可启动的Linux系统的方法有很多,可以在硬盘上安装另外一个Linux发行版,可以在DOS环境下使用loadlin.exe启动一个 Linux系统,最简单的方式是使用Live CD,从光驱启动。无论使用什么形式,它都必须能挂载需要升级Glibc的根文件系统。

如果选择Live CD启动,Knoppix是一个很好的选择。您可以从Knoppix的网站下载iso文件,烧制成启动CD,也可以把Knoppix的系统文件拷贝到硬盘 上,在DOS环境下,执行loadlin.exe启动。笔者使用了Knoppix 5.0.1,制作成Live CD启动。参考资料有介绍如何使用 Knoppix 进行系统恢复。

2 编译

Glibc的编译安装与一般的软件很类似,都是要经过configure,make和make install三个阶段。Glibc不能在源代码目录下编译,必须在一个空目录下编译。

编译Glibc是需要内核头文件的,笔者的Mandriva Linux release 2006.0的内核版本是2.6.12-12mdk,可以直接使用该版本内核的头文件升级到Glibc2.4 和Glibc2.5。如果升级到Glibc2.6,在make过程中,会出现以下错误:

这是由于2.6.12-12mdk的内核头文件太旧,为了顺利编译Glibc2.6,必须使用新的内核头文件。

2.1 编译Glibc2.4或Glibc2.5

如果要升级Glibc到2.4或2.5,configure的时候只需要--prefix=/usr一个选项,意思是该Glibc将会作为系统的标准动态库。

以升级到Glibc2.5为例,执行以下命令进行编译:

glibc-2.5.tar.bz2是Glibc2.5的源代码压缩包,执行"tar xjf glibc-2.5.tar.bz2"命令后,在~/build/目录下产生了glibc-2.5目录树,Glibc2.5的源代码就在这个目录里面。 Glibc不能在源代码目录下编译,因此执行了"mkdir glibc-2.5-build"命令,生成glibc-2.5-build目录,编译Glibc2.5时产生的文件,保存在这个目录下。如果顺利,将会成功编译,不会出现错误信息。

2.2 编译Glibc2.6

如果您打算升级到 Glibc2.6,使用版本为2.6.12-12mdk的内核头文件是不能成功编译的,必须使用新的内核头文件。configure的时候使用 --with-headers选项指向新的内核头文件的目录。Glibc的FAQ文档明确指出最好使用最新版本的内核头文件,而且编译时需要的内核头文件 的版本不需要与当前正在运行的内核版本一致。笔者试验了版本为linux-2.6.20.7和linux-2.6.18两个版本的内核头文件,编译时系统 运行的内核版本是2.6.12-12mdk,都可以成功编译Glibc2.6。

为了使用新版本的内核头文件,解开新版本的内核压缩包后,在源代码目录下执行"make menuconfig",这将会进入内核的设置页面,不需要作任何处理,直接退出并保存。然后执行"make",不需要等待make完毕,一开始看到

就可以按下ctrl+c停止编译内核。执行"make"的目的是在内核源代码目录树内生成一些重要的文件和软链接,其中在include/目录下产生一个名为asm的软链接指向asm-i386目录,没有这个链接,Glibc2.6是无法编译的。

假设使用linux-2.6.20.7的内核头文件,执行以下命令:

linux-2.6.20.7.tar.bz2是2.6.20.7版本的Linux内核源代码压缩包,执 行"tar xjf linux-2.6.20.7.tar.bz2"命令后,将会产生linux-2.6.20.7目录,Linux内核的源代码都在这个目录下,其中内核头 文件在linux-2.6.20.7/include/下。确保linux-2.6.20.7/include/asm已经产生后,就可以停止内核的编 译,然后进行Glibc2.6的编译:

glibc-2.6.tar.bz2是Glibc2.6的源代码压缩包,执行"tar xjf glibc-2.6.tar.bz2"命令后,在~/build/目录下产生了glibc-2.6目录树。

如果您的系统当前运行的内核已经升级到比较新的版本,例如2.6.20.7,configure的时候,就不需要--with-headers选项了,与 Glibc2.4或Glibc2.5的configure命令一样,只需要--prefix=/usr选项就可以了,但是前提条件是/lib /modules/uname -r/source指向内核的源程序目录,您可以用以下命令查看它指向哪里:

3.make install前的准备工作

3.1 哪些目录需要备份?

安装Glibc前必须备份好原来的系统动态库,一旦安装失败,使用另外一个Linux系统启动,挂载升级失败的根文件系统,还原Glibc为原来的状态。可是哪些目录需要备份?Glibc在安装的时候,将会修改哪个目录下的文件?

Glibc 在安装时可以指定install_root选项,命令Glibc把该选项指向的目录作为根,文件都安装到这个目录下,通过观察Glibc在这个目录里生成了什么目录和文件,我们就可以知道Glibc在安装的时候到底会修改哪些目录了。假设安装到~/build/system_fake_root上:

安装后:

可以看出,Glibc的make install命令会修改/etc,/lib,/sbin和/usr目录下的文件。这里最重要的是/lib和/usr。一般来说/usr目录下有很多文件,占用硬盘空间很大,实际也不需要对整个/usr目录备份,使用以下命令查看Glibc会修改/usr/下的哪些目录:

经分析,笔者选择了备份/lib,/usr/lib,/usr/include,/usr/sbin和/usr/bin。您当然可以备份更多的目录,不过笔者发现备份上述5个目录已经可以恢复系统的Glibc为原来的版本了。

3.2 备份目录

使用su命令切换为root。执行:

经过以上步骤,就备份了以后还原用的目录。备份的目录名字使用原目录名后加上.2.3.5后缀,目的是区分不同的Glibc版本目录。

3.3 如何还原系统的Glibc

如果升级最终失败,导致系统无法启动,就必须使用另外一个Linux系统启动,还原上述备份的目录为原来的名字。以笔者的系统为例,升级失败的根文件系统使用hda5分区,其文件系统格式为xfs,将被挂载到/mnt/m1目录。使用Knoppix 5.0.1 Live CD启动后,打开一个控制台,执行"su"命令切换为root用户,执行以下命令

执行上述命令后,Glibc已经被恢复为原来的版本,系统应该可以正常启动。

3.4 如何知道当前的Glibc版本

Mandriva Linux release 2006.0的动态库是Glibc2.3.5。执行"/lib/libc.so.6"可以知道当前的Glibc是什么版本:

从以上输出可以看到,当前系统的Glibc版本是2.3.5,使用Gcc4.0.1编译,编译时运行的Linux内核版本是2.6.12。

Glibc的FAQ文档给出以下程序用于查看当前的Glibc的版本:

把上述程序写到chk_lib_v.c文件,执行以下命令编译:

执行chk_lib_v后有以下输出:

3.5 注意Coreutils依赖的动态库情况

Mandriva Linux release 2006.0系统的/lib/目录下有个tls目录。该目录下的文件是能否成功升级Glibc到2.6的关键。使用ldd命令查看Coreutils的应用程序依赖的动态库情况可以发现:

请注意上述的librt.so.1,libc.so.6和libpthread.so.0,它们都是位于/lib/tls/,而不是/lib/。换言之,ls的执行,依赖于/lib/tls目录下的某些动态链接库文件。tls是thread-local storage,当不同的线程使用同一个全局变量的时候,各线程将会在本地保留该变量的备份,查阅参考资料可以了解更多有关tls的信息。 Glibc2.4,Glibc2.5和Glibc2.6都支持tls。

/lib/tls/下有以下文件:

/lib/tls目录下的文件是一些很重要的动态库及软连接,其中包括libc.so.6,它们都是指向2.3.5版本的动态库文件。

4. 安装Glibc2.6

4.1 第一次make install

切换到root用户,执行make install就开始安装Glibc了:

在安装过程中,将会出现如下错误:

安装失败后,输入任何命令都是无效的,系统只会重 复"relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference"的错误信息,重新启动计算机在启动中就会失败,根本无法进入原Linux系统。

出现这样的错误的原因是 Coreutils的应用程序都依赖于/lib/tls/下的动态库,在make install的时候,/lib/ld-linux.so.2从原来指向ld-2.3.5.so被改为指向ld-2.6.so,但这个时候/lib /tls/libc.so.6指向的仍然是/lib/tls/libc-2.3.5.so。/lib/ld-linux.so.2和/lib/tls /libc.so.6各自指向不同版本的库文件导致了Coreutils的命令执行失败,从而make install也失败。

这个时候, 就要用另外一个Linux系统启动,挂载升级失败的根文件系统,把原根文件系统的/lib/tls/下的链接全部改为指向2.6版本的库文件,具体就是 /lib/tls/libc.so.6,/lib/tls/libm.so.6, /lib/tls/libpthread.so.0和/lib/tls/librt.so.1这4个软链接分别指向libc-2.6.so, libm-2.6.so,libpthread-2.6.so和librt-2.6.so。libthread_db.so.1仍然是指向 libthread_db-1.0.so,但这个时候/lib/libthread_db-1.0.so已经是Glibc2.6版本的了,原/lib /tls/libthread_db-1.0.so必须被替换为Glibc2.6版本的libthread_db-1.0.so。

笔者使用Knoppix 5.0.1 Live CD启动计算机,启动后,打开一个控制台,执行"su"命令切换为root,执行以下命令:

上述命令就是把原根文件系统/lib/下的libc- 2.6.so, libm-2.6.so,libpthread-2.6.so和librt-2.6.so拷贝到/lib/tls/下,并把/lib/tls /libc.so.6,/lib/tls/libm.so.6,/lib/tls/libpthread.so.0和/lib/tls /librt.so.1这4个软链接从原来指向2.3.5版本的库文件改为指向最新的2.6版本的库文件。原/lib/tls /libthread_db-1.0.so下的文件被/lib/libthread_db-1.0.so替换。

4.2 第二次make install

修改了/lib/tls/下的链接和文件后,就可以重新启动计算机,进入原Linux系统,这次将会正常启动,登陆后,执行Coreutils的命令,例如 ls,已经不会出现"relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference"的错误信息。由于Glibc2.6没有彻底安装完毕,我们还要重新执行一次make install:

这次make install将不会出现错误,如果安装成功,到最后会有以下信息提示:

执行/lib/libc.so.6查看Glibc的版本:

这都表明当前系统的动态库已经使用了Glibc2.6。

如果把/lib/tls/下的链接改为指向2.6版本的库文件后,重新启动计算机仍然无法进入原Linux系统,就说明升级Glibc失败,只能再次使用另外一个Linux系统启动,恢复原系统的Glibc为原来的版本,请参考3.3节。

4.3 安装时区和地区数据库

虽然现在系统已经使用Glibc2.6,但是在X Window下,使用fcitx中文输入法的用户会发现按下ctrl+space不会弹出中文输入框。这是因为新的Glibc2.6还没安装时区和地区数据库。执行以下命令:

上述命令将会在/usr/lib/locale/下生成一个名为"locale-archive"的文件。重新启动X Window, 按下ctrl+space就可以调出中文输入框并输入中文了。

至此,升级Glibc完毕。笔者在升级到了Glibc2.6的Linux系统上使用了 VMware,Openoffice,Mplayer,Skype,Firefox,Thunderbird,Vim,Fcitx等一系列软件一段时间, 未发现由于升级了Glibc而导致的错误出现。

回到Glibc2.3.5 成功升级后,想在Glibc2.6和原来的Glibc2.3.5之间切换是很容易的。因为安装前对Glibc2.3.5的重要目录进行了备份,只需使用另 外一个Linux启动,挂载原Linux的根文件系统,把升级前备份好的/lib.2.3.5等目录的名字改为/lib等原来的名字即可。

使用Knoppix 5.0.1 Live CD启动,打开一个控制台,执行"su"命令切换为root,执行以下命令:

重新启动,系统将会使用原来的Glibc2.3.5,Glibc2.6的目录备份为原目录名后加.2.6后缀。

总结

使用源代码升级Glibc,做好升级前的准备是最重要的。首先要准备好另外一个可以启动的,能挂载原根文件系统的Linux系统。其次是对/lib, /usr/lib,/usr/include,/usr/sbin,/usr/bin等目录进行备份。成功升级后,可以在高低两个版本的Glibc之间自 由切换。

升级前只要做好上述两个准备,升级系统的Glibc是安全的。

由于不同的Linux发行版的系统环境不一样,因此使用源代码升级Glibc的过程可能会有差异,为了成功升级,读者必须在升级过程中根据自己的系统的实际情况作相应的调整。

链接地址

http://www.ibm.com/developerworks/cn/linux/l-cn-glibc-upd/

VisualSVNServer Service failed to start

这是VisualSVN Server Manager启动时报出的一个启动错误,可能的问题有以下3种。

1:端口被占用:使用CMD命令

查看端口是否已使用,如果已使用则更换一个端口。

2:Repositories 的物理目录不存在,重新设置Repositories  物理路径。

3:服务VisualSVN Server Manager 服务启动用户设置不正确,在系统服务中,找到 VisualSVN Server 点击右键——属性——登录选项卡,如果是网络用户,就尝试切换到本地用户试试,如果是本地用户,就尝试指定一下其他用户试试。

VistualSVN

解决Win7“无法访问Windows Installer服务。Windows Installer没有正确安装时可能发生这种情况...”

今天在卸载一个软件时,发生错误,提示信息如下:

无法访问Windows Installer服务。Windows Installer没有正确安装时可能发生这种情况...

截图如下:
1356154505_5881

在网上找了下原因,都知道是Windows Installer服务出现了问题,如没有启动它呀,

启动不了Windows Installer呀之类的...却没有给出一个有用的解决方法。

好不容易知道微软提供了一个 Windows Fix it 服务,网址如下

http://support2.microsoft.com/default.aspx?scid=kb;%5BLN%5D;290301
或者
http://support2.microsoft.com/fixit/zh-cn
或者
Fix problems that block programs from being installed or removed
经过一番折腾,搞定!

目前(2018.03.14)貌似微软关闭了这个网站,可以在本站下载Microsoft Fix it 51015

这个工具微软的下载地址为http://download.microsoft.com/download/D/9/7/D97359C4-B5EA-40C7-9991-3EEF14D4848F/MicrosoftFixit51015.msi

如何在VS2010 IE11 下调试BHO控件

VS2010 IE11 下调试BHO控件,在新版本的调试器中已经简化调试流程,简单的设置一下,就可以直接调试BHO的DLL文件了,方便很多。

如下图设置,点击工程属性,然后选择 “调试”在“要启动的调试器”中选择 “Web 浏览器调试器”,在“HTTP URL”中输入具体的网站地址,然后直接启动调试即可。

BHODebug