This may be just an error I only came across but while updating the kernel on piaware today, I ran into not enough room on the /boot folder to create a new initramfs.
To solve the problem I had to do the following:
update-initramfs -d
mkinitramfs -o initrd.img-4.14.62+ 4.14.62+
Looking through the boot directory, I didn’t see a whole lot that could be remove to make some space.
Did you expand the partition when you created the image?
How large is the SD card? I normally use a 32GB card but it should work on an 8GB image.
Check the /var/log folder for large log files.
The /boot directory isn’t on the partition/filesystem that is expanded. The size is set in the initial install image.
there is a tutorial (difficult) how to resize partitions (if you must) at
https://www.raspberrypi.org/forums/viewtopic.php?t=187999 with doubtful results.
If I face such a situation, I never waste my energy in debugging. I simply download latest image and write to microSD card. Easy solution 
If the SD card was ever accessed by a PC running windows, you might have windows files/directories there - these might be hogging up space. Things like ‘System Volume Information/’ or ‘RECYCLE’ aren’t used by Linux and should be deleted while you are logged into the Pi via VNC or ssh.
If you feel adventuresome, and/or a desire to tear into the guts of the operating system: partition a fresh SD card with larger sizes for the partition holding /boot with the remainder going to / - lots of HOW-TOs out there - copy each partition contents to the new SD card, change /boot/cmdline.txt and /etc/fstab to reflect the new SD card’s PARTUUID, and swap cards. The worst that can happen is doing what @abcd567 recommends - starting fresh with a new image (having saved your feeder-id setting first).
BTW - no issues here updating to the latest kernel 4.14.62-v7+ /boot has 19M out of 41M free.
Or those that are creating the piaware image could just reserve a little more space when making the image…hint hint.
I too found easier to reimage the SD card than to fix issues that arise from long use. Actually I have two 16GB cards and I can reimage one while the other is still in use.
As for the space… the boot partition is 23MB used, 22MB free and very unlikely to require more than that.
The root partition is extended to 16MB on my cards and filled to 1.3G (9%) - Raspbian Stretch Lite. Again, plenty of space.
I’m not sure I understand what reimaging would really solve since the problem would happen again as raspbian tried to update.
I want to thank everyone for their feedback. Honestly I just created the post in case someone else ran into the problem.
I compared the piaware image to the raspbian lite image and the free space between images on the boot directory is just a few kilobytes. I don’t have another raspberry 3 sitting around to try the same thing over again to see if it reproduces the problem.
I did -update and -upgrade and I don’t have problems. But mine is 3 (not 3+).
I logged into another raspberry 3+ I have running Raspbian Stretch here because I was wondering where it was at software wise. Oddly enough it hasn’t been offered the 4.14.62 kernel yet.
What sdcard image did you start from? The 3.6.2 (stretch) piaware image no longer uses an initramfs so I’m not sure how update-initramfs applies here (and you won’t have problems with old versions piling up). The 3.5.3 (jessie) piaware image did use an initramfs, but it also pinned the kernel version to avoid problems with mlat timing, so you shouldn’t be getting kernel upgrades there.
FWIW the 3.6.2 image uses the same build process (pi-gen) as Raspbian-lite and doesn’t change the rules for sizing /boot - a fresh image will have a /boot that is about 50% used.
How weird. I’m more confused now why it was like that.
Alright, I found another another Raspberry 3 sitting around. Installed the 3.6.2 image. Enabled ssh and wireless networking on my mac before first boot. Everything is great to that point.
Did an apt update followed by apt upgrade. The following packages want to be upgraded off the latest image:
libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 libwbclient0 raspberrypi-bootloader raspberrypi-kernel samba-common
The kernel update takes it to 4.14.62. During the process this other pi got the following:
update-initramfs: Generating /boot/initrd.img-4.14.62+
rpi-bootconfig: recording update of initramfs for kernel 4.14.62+
run-parts: executing /etc/kernel/postinst.d/rpi-bootconfig 4.14.62+ /boot/kernel.img
/etc/kernel/postinst.d/rpi-bootconfig:
rpi-bootconfig: recording installation of kernel 4.14.62+
run-parts: executing /etc/kernel/postinst.d/zz-update-bootconfig 4.14.62+ /boot/kernel.img
/etc/kernel/postinst.d/zz-update-bootconfig:
rpi-bootconfig: updating /boot/config.txt
rpi-bootconfig: pi0 using kernel 4.14.62+ (kernel.img) and initramfs initrd.img-4.14.62+
rpi-bootconfig: pi1 using kernel 4.14.62+ (kernel.img) and initramfs initrd.img-4.14.62+
rpi-bootconfig: pi2 has no suitable kernel, skipped
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
/etc/kernel/postinst.d/initramfs-tools-hack:
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
Setting up libraspberrypi0 (1.20180817-1) …
Setting up libraspberrypi-doc (1.20180817-1) …
Setting up libraspberrypi-dev (1.20180817-1) …
Setting up libraspberrypi-bin (1.20180817-1) …
So now again, why is it trying to create an initramfs??
That’s weird, I didn’t see that when I upgraded mine.
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.14.62-v7+ #1134 SMP Tue Aug 14 17:10:10 BST 2018 armv7l GNU/Linux
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
I had been building the images on macOS Mojave and to rule out anything it might be doing, I built a new image using Windows 10 and got the same result.
What I found out in my case was that flashing directly the .zip file it gave me weird errors (like the WiFi hardware wasn’t present).
I had to extract the ISO first, using 7zip, and then I flashed that. No more problems.
I have been using etcher for a while now. I used to do it by hand in macOS.
For problem free installations, format the SD card with SDFormatter, and write with Etcher.