这里记录早期版本docker （1.11.2）在centos 7（linux3.10）devicemapper存储异常，导致docker容器的空间内文件删除后存储空间不能正常释放。

磁盘40G，早期因为日志异常docker使用了30G，后面删除日志后容器容量一致在30G往上涨，慢慢地主机的磁盘完全被消耗掉，但是实际容器使用7G。

关于如上描述异常，这里有详细分析描述：

• Device-mapper does not release free space from removed images #3182
• Friends Don't Let Friends Run Docker on Loopback in Production
• Clean docker environment: devicemapper

这里采用aufs,需要说明的是所有更改都需要删除原来容器数据后再次创建。所以这里需要讲当前容器进行备份后恢复。

• 提交容器最新更改，导出镜像文件；

• 删除当前docker 数据；

• 更新非主线的aufs 内核；

• 更改grub后重启，并且检测生效；

• 重启后通过/proc/filesystems 确认是否更改生效；

• 更改docker.service

• 安装镜像文件；

重启电脑后发现wifi不能使用了，网络设置里面提示未发现网络适配器。电脑比较新，之前安装ubuntu18.10 低版本kernel 版本就发现不识别wifi设备，更新到ubuntu19.10 后正常，不过正常安装后也反复重启过使用了一段时间。

• Detected Intel(R) Wireless-AC 9560, REV=0x354；
• Ubuntu 19.10 5.3.0-40-generic；
• 小米笔记本pro 15；

第一时间排查dmesg 发现有iwlwifi 内核模块报错。主动搜索报错码-110毫无头绪，电脑比较新，系统也比较新。

顺着iwlwifi提示做了以下排除。

• 通过dmesg报错信息驱动wifi型号为intel-Wireless-AC-9560

• 查找官网 linux 支持最新驱动并按照README更新；

  • Cannot detect wireless driver intel ac wireless 9560
  • WiFi on ASUS ROG GX501 works with Ubuntu 18.04, fails on Ubuntu 16.04

  确定官网驱动提供iwlwifi-9000-pu-b0-jf-b0-34.618819.0.tgz 为.ucode格式。

  同时按照型号查找本地的固件版本。

  确定本地的固件都比官网提供的的新，但是不确定当前使用的哪一个。

  在dmesg中并没有找到uco...

由amazon、apple、google、zigbee alliance牵头的project connected home over ip项目成立了，旨在统一智能硬件在应用层的通信协议，多年智能家居从业，从早期私有协议，再到各家所谓的data models、tls（things language specification）、物模型、miot-spec，甚是知道在上层应用的通信语言的不统一，带来的设备模型重影映射是多么繁琐。

1. mazon’s Alexa Smart Home
2. Apple’s HomeKit
3. Google’s Weave
4. Zigbee Alliance’s Dotdot data models

巧的是第二天zigbee 联盟就来公司就行了宣讲。很多人会觉得很别扭，上层的应用通信语言的统一为什么会有zigbee联盟的加入，熟悉zigbee协议的应该知道，发展了10多年的zigbee在zigbee3.0后才逐渐进入人们视野。很大程度上是得益于zigbee3.0设备的zcl revision7，基于硬件属性统一了硬件之间的通信语言，打通不同硬件厂商的设备的通信。而zcl则是zigbee 联盟的物联网统一语言规范dotdot的over zigbee应用，显然地，zigbee 并不满足于此，这一次四位大佬的相聚相信会取其大家特长，打通设备之间的网关、iot平台、应用之间的标准通信语言。

利...

自从使用了onedrive过后就像发现宝贝似得，跨机器自动同步文件很是方便，特别是一些正在进行调试笔记、开发文档。所以在ubuntu也马上考虑使用onedrive。

• https://github.com/xybu/onedrived-dev

通过apt安装如下依赖工具包。

• gcc

• python3-dev

• libssl-dev
• inotify-tools
• python3-dbus (or probably libdbus-glib-1-dev)

安装pip3和setuptools。

同时还需要手动下载ngrok,解压后导出环境变量NGROK。

成功下载依赖过后通过通过clone源码安装onedrived。

成功安装onedrived后系config统会增加onedrived和onedrived-pref 两个应用工具。

需要通过onedrived-pref配置onedrive信息，选择交互模式执行命令添加账户onedrived-pref account add。该命令会生产onedrive登录链接并提示你浏览器打开。成功打开该链接后会自动引导从Microsoft登录onedrive，成功登录后会自动跳转到空白网页，并且生成包含登录token的url，我们拷贝该url到命令输入窗口完成认证。

完成登录认证后还需要去通过 onedrived-pref drive set配置onedrive本地路径和配置文件路径...

需要理解linux下面的几个概念。

主机名，默认保存在/etc/hosname，可以通过命令hostname查看和更改。

本地域名文件，配置后再本机立即生效。默认地，会设置本机hostname到hosts使之映射到127.0.0.1。同样地，局域网内也可以通过http://hostname 到该机器。

• Multicast DNS
• mdns

mdns 即多播dns（Multicast DNS），mDNS主要实现了在没有传统DNS服务器的情况下使局域网内的主机实现相互发现和通信，使用的端口为5353，遵从dns协议，使用现有的DNS信息结构、名语法和资源记录类型。并且没有指定新的操作代码或响应代码。在局域网中，设备和设备之前相互通信需要知道对方的ip地址的，大多数情况，设备的ip不是静态ip地址，而是通过dhcp协议动态分配的ip 地址，如何设备发现呢，就是要mdns大显身手，例如：现在物联网设备和app之间的通信，要么app通过广播，要么通过组播，发一些特定信息，感兴趣设备应答，实现局域网设备的发现，当然mdns 比这强大。

当mDNS客户端需要解析主机名时，它会发送一个IP多播查询消息，要求具有该名称的主机标识自己。然后该目标机器多播包含其IP地址的消息。然后，该子网中的所有计算机都可以使用该信息来更新其mDNS高速缓存。任何主机都可以通过发送生存时间（TTL）等于零的响应数据包来放弃其对名称...

请输入密码访问

已经完整梳理主要程序流，对于每个主程序流会按章节阻逐个细化分解。

• uboot 入口main

  main完成一些状态初始化和标记，之后通过board_init_f和board_init_r 完成早期、中期初始化工作；

• 对于如上初始化board_init_f主要通过预定义并且初始化的函数指针列表init_sequence_f[]依次执行完成；

  同样地，对于board_init_r 通过预先定义好的init_sequence_r 数组依次完成函数调用；

• 之后程序进入main_loop 通过解析预定义环境变量bootcmd=x执行后续操作。

  bootcmd的函数实体通过预先定义好命令序列。

  完成boot image的查找查找android 引导分区，为kernel 跳转查找基地址；

  在这里完成boot到kernel 基地址跳转；

详细分析mmc初始化流程。

allwinner a64支持uboot阶段显示静态图片，这里梳理程序结构，确定gac-350未什么未生效，同时确定从boot->rootfs 整个过程显示蓝屏的根本原因。

从如上代码走的来看，lcd完整驱动区分如下层次关系；

此uboot中的disp模块同内核/linux-3.10/drivers/video/sunxi/disp2/disp中的一一对应。

不同的是，内核中的显示驱动通过内核模块的方式加载。也就是，在uboot通过的boardc_r.c ...

• Top 5 Programming Languages For Developing Linux Desktop Applications
• https://www.gtk.org/
• Overview of GTK+ and its Libraries
• GTK+ 3 Reference Manual

• 安装开发包和下载源码

• 编译

• 对于复杂ui的开发，可以通过GtkBuilder 实现xml来描述ui，同时可以通过 Glade 做图形化配置控件；

  https://developer.gnome.org/gtk3/stable/gtk-getting-started.html

• 对象继承关系；

  https://developer.gnome.org/gtk3/stable/ch02.html

• 控件画廊

  https://developer.gnome.org/gtk3/stable/ch03.html

需要在非root用户 DISPLAY=:0 ./example-0 运行。

同时，x server 限制连接用户。所以如果要通过root调试，会麻烦一些。

基于debian8 的linux设备会低概率的出现的系统完整死机，这里思考给linux添加完整的看门狗策略。

debian8已经采用systemd用以初始化系统和守护、管理系统进程。这里同时存在systemd 的watchdog和keepalive 单元文件，以及sysv init的watchdog keepavlie 初始化脚本，同时systemd也直接看门狗启动，那么该如何选择呢？

• systemd直接支持看门狗启动；

• debain8同时支持systemd和sysv init的看门狗以及保活机制。

• Device Drivers-> Watchdog Timer Support

• ./drivers/watchdog/Kconfig

  所以这里只需要使能CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y

如上使能了过后还是没有出现看门狗设备，参考sunxi 主核发布说明确定4.17之后a64才加入看门狗功能，这里涉及sunxi_wdt和dts和驱动移植。

• error

• 启动日志

/bin/systemd-tty-ask-password-agent --watch

supervisor启动失败，通过/var/log/syslog 直接报错。

该报错通过systemd控制的sysv init启动脚本报出。从直接报错的代码位置来看是start-stop-daemon启动supervisord 失败。

为什么这里会启动进程失败呢？通过man start-stop-daemon 找到了可能的报错原因。

通过如上分析可以知道这里可能存在了--pidfile 指定的进程id，尝试更改/var/log/supervisord.pid 文件进程id为1（systemd进程名）。此时发现supervisd再也启动不了了，同时也直接如上报错。

那么这里为什么会出现相同进程id的进程名呢？

通过分析这里设备可能存在异常断电导致设备未正常销毁pid文件，再次启动的时候又检测到相同pid的进程名，所以直接导致了进程的启动失败。

pidfile单例模式启动进程这么通用的机制为什么会出现该缺陷？其他守护进程也会出现？还是只是概率问题。

其实不然，以下分析。

在systemd#systemd vs sysv init 详细介绍了sysv init 和systemd控制的进程启动。这里的3.0.0 版本supervisor 通过sysv init启动。sysv init通过start-stop-daemon 和--pidfile 单例模式启动supervisor，升级到高版本的由syste...