[opensuse-support] Since latest snapshot: TW does start only in rescue mode. "couln't get uefi list"
17 Jul
2019
17 Jul
'19
8:18 a.m.
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?
Thank you.
_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte
E-Mail-Adresse mitnehmen! https://www.eclipso.de
--
To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org
17 Jul
17 Jul
8:38 a.m.
New subject: [opensuse-support] Since latest snapshot: TW does start only in rescue mode. "couln't get uefi list"
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.
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
--
To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org
9 a.m.
New subject: [opensuse-support] Since latest snapshot: TW does start only in rescue mode. "couln't get uefi list" [solved]
In data mercoledì 17 luglio 2019 08:38:46 CEST, Felix Miata ha scritto:
stakanov composed on 2019-07-17 08:18 (UTC+0200):
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.
Once done a fsck on /sdc1 which was home I found invalid inodes (which is bad
enough, I will have to see which problem/corruption that may bring after
repair) and repaired.
Now the system boots.
The point is that this error does still appear. Should I go after it and
"repair it"?
I will try with efibootmgr if you think it is useful, so at least from that
side there will be no problem.
_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte
E-Mail-Adresse mitnehmen! https://www.eclipso.de
--
To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org
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. 
2:40 p.m.
New subject: [opensuse-support] Since latest snapshot: TW does start only in rescue mode. "couln't get uefi list" [solved]
* stakanov <stakanov(a)eclipso.eu> [07-17-19 03:01]:
In data mercoledì 17 luglio 2019 08:38:46 CEST, Felix
Miata ha scritto:
use efibootmgr and see if you have "unused entries" or unwanted entries
that you will *never* use and remove them. no one can see what you see
and will have to again question you about particulars. if you still see
the error msg, that did not solve the problem.
I would take cell phone photos of or otherwise record the present
efibootmgr settings and entries in case the need arises to revert or
revise your changes.
do not depend on others to assess the value of particulars of your system.
--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
--
To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org
stakanov composed on 2019-07-17 08:18
(UTC+0200):
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.
Once done a fsck on /sdc1 which was home I found invalid inodes (which is bad
enough, I will have to see which problem/corruption that may bring after
repair) and repaired.
Now the system boots.
The point is that this error does still appear. Should I go after it and
"repair it"?
I will try with efibootmgr if you think it is useful, so at least from that
side there will be no problem. 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.
10:34 p.m.
New subject: [opensuse-support] Since latest snapshot: TW does start only in rescue mode. "couln't get uefi list" [solved]
In data mercoledì 17 luglio 2019 14:40:28 CEST, Patrick Shanahan ha scritto:
* stakanov <stakanov(a)eclipso.eu> [07-17-19
03:01]:
It is
weird. No unused entries, all very standard. That error seems to be an
artifact of not having a TPM.
_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte
E-Mail-Adresse mitnehmen! https://www.eclipso.de
--
To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org
In data mercoledì 17 luglio 2019 08:38:46 CEST,
Felix Miata ha scritto:
use efibootmgr and see if you have "unused entries" or unwanted entries
that you will *never* use and remove them. no one can see what you see
and will have to again question you about particulars. if you still see
the error msg, that did not solve the problem.
I would take cell phone photos of or otherwise record the present
efibootmgr settings and entries in case the need arises to revert or
revise your changes.
do not depend on others to assess the value of particulars of your system. stakanov composed on 2019-07-17 08:18
(UTC+0200):
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.
Once done a fsck on /sdc1 which was home I found invalid inodes (which is
bad enough, I will have to see which problem/corruption that may bring
after repair) and repaired.
Now the system boots.
The point is that this error does still appear. Should I go after it and
"repair it"?
I will try with efibootmgr if you think it is useful, so at least from
that
side there will be no problem. 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. 
18 Jul
18 Jul
1:42 a.m.
New subject: [opensuse-support] Since latest snapshot: TW does start only in rescue mode. "couln't get uefi list" [solved]
On 17/07/2019 09.00, stakanov wrote:
In data mercoledì 17 luglio 2019 08:38:46 CEST, Felix
Miata ha scritto:
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.
--
Cheers / Saludos,
Carlos E. R.
(from 15.0 x86_64 at Telcontar)
stakanov composed on 2019-07-17 08:18
(UTC+0200):
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. 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.
8:40 a.m.
New subject: [opensuse-support] Since latest snapshot: TW does start only in rescue mode. "couln't get uefi list" [solved]
In data giovedì 18 luglio 2019 01:42:08 CEST, Carlos E. R. ha scritto:
On 17/07/2019 09.00, stakanov wrote:
I did not know that. Yes, it was "suspend
to ram" and yes, it may have been
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.
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.
_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte
E-Mail-Adresse mitnehmen! https://www.eclipso.de
--
To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org
In data mercoledì 17 luglio 2019 08:38:46 CEST,
Felix Miata ha scritto:
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. stakanov composed on 2019-07-17 08:18
(UTC+0200):
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. 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.
19 Jul
19 Jul
2:30 p.m.
New subject: [opensuse-support] Since latest snapshot: TW does start only in rescue mode. "couln't get uefi list" [solved]
Resending due to "Mailinglist outage yesterday" - was sent at 12:42 UTC 18/7
On 18/07/2019 08.40, stakanov wrote:
In data giovedì 18 luglio 2019 01:42:08 CEST, Carlos
E. R. ha scritto:
:-?
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.
On 17/07/2019 09.00, stakanov wrote:
I did not know that. Yes, it was "suspend
to ram" and yes, it may have been
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. In data mercoledì 17 luglio 2019 08:38:46 CEST,
Felix Miata ha scritto:
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. 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.
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)
549
days inactive
551
days old
7 comments
4 participants
participants (4)
-
Carlos E. R. -
Felix Miata -
Patrick Shanahan -
stakanov