K-Res

不为追求完美,只为平衡得失!

Proxmox VE由7升级8后遇到的networking.service/start卡死问题

最近发现Proxmox VE 7的管理页面开始提示支持到期的红字了(查了下,官方说明是24年7月底正式停止),于是趁最近有空给服务器升级到了8,开始前仔细研读了官方的大版本升级说明:https://pve.proxmox.com/wiki/Upgrade_from_7_to_8,这个wiki提到了两种升级方式,一是全新安装一个8,然后将原有的磁盘配置和虚拟机通过备份、还原等方式迁移过去,另一种是就地升级,类似系统内软件的升级方式apt update,apt upgrade这样。

从操作方式上来看,感觉第一种方式安全系数更高一些,但是需要有两个服务器,至少是两套一模一样的磁盘环境,新部署的新版本虚机系统如果遇到问题,旧的不受影响,还可以用,新的研究好了,旧的一停,切割完成!第二种方法呢,风险就大一些,一旦升级出现问题,虚机的服务就会中断,而且还需要重装,再还原备份等等麻烦的操作。不过对于博主我来说,也只有第二种就地升级是可行的,因为没有富裕的硬件资源。

虽然升级前感觉做足了功课,但升级过程中还是挺坎坷的,其中坑最大的就是标题上写的这个networking.service/start卡死问题,最早发现问题的症状是在升级正常完成后,重启系统,然后就卡在这个状态:

一开始还傻等了半天,后来发现硬盘灯根本不亮了,才意识到出事了,于是上网搜了一下,发现果然有不少遇到类似问题的人,其中下面这篇文章提到了这个卡住界面背后的实际问题:“Job networking.service/start running

Continue reading…

记一个linux系统c++动态库全局符号重名问题

首先,简单说明下问题情境,一共三个代码文件,一个主执行程序,两个动态库程序,结构与之前写的弱符号,weak symbol一致:

#include <string>

std::string g_name;

void init_name_lib1()
{
    g_name = "lib1";
}

const char* get_name_lib1()
{
    return g_name.c_str();
}
#include <string>

std::string g_name;

void init_name_lib2()
{
    g_name = "lib2";
}

const char* get_name_lib2()
{
    return g_name.c_str();
}
#include <iostream>

void init_name_lib1();
void init_name_lib2();
const char* get_name_lib1();
const char* get_name_lib2();

int main()
{
    init_name_lib1();
    init_name_lib2();

    std::cout << "name from lib1: " << get_name_lib1() << std::endl;
    std::cout << "name from lib2: " << get_name_lib2() << std::endl;

    return EXIT_SUCCESS;
}
Continue reading…

linux系统gcc编译动态库so中的attribute((weak))弱符号使用

首先说明下代码结构:一共三个源码,两个动态库so的源码:lib1.c和lib2.c,各导出一个库函数(gcc编译时默认导出,不像windows的msvc要明确指定导出dllexport),一个主执行程序源码:main.c,调用两个动态库的导出函数,如下:

lib1.c

#include <stdio.h>

void lib1_func(const char* from)
{
        printf("lib1 func from %s\n", from);
}

lib2.c

#include <stdio.h>

void lib2_func(const char* from)
{
        printf("lib2 func from %s\n", from);
}

main.c

#include <stdio.h>

void lib1_func(const char* from);
void lib2_func(const char* from);

int main()
{
        printf("hello from main\n");
        lib1_func("main");
        lib2_func("main");
        return 0;
}
Continue reading…

记录一个cmake局部变量传入子项目问题CMP0077

最近在搞一个依赖了开源库fftw(写此文时用的官网最新发布版3.3.10,https://www.fftw.org/fftw-3.3.10.tar.gz)的代码,项目使用cmake构建,fftw依赖以子项目的方式引入:

add_subdirectory(dep/fftw-3.3.10)

测试后发现调用代码使用的是float版的接口,也就是需要通过设置“ENABLE_FLOAT”这个选项来编译fftw,参见:

set (FFTW_VERSION 3.3.9)

set (PREC_SUFFIX)
if (ENABLE_FLOAT)
  set (FFTW_SINGLE TRUE)
  set (BENCHFFT_SINGLE TRUE)
  set (PREC_SUFFIX f)
endif ()

由于这个是调用代码的刚需,所以不想通过cmake命令行传递此设置,于是想到了再add_subdirectory前临时设置下这个选项,如下:

Continue reading…

W801(W80X_SDK_v1.00.10)https请求mbedtls报错0x7780问题解决记录

事情的起因是想通过W801实现检测到gpio电平变化后,通过telegram发送bot通知消息,结果在调用自己的tg api反代(caddy v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=)接口时,串口日志提示标题上的ssl握手0x7780错误。

代码是直接抄的SDK示例中的demo\wm_https_demo.c代码,报错的函数是在握手时,也就是调用HTTPWrapperSSLConnect的时候,如下:

                    wm_printf("step 1: ssl connect to...\r\n");
                    ret = HTTPWrapperSSLConnect(&ssl_p, fd, (const struct sockaddr *)&server, sizeof(server), HTTPS_DEMO_SERVER);
                    if (ret < 0)
                    {
                        wm_printf("https connect error\r\n");
                        close(fd);
                        break;
                    }

开始的时候只是能看到串口输出step 1: ssl connect to…,然后报了个0x7780的错误,接下来https connect error,请求失败返回,研究了下内部使用的mbedtls库,发现其实还有更详细的调试日志,要在SDK的\src\app\mbedtls\include\mbedtls\config.h中打开“define MBEDTLS_DEBUG_C”这行宏定义(并且需要确保makefile项目的lib目标重新构建,如果是参考我之前的CLion IDE用法,就是在构建的configuration里选择lib,然后rebuild),打开后就能看到类似:https://forums.mbed.com/t/error-0x7780-during-handshake/6883 这里提到的错误信息:

Continue reading…

小米米家温湿度计2的正确重置(复位、恢复出厂、reset、触点按不动)方法

家里三个小米温湿度计2,连着小米智能插座2的蓝牙网关,小巧方便,手机随时查看家里温湿度情况。最近其中一个在更换电池后,出现了奇怪的问题:米家app上能看到设备,并且也显示已连接蓝牙网关,但是温湿度数据就是获取不到,点进设备详情界面也一直没反应,提示“打开蓝牙”,此时如果开启手机蓝牙,会以很慢的速度通过蓝牙连接设备,然后确实可以正常获取到数据,只是整个过程反应很慢,不像之前网关正常时随点随出,同时这样在外出时也看不到这个温湿度计的实时信息了(从米家app的中枢网关界面里也能看到这个温湿度计是连接状态,并且离着不远三格信号满格),后来看了下固件,发现可以升级到最新的“0130”,于是升了下级(这个过程也是特别慢,不知道是不是由于蓝牙传输所致),升级完成后问题依旧!百度搜索了下,发现有人提到可以重置一下试试,然后就进入了今天记录的主题,这个小米温湿度计的重置设计也算是另类了,网上能搜到的重置方法基本都是这样说的:

Continue reading…

记录Mac系统下构建FFmpeg(-Wl,rpath不支持)及依赖库libxml2遇到的两个问题

最近在Mac系统下尝试编译FFmpeg源码,虽然由于都是nix系的系统,比Win下编译方便很多,但还是遇到一些由于系统差异导致的问题。首先是依赖库libxml2编译时,提示:

-bash: libtoolize: command not found

这个问题,简单调查后发现是由于Mac系统已经存在libtool这个工具,但是功能不同,而相同功能的工具程序换了个名字,叫glibtool,可以通过brew安装,参考这个地址:https://stackoverflow.com/questions/15448582/installed-libtool-but-libtoolize-not-found

glibtool可用后,增加个符号链接,或者改下libxml2的构建脚本,就可以build成功了。

第二个要记录的问题是FFmpeg在编译时,由于使用的是Xcode命令行工具安装的clang,无法识别gcc的“-Wl,rpath=”链接命令,用于指定rpath。

这个问题参考这个github上的issue描述:https://github.com/klee/klee/issues/591,将指定rpath链接参数的写法换成“-Wl,-rpath xxx”即可,多个rpath路径时可以参考下Xcode项目设置里增加rpath后生成的编译链接命令写法。

OpenWRT误删uhttpd服务配置导致LuCI管理页面无法访问问题

自己编译的OpenWRT固件带了uHTTPd的LuCI设置UI,在研究服务器映射时点了右上角的删除,并且应用了:

结果发现LuCI界面无法访问了,才意识到原来刚才删除的配置就是通过uhttpd支撑的LuCI管理页面的web服务器,重启了几次后发现路由器功能还是正常的,只是无法访问web管理,dropbear的ssh还是能正常连上的,本来都做好了重新刷机的准备了,后来查了下,发现下面论坛里说的方法:

https://forum.openwrt.org/t/cannot-access-luci-after-messing-with-settings/147903

通过执行下面的命令:

cp /rom/etc/config/uhttpd /etc/config/uhttpd

即可将默认uhttpd配置文件还原回来,然后重启uhttp服务:service uhttpd restart,或者直接重启路由器即可恢复管理页面,不需要刷机,快速救回LuCI管理页面。

Win下搭建CLion配合远程Linux的联盛德W801开发环境(csky-elfabiv2-tools)

之前9块钱促销买了块海凌科(Hi-Link)的W801开发板HLK-W801-KIT-V1.1:

到手后看了各种资料用CDK IDE搭起了开发环境,简单试了试灯,还踩了个Upgrade Tools上传程序的坑:W801开发板Upgrade Tools上传程序失败问题,那之后这块板就吃灰了😂,最近因为发现网口WOL网络唤醒在电脑完全断电恢复后无法使用的问题(试了自己和朋友的几台电脑,华硕的x370主板、技嘉的x570主板、公司的技嘉z390主板都不行,网上看有人说自己的电脑可以掉电后WOL,介绍的各种设置方法也基本都试了个遍,无果), 打算研究个IoT远程开机功能,嘉立创的开源平台上一搜能搜到很多,但大都基于ESP的MCU,于是又想起了这块W801…不过用惯了VS、Xcode、CLion的我对之前使用CDK的体验着实不怎么样,在联盛德的官方论坛上也看到有人基于VSCode搭建了开发环境,有win下配msys的,也有走远程linux编译的,由于本人实在是对cgywin,mingw这类windows下移植linux环境的工具不感兴趣,所以这回打算尝试下远程linux编译的方式再次搭建下W801的开发环境,同时使用最近经常用的CLion IDE(我用的Nova版,写此文的时候还处于EAP状态,已经进入RC状态了,下载2024.1 RC版(设置中高级里启用ReSharper 引擎,重启后就是Nova办了),但实际测试并没发现什么严重问题,理论上稳定版对远程linux开发支持应该也是一样的),另外,多说一句,虽然说的是remote linux,其实WSL,或者本地虚拟机也都是一个道理,那下面我就记录下这样搭环境的主要步骤。

Continue reading…

给退役的路由器联想y1s硬改升级64M闪存

自从去年10月换了红米AX6000后,服役快10年的y1s终于迎来了退役的日子,此后便一直待在盒子里吃灰…

直到前段时间逛恩山论坛时无意间看到了 1421890054 大佬的这篇帖子:【2022-1-22】折腾一下OpenWrt-Lenovo-newifi-y1s-R22.1.1-mt7620a-USB,意识到原来y1s是可以支持更大容量的闪存的(原配winbond 25Q128 16M,装完op后基本就装不了什么软件了…),于是又翻出了退休的y1s,准备也试着硬改升级下闪存玩玩。

Continue reading…