Dan O.

Once you have it back, there is a tool that lets you view and edit firmware boot entries from a running Linux system. Worth installing and learning to read the output of, because next time you can see immediately whether the entry exists and where it points, instead of inferring it from the firmware's menu.

It also lets you set the boot order from the OS, which is much less painful than the firmware setup screen on most laptops.

Be careful with it though — it writes to NVRAM, and a small number of laptops have historically handled aggressive NVRAM writes badly. Reading is entirely safe; think before you delete entries in bulk.

If you are willing to give up seamless access from the Windows side, the cleaner arrangement is a Linux-native filesystem on the shared drive and a driver on Windows for the occasional read.

You get real permissions, real case sensitivity, real symlinks, and the Linux side stops fighting the filesystem. The trade is that Windows access becomes second-class, and third-party drivers for Linux filesystems on Windows vary in quality — treat that direction as read-mostly and do not run a game from it.

Worth it if the majority of your gaming has moved to the Linux side. Not worth it if it is genuinely fifty-fifty.

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.