Linux

Now after decrypting my LUKS storage it seems is tries to mount a nonexistent Windows partition and always fails.

I have never used Kinoite, nor a LUKS-based environment, but if you have a mount point in your /etc/fstab and mounting it fails at boot, at least Debian will go into emergency mode. I wouldn't be surprised if Kinoite does too.

If you have an entry there for the Windows partition, enter emergency mode, use an editor like nano or whatever you're comfortable with to edit that file, and comment the windows mount line out with a leading pound sign. Save, and run shutdown -r now to reboot and hopefully you should come up to a sane Linux environment, sans the Windows mount.

It's possible that whatever drive Windows is on -- which I assume is internal -- is dying. That could cause Windows to fail a repair, to be unable to boot, and your Linux distro on your external drive not to be able to find your Windows partition.

If you can get into your Kinoite environment, you can run lsblk to see a list of drives that it can see. If the internal drive doesn't show up, that'd be a a pretty good red flag that something's wrong with it.

EDIT: I'll also add that if that's the problem, this is the second time someone's posted a request for help in a couple days that I've responded to related to a drive failing, where it wasn't obvious to the user that the drive was failing, and in diagnosing the problem, they interpreted the problem as software on the computer producing problems with their drive (one person decided that Arch was likely at fault and put Debian on their system, and here Windows is catching flak). I think that there's a legit argument that PCs need to do a better job of handling drive failure from a UI standpoint, as the symptoms that a failing drive can produce are not always obvious:

• Lengthy delays when an OS tries accessing a drive.

• A drive not being visible to the computer.

• Various programs failing when trying to work with the drive.

• Failure to boot.

A number of things occur to me that could be helpful:

• A BIOS could remember a brief description of the last media it successfully booted from. If it cannot find any valid boot media, it could display a message saying that it cannot see the drive with the given manufacturer, model name, and capacity and suggesting that the drive may have failed. That won't catch every situation, like if there are multiple sources of bootable media present, but I think that for a lot of users, that'd direct them down the right path.

• If there has been no hard power down (i.e. to cold-remove a drive), a BIOS has a drive plugged into a controller that it knows does not support hot-swap capabilities (e.g. an on-board ATA/SATA/NVMe controller), and the drive is no longer visible, it's a pretty good bet that that drive has failed. It might not be a bad idea to default to a delay at boot for N seconds showing a message about a probably failed drive. Have a BIOS option to disable "interactive diagnostic support" for headless systems.

• Linux distros could be set up with better support for indicating to a user that a drive is failing. SMART won't always catch it, but having SMART active on a distro by default might be a good idea. Having errors there, or I/O errors to a non-removable-media drive percolate up to something user-visible, like the notification manager, by default that suggests that the drive might be seeing physical problems might help. Normally, if I'm thinking that a drive might be failing, I go check the kernel log for I/O failures, but that's probably not obvious to everyone, and it doesn't default to indicating to the user that something might be broken. If SMART is saying that a drive is failing or there are I/O errors occurring to the drive, it's probably at least reasonable to suggest to the user that they don't want to be relying on that drive any more.

• On the above note, having the kernel retain I/O error counts for devices (maybe it does, but I don't recall seeing it) and logging those in system statistics daemons like sysstat and collectd might help for post-mortem analysis of drive failure (well, maybe not if the failing drive is the one where the statistics log is going).

Those are heuristics, but I think that they aren't likely to throw too many false positives out, and they may help users figure out why their machine isn't happy.