Fikri

One thing worth doing before any of that, because it eliminates the largest single variable: prove the board itself works.

Upload something that blinks a light. If that fails, you have a toolchain, driver or board problem and the sensor is irrelevant. If it works, the board and the upload path are fine and you can concentrate on the module.

It sounds too basic to bother with and it is the step that most often reveals the real problem, particularly on a fresh setup where nothing has ever worked yet.

One mundane cause worth ruling out early because it costs nothing: the enclosure or the cable.

External drives fail to enumerate properly with a marginal cable or an under-powered hub, and the symptom can be a partition table that reads intermittently and a mount that fails. If dmesg shows the device connecting and disconnecting, or resetting, stop debugging filesystems and change the cable and the port first.

Garbage characters is a very specific symptom and it almost always means one thing: the baud rate does not match.

The connection is working — bytes are arriving — and they are being sampled at the wrong speed, so you get plausible-looking rubbish. Nothing at all usually means the wrong port, or the board is not printing.

The settings that matter:

• Baud rate, which must match what the firmware set. Common values are 9600 and 115200, and many boards print their bootloader messages at a different rate from the program, which is why you sometimes get garbage followed by readable text.
• Line ending. If you send commands and the board ignores them, this is usually why — it is waiting for a newline you are not sending.
• The port, which changes between plugs.

And everything else is usually left at the defaults of eight data bits, no parity, one stop bit.

Why the guides tell you to turn it off anyway, and it is not laziness:

Out-of-tree kernel modules. Anything not built as part of the signed kernel — proprietary graphics drivers, virtualisation modules, some hardware drivers — has to be signed too, or the kernel refuses to load it. On distributions with tooling for this it is handled automatically. On others you enrol your own key and sign modules yourself, and that is a real chore.

Rolling and community distributions often do not ship a signed bootloader at all, so the only route is enrolling your own keys.

Hibernation and some kernel features are restricted under the lockdown mode that usually accompanies it.

Dual boot ordering breaks in confusing ways after firmware updates.

So the honest guidance: on a mainstream distribution with open drivers, leave it on and you will not notice. If you need proprietary drivers or run a distribution without a signed loader, turning it off is a defensible choice — and make it a decision rather than a default.

What it protects against is narrow and real: code running before the operating system starts.

The firmware checks that the bootloader it is about to run carries a signature from a key it trusts, and the bootloader checks the kernel in turn. The threat model is malware that installs itself into the boot path, where it loads before any antivirus, any disk encryption prompt and any security software, and is therefore very hard to detect or remove.

That is a narrow class of attack and a serious one, and it is worth noting what it does not protect against: essentially everything after boot. It is not a general-purpose defence and it does nothing about ordinary compromise.

Running with it enabled is entirely realistic. Most mainstream distributions ship a signed bootloader precisely so this works, and they install with it on.