又一次奇特的问题解决

因为有在床上开电脑的需求,所以某天爬了Arch Wiki来配置WOL。

碰到的第一个问题就是跑# ethtool interface | grep Wake-on压根没有任何输出,想了想E2400应该还没寒酸到连WOL支持都没有,遂Google一番看到Arch论坛有个求助帖,解答就是再读一遍Wiki…

好吧,拉到Wiki的在下面,发现确实有alx相关的内容,虽然such as里面没有E2400,但E2400应该是包括在内吧…嗯。

去AUR搜索一番,果然有人已经打好包了,就是alx-wol-dkms,装完之后美滋滋,WOL运行一切正常。

不过问题很快又来了,我发现这个包在内核更新的时候不会自动重编译,必须再装一遍这个包,pacman hooks才能正常工作。最初我还以为手贱删了什么东西,外加重新装过之后再次安装内核也能自动编译了,就当问题解决了。不过我很快就发现,一旦重启一次,安装内核的时候又不能自动重新编译了…

起初我还以为是trizen的Bug,上github瞅了一圈没发现有相关的issues,想了想这么大的Bug应该不会没人注意到,就在其他方面继续找问题。

这时我想是不是PKGBUILD的锅,遂又爬了一天了解包是如何调用pacman hooks的,结果就是有dkms.conf就能自动调用了…到这又卡住了。

查看Arch WIki的dkms页面,试着执行了下dkms status,有报错说无法找到alx这个模块的dkms.conf,找了下发现dkms的目录应该在/var/lib/dkms/找到之后发现alx模块相关的文件竟然都是最终(中间还指向/usr/src/)指向/tmp/trizen/的软链接……这可不一重启就没了。

我决定手动用makepkg打包试试,结果发现这玩意不是trizen的锅,/usr/src/下面的东西就是指向makepkg的工作目录……

看了下PKGBUILD,起作用的也就这几行:

package() {
    local dest="$pkgdir/usr/src/${_pkgbase}-$pkgver"
    mkdir -p $dest
    cp -a Kbuild dkms.conf alx.h ethtool.c hw.c hw.h main.c reg.h $dest
}

命令很简单,看起来也没什么问题,又参考其他PKGBUILD进行了一些改写,仍然不行。查看makepkg在构建包时生成的文件,发现PKGDIRSRCDIR中的文件都是指向PKGBUILD目录的软链接。又在中间加了个pwd,发现在package函数执行的时候目录位于SRCDIR

查看makepkg的Wiki页面,发现有这么一行:

SRCDEST — directory for storing source data (symbolic links will be placed to src/ if it points elsewhere)

回头看看PKGBUILD,这cp -a就是复制的一堆软链接啊……

cp -a改为cp --preserve=all之后问题解决。

 

 

最后……我直接接手了这个软件包

发表评论

电子邮件地址不会被公开。 必填项已用*标注