什么是rpikernelhack?


96

如果做一个apt-get upgrade对我的RPI 3,输出的多条线路出现这样的:

Adding 'diversion of /boot/bcm2708-rpi-b-plus.dtb to /usr/share/rpikernelhack/bcm2708-rpi-b-plus.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2708-rpi-b.dtb to /usr/share/rpikernelhack/bcm2708-rpi-b.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2708-rpi-cm.dtb to /usr/share/rpikernelhack/bcm2708-rpi-cm.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2709-rpi-2-b.dtb to /usr/share/rpikernelhack/bcm2709-rpi-2-b.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2710-rpi-3-b.dtb to /usr/share/rpikernelhack/bcm2710-rpi-3-b.dtb by rpikernelhack'
Adding 'diversion of /boot/kernel.img to /usr/share/rpikernelhack/kernel.img by rpikernelhack'
Adding 'diversion of /boot/kernel7.img to /usr/share/rpikernelhack/kernel7.img by rpikernelhack'
Adding 'diversion of /boot/COPYING.linux to /usr/share/rpikernelhack/COPYING.linux by rpikernelhack'
...
...
...

我对Linux内核的功能不是很了解,而这对于RPi来说似乎很特定。

我的问题是:这是什么?

什么是“转移”?被引用的所有这些文件(作为一个组)实际上是做什么的?什么是“ rpikernelhack”?

我做了一些谷歌搜索,无法轻易找到任何有趣的东西。我想我不是唯一对此感到好奇的人,所以我希望这是一个适当的问题!


3
当然不是唯一一个好奇的人-我也想知道。
2016年

我也是。我做的时候他们花了很长时间apt-get upgrade
孔除嗯浩

2
可能没有您想像的那么令人兴奋-我认为这里的“ hack”是在软件包管理系统上,而不是内核上。 debian.org/doc/debian-policy/ap-pkg-diversions.html
goldilocks

以下是该preinst部分的示例:dpkg-divert --package rpikernelhack --divert /usr/share/rpikernelhack/kernel.img /boot/kernel.img。@goldilocks的链接解释--package清楚。
PNDA

2
@qbicdesign我认为这取决于您对“ hack”一词的理解。一种常见的用法是指可能不是理想或适当解决问题的东西,但至少在紧要关头或花费最小的努力才能奏效,所以有人只是明确指出了这一点(该文章开头的内容是并不是解决任何问题的方法,但是常见的主题是“不当” =“以某种非预期的方式使用某些东西” =“不一定是错误的,甚至可能是聪明的”。
goldilocks

Answers:


67

“ rpikernelhack”是一个虚假的程序包名称和一个目录名称,它用作hack的一部分(从某种意义上说是肮脏但权宜的解决方案)来解决Raspberry Pi基金会决定使/ boot成为fat32分区这一事实。 dpkg与fat32的配合不佳。我是最初提出这个想法的人,尽管后来其他人对其进行了改进。

dpkg将新文件安装到fat32分区上(沿途发出一些警告),但是,如果它尝试更新fat32分区上的现有文件,它将失败(iirc尝试通过创建硬链接来备份旧文件)而fat32不支持硬链接)。

当人们(包括我在内)开始尝试制作Pi内核和固件的Deb软件包时,他们遇到了这个问题,最初会安装一个软件包,但是尝试对其进行升级会失败,哎呀。

我的解决方法是(ab)使用dpkg中的“转移”功能。此功能旨在允许文件被转移,以便可以用本地修改的版本或其他软件包中的版本替换它们,但是我能够通过维护者脚本使用dpkg来在Linux分区,然后最后将文件移动到其最终位置。

转移要求您指定“程序包名称”或“本地”。如果指定软件包名称,则转移将影响指定软件包以外的所有软件包所拥有的文件(此处的目的是允许软件包转移另一个软件包所拥有的文件,然后安装其自己的版本)。我还需要一个目录来将文件转移到。

使用要安装的内核软件包的名称将使黑客无效。使用“本地”也似乎是错误的,因为应该将其保留给本地系统管理员使用。因此,我需要一个假包装名称,该名称不太可能与任何内容冲突。我想出了“ rpikernelhack”,我也使用相同的字符串作为目录名。


4
非常感谢您的回答。它对设计和命名决策非常有见地。互联网对我来说是一个神奇的地方,能够得到实际上正在研究此特定作品的那个人的回应。
MD-7

只是更新我的RPi,并想知道这个奇怪的日志,感谢最终的澄清。
schlump

使dpkg与FAT32配合使用会更加干净。这是我建议的MR:salsa.debian.org/cklein-guest/dpkg/merge_requests/1/diffs
user1202136

43

它只是为Linux内核创建了Raspberry Pi特定修补程序集的开发人员提供的目录名称。

它是Raspbian开发人员的一项修复程序,用于修复FAT2016内核中存在的文件系统损坏问题,此更新到2017内核,因此无需担心。要进行此内核更新,您需要使用它sudo apt install -f来修复由错误引起的依赖关系问题(-f根据手册页,在本文中,意味着apt-get(8)

-f,--fix-broken
修复; 尝试更正具有损坏依赖性的系统。...


0

FWIW,当我在2019年2月28日在rpi3b +跑步机上进行更新升级时再次发生这种情况。182行转移... rpikernalhack ...这里是一个示例:

Preparing to unpack .../17-raspberrypi-kernel_1.20190215-1_armhf.deb ...
Adding 'diversion of /boot/bcm2708-rpi-0-w.dtb to /usr/share/rpikernelhack/bcm2708-rpi-0-w.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2708-rpi-b-plus.dtb to /usr/share/rpikernelhack/bcm2708-rpi-b-plus.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2708-rpi-b.dtb to /usr/share/rpikernelhack/bcm2708-rpi-b.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2708-rpi-cm.dtb to /usr/share/rpikernelhack/bcm2708-rpi-cm.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2709-rpi-2-b.dtb to /usr/share/rpikernelhack/bcm2709-rpi-2-b.dtb by rpikernelhack'
Adding 'diversion of /boot/bcm2710-rpi-3-b-plus.dtb to /usr/share/rpikernelhack/bcm2710-rpi-3-b-plus.dtb by rpikernelhack'

...
...

如果有帮助,一个小时前我做了一次更新升级,结果是(2)哈希总和不匹配。也许正是在更新存储库时?我重新启动,等待了一个小时,然后进行了第二次更新升级,没有哈希值不匹配,也就是在我得到182行转移指令的时候……rpikernalhack。

结果版本:

pi@___:~ $ uname -a
Linux ISS 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
pi@___:~ $

当然,当我说“更新升级”时,我的意思是...

sudo apt-get update
sudo apt-get upgrade

由于篇幅太长,我尴尬地将其发布为答案,希望它能丰富所选的答案,表明这种事情不是上一年的一次“解决”。


1
我不明白您的升级为何以旧内核结束。当前内核是4.14.98-v7 +

我执行了更新升级,并在几分钟前重新启动。现在的核心是:Linux ISS 4.14.98-v7 +#1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU / Linux除了我在帖子中所述,我似乎对此没有其他解释在存储库更新时进行了第一次更新(因此哈希总和不匹配吗?)。第二次更新要么没有4.14.98-v7 +可用,要么,在更新内核之前还有更多文件要更新?我不知道。你呢?TY指出。
always_learning

不,我没有主意。也许存储库刚刚更新且处于不一致状态?无论如何...
Ingo

我将在将来意识到这种可能性。
always_learning
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.