Resending due to "Mailinglist outage yesterday" - was sent at 12:42 UTC 18/7 On 18/07/2019 08.40, stakanov wrote:
On 17/07/2019 09.00, stakanov wrote:
In data mercoledì 17 luglio 2019 08:38:46 CEST, Felix Miata ha scritto:
stakanov composed on 2019-07-17 08:18 (UTC+0200):
more or less that is what I find. the machine was running for long time and was suspended before the update. NVRAM may be full? How could I free it in order to boot?
Surplus entries may be removed using the efibootmgr utility in a rescue mode boot. Simply enter efibootmgr in a root login shell to list all the entries. Man efibootmgr shows the options required to remove unwanted entries.
Thank you. I checked also in the bios. I have to say that it is very(!) misleading having this error in the log when you have (like in this case) another issue. In fact I had a ext4 problem on /home that would not mount but the error shown first in the logs and in the boot process is that stupid could not get uefi list.
You said the machine was suspended?
Suspended means suspended to RAM, different than hibernation, where the image is saved to disk. If the battery runs out while suspended, on next boot the machine has to recover from bad corruption on all the mounted partitions at the time of suspend. I did not know that. Yes, it was "suspend to ram" and yes, it may have been
In data giovedì 18 luglio 2019 01:42:08 CEST, Carlos E. R. ha scritto: that the suspended partition was not correctly recovered when the update required a reboot. So the corruption may be a result of this. Thanks for the heads up.
:-? I'm not sure if you understood the issue, so I'll try to explain again, just in case - maybe it is a translation issue :-) The update is not related. The machine gets suspended to ram; all the mounted partitions are, well, mounted: opened files, half written files, the lot. The battery doesn't last enough, and the machine, instead of recovering from suspend, reboots. The effect is basically the same as recovering from a hard crash in the middle of the session. Every partition in use is corrupt. Some may recover fine, some not. There is a suspend method that avoids this, called "hybrid". It does both suspend to ram and to disk procedures. On recover, if battery lasts, it just continues from ram, instant recover. If the battery failed, it recovers from disk just as from a normal hibernation. Whether the machine was updated doesn't affect any of this. So if you suspended, recovered, updated, and rebooted, then that was just normal work.
However, I still get the "could not get uefi list" while the uefi entries are correct and no residuals are to be found. I think that that error is because the machine has secure boot without a TPM.
Trusted Platform Module? If a command can read the uefi list, I don't see why some part of the boot process can't. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)