引入
随着现实生活中的设备性能越来越强,CPU主频变高核数变多,内存也越来越大,如何链接依赖库越来越少的考虑性能因素了。我这里结合工作经验谈一下兼容性因素、热更新因素和许可证因素。
sharpbai's tech blog~
上周末使用do-release-upgrade
升级了下Ubuntu 20.04的服务器,升级完成后,重启机器无法正常进入系统,不断重启,期间在initramfs阶段报告Failed to connect to udev daemon: No such file or directory
。这该如何解解决?
自从将W520从Win7升级到Win10之后,发现独显直连模式或Optimus切换模式,只要启用NVIDIA Quadro 1000M独立显卡,就会发生死机的问题。难道智能用鸡肋的HD3000集显么?
一直一来,我的迷你主机总是会在启动阶段或者莫名其妙的在任意时刻出现内置的SATA固态硬盘sda的Buffer I/O error
问题,另外也会随机出现外置USB3.0磁盘的Buffer I/O error on /dev/sdb1 (...) async page read
问题,一旦出现,设备就会失去响应或磁盘进入只读状态,必须断电重启设备才能恢复。这该如何处理?
最近,我的占美1037U小主机遇到了开机超过10分钟才正常启动的问题,我怀疑是网络启动开启了,想调整BIOS设置,但开机后就一直花屏,直到进入ubuntu系统后才恢复,导致我无法修改BIOS设置。
这个问题如何解决呢?
前天做系统迁移,将x86架构的机器迁移到了arm架构的机器上,发现vim的YouCompleteMe出现了问题,不能正常使用。按照正常套路,需要进行一次重新编译才行。但是在重新编译时,报了以下错误
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
/path/to/k-vim/bundle/YouCompleteMe/third_party/ycmd/cpp/BoostParts/libs/python/src/converter/builtin_converters.cpp:51:14: error: cannot initialize return object of type 'void *' with an rvalue of type 'const char *' return PyUnicode_Check(obj) ? _PyUnicode_AsString(obj) : 0; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/homebrew/opt/python@3.9/Frameworks/Python.framework/Versions/3.9/include/python3.9/unicodeobject.h:115:18: note: expanded from macro 'PyUnicode_Check' PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS) ^ /opt/homebrew/opt/python@3.9/Frameworks/Python.framework/Versions/3.9/include/python3.9/object.h:633:41: note: expanded from macro 'PyType_FastSubclass' #define PyType_FastSubclass(type, flag) PyType_HasFeature(type, flag) ^ 1 error generated. [19/67] Building CXX object BoostParts/CMakeFiles/BoostParts.dir/libs/python/src/list.cpp.o ninja: build stopped: subcommand failed. ERROR: the build failed. |
这该怎么办呢?
在做Ubuntu 18.04原地升级到Debian 10的过程中,我进行了apt的purge操作,删除了旧的mysql-server-5.7。没想到在弹出的交互式是否删除配置文件的提示中,我脑残的点了”是”。我马上反应过来不对,按下了Ctrl+C。但是屏幕上已经刷过了后面purge的几十个数据包了。我进入/var/lib/mysql/
一看自己的数据库目录不见了!
这。。。我居然自己搞了一次删库。。。里面可是我8年来的博客数据啊!我头皮一下子麻了起来。。。
该怎么拯救我的被删的数据库呢?
最近发现阿里云的1核512M内存的云主机上的Ubuntu是18.04.5,但是/etc/apt/sources.list
中的dist名称却是bionic(20.04),就有些奇怪,为啥之前没有完成dist-upgrade的升级呢?
于是我试着做了一下do-release-upgrade
,然后提示直接告诉我说Ubuntu 20.04不打算支持i386架构了,所以不能升级。
我没有更换ecs.t1.xsmall
这个云主机的计划,且这个袖珍款从15年到现在的6年时间从运行Ubuntu 14.04 i386开始都很好的服务于我的博客系统,鉴于升级到x64会显著增加应用的内存占用,所以我想原地更换当前发行版到一个还持续维护的i386的发行版。看了一圈还是Debian最合适,毕竟是同源的东西。
但是如何原地升级呢? 今天打算具体实操下。