The bootloader disappeared after upgrading Linux to the next long-term release, and now the machine boots straight to Windows

For next time — and there will be a next time, because this is a release upgrade rather than a one-off:

Before any major release upgrade on a dual-boot machine, note down what your ESP and root partitions are, and have the live USB already made and tested. Both take five minutes when nothing is wrong, and they are the two things you cannot easily get hold of when the machine will not boot.

During the upgrade, when the bootloader dialogue appears, actually stop and read it. It is the only screen in the whole process that can leave you unable to boot.

Before the live USB: check the firmware boot order. Twice now I have seen a release upgrade install the bootloader perfectly and then the firmware quietly reorder itself to put Windows first, which produces exactly this symptom with nothing actually broken.

If the Linux entry is still listed in the firmware, move it above Windows and reboot. If that works, you have saved yourself the chroot entirely.

Thirty seconds to check, and it is the difference between a coffee break and an evening.

Recoverable, and the thing you clicked past is almost certainly the answer.

A release upgrade nearly always installs a new bootloader, and at that point it asks which device to install it to. The dialogue presents a list of disks and partitions with a checkbox next to each, and on a multi-disk machine it frequently pre-selects nothing, or the wrong thing. Press enter without reading and you get one of two outcomes:

• the bootloader was installed nowhere, so the old one is still in place but no longer matches the upgraded system, or
• it was installed to a device the firmware does not boot from — a second disk, or the wrong EFI system partition on a machine that has two.

Either way the files on your root partition are completely fine. Only the boot path is wrong.

Fix, from a live USB of the release you upgraded to:

1. Identify your root partition and your EFI system partition. The ESP is the small FAT32 one carrying the boot flag. On a normal dual-boot machine there is one shared with Windows and that is the one you want.
2. Mount root, then mount the ESP at the EFI directory inside it.
3. Bind-mount the pseudo-filesystems and chroot in.
4. Reinstall the bootloader to the ESP, and this time watch what it says about the target.
5. Regenerate the bootloader configuration so it picks up both your upgraded kernel and Windows.
6. Exit, unmount, reboot.

Step five is the one that gives you back the dual-boot menu specifically. Reinstalling the bootloader without regenerating its configuration gets Linux booting again but often leaves Windows off the menu, and then you post a second question about that. The config generator detects other operating systems, so run it after everything is mounted correctly, and check that the Windows entry appears in its output as it runs.

If Windows does not appear even then: the detection needs the ESP mounted and, on some systems, needs to be explicitly permitted to probe other operating systems. There is a setting for that in the bootloader's configuration file, disabled by default on some distributions for security reasons. Enable it, regenerate, and it appears.

Also turn off Fast Startup on the Windows side if you have not. It is not what broke this, but it will cause you a separate confusing problem within the month.

Worth knowing the shortcut for the future: some distributions ship a small tool on the live image that automates the chroot-and-reinstall dance for exactly this situation.

It is not magic and it can pick the wrong disk on a complicated machine, so understanding the manual steps first is genuinely worth it. But once you know what it is doing, it turns this into two clicks.