On Fri, Mar 22, 2024 at 07:10:07AM +0300, Andrei Borzenkov wrote:
On 22.03.2024 00:37, Joe Salmeri wrote:
-rw-r--r-- root root 3/21/2024 13:15 33,481 StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824 With the large jump in percent used, could there be an issue with fwupdmgr that is causing your issue ?
It is quite possible that your firmware only performs garbage collection and/or compaction on demand or power on.
Different firmware has different garbage collection logic. Some firmware always runs garbage colleciton when booting. But some firmware wants to speed up booting, so it set a threshold of free NVRAM space. The garbage collection be triggered when the free NVRAM space lower than threshold. In early UEFI firmware implementation, someone found a case that the threshold is too low. The threshold is lower than the requirements of garbage collection mechanism. Firmware does not reserve enough free NVRAM space fore garbage collection. Then the machine is brick, which always hang in garbage collection. That's why Linux kernel reserves a space to prevent the situation. But actually nobody knows all UEFI firmware's requeirement of minimum space for garbage collection. Only OEM/ODM firmware team knows. Regards Joey Lee