>>>>> Max Nikulin <[email protected]>: [snip!] > Even if you are not going to flush firmware, read changelog.
Hm... good tip! There could be a clue there. > I recall I have seen some workarounds related to NVRAM in articles on > UEFI secure boot troubleshooting. Perhaps some commands may be adapted > to inspect if there is no room on the NVRAM storage. Do you have any references to these workaround? Thanks! > Likely just a coincidence, but the date is not so far from expiration > of MS secure boot keys. Firmware might be buggy. > <https://lwn.net/Articles/1029767/> > Jake Edge. Linux and Secure Boot certificate expiration. Thanks! Will study! > 20 years ago I fixed repeating corruption of BIOS settings on a > *desktop* by replacing its RTC battery that was discharged. I have no > idea if something similar may happen with modern laptops. Probably won't. Google tells me it's not RAM really. It's an EEPROM. > I am skeptical concerning xev. I would start from reading logs for > /dev/input* devices detected during boot (sudo journalctl > -b). Libinput tools might be better for diagnostics, Thanks! Will study boot log and what libinput tools says. > help if the issue with system firmware settings. Indeed. > Have you tried to boot a live image to confirm that the issue is not > due to some OS setting? Not yet. But that is a good suggestion. Will give a clue on hardware issues as well.
