解决Windows Update提示“当前无法检查更新,因为未运行服务”

故障:点击“检查更新”,出现“Windows Update 当前无法检查更新,因为未运行服务。您可能需要重新启动计算机”,如下图:
继续阅读解决Windows Update提示“当前无法检查更新,因为未运行服务”

WD MyCloud编译的busybox-1.23.2中增加e2fsprogs-1.43.7

参考更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)配置编译出来的镜像中缺少mkfs.ext3,mkfs.ext4,无法创建GPT分区,我们在此介绍一下如何增加mkfs.ext3,mkfs.ext4的功能。

首先参考Ubuntu 17.10上使用crosstool-ng-1.23.0建立WD MyCloud修复工具编译环境(uClibc)创建我们需要的编译工具。

接着参考更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)配置编译出启动镜像。

具体编译过程如下:

重新打包uImage镜像

如果e2fsprogs-1.43.7的源代码不能下载,可从本站下载一份代码拷贝。点击这里下载

参考链接


WD MyCloud编译的busybox-1.23.2中增加mdadm-3.2.6(独立编译uClibc版本)

参考更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)配置编译出来的镜像中缺少mdadm,无法创建Raid-1分区,我们在此介绍一下如何增加mdadm-3.2.6的功能。

首先参考Ubuntu 17.10上使用crosstool-ng-1.23.0建立WD MyCloud修复工具编译环境(uClibc)创建我们需要的编译工具。

接着参考更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)配置编译出启动镜像。

具体编译过程如下:

重新打包uImage镜像

其他操作参照更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)

参考链接


WD MyCloud编译的busybox-1.23.2中增加parted-3.0/parted-2.3

参考更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)配置编译出来的镜像中缺少parted,无法创建GPT分区,我们在此介绍一下如何增加parted-3.0/parted-2.3的功能。

首先参考Ubuntu 17.10上使用crosstool-ng-1.23.0建立WD MyCloud修复工具编译环境(uClibc)创建我们需要的编译工具。

接着参考更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)配置编译出启动镜像。

然后下载并编译libuuid-1.0.3的源代码

然后下载并编译parted-3.0/parted-2.3的源代码

完成后,打包我们刚刚构建的应用

重新打包uImage镜像

其他操作参照更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)

上面涉及到的源代码,如果不能下载成功,可以从本站下载一份代码拷贝。点击这里下载libuuid-1.0.3点击这里下载parted-2.3, 点击这里下载parted-3.0

参考链接


Building a minimal RootFS with Busybox, GLIBC and DropBear

Ubuntu 17.10上使用crosstool-ng-1.23.0建立WD MyCloud修复工具编译环境(uClibc)

参考更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)编译出来的Busybox是只有3MB大小的样子,这样编译出来的东西非常基础,功能有限。如果想要增加其他软件的时候,最少改动的情况下,一般都依赖GLIBC,而GLIBC完整编译出来的库接近50MB,而我们修复系统,是一个纯内存文件系统。直接采用GLIBC会非常浪费不多的内存空间。

因此在低内存的系统上采用uClibc,变成一个不错的选择。下面我们讲一下如何通过crosstool-ng-1.23.0构建一个我们需要的编译系统出来。

首先编译crosstool-ng-1.23.0源代码

如果下载crosstool-ng源代码存在问题,可以从本站下载一份代码拷贝。点击此处下载

最终的.config文件,可以参考下面的配置信息,或者简单的拷贝这个文件到编译目录即可

最终在如下目录生成我们需要的编译程序

编译过程中的源代码下载可能会非常缓慢,可以从本站下载一份代码的拷贝。点击这里下载。下载完成后,解压缩到当前用户根目录,编译的时候,会自动使用已经下载的文件。可以使用下面的命令进行下载解压缩操作:

如果懒得编译,也可点击这里下载一份已经编译好的编译工具

参考链接


WD MyCloud编译的busybox-1.23.2中增加mdadm-3.2.6

参考更优雅的(不拆硬盘)拯救死翘翘了的WD MyCloud(Ubuntu 17.10)配置编译出来的镜像中缺少mdadm,我们在此介绍一下如何增加mdadm-3.2.6的功能。

如果mdadm-3.2.6的代码不能成功下载,可以从本站下载一份代码拷贝。点击这里下载

具体使用的时候:

参考链接


PTP简介

在通信网络中,许多业务的正常运行都要求网络时钟同步,即整个网络各设备之间的时间或频率差保持在合理的误差水平内。网络时钟同步包括以下两个概念:

时间同步:也叫相位同步(Phase synchronization),是指信号之间的频率和相位都保持一致,即信号之间的相位差恒为零。

频率同步(Frequency synchronization):也叫时钟同步,是指信号之间在频率或相位上保持某种严格的特定关系,信号在其对应的有效瞬间以同一平均速率出现,以保证通信网络中的所有设备都以相同的速率运行,即信号之间保持恒定的相位差。

继续阅读PTP简介

网络时钟同步协议-- NTP, PTP

这篇文章介绍一下两个时钟同步的网络协议:NTP和PTP。
这里不涉及协议的原理和具体实现(想了解的可自行Google),重点是如何搭建起这两个服务。

1. NTP及PTP简介


NTP(Network Time Protocol)是用于不同计算机之间同步时钟的网络协议。
它的设计目标是使所有的互连的机器之间的时钟与UTC时间只相差若干毫秒

目前NTP协议已经是有第4版了,如果不需要了解NTP太多细节的话,看看这个wiki页面应该就足够了。需要注意的就是它有clock strata的概念。

PTP(Precision Time Protocol)看名字就知道是一个比NTP更精确的时钟同步协议了,PTP的设计目标是使机器之间的时钟偏差在sub-microsecond范围—这是wiki页面上提到的,有其他的地方说的是偏差若干微秒,本文搭建的环境中测量到的偏差也在微秒级别,没有到sub-microsecond级别。在使用PTP协议时,需要了解的主要概念点就是它的master/slave机制。

接下来我们就介绍我搭建NTP和PTP环境的过程,所用到的操作系统是CentOS6.5,内核版本是3.10。其他软件的版本会在用到时提及。

2. 搭建NTP服务


配置环境:两台服务器,一台做NTP服务器,一台做NTP的客户端。同时这两台机器都未联网。
NTP服务器地址:192.168.0.11
NTP客户端地址:192.168.0.22

A. 在192.168.0.11中启动NTP服务

B. 在192.168.0.22上启动NTP服务,选择192.168.0.11为NTP服务器

我的这两台实验机器是在同一个Rack的,结果显示差不多同步的偏差在30ms左右。
每个版本的ntpd配置文件可能有少许的差别,不过好在注释都做的不错,所以别的细节就不啰嗦了。

3. 搭建PTP服务


List of PTP implementations可以看到PTP的实现有很多很多种,可以是硬件实现的,可以是软件实现的也可以是软硬件结合实现的。本文中搭建的PTP服务是基于软件PTPd。如果没有特殊的硬件的话,这算是一种非常方便的方法了。

如果遇到任何问题,首先一定要看看help,使用-H选项的话还能看到非常详细的配置(虽然大多我可看不懂,不过不能不看,理解的越多,遇到的问题就会越少)。
如果log里面的信息看不懂,可以把代码下下来,一个grep搞定。

经测试,在我的机器上使用PTPD软件搭建的服务,时钟偏移的平均值能够达到5us左右。这个粒度基本能满足我们的需求了。

参考链接


Linux中的时钟准确度

本文来自戴尔软件开发高级工程师Stuart Hayes

一个关于计时的问题最近引起了我的关注。 有用户在 Dell 服务器上运行 Linux,并且发现时钟时间(Linux 所报告的)每天误差五秒以上,偏差比较明显。

我们首先想到的也许是运行 NTP,定期与真实世界同步操作系统的时钟。

但是这样的误差最初是如何产生的?

在Linux运行时,Linux 系统未使用实时时钟(real time clock - RTC) 硬件来计时。 Linux 通常在启动时从RTC 读取时间,然后从该点开始,Linux 使用另一个时钟来源(系统中的另一个计时器/计数器)来计时。

自第 2.6.18 版起,Linux 的内核就使用 CPU 时间戳计数器 (TSC) 作为首选的时钟来源(假设 TSC 以恒定频率运行,以新款的 Intel 服务器 CPU为例)。 但是,尽管读取速度很快且解析度很高,TSC 却不是一个已知的频率。 当内核使启动时,它需要使用频率已知的另一个计时器,对其进行校准。 这样的校准并非天衣无缝(即使用于校准的计时器也是如此),因此把 TSC 作为时钟来源会造成时间误差。

如果减少时间误差对您非常重要,而非若干微秒的调度延迟,则最好使用频率已知的计时器,如大多数 x86 服务器上提供的 HPET(高精度事件计时器)。 借助新内核上的参数"clocksource=hpet"可实现这一目标。 HPET 计时器以已知、固定的频率运行,Linux 内核可直接从计时器读取时间。

话说回来,尽管 HPET 的精度高于 TSC,运行 NTP 以在 Linux 中实现长期的时钟精度始终是很好的想法。
上述讨论仅适用于运行于裸机的 Linux。 在虚拟机中的问题略微复杂。

原文链接


Linux 中的时钟准确度