When doing an apt-get upgrade on my RPi 3, many lines of output show up like this:

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'

I'm not very educated on Linux kernel features and this looks pretty specific to the RPi.

My question is: What is all this?

What is a 'diversion'? What do all these files (as a group) that are being referenced, actually do? What is 'rpikernelhack'?

I did a little bit of googling and couldn't easily find anything interesting. I figure I'm not the only one who's curious about this so I hope this is an appropriate question!

  • 4
    Certainly not the only one who's curious - I'd like to know as well. – joan Jul 18 '16 at 18:52
  • Me too. They took a quite long time when i am doing apt-get upgrade. – Kong Chun Ho Jul 18 '16 at 18:59
  • 2
    Probably not as exciting as you think -- I think the "hack" here is on the package management system, not the kernel. debian.org/doc/debian-policy/ap-pkg-diversions.html – goldilocks Jul 18 '16 at 19:24
  • Here's a sample from the preinst part: dpkg-divert --package rpikernelhack --divert /usr/share/rpikernelhack/kernel.img /boot/kernel.img. @goldilocks' link explains --package clearly. – PNDA Jul 20 '16 at 4:53
  • 2
    @qbicdesign I think that hinges on your understanding of the word "hack". One commonplace use would be to refer to something that's perhaps not an ideal or proper solution to a problem but works, at least in a pinch or with minimal effort, so someone is just indicating that explicitly (the one at the beginning of that article isn't a solution to anything, but the common theme would be "improper" = "using something in a way it was not intended" = "not necessarily wrong, maybe even clever"). – goldilocks Sep 11 '16 at 16:48

"rpikernelhack" is a fake package name and a directory name used as part of a hack (in the sense of a dirty but expedient solution to a problem) to work around the fact that the Raspberry Pi foundation decided to make /boot a fat32 partition and dpkg does not get on well with fat32. I was the one who initially came up with the idea, though it was refined later by others.

dpkg will install new files onto a fat32 partition (spewing some warnings along the way), but if it tries to update an existing file on a fat32 partition it will fail (iirc it tries to make a backup of the old file by creating a hardlink and fat32 doesn't support hardlinks).

When people (including me) started trying to make deb packages of Pi kernels and firmware they ran into this problem, a package would install initially but trying to upgrade it would fail, ouch.

My workaround was to (ab)use the "diversion" feature in dpkg. This feature was intended to allow files to be diverted so they could be replaced with either locally modified versions or versions from another package, but I was able to use it from the maintainer scripts in such a way that dpkg would perform its installation tasks on a Linux partition and then move the file to its final location at the end.

Diversions require you to either specify a "package name" or "local". If you specify a package name then the diversion will affect files owned by all packages except the one you specify (the intent here is to allow a package to divert a file owned by another package and then install its own versions). I also needed a directory to divert the files to.

Using the name of the kernel package being installed would have rendered the hack ineffective. Using "local" also seemed wrong, since that is supposed to be reserved for use by the local sysadmin. So I needed a fake package name that was unlikely to conflict with anything. I came up with "rpikernelhack", I also used this same string for the directory name.

| improve this answer | |
  • 11
    Thank you so much for this answer. It was very insightful towards the design and naming decisions. The internet is a magic place for me to have been able to get a response from the guy who actually worked on this specific piece in question. – MD-7 Mar 20 '19 at 15:51
  • Was just updating my RPi and wondered about this weird log, thanks for the ultimate clarification. – schlump Jun 15 '19 at 19:12
  • 1
    Wouldn't it be cleaner to make dpkg play nicely with FAT32. Here is the MR I suggest: salsa.debian.org/cklein-guest/dpkg/merge_requests/1/diffs – user1202136 Oct 5 '19 at 17:54
  • Fantastic usage of the word refined, that's kind of a nightmare. Why did they chose FAT32? – James May 28 at 13:22
  • 1
    @James I'm not entirely sure but I'd guess to make the partition more widely compatible. There's a lot of setup you can do (such as enabling ssh, adding WiFi networks and general config setup etc.) that you can do by accessing the boot partition. If it was a Linux partition, Windows users would have a much harder time doing this. Since the Raspberry Pi is intended to be an education tool, this is probably the driving factor for making the boot partition FAT32. – NathanielJS Jul 20 at 15:01

It's just the directory name given by the developers who have created a Raspberry Pi specific set of patches to the Linux kernel.

It is a fix by the Raspbian developers to fix a FAT file-system corruption issue present in the 2016 kernel, this updates to the 2017 kernel and is nothing to worry about. To make this kernel update you need to use sudo apt install -f to fix the dependency issues caused by the bug (the -f in this context means, according to the man page, apt-get(8):

-f, --fix-broken
Fix; attempt to correct a system with broken dependencies in place. ...


| improve this answer | |

FWIW, this occurred again when I did an update upgrade on 2019-02-28 on an rpi3b+ running stretch. 182 lines of diversion ... rpikernalhack ... of which here is a sample:

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'


If it helps, one hour previous I did an update upgrade and it produced (2) Hash sum mismatches. Perhaps it was precisely as the repository was being updated? I rebooted, waited an hour, and did the second update upgrade, had no Hash sum mismatches, and that is also when I got the 182 lines of diversion ... rpikernalhack.

The resulting version:

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

Of course when I say 'update upgrade', I mean...

sudo apt-get update
sudo apt-get upgrade

I posted this, awkwardly, as an answer, due to its length, hoping it would enrich the selected answer, showing that this sort of thing is not a one time 'fix' from a previous year.

| improve this answer | |
  • 1
    I do not understand why your upgrade ends with an old kernel. The current kernel is 4.14.98-v7+. – Ingo Mar 1 '19 at 19:16
  • I performed an update upgrade and reboot a couple of minutes ago. The kernal is now: Linux ISS 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux I do not have an explanation for this other than, as stated in my post, I appear to have been doing the first update at the time of a repository update (hence the Hash sum mismatches?). And the second update either did not yet have 4.14.98-v7+ available, or , there were more files to update before it would update the kernal? I do not know. Do you? TY for pointing it out. – always_learning Mar 3 '19 at 16:29
  • No, I don't have an idea. Maybe the repository was just updated and in an inconsistent state? Anyway ... – Ingo Mar 3 '19 at 16:35
  • I shall be aware of this possibility in the future. – always_learning Mar 3 '19 at 16:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.