The not so secret history of vmlinuz
By convention, Linux kernels are called
vmlinuz (usually with a
version suffix and found in
/boot, although Debian is in love with a
/vmlinuz symlink). This name has an interesting history that
probably stretches back to the early days of Unix.
(I say probably because I'm just guessing at some of the Linux history, as it predates my involvement with Linux.)
Originally, Unix kernels were just called
/unix; this is the name Bell
Labs used for the original versions up through V7. These early Unixes
ran on PDP-11s and only had whole-process swapping, not paging. (I'm not
sure if PDP-11s even had paging hardware.)
When UC Berkeley moved V7 to the new DEC VAX series, they added paged
virtual memory (among other things). To mark this, UCB changed the
conventional kernel name to
Mutating this to
vmlinux for Linux kernel images is a small step
(especially given the old commotion about 'Linux is not Unix'). Even today,
vmlinux is the name used for the uncompressed kernel executable that's
created as part of the kernel build process.
When it became necessary to compress kernel images in order to make them
fit into the available early boot memory,
vmlinux was transmogrified
vmlinuz, with the 'z' marking the use of compression.
vmlinux name dates from Linux 0.99, if not earlier;
came in slightly later. The very earliest Linux kernel source just
called the bootable kernel file '
Sidebar: Linux kernel image names (on PClone hardware)
Image: as mentioned, the original name for the bootable kernel image. Uncompressed.
zImage: a gzip-compressed image, with a decompresser et al glued on the front.
bzImage: contrary to popular legend, not compressed with bzip2 instead of gzip; instead it stands for 'big zImage', and is a new format that allows for much bigger kernel images.
Apparently one reason bzip2 compression is not used for kernel images is that the bzip2 decompresser requires a significant amount of memory.
In theory Linux could go back to uncompressed kernel images now, but
compressed ones are much smaller and thus load much faster; a recent
kernel build on my 64-bit Athlon created an 8 megabyte
(with 4 megabytes of real content) that compressed into a 1.75