WDMyCloud编译TestDisk&PhotoRec 7.0/7.1

1.按照How to successfully build packages for WD My Cloud from source中的介绍,搭建完成 WDMyCloud的编译环境

2.下载TestDisk & PhotoRec 7.1的源代码

3.解压缩源代码

4.安装依赖库

5.编译源代码

编译好的文件在 src目录下面。

上面的编译方法编译出来的没办法生成安装包,如果需要安装包的版本,可以直接从 Debian源中下载已经适配过的源代码进行编译,目前已经被适配的版本是 testdisk_7.0-2

使用如下方式编译:

参考链接


源码包: testdisk (7.0-2)

WDMyCloud编译USB网卡MT7601U驱动(小米,小度,360WiFi)

前言


有人留言希望尝试在WDMyCloud上尝试使用USB无线网卡,目标芯片是MT7601U。

经过几天的研究,找到了相关的编译方式。

链接地址 https://github.com/porjo/mt7601u,提示在Linux-4.2以后的版本中已经集成MT7601U芯片的驱动了(drivers/net/wireless/mediatek目录下),但是可惜的是WDMyCloud上的Linux内核版本号是3.2.26,曾经尝试升级到4.2版本之后的Linux内核,可惜尝试之后,发现无法成功编译Mindspeed C2000芯片(WDMyCloud使用的IC芯片,包含CPU,网卡等)驱动,因此只能退而求其次,使用MTK官方提供的驱动程序在3.2.26版本的Linux内核上进行编译。

另外注意,在WDMyCloud提供的默认系统镜像上,没有提供802.11相关的驱动,导致如果使用无线网卡,必须重新编译内核。

具体操作


1.下载MT7601U芯片驱动

驱动程序的下载地址为:http://www.mediatek.com/products/broadbandWifi/mt7601u#product-downloads

也可本站下载

2.下载最新的WDMyCloud的系统源代码

目前最新的下载地址为:http://downloads.wdc.com/gpl/gpl-source-wd_my_cloud-04.04.03-113.zip

3.参照 How to successfully build packages for WD My Cloud from source构建编译环境

4.解压缩下载到的代码中的"packages/kernel_3.2"到"64k-wheezy/build/root"目录下面。

5.执行如下命令,重新编译内核,为驱动的编译准备必备的文件

修改内核编译文件"/kernel_3.2/linux/arch/arm/configs/sequoia64k-wifi_defconfig",在文件的顶部增加"CONFIG_WEXT_PRIV=y",定义这个宏的目的,是为了编译MT7601U芯片驱动的时候使用的,缺少这个宏会导致芯片驱动编译的时候缺少变量。

6.编译内核

编译成功后,在"kernel_3.2/_bld"目录下生成编译文件,在"kernel_3.2/_bin"目录下生成最终的内核镜像和驱动程序。

7.解压缩MT7601U芯片驱动代码到"64k-wheezy/build/root"目录下面,并命名为"MT7601U"。

修改芯片驱动编译文件"Makefile",找到

在这行下面增加

修改"Makefile"中,编译目标系统从 PLATFORM = PCPLATFORM = WDMyCloud.

接下来修改"os/linux/config.mk",在文件尾部增加

最后,切换到驱动程序所在的"MT7601U"目录,执行编译。

编译完成后,在"MT7601U/os/linux/"目录下生成名为"mt7601Usta.ko"的驱动程序文件。

剩下的,参考"MT7601U"目录下的"README_STA_usb"中的说明进行操作即可。

注意,如果要成功使用无线网卡驱动,那么需要用刚刚编译好的Linux内核,替换掉原来的内核,并且把"kernel_3.2/_bin"目录下的驱动也拷贝到系统根目录下面相同的位置即可,这个操作是高风险操作,极可能这么操作之后,系统无法正常运行,因此要提前备份文件,并且做好拆硬盘,挂载到其他机器上撤销刚刚的修改的准备。

参考链接


mt7601驱动使用(三)

WDMyCloud中使用Subversion Server不支持中文路径问题的解决

WDMyCloud中使用 Subversion Server的时候,发现工程名字为中文的情况下,无法下载代码,此时 Subversion客户端报告:

解决方法是在启动 Subversion Server之前指定语言为中文,如下:

其他的的参考如下链接:
WD MyCloud中设置服务在开机时候自动启动

WD MyCloud下面Git提交(Push)失败 index-pack died of signal 9

WD MyCloud下面Git提交(Push)失败

如下图所示:
rpi_linux_error

根据网上的其他人的讨论,采用过

1.安装最新的git(2.14)无效)

2.限制git处理的文件的大小,超过大小则保持原始文件不变 (无效)

3.限制线程数量(无效)

4.限制pack的内存占用(无效)

5.限制pack的内存以及文件大小(无效)

6.使用上面的配置,重新在大内存电脑上重建索引提交(无效)

7.增大交换分区(提交过程变得巨慢,耗费了三天后提示失败,无效)

 

最后的解决方法,其实就是在足够内存的机器上面,提交到本机,然后使用scp作为一个文件夹同步到WDMyCloud中。

参考链接


  1. Git push “error: index-pack died of signal 9”
  2. error: index-pack died of signal [问题点数:40分]
  3. Repack of Git repository fails
  4. Repack of Git repository fails
  5. Git使用小坑 Out of memory错误的解决方法
  6. linux增大swap空间
  7. /dev/null与/dev/zero详解

"method driver /usr/lib/apt/methods/https could not be found" update error

在配置了 /etc/apt/sources.list中使用了 https之后,出现如下错误

如果是中文系统的话,会输出如下信息:

解决的方法是安装 apt-transport-https:

如果此时执行

更新会提示:

则执行如下命令来更新本地的证书:

然后就一切正常了。

参考链接:


WDMyCloud配置Apache访问Subversion

1.确保WDMyCloud是最新的版本,应该是WDMyCloud v04.04.01-112以后,并且确保Apache2的版本号是2.4.9版本。

2.安装Subversion Server

3.配置并启用Apache dav_svn模块

在文件的尾部增加如下内容:

4.创建Subversion用户

5.重启 Apache2

6.网络访问“http://wd-mycloud/svn”。
7.检出项目 “svn co http://wd-mycloud/svn/project project

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

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

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

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

以启动subversion为例子

使用源代码将 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/

WD MyCloud 4.0 deb 安装源

请注意,以下的服务仅仅针对WDMyCloud Gen1,也就是比较早期的型号,最新的Gen2已经把系统从Debian Wheezy切换到了Busybox,因此下面的源已经不适用了。

WDMyCloud Gen1与WDMyCloud Gen2的区别如下:

Gen1: Mindspeed Comcerto C2000 (2 core, 650MHz) 256 MB Ram Debian wheezy
Gen2: Marvell armada 370 (2core, 800MHz) 512MB Ram Busybox


最近由于 WD MyCloud 的固件升级到4.0 之后,新的程序是以 64K 内存对齐的方式运作的,这就导致使用 apt-get 安装的所有安装包都是不能正常运行的,安装后,执行的时候会直接提示 “Killed”,因此需要全新编译代码才能成功安装。有动手能力的,可以参考 How to successfully build packages for WD My Cloud from source 来自己编译。不过非常的折腾。

今天刚刚更新了一下 WD MyCloud 的固件到V04.01.03-421版本,发现他的apt的源列表更新了一下,变成了如下

试了一下,竟然可以安装,并且部分软件运行正常,比如 VIM,Git-Core,Subversion.但是对于 aria2,expect 等软件,建议还是用我提供的源安装,原因在于有些软件需要升级libc6,stdlibc++6等这几个库,而这几个库如果更新,基本上,系统就启动不了了!

对于想省事的人来说,可以设置我的服务器为deb 的更新服务器,里面的是我编译好的版本。

最近调整了更新服务器地址,同时,又增加了Jseeie 版本的编译,这样的话,会有最新的版本的软件,但是,使用的时候要慎重,新版本软件可能没有经过长时间的严格测试,不排除有BUG的可能,如果下载的某些包有问题,麻烦尽快邮件反馈

安装新版本的话,需要手工卸载旧版本,apt-get remove 一下即可。

安装不上软件,提示缺少依赖的,暂时注释掉 jessie 部分的源,原因在于新版本正在编译中,耗时较长,只能是编译完成就上传导致了某些模块缺失。

如下操作即可。

1.打开 WD MyCloud 的SSH 登陆功能。

2.在SHELL 里面执行如下命令

修改里面的内容如下

目前这个安装源中支持的软件可以在下面的软件列表中找到 ,后续我会根据需要编译其他的软件,并且上传的。如果有什么软件是需要的,可以邮件联系我

注意:本源支持HTTPS方式访问,因此上面的配置也可以写成如下方式(目前貌似HTTP会有被劫持的倾向,建议使用HTTPS方式访问(切换到HTTPS之前需要先安装 apt-transport-https),切换到HTTPS之后出现问题,可以参考
"method driver /usr/lib/apt/methods/https could not be found" update error来解决。):

3.执行更新

4.安装软件(以VIM 为例子)

5.目前已经编译完成的软件列表如下

wheezy

jessie

目前根据反馈,有人在使用本源的时候,存在如下的情况

base_download_att

也就是在安装任何应用的时候都提示:

这种情况发生的原因,目前初步定位为使用WDMyCloud自带的源执行过

不管成功失败,还是中途中断,可能会导致" /lib/arm-linux-gnueabihf"中的 libc库被升级,从而出现下图所示的情况(左边是正常的WDMyCloud系统,右图是出现问题的WDMyCloud):

20160212140006

这个问题的目前有效的解决方法是,使用降级系统版本的方式重新刷机来还原系统:

downgrade_version

How to successfully build packages for WD My Cloud from source

The WD My Cloud comes with a Debian wheezy system on it. However WD customized that in a way that it is hardly possible (if not impossible at all) to install new packages using the standard "apt-get install <package name>" way, especially when you update the device firmware to version 4.x or later. The latest firmware, in fact, uses a modified Debian system with 64K sized memory pages: if you install a package using "apt-get install <package name>" from the standard repositories, almost certainly it won't run and produce just a laconic "Killed" output.
继续阅读How to successfully build packages for WD My Cloud from source