Salim

Two firmware settings to check while you are in there, because either can produce this exact symptom with the boot files completely intact.

Secure Boot. If it was on and something changed — a firmware update, a kernel update on the Linux side with an unsigned module, a reset of the secure boot keys — the firmware will silently refuse to launch a bootloader it cannot verify. Some firmware then hides the entry rather than showing you an error, which is exactly what you are describing.

Storage mode. Rarer on an existing install than on a new one, but if the SATA or NVMe controller mode got reset to a RAID or acceleration mode, Linux may no longer see the disk at all while Windows continues fine because it has the vendor driver. Confirm it is in the mode it was installed under.

Both are two minutes to check and both save you a chroot session.

Second the storage mode as the overwhelming favourite. Two smaller causes worth knowing, since they produce a similar-looking dead end:

Secure Boot with an installer that is not signed for it. Usually this stops the live environment from booting at all rather than hiding disks, so it does not fit your description — but if you disabled it to get this far, remember you did, because it affects what you do afterwards.

A pre-existing four-primary-partition situation on an older MBR disk. Not your case on a recent NVMe laptop, but if someone lands here with a disk full of vendor recovery partitions and no free partition slot, the installer will refuse to offer alongside-install even though it can see everything.

Also: check in the firmware whether there is a separate setting for the specific NVMe slot. On some machines the mode is per-port and changing the global one does not cover the slot the drive is actually in.

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.

Adding the DHCP variant, because it produces the identical error from a different direction.

If the interface was on DHCP and you switched it to static — or built the bridge and the bridge came up on DHCP with no server answering on that path — you get an address but no gateway, and therefore no default route. Same message.

So the check is not "do I have an IP address", it is specifically "do I have a default route". Those are different questions and the first one being yes tells you nothing.

If you set a static address anywhere in this process, make absolutely sure you also set the gateway. Half the network configuration forms in the world let you save one without the other.