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.

So, to install new packages on the My Cloud you need to build them from source on another system, copy the obtained deb packages on the My Cloud and install.

WD provides a GPL source package of the latest firmware on their website, which contains a build environment to perform this operation. This is totally at the end-user own risk, since no support at all is provided by WD and installing 3rd party software may void warrany.

An additional problem is that the build environment provided by WD has a "minor" problem that causes the building process of most packages to fail because of a GCC compiler segmentation fault.

This guide shows how to deal with this problem and, in general, how to create a build environment to easily do the task.

Some Linux knowledge is needed.

NOTE 1: as of now, this procedure is surely needed to build packages for the 4.x firmware; however, by experience, I find out that it's a useful procedure even if you are sticking with the 3.x firmware; so the guide explains how to build packages for both firmware versions

NOTE 2: in principle, it should be possible to build packages directly on the My Cloud, instead of using an external system; however I don't think it's a good idea to try this, because of many reasons, including: the My Cloud system is surely slower than a regular PC to compile packages; you would need to install all the development tools on the My Cloud itself (and this may require in turn to build them on another system first...)

Step 1: prepare the build system (required only once)
The build environment must be a Linux system, either Debian-based or Ubuntu-based. I personally suggest to create a virtual machine with such a system in it. This guide will take this route.

Download and install VirtualBox (https://www.virtualbox.org/) on your phisical system (either Linux, Windows or Mac). Start VirtualBox and create a new virtual machine for a Debian 64-bit. The default settings suggested by VirtualBox regarding memory, disk size and VM configuration should be ok to start.

After the VM is ready, download a Debian Wheezy 64-bit ISO image; I suggest the netinst image, which is the smaller one. Right now, Debian 7.8.0 is available and the direct links are:

注意,强烈推荐用最新的Debian 8.3系统来进行编译,就目前的编译经验来讲,Debian 8.3所使用的Qemu修正了大量的BUG,尤其是编译期间出现的大量的"段错误(Segment fault)",7.8版本上完全无法通过编译的软件,在8.3上轻松编译通过。

Boot the VM with the downloaded ISO mounted in and install just the Debian base system (nothing else is required). Refer to VirtualBox and Debian websites for documentation on how to perform these operations.

Once the guest VM is installed, we need to make just a couple little tunings. First of all, Debian Wheezy comes with qemu-user-static package version 1.1.2. Qemu is an environment needed to emulate an actual ARM system on another platform, like the AMD64 platform our build system consists of. It's a good idea to update Qemu to version 2.x from the wheezy-backports repository. To do this, start the build system and login. Then:

对于国内的用户,使用官方源可能无法更新,建议如下设置

如果使用现在最新的Debian 8.3版本,则不需要继续在backports中安装qemu了,执行如下命令即可。

This should also install binfmt-support, which is another packages needed by the build environment. If this is not the case, also type:

Now, let's prepare the actual build environment. Let's create a folder in the /root directory of the build system and download the WD My Cloud 4.x firmware source package from WD website.

In case the link changes, refer to WD My Cloud support page to find the new one: http://support.wdc.com/product/download.asp?groupid=904&lang=en

I then suggest to create different folders for different build scenarios. These are the possibilities:

  • the target system may be firmware 3.x (4k) or firmware 4.x (64k)
  • the source package base may be wheezy (Debian stable) or jessie (Debian testing); wheezy contains older packages, but that should run happily in My Cloud (which has a Wheezy in it!), while jessie contains newer packages that might also work and provide updated versions of many applications; I would personally recommend to build packages from wheezy, unless you absolutely need a newer version that is only in jessie

I don't recommend to mix things, so I would create different folders for any different combination. You're free to create just the one you are interested in, so among the following commands type fhe first ones, then only the block of commands of the combination(s) you're interested in, then the last command:

In this way, in every folder will be created a build.sh script that passes the right parameters to the WD provided script, requiring only the name of the package to build. This would work straight away if there weren't the problem with qemu I mentioned in the beginning, so another step is required to finish the prepare phase. Again, only type commands for the scenario(s) you're interested in:

64k-wheezy:

64k-jessie:

4k-wheezy:

4k-jessie:

The meaning of the above is the following: prepare an emulated ARM system and replace the qemu-arm-static binary provided by the bootstrap with the recent one we've installed in our actual build system.

Ignore any errors produced by setup.sh: that script is really buggy and many things it tries to do seem to be useless, unless we apply the mentioned qemu fix.

As a final step, I would recommend to edit the sources file list within the armhf build subsystem in order to be able to build packages that are in any of the distribution repositories. To do this, type the following:

by replacing <scenario> with the desired one (64k-wheezy, 64k-jessie, 4k-wheezy, 4k-jessie); the nano editor will open, then replace the contents of the existing file with the following:

For 64k-wheezy and 4k-wheezy:

For 64k-jessie and 4k-jessie:

In case of wheezy, uncomment the last two lines if you want to build package versions from wheezy-backports. I don't know however if additional changes to the build.sh script (or better to the WD provided one) are needed to instruct apt to download and build the source from the backports repository. I don't have tried it yet. Anyway, I would recommend to leave those two lines commented unless you actually need something from the backports repository.

Save the file by hitting Ctrl+X, Y, Enter.

Now you're ready to build your first package!

如果使用现在最新的Debian 8.3版本,需要把主机的域名解析的配置文件,复制到编译的对应目录,否则会造成无法解析域名(当然,也可以自行编辑一个正确的 resolv.conf文件,指定域名解析服务器地址)。

Optional additional step (not strictly required) for wheezy scenarios

You may also want to use an updated C++ compiler to build packages in the wheezy scenarios. Debian Wheezy provides g++ package 4.6, but 4.7 is also available. With the following commands you can install the new version and then switch from one to the other using update-alternatives:

After these commands, the default C++ compiler will be version 4.7. You can then switch to the old version by typing:

Or use

to get an interactive prompt.

Step 2: build your package
It's time to build your package. Let's build htop for instance, a nice replacement for top comma
nd. The example will build it for the scenario 64k-wheezy (i.e: packages suitable for 4.x firmware, built from the version of htop provided by Debian Wheezy). Start your build system, login, then:

The built package will be placed into /root/wdmc-build/<scenario>/build/root and will consist of one or more .deb files (you'll also find other files and folder, just ignore them and consider only .deb files). Sometimes building a package will build other packages, too: it depends on how package sources are organized. For instance, if you build transmission-daemon, you'll also get the deb packages for the GUI packages (like transmission-gtk or transmission-qt): you can simply throw away those additional debs if you don't need them.

Once the deb files are ready, copy them from the build system to your My Cloud (to achieve this, if you built a VirtualBox VM you may use a shared folder to exchange data with the physical host system). Then, login via SSH to your My Cloud and type:

where <path-to-built-deb-file> is the path where you stored the deb file you just built; if you copied it to the standard Public shared folder, the path will be /shares/Public/.

If you're lucky, you're done. Otherwise, the /installation command may prompt you something like this:

This simply means that the package you're trying to install depends on another package (in this case: transmission-daemon requires libcurl3-gnutls) which is not yet installed. You then need to build in turn this required package, with the same procedure, and install it before the package you originally intended to install. Repeat the steps for all the missing dependencies that dpkg reports. Sometimes, to fix circular dependencies (packages depend on each other), once you've built all the necessary packages you may install them all at once with: dpkg -i <path-to-built-debs>/*.deb, so that dpkg will resolve dependencies automatically.

Final notes

  1. building a package may require a LOT of time, just be patient...
  2. you may periodically clean /root/wdmc-build/<scenario>/build/root folder after you've built your packages, to free up space; in fact, building may require a considerable amount of (temporary) disk space
  3. once installed with dpkg, packages contents are unpacked to the My Cloud system partitions. There should be enough disk space available to not worry about disk space, however almost certainly a firmware upgrade will delete all of your installed packages; I would suggest to create a shared folder using the web UI, named "System", protected by password and accessible only to admin users; inside it you may put your built deb files, organized as you like. In case of a firmware upgrade, you may simply re-install the packages from there using dpkg -i (one at a time, or all of them at once using wildcards, etc.); however please consider the following notes
  4. a firmware upgrade might change the architecture of the provided Debian system and might require to rebuild all packages... this is exactly what happened with the upgrade from 3.x to 4.x firmware, where WD decided to rebuild the whole system using 64k sized memory pages rather than the standard 4k sized ones... I don't think WD is so sadistic to do that again and again, but who knows? I suggest to read carefully the release notes of the new firmware, have a look to the updated GPL source package (if they make it available on their website) and try to install a few small packages after firmware upgrade just to check that everything is ok; installing all in a rush may have catastrophic effects, especially when a package you had built on your own requires to update one of the WD provided ones... if it won't work, it will almost certainly break something of the WD built-in features, causing a device failure in the worst case... again, you are on your own, you get no support for this
  5. to restore the whole functionality of third-party applications after a firmware upgrade, not only you may need to reinstall the deb packages, but you will also need to restore any custom application configuration; if you leave default settings, usually applications save their settings in /etc or in /root, which are both on the system partitions of WD and might be deleted and recreated by the firmware update process; you may choose to backup your application configurations or change things so that they are linked to a shared folder (for instance the aforementioned System shared folder) where they won't be deleted; in this way, after the firmware upgrade you may just need to restore your backups or your symlinks; howerver, the exact procedure may be different for each package and is above the scope of this guide

From the above, two things should be quite clear: disable the automatic firmware upgrade in the web UI and use all of this at your own risk.

目前已知的包编译问题:

  • runit-2.1.1包编译的时候,会提示失败

原因为其中的一个检查脚本对于 chroot重定向之后的目录检查存在问题,解决方法为找到 “/wdmc-build/64k-wheezy/build/root/runit-2.1.1/runit-2.1.1/src/check-local”,注释掉里面的代码,修改

  • 编译 gcc-4.6的时候,会提示失败

解决方法为,手动执行所有的命令,不要让他执行创建子进程命令。

注意,不要编译 gcc-4.7 版本,因为会导致 libstdc++6升级,而libstdc++6升级之后会导致系统工作不正常。

另外,上面的编译完成之后,安装GCC-4.6的时候,会提示libgomp1 这个包不存在,貌似ARM下面到 Gcc-4.6 的时候还不能很好的支持OpenMP,网上的其他编译GCC 4.6 ARM的都是禁用掉了OpenMP的编译。

修改里面的

然后重新编译即可。

  • 编译Subversion的时候提示失败

这个时候是不能编译成功的,必须用一个非root 的用户执行命令,执行如下命令,增加一个普通用户user,并且安装fakeroot,然后用user的身份登录

此时如果编译还是编译不通过的,主要是JAVAHL部分不能编译通过,ARM下面用的JAVA解析器是gcj-jdk,这个解析器貌似根本不能运行起来,最后会卡在如下的部分,尝试过切换到Open-jdk,可惜也不能编译过去,因此只能去掉这部分的编译

这时候需要修改源代码的debian/rules文件,去掉JAVAHL部分的编译

修改

然后修改

然后继续执行上面的命令,并且切换用户到user

以上为Subversion-1.6 Wheezy 版本的编译,如果要编译 Subversion-1.8 Jessie版本的话,还需要如下配置

1.用user用户登录

2.删除Subversion-1.8 目录

3.重新以低权限生成目录,如果不如此操作,会提示各种各样的权限不足。

4.返回root,并安装缺少的依赖库

5.修改debian/rules,禁止测试安装包,目前启用测试会失败。

修改为

6.重新返回 user,执行编译。

  • 编译GCC 4.9

很遗憾的是Gcj,Ecj模块在ARM下面即使到了GCC-4.9都不能正常运行,运行的时候,直接卡死在运行界面上面,既不失败,也不返回,就是卡住比如安装 ecj-gcj 后在Shell 直接运行 ecj-gcj,连版本号都不能显示,就是卡住。

因此只能在ARM下面要求GCC不支持JAVA的编译,编译JAVA还是用OpenJDK 好了。

打开规则配置文件

修改

也就是在最后面增加

去掉JAVA模块,然后重新编译即可。

  • 编译最新的aria2

编译最新的Jessie版本的 aria2,如果使用 Jessie 的编译环境编译,则编译出来的程序依赖了gcc-4.9 导致libc6的升级,一旦 libc6升级,则系统立即崩溃,因此编译方法为把64k-Jessie 下面的文件夹拷贝到 64k-wheezy目录下面然后编译即可。

  • 编译PHP5

编译PHP5的时候,会出现卡住在 stop mysqld 的问题,此时应该新开一个shell,然后手工杀掉mysql服务,貌似是编译程序没办法停止mysql,只能是手工处理,杀掉后,编译进程就可以正常继续了。

  • 编译update-inetd

编译update-inetd-4.43的时候,总是失败,卡住在

因此需要注释掉 debconf-updatepo

修改

然后重新编译即可。

  • 编译git-2.1.4

编译最新的Jessie版本的 git-2.1.4,(git版本低于1.8的服务器存在一个当大量文件被pull到服务器会出现内存峰值导致内存不足而提交失败的BUG),如果使用 Jessie 的编译环境编译,则编译出来的程序依赖了gcc-4.9 导致libc6的升级,一旦 libc6升级,则系统立即崩溃,因此编译方法为把64k-Jessie 下面的文件夹拷贝到 64k-wheezy目录下面然后编译即可。

需要注意的是 libpcre3-dev的开发包安装语句

否则会提示如下错误:

参考链接


GUIDE-Building-packages-for-the-new-firmware-someone-tried-it