Piaware latest kernel update

Didn’t fix it, same result.

Hardware: Pi model 2, 8Gb microSD Card, Class 10

Finished this just now. No issues.

(1) microSD card in WINDOWS-8 card reader
SD Card Formatter >> Win32DiskImager >> Wrote 2018-06-27-raspbian-stretch-lite.img

(2) microSD card slipped into Pi Model2

sudo raspi-config

#Expanded file system
#Set Locale
#Set Time Zone

(3) apt update

sudo apt update
Reading state information... Done
24 packages can be upgraded. Run 'apt list --upgradable' to see them.

(4) apt upgrade

sudo apt upgrade

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  ca-certificates dpkg dpkg-dev file libdpkg-perl libmagic-mgc libmagic1 libpam-systemd
  libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 libsystemd0 libudev1
  libwbclient0 patch raspberrypi-bootloader raspberrypi-kernel samba-common shared-mime-info
  systemd systemd-sysv tzdata udev
24 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 80.6 MB of archives.
After this operation, 737 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.raspberrypi.org/debian stretch/main armhf libraspberrypi-doc armhf 1.20180817-1 [31.4 MB]
Get:2 http://muug.ca/mirror/raspbian/raspbian stretch/main armhf dpkg armhf 1.18.25 [2,055 kB]
Get:3 http://muug.ca/mirror/raspbian/raspbian stretch/main armhf systemd-sysv armhf 232-25+deb9u4 [81.3 kB]
Get:4 http://muug.ca/mirror/raspbian/raspbian stretch/main armhf libpam-systemd armhf 232-25+deb9u4 [174 kB]
Get:5 http://muug.ca/mirror/raspbian/raspbian stretch/main armhf libsystemd0 armhf 232-25+deb9u4 [257 kB]
Get:6 http://muug.ca/mirror/raspbian/raspbian stretch/main armhf systemd armhf 232-25+deb9u4 [2,220 kB]
Get:7 http://muug.ca/mirror/raspbian/raspbian stretch/main armhf udev armhf 232-25+deb9u4 [1,072 kB]
Get:8 http://muug.ca/mirror/raspbian/raspbian stretch/main armhf libudev1 armhf 232-25+deb9u4 [120 kB]
Removing 'diversion of /boot/overlays/w1-gpio-pullup.dtbo to /usr/share/rpikernelhack/overlays/w1-gpio-pullup.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w1-gpio.dtbo to /usr/share/rpikernelhack/overlays/w1-gpio.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/wittypi.dtbo to /usr/share/rpikernelhack/overlays/wittypi.dtbo by rpikernelhack'
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.14.62+ /boot/kernel.img
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.14.62+ /boot/kernel.img
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.14.62-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.14.62-v7+ /boot/kernel7.img
Setting up systemd (232-25+deb9u4) ...
addgroup: The group `systemd-journal' already exists as a system group. Exiting.
Processing triggers for man-db ( ...
Setting up shared-mime-info (1.8-1+deb9u1) ...
Processing triggers for dbus (1.10.26-0+deb9u1) ...
Setting up ca-certificates (20161130+nmu1+deb9u1) ...
Updating certificates in /etc/ssl/certs...
20 added, 35 removed; done.
Setting up libraspberrypi0 (1.20180817-1) ...
Setting up libraspberrypi-doc (1.20180817-1) ...
Setting up systemd-sysv (232-25+deb9u4) ...
Setting up libraspberrypi-dev (1.20180817-1) ...
Setting up file (1:5.30-1+deb9u2) ...
Setting up dpkg-dev (1.18.25) ...
Setting up libraspberrypi-bin (1.20180817-1) ...
Setting up libpam-systemd:armhf (232-25+deb9u4) ...
Processing triggers for initramfs-tools (0.130) ...
Processing triggers for ca-certificates (20161130+nmu1+deb9u1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

(5) Checked

 uname -a
Linux raspberrypi 4.14.50-v7+ #1122 SMP Tue Jun 19 12:26:26 BST 2018 armv7l GNU/Linux

Friends don’t let friends use Win32DiskImager any more. Use Etcher instead. It has a verify image step.

I have ALWAYS used Win32DiskImager, innumerable number of times, over past 3½ years, and NEVER faced any problem.

Well YMMV.

1 Like

People using RPi 3+, Odroid, Tinker, etc and more powerful SBC’s are all being directed to use 7-Zip and Etcher and > class 10 SD cards because of booting issues. 7-Zip and Etcher are now SOP from Raspberry Pi Foundation instructions.

Ok, but that recommendation does NOT mean “Don’t use Win32DiskImager”.

Of course. But Etcher is open source, it validates the flashing, and for those of us who are either noobs or are working late at night, its helps prevent flashing a hard drive.

So what. Does this improve image writing?


So does the Win32DiskImager. Please see screenshot below


I was able to reproduce the problem @jridder ran into.

  1. Start with a freshPiAware image downloaded from Flightware - I got piaware-sd-card-3.6.2bis.img.zip

  2. Burn the image to an SD card using whatever imaging tool that works for you. I used etcher, windiskimager, as well as dd in Linux just to cover all experiences here.

  3. Enable ssh by creating the empty file ssh.txt in /boot

  4. Boot the new image - kernel comes up as

    Linux piaware 4.14.52+ #1123 Wed Jun 27 17:05:32 BST 2018 armv6l GNU/Linux

And /boot partition is about 50% used. Here’s where the fun starts -

Initiate an update/upgrade - about towards the end is where the problem occurs:

rpi-bootconfig: pi3 has no suitable kernel, skipped
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.14.62-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.14.62-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postinst.d/initramfs-tools-hack 4.14.62-v7+ /boot/kernel7.img
update-initramfs: Generating /boot/initrd.img-4.14.62-v7+

gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-4.14.62-v7+ with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools-hack exited with return code 1

Although /etc/default/raspberrypi-kernel has INITRD and RPI_INITRD commented out (meaning disabled), the Piaware image seems to want to use initramfs anyway during a kernel update.

I have the complete terminal session recorded if it’s any use to anyone.

The answer? There are likely one of many to choose from, in my opinion:

  • don’t apply updates after installing the stock image :frowning:
  • apply the ‘fix’ noted by @jridder at the start of this thread
  • increase the size of the /boot partition
  • Flightware team reviews the update/upgrade process to find why initramfs is somehow re-mixed in.
  • other?

I suspect anyone that starts with this Piaware image piaware-sd-card-3.6.2bis.img.zip will experience the same problem if/when a kernel update/upgrade is initiated either by the user or by Flightware. It appears @abcd567 did not experience this because it appears he started with the bare Raspbian image with the intention of installing Piaware and related items separately:

I did notice this snippet in /boot/config.txt in the original image does not have the initramfs lines appear

## start of rpi-bootconfig autogenerated section. Do not modify or remove this line.
## end of rpi-bootconfig autogenerated section. Do not modify or remove this line.

But the updated /boot/config.txt has the initramfs lines:

## start of rpi-bootconfig autogenerated section. Do not modify or remove this line.
initramfs initrd.img-4.14.62+ followkernel
initramfs initrd.img-4.14.62+ followkernel
## end of rpi-bootconfig autogenerated section. Do not modify or remove this line.

By the way - I observed the same problem initramfs problem during the kernel update/upgrade regardless of the imaging tool used for image piaware-sd-card-3.6.2bis.img.zip - the imaging tool has nothing to do with this issue, in my opinion.


I have used Etcher too. But it failed the creation of the SD card directly from zip. So, like I said, I have unzipped with 7zip firstly.

And yes, I have started with the official Raspbian Lite image.

One thing of note is that we aren’t using the Raspbian Lite image and installing from there.

I spent some time looking at the script /etc/kernel/postinst.d/initramfs-tools-hack. I don’t think it’s doing what it’s supposed to do.

Also SoNic67, if you are using the official Raspbian image, how are you getting the 4.14.62 kernel? So far none of the other Pi’s I have running official Raspbian have been offered that kernel.

I’m re-reading this thread and scratching my head. This discussion went all over the place.

If anybody is using their RPi for other purposes, as well as ADS-B decoding and feeding, it’s a bad idea.

If dedicated to ADS-B decoding and feeding, but installing additional related programs, be prepared to deal with all sorts of issues. Nothing is straight forward in this case.

FA has the best image setup, of all similar applications, in Piaware. It takes literally minutes to re-image and re-configure an SD card. Unless your hobby is to deal with compatibility issues non stop, I fail to understand why travel on this ‘hard road’.

The only partial exception would be remote sites, but even those, wait until the next site visit, or better still, if it ‘ain’t broke don’t fix it’.

1 Like

Oh, good catch, that should probably not be there any more. It’s actually a workaround that should only be needed on jessie; upstream have fixed their kernel packaging more recently. I’ll take a look.

For some background … Both standard PiAware, and FlightFeeder images, used to use an initramfs, for two reasons:

  1. to get piaware’s plymouth boot splashscreen started early;
  2. to handle the FlightFeeder’s “readonly” mode

When building 3.6.2 there were two problems with initramfs:

a) Without careful workarounds in cmdline.txt, there was a kernel bug that would make the kernel panic very early during boot about 50% of the time when there was an initramfs around: 4.14: bad mode in data abort handler detected · Issue #2450 · raspberrypi/linux · GitHub
b) Raspbian-lite’s first-boot-resize-sdcard did not handle having an initramfs present

So fo the 3.6.2 PiAware image, the initramfs was disabled … and so there was no need to change Raspbian-lite’s /boot sizing … but it looks like it didn’t get entirely disabled in all the places it needed to be :frowning:

1 Like

Dxista, we should patch because we don’t need to discover that several Raspbian machines have been turned into a zombie army attacking other networks.

obj, thanks for explaining all that. Makes sense to me.

1 Like

I would expect FA to issue a dot dot (3.6.X) updated image any time something major is discovered. They would not want thousands of ‘zombies’, carrying their ‘product’ and/or name, attacking other networks.

If my expectation is not correct, please let me know. I’ll be happy to take my feeder offline for good.

You can’t expect a perfect world when it comes to software. Things happen that people never thought about. Typo’s get introduced.
I don’t think of this as a major issue.

1 Like


Nobody expects a perfect world… well, we do, but it’s not the case.

You said: “we should patch because we don’t need to discover that several Raspbian machines have been turned into a zombie army attacking other networks.”. It’s a known issue then. How would you patch something you don’t know about? If it’s serious, FA should update the image.

Then you said: “I don’t think of this as a major issue.”, then why bother? As I said, if it ain’t broke don’t fix it.

Remember what I said in the beginning: if your RPi is wearing many different, unrelated, hats, you are looking for trouble. Dedicate a Pi Zero (low cost) to feeding FA, and sleep easy.

1 Like

:+1: :+1: :+1:

I don’t think this issue has any thing to do with what else the Pi I have is doing.
This conversation has gone off the deep end. Back to reality.