缘起承载几个libvirt虚拟机（kvm）的宿主更新了系统，更新完重启后发现虚拟机起不来了。启动会报错：内部错误：无法载入 AppArmor 侧写这个显然是个非常硬的中文翻译，网上查了下，对应的英文应该是：Error starting domain: internal error: cannot load AppArmor profile 'libvirt-看起来是AppArmo

缘起从几年前开始为了使用虚拟化直通的功能，一直使用自行编译开启了pci设备拆分功能的内核，这几年积累下来也有十几个内核了，由于使用的是make install安装，不能在更新内核时及时删除老的。最近系统磁盘空间有点吃紧，就研究了一下怎么清理老的make install的内核。折腾过程标准apt安装内核的清理网上查了下，都是讲标准通过apt安装的内核的清理，主要的步骤如下：1、找出已经安装的内核dpkg -l | grep linux-image-2、卸载内

缘起之前使用一个Android废弃平板做的客厅时钟，用于显示一些日期、时间、天气等。最近由于这台寨板的电池挂了，没办法不插电源开机，而且触摸也全坏了，也就是开机后也没办法操作了。如果想要连接电脑操作，此时又会由于没电立马关机，属于是死循环了。中途也想过其他的办法，比如使用usb-otg一边充电，一边连接电脑，把时钟启动起来，但实测下来没办法在这台android寨板上操作。而最近发现还有个老的kindle在吃灰，且kindle也不在中国运营了，就抓来临时做个时钟吧。因此有了此次使用kindle做时

缘起最近更新华硕路由器固件时，可能由于是老的型号，MVRAM空间不够等原因，在升级后变砖没法用了，因此折腾这次的救砖操作了。折腾过程整体参考了恩山论坛的方法，采用官方firmware restoration软件没法恢复，使用U-boot模式的网页成功恢复。因此这里主要写U-boot恢复的操作：总结华硕的路由器或者说目前市面上的路由器都有恢复模式，在刷机失败变砖后，都可以通过一些方式进行恢复。参考文档https://www.right.com.cn/forum/thread-4137387-1-1

缘起最近使用的照片同步软件一直提示错误，报文件无法读取的问题。经过详细的分析测试，发现是手机上通过adb push到照片文件夹的文件夹存在中文，而在windows下由于gbk和Android系统编码的问题，在Android系统层面无法删除文件（在文件管理器里也看不到），而软件扫描到后无法读取（这里很坑由于在文件管理器看不到，不好分析，还是我从系统相册中发现有相关空白照片才发现的）。解决方法试了网上说的使用linux命令行、通过inode删除，都无法删除，最后网上有段分析(引用自：https://

缘起最近用了好几年的华硕路由器，在升级固件版本后，右上角有个提示，说是NVRAM空间不足了，可以重置或者清理dhcp进行释放。开始看到这个提示是很懵逼的，因为路由器的内存页面显示还有很多内存的，因此有这次折腾过程。折腾过程什么是NVRAM通过网上查询，这块NVRAM是内存，但是和普通内存有很大区别，这块内存最终是会存储到物理硬件的，而且NVRAM的大小，是cpu强相关的，基本在华硕路由器的某个型号下，是固定的大小，比如我在使用的路由器，是64KB的大小。为什么会突然提示NVRAM空间补助实际上，

缘起最近发现家里的游戏显示器根本没有时间玩，基本就是在吃灰，而本来准备在办公室换个好点的显示器的，这下直接把家里显示器利用起来，不买新的立省100%哈哈!家里的游戏显示器是2k分辨率的155高刷屏幕，而办公室之前使用的一直都是HDMI连接的，因为来回有一番折腾~折腾过程HDMI连接一开始直接使用之前的HDMI连接方式，把笔记本的HDMI连接到显示器上，但是发现只能60hz，不能开启高刷了，即使使用了Custom Resolution Utinity超频，也仅仅能超频到74hz，和显示器支持的15

缘起众所周知centos本来是个挺稳定的系统，提供了十年的超长支持周期，且是readhat红帽linux的下游稳定版本，适合作为服务器使用，之前vps上也一直使用centos7系统。但在centos所属的redhat被IBM收购后，21年宣布未来centos不会作为redhat的下游，而是变成了介入fedora和redhat之间的测试版非稳定系统。当前的centos8系统在2022年已经终止支持（本来要到2029年停止的），centos7也会在2024年6月终止支持。当前的时间点，也快到cent

缘起之前使用的tolist，最近考虑迁移（tolist只能用windows app形式在微软store安装非常麻烦），就找了nextcloud的替代品。操作过程1、docker安装nextcloud不赘述，如下命令安装即可：sudo docker run --network ma1 --name nextcloud -v ./docker/nextcloud/html:/var/www/html -d&nb

缘起最近发现v2里有一些本地局域网网关的代理记录，这非常的奇怪，因为网关地址是局域网地址，不可能会走到v2透明代理里的（只对g.f.w生效）。折腾过程经过一段时间分析，发现是bt下载客户端一开启，就有相关的日志，关闭后就没有了。这样的话就可能是bt下载客户端导致的了，关闭bt下载客户端的代理配置，发现问题依旧。于是把所有的下载全部暂停再观察，发现问题消失，这样的话应该是和bt下载过程强相关了。于是分析是不是bt下载里的一些tracker存在问题，通过一一排查，最后发现是一些走udp协议的trac