How does kernel updates itself while it's running without breaking anything in the process?

  • 41
    Short answer is it doesn't.
    – slebetman
    Jan 22, 2020 at 7:22
  • 10
    The real question (but OT for this site) is why aren't windows able to do the same. I remember with horror the time when I still had an MS partition, and every time it booted it would spend ages updating/restarting/updating again and so on, before you could use the computer at all. Once I even drove to the airport with the laptop running on the passenger seat, because it was updating windows.
    – user000001
    Jan 22, 2020 at 8:08
  • 4
    @user000001 Windows kernel already had had hot-patching capability longggggg before Linux gained that ability. It just restarts because user-space apps are too stupid to use the replaced file, and Windows doesn't allow replacing file while it's being opened like Unix. The 64-bit Windows kernel has 100% hot patchability right from the start and it also has kernel patch protection
    – phuclv
    Jan 22, 2020 at 12:40
  • 12
    Linux can do live patching since 2015 with Ubuntu users can utilize that since the end of 2016
    – phuclv
    Jan 22, 2020 at 12:40
  • 5
    Linux was able to do live patching long before that - I was running ksplice+uptrack back in 2010.
    – Skyler
    Jan 22, 2020 at 15:01

1 Answer 1


When you update the kernel, you actually update the kernel package. On most Linux distributions, what this really does is just register the package in your package manager, add the new modules under /lib/modules, add the initramfs and kernel under /boot, and maybe update the bootloader entries and some other miscellaneous activity. It doesn't generally actually replace the loaded kernel in memory.

At boot, the kernel itself is loaded into memory. That is, even if the file it was loaded from (eg. /boot/vmlinuz) goes away, it's not needed after initial loading of the kernel.

Even if it was needed for something (say, debugging information) and has been replaced, anyone already with an open file handle to it will still be able to use the file, since the backing data won't be deleted until the inode in question has a reference count of 0 (the kernel itself doesn't need such a reference though, since it's already loaded into memory, unlike running processes from userspace executables). Those blocks normally can be fully freed from disk unless you're in the middle of running some user-space program on that file. The Linux kernel doesn't page its own memory, and even decompresses itself on the fly at startup. There's no /proc/.../exe or /proc/.../fd way to access the booted /boot/vmlinuz — the kernel might not even mount the device it was booted from in a netboot or USB-boot situation.

So generally, the kernel doesn't update itself. That's typically done at reboot or kexec time. The kind of thing you're describing does exist for limited use cases as kpatch, kgraft, and ksplice, but generally these can only be used for small and targeted patches, not new upstream kernel releases.

  • 4
    Also worth noting that this isn't really any different from Windows or macOS. No modern OS does online upgrades to core kernel code for full release updates, because it's actually almost impossible to reliably hot-patch a running executable unless it's a super-targeted patch and you have existing instrumentation in the executable code to allow for it. Jan 22, 2020 at 19:51
  • 2
  • "even if the file it was loaded from goes away"... except it won't. On POSIX file systems, unlinked files aren't actually deleted until nothing has an open handle to them any more. This is why you can unlink a file in use (unlike on Windows). If you know what you're doing (i.e. can identify the correct file handle), it's possible to relink an unlinked file back into the file system.
    – Matthew
    Jan 23, 2020 at 16:11
  • 1
    @Matthew I'm afraid you're conflating inode (ie. in the purest struct inode sense), file, and data :-) If you read further in the answer you'll see that there's already discussion about inode reference counting.
    – Chris Down
    Jan 23, 2020 at 16:40
  • 1
    @jcaron Tanembaum wasn't very good on his predictions about microkernels or how soon x86 would be deprecated, however. That discussion didn't age well for his side. I mean, I'm not exactly a fan of Linux, but you can't call it obsolete by any measurement.
    – T. Sar
    Jan 23, 2020 at 17:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .