efivarfs_set_variable: writing to fd 6 failed: No space left on device. MokList löschen?

[Marco Moock]

Hallo zusammen!

In einem laufenden System muss die Platte mit der EFI-Partition
getauscht werden. Daher soll ein neuer UEFI-Booteintrag rein, den alten
habe ich gelöscht.


root@srv1:/sys/firmware/efi/efivars# grub-install
Installing for x86_64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: efivarfs_set_variable: writing to fd 6 failed:
No space left on device. grub-install: warning: _efi_set_variable_mode:
ops->set_variable() failed: No space left on device. grub-install:
error: failed to register the EFI boot entry: No space left on device.
root@srv1:/sys/firmware/efi/efivars#

/sys/firmware/efi/efivars/dump* gibt es gar nichts.

-rw-r--r-- 1 root root 12 Nov 14 14:37 AcpiGlobalVariable-c020489e-6db2-4ef2-9aa5-ca06fc11d36a
-rw-r--r-- 1 root root 5 Nov 14 14:37 BadgeBackgroundColor-015698bc-457c-43f4-b257-f2ac5ed55f28
-rw-r--r-- 1 root root 12 Nov 14 14:37 BoardFeatures-94b9e8ae-8877-479a-9842-f5974b82ced3
-rw-r--r-- 1 root root 6 Nov 14 14:37 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 38 Nov 14 14:37 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 38 Nov 14 14:37 ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 34 Nov 14 14:37 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 34 Nov 14 14:37 ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 388 Nov 14 14:37 DmiData-70e56c5e-280c-44b0-a497-09681abc375e
-rw-r--r-- 1 root root 34 Nov 14 14:37 ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 265 Nov 14 14:37 Events-b452fd8a-c9ca-4764-977e-59d839dd861b
-rw-r--r-- 1 root root 76 Nov 14 14:37 HDDP-fab7e9e1-39dd-4f2b-8408-e20e906cb6de
-rw-r--r-- 1 root root 12 Nov 14 14:37 HiiDB-1b838190-4625-4ead-abc9-cd5e6af18fe0
-rw-r--r-- 1 root root 5 Nov 14 14:37 ItkBiosModVar-3812723d-7e48-4e29-bc27-f5a39ac94ef1
-rw-r--r-- 1 root root 152 Nov 14 14:37 ItkDataVar-3812723d-7e48-4e29-bc27-f5a39ac94ef1
-rw-r--r-- 1 root root 7 Nov 14 14:37 Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 10 Nov 14 14:37 LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 8 Nov 14 14:37 MTC-eb704011-1402-11d3-8e77-00a0c969723b
-rw-r--r-- 1 root root 8 Nov 14 14:37 MemCeil.-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 107 Nov 14 14:37 MemoryConfig-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 432 Nov 14 14:37 MfgDefault-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root 978 Nov 14 14:37 MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23
-rw-r--r-- 1 root root 5 Nov 14 14:37 MokListTrustedRT-605dab50-e046-4300-abb6-3dd810dd8b23
-rw-r--r-- 1 root root 80 Nov 14 14:37 MokListXRT-605dab50-e046-4300-abb6-3dd810dd8b23
-rw-r--r-- 1 root root 80 Nov 14 14:37 MokListXRT1-605dab50-e046-4300-abb6-3dd810dd8b23
-rw-r--r-- 1 root root 80 Nov 14 14:37 MokListXRT10-605dab50-e046-4300-abb6-3dd810dd8b23

[...] von den MokList gibt es ganz viele

-rw-r--r-- 1 root root 7 Nov 14 14:37 OriginalLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 7 Nov 14 14:37 PciLanInfo-0d9a1427-e02a-437d-926b-aa521fd722ba
-rw-r--r-- 1 root root 276 Nov 14 14:37 PlatformCpuInfo-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 136 Nov 14 14:37 PlatformInfo-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 8 Nov 14 14:37 SLP20Magic-41282ef2-9b5a-4eb7-95d8-d9cd7bdce367
-rw-r--r-- 1 root root 29 Nov 14 14:37 SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23
-rw-r--r-- 1 root root 432 Nov 14 14:37 Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root 432 Nov 14 14:37 SetupDefault-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root 8 Nov 14 14:37 SwitchBoard-56772831-0132-4ebe-8842-d65a50c0a7d0
-rw-r--r-- 1 root root 86 Nov 14 14:37 SystemPassword-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
-rw-r--r-- 1 root root 28 Nov 14 14:37 UUID-d357c710-0ada-4717-8dba-c6adc7cd2b2a
-rw-r--r-- 1 root root 6 Nov 14 14:37 'main firmware-05a798ea-39ee-40fc-82c5-622582fa634b'
-rw-r--r-- 1 root root 6 Nov 14 14:37 'recovery firmware-05a798ea-39ee-40fc-82c5-622582fa634b'
-rw-r--r-- 1 root root 8 Nov 14 14:37 sOemT3-4acacc46-a23e-4114-8169-e5edebe2045d
-rw-r--r-- 1 root root 6 Nov 14 14:37 'supplemental recovery area-05a798ea-39ee-40fc-82c5-622582fa634b'

Kann man die bedenkenlos löschen (ich will kein SecureBoot nutzen)?
Backup mache ich vorher, aber ob man die dann wieder da hinbekommt, ist
fraglich.

Auf meinem Desktop ist MokList gar nicht vorhanden.

--
Gruß
Marco

[Markus Schaaf]

Am 15.11.23 um 07:31 schrieb Marco Moock:

> Kann man die bedenkenlos löschen (ich will kein SecureBoot nutzen)?

Ich würde das im Zweifel vom Firmware-Setup aus versuchen. Es
gibt viele Gründe, warum das Schreiben von Linux aus nicht geht.
Kannst auch mal die Tipps im Arch-Wiki lesen:

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Userspace_tools_are_unable_to_modify_UEFI_variable_data

Wenn Du auf der Platte den Default-Loader installierst
(EFI/BOOT/BOOTX64.EFI), sollte Booten auf jeden Fall möglich
sein, auch wenn kein expliziter Eintrag vorhanden ist.

MfG

[Marco Moock]

Am 15.11.2023 um 09:09:33 Uhr schrieb Markus Schaaf:

> Am 15.11.23 um 07:31 schrieb Marco Moock:
>
> > Kann man die bedenkenlos löschen (ich will kein SecureBoot nutzen)?
> >
>
> Ich würde das im Zweifel vom Firmware-Setup aus versuchen. Es
> gibt viele Gründe, warum das Schreiben von Linux aus nicht geht.

Viele sind mit chattr +i geschützt.
Grund soll wohl sein, dass es nichtstandardisierte Variablen gibt, die
das MB bricken, wenn die gelöscht werden.

> Kannst auch mal die Tipps im Arch-Wiki lesen:
>
> https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Userspace_tools_are_unable_to_modify_UEFI_variable_data
>
> Wenn Du auf der Platte den Default-Loader installierst
> (EFI/BOOT/BOOTX64.EFI), sollte Booten auf jeden Fall möglich
> sein, auch wenn kein expliziter Eintrag vorhanden ist.

Das hoffe, ich denn das Mainboard D525MW stammt aus der Anfangszeit von
UEFI und auch bei der Installation hat das Ärger gemacht.

Ich hoffe, dass das klappt, sonst muss ich wohl versuchen, das System
auf BIOS-Boot umzustellen und das wird wegen der GPT-Tabelle und der
dann nötigen bios_grub-Partition auch unschön. Oder ich lagere das halt
auf nen Stick aus, würde auch gehen.

[Gerald E¡scher]

Marco Moock schrieb am 15/11/2023 07:31:

> In einem laufenden System muss die Platte mit der EFI-Partition
> getauscht werden. Daher soll ein neuer UEFI-Booteintrag rein, den alten
> habe ich gelöscht.

Die Booteinträge sollte die UEFI-Firmware automatisch eintragen sobald
sie eine neue Platte und/oder EFI-Partition findet.

> root@srv1:/sys/firmware/efi/efivars# grub-install
> Installing for x86_64-efi platform.
> grub-install: warning: Cannot set EFI variable Boot0000.

Was sagt efibootmgr -v?

> grub-install: warning: efivarfs_set_variable: writing to fd 6 failed:
> No space left on device. grub-install: warning: _efi_set_variable_mode:

Welches device? Ist /boot voll?

> ops->set_variable() failed: No space left on device. grub-install:
> error: failed to register the EFI boot entry: No space left on device.
> root@srv1:/sys/firmware/efi/efivars#
>
> /sys/firmware/efi/efivars/dump* gibt es gar nichts.
>
> -rw-r--r-- 1 root root 12 Nov 14 14:37 AcpiGlobalVariable-c020489e-6db2-4ef2-9aa5-ca06fc11d36a

[...]

> -rw-r--r-- 1 root root 6 Nov 14 14:37 'supplemental recovery area-05a798ea-39ee-40fc-82c5-622582fa634b'
>
> Kann man die bedenkenlos löschen (ich will kein SecureBoot nutzen)?

Kannte ich bisher nicht, habe ich noch nie benutzt, im Zweifel: nein.
Zum Manipulieren der EFI-Variablen fürs Booten ist efibootmgr da.

--
Gerald

[Marco Moock]

Am 15.11.2023 um 11:42:09 Uhr schrieb Gerald E¡scher:

> Marco Moock schrieb am 15/11/2023 07:31:
>
> > In einem laufenden System muss die Platte mit der EFI-Partition
> > getauscht werden. Daher soll ein neuer UEFI-Booteintrag rein, den
> > alten habe ich gelöscht.
>
> Die Booteinträge sollte die UEFI-Firmware automatisch eintragen sobald
> sie eine neue Platte und/oder EFI-Partition findet.

Wäre mir neu, denn dann müsste das bei jedem Stick auch passieren.

> > root@srv1:/sys/firmware/efi/efivars# grub-install
> > Installing for x86_64-efi platform.
> > grub-install: warning: Cannot set EFI variable Boot0000.
>
> Was sagt efibootmgr -v?

root@srv1:~# efibootmgr -v
BootCurrent: 0000
No BootOrder is set; firmware will attempt recovery
root@srv1:~#

0000 habe ich gelöscht, da auf alter Platte.

> > grub-install: warning: efivarfs_set_variable: writing to fd 6
> > failed: No space left on device. grub-install: warning:
> > _efi_set_variable_mode:
>
> Welches device?

Ich vermute das NVRAM des EFI.

> Ist /boot voll?

Nein, auch /boot/efi nicht.

> > ops->set_variable() failed: No space left on device. grub-install:
> > error: failed to register the EFI boot entry: No space left on
> > device. root@srv1:/sys/firmware/efi/efivars#
> >
> > /sys/firmware/efi/efivars/dump* gibt es gar nichts.
> >
> > -rw-r--r-- 1 root root 12 Nov 14 14:37
> > AcpiGlobalVariable-c020489e-6db2-4ef2-9aa5-ca06fc11d36a
> [...]
> > -rw-r--r-- 1 root root 6 Nov 14 14:37 'supplemental recovery
> > area-05a798ea-39ee-40fc-82c5-622582fa634b'
> >
> > Kann man die bedenkenlos löschen (ich will kein SecureBoot nutzen)?
> >
>
> Kannte ich bisher nicht, habe ich noch nie benutzt, im Zweifel: nein.
> Zum Manipulieren der EFI-Variablen fürs Booten ist efibootmgr da.

Das kann aber sich nicht die MOK ändern, dafür gibt es mokutil. Das tut
aber nicht, weil SecureBoot nicht unterstützt wird (vermutlich nur
deaktiviert).

[Bernd Mayer]

Am 15.11.23 um 12:59 schrieb Marco Moock:

Hallo,

welche Distribution verwendest Du da?

IIRC gibt es Ubuntuversionen die Probleme mit Secureboot haben.
Versionen von linuxmint die darauf beruhen haben diese Probleme übernommen.

Die neue edge-Version vom aktuellen linuxmint hat das korrigiert.


Bernd Mayer

[Gerald E¡scher]

Marco Moock schrieb am 15/11/2023 12:59:

> Am 15.11.2023 um 11:42:09 Uhr schrieb Gerald E¡scher:
>
>> Marco Moock schrieb am 15/11/2023 07:31:
>>
>> > In einem laufenden System muss die Platte mit der EFI-Partition
>> > getauscht werden. Daher soll ein neuer UEFI-Booteintrag rein, den
>> > alten habe ich gelöscht.
>>
>> Die Booteinträge sollte die UEFI-Firmware automatisch eintragen sobald
>> sie eine neue Platte und/oder EFI-Partition findet.
>
> Wäre mir neu, denn dann müsste das bei jedem Stick auch passieren.

USB-Stick weiß ich nicht, aber Platten werden normalerweise automatisch
eingetragen. Ich habe eben mit efibootmgr meine Backup-Platte
deaktiviert und aus der Boot-Reihenfolge raus geschmissen :-)

>> > root@srv1:/sys/firmware/efi/efivars# grub-install
>> > Installing for x86_64-efi platform.
>> > grub-install: warning: Cannot set EFI variable Boot0000.
>>
>> Was sagt efibootmgr -v?
>
> root@srv1:~# efibootmgr -v
> BootCurrent: 0000
> No BootOrder is set; firmware will attempt recovery
> root@srv1:~#

Da sollten mindestens die Platte, GRUB und die UEFI-Shell aufscheinen.
Ist die aktuellste UEFI-Firmware drauf?

> 0000 habe ich gelöscht, da auf alter Platte.

Würde ich nicht löschen sondern nur deaktivieren
(efibootmgr -A -b xxxx).

>> > -rw-r--r-- 1 root root 12 Nov 14 14:37
>> > AcpiGlobalVariable-c020489e-6db2-4ef2-9aa5-ca06fc11d36a
>> [...]
>> > -rw-r--r-- 1 root root 6 Nov 14 14:37 'supplemental recovery
>> > area-05a798ea-39ee-40fc-82c5-622582fa634b'
>> >
>> > Kann man die bedenkenlos löschen (ich will kein SecureBoot nutzen)?
>> >
>>
>> Kannte ich bisher nicht, habe ich noch nie benutzt, im Zweifel: nein.
>> Zum Manipulieren der EFI-Variablen fürs Booten ist efibootmgr da.
>
> Das kann aber sich nicht die MOK ändern, dafür gibt es mokutil. Das tut
> aber nicht, weil SecureBoot nicht unterstützt wird (vermutlich nur
> deaktiviert).

Letzteres lässt sich einfach herausfinden:

| gerald@tigermaus:~$ sudo mokutil --sb-state
| SecureBoot disabled

--
Gerald

[Marco Moock]

Am 15.11.2023 um 13:31:34 Uhr schrieb Bernd Mayer:

> welche Distribution verwendest Du da?

Debian 12.

[Marco Moock]

Am 15.11.2023 um 13:04:43 Uhr schrieb Gerald E¡scher:

> Da sollten mindestens die Platte, GRUB und die UEFI-Shell aufscheinen.

GRUB jetzt nicht mehr.

> Ist die aktuellste UEFI-Firmware drauf?

version: MWPNT10N.86A.0132.2013.0726.1534
date: 07/26/2013

Ich kann bei Intel leider nix finden.

> > 0000 habe ich gelöscht, da auf alter Platte.
>
> Würde ich nicht löschen sondern nur deaktivieren
> (efibootmgr -A -b xxxx).

Habe den gelöscht, damit ich freien platz auf den NVRAM bekomme.
Er ist aber nach dem Neustart wieder da.

Da konnte ich auch grub-install & Co. nutzen.
Ich habe aber nix im UEFI geändert. Sehr komisch das Ganze.

[Bernd Mayer]

Am 15.11.23 um 14:46 schrieb Marco Moock:

> Am 15.11.2023 um 13:04:43 Uhr schrieb Gerald E¡scher:
>
>> Da sollten mindestens die Platte, GRUB und die UEFI-Shell aufscheinen.
>
> GRUB jetzt nicht mehr.
>
>> Ist die aktuellste UEFI-Firmware drauf?
>
> version: MWPNT10N.86A.0132.2013.0726.1534
> date: 07/26/2013
>
> Ich kann bei Intel leider nix finden.

Hallo,

Hier gibts was dazu, ich habe jetzt nicht alles durchgesehen ob da für
Dich was passendes dabei ist:

https://www.intel.com/content/www/us/en/products/sku/48952/intel-desktop-board-d525mw/support.html


Bernd Mayer

[Marco Moock]

Am 15.11.2023 um 15:43:21 Uhr schrieb Bernd Mayer:

> https://www.intel.com/content/www/us/en/products/sku/48952/intel-desktop-board-d525mw/support.html

Wo gibt es da jetzt das UEFI als Download?

[Bernd Mayer]

Am 15.11.23 um 15:49 schrieb Marco Moock:

> Am 15.11.2023 um 15:43:21 Uhr schrieb Bernd Mayer:
>
>> https://www.intel.com/content/www/us/en/products/sku/48952/intel-desktop-board-d525mw/support.html
>
> Wo gibt es da jetzt das UEFI als Download?

Hier gibt es auch noch BIOS-Updates dafür:

https://theretroweb.com/motherboards/s/intel-d525mw-mount-washington#downloads

Demnach hast Du das Neuste von 2013, das ist 10 ja schon Jahre alt.

Siehe:
https://de.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface


"Wie Forscher der Mitre Corporation Mitte 2014 bekannt gegeben haben,
weist die Intel-Referenzimplementierung von UEFI zudem eine
Sicherheitslücke auf, die das dauerhafte Einschleusen von Malware
ermöglicht. Genutzt wird hierfür eine fehlerhafte Update-Funktion, durch
die es zu Integer-Overflows kommt und Schadcode ausführbar macht. Viele
verwenden den Code der Intel-Referenzimplementierung als Basis für ihr
UEFI.[11]"


Bernd Mayer

[Bernd Mayer]

Am 15.11.23 um 15:49 schrieb Marco Moock:

> Am 15.11.2023 um 15:43:21 Uhr schrieb Bernd Mayer:
>
>> https://www.intel.com/content/www/us/en/products/sku/48952/intel-desktop-board-d525mw/support.html
>
> Wo gibt es da jetzt das UEFI als Download?

Hier gibt es auch noch BIOS-Updates dafür:

https://theretroweb.com/motherboards/s/intel-d525mw-mount-washington#downloads

Demnach hast Du das Neuste von 2013, das ist ja schon 10 Jahre alt.

[Marco Moock]

Am 15.11.2023 um 16:52:37 Uhr schrieb Bernd Mayer:

> "Wie Forscher der Mitre Corporation Mitte 2014 bekannt gegeben haben,
> weist die Intel-Referenzimplementierung von UEFI zudem eine
> Sicherheitslücke auf, die das dauerhafte Einschleusen von Malware
> ermöglicht. Genutzt wird hierfür eine fehlerhafte Update-Funktion,
> durch die es zu Integer-Overflows kommt und Schadcode ausführbar
> macht. Viele verwenden den Code der Intel-Referenzimplementierung als
> Basis für ihr UEFI.[11]"

"Die festgestellten Schwachstellen im BIOS ermöglichen es, dass Malware
in das BIOS eingeschleust und auf Dauer installiert werden kann.
Verantwortlich ist hierfür die Update-Funktion des BIOS. Das
installierte Betriebssystem, beispielsweise Windows 8, kann auf diese
Update-Funktion zugreifen und diese ausführen. Hierfür muss eine
bestimmte Variable („CapsuleUpdateData“) gesetzt sein. In dieser
Variable ist ein Speicherbereich definiert, in dem das BIOS nach einem
ausführbaren Image sucht. Hierbei kommt es an zwei Stellen zu Integer
Overflows, also Zählerüberläufe, welche sich die Angreifer zunutze
machen kann und Schadcode ausführen kann. Für den ausführbaren Code ist
nicht einmal eine gültige Signatur notwendig."

Ergo muss man da Zugriff auf das Betriebssystem haben und wenn das bei
mir der Fall ist, ist ein Angriff auf das UEFI wohl das Langweiligste,
was der Angreifer machen kann.

[Bernd Mayer]

Am 15.11.23 um 16:58 schrieb Marco Moock:

Hallo,

"no space left on device"

Wieviel Platz ist da denn vorhanden?


Bernd Mayer

[Marco Moock]

Am 15.11.2023 um 17:07:06 Uhr schrieb Bernd Mayer:

> "no space left on device"
>
> Wieviel Platz ist da denn vorhanden?

Keine Ahnung.
Das ist das NVRAM.

*-firmware
description: BIOS
vendor: Intel Corp.
physical id: 4
version: MWPNT10N.86A.0132.2013.0726.1534
date: 07/26/2013
size: 64KiB
capacity: 1MiB
capabilities: pci upgrade shadowing cdboot bootselect edd
int9keyboard int14serial int17printer int10video acpi usb zipboot
biosbootspecification netb oot

Ob das aber nur der Platz für die Firmware ist oder auch den anderen
Kram, weiß ich nicht.

du kann das auch in dem Verzeichnis nicht anzeigen.
ls -la zeigt aber die Größen der einzelnen Dateien in
/sys/firmware/efi/efivars

[Bernd Mayer]

Am 15.11.23 um 07:31 schrieb Marco Moock:

> Hallo zusammen!
>
> In einem laufenden System muss die Platte mit der EFI-Partition
> getauscht werden. Daher soll ein neuer UEFI-Booteintrag rein, den alten
> habe ich gelöscht.
>
>
>

> /sys/firmware/efi/efivars/dump* gibt es gar nichts.
>

> -rw-r--r-- 1 root root 265 Nov 14 14:37 Events-b452fd8a-c9ca-4764-977e-59d839dd861b

> Kann man die bedenkenlos löschen (ich will kein SecureBoot nutzen)?
> Backup mache ich vorher, aber ob man die dann wieder da hinbekommt, ist
> fraglich.

Hallo,

schau mal im BIOS nach, ob man die events anzeigen und löschen kann.


Bernd Mayer

[Gerald E¡scher]

Marco Moock schrieb am 15/11/2023 14:46:

> Am 15.11.2023 um 13:04:43 Uhr schrieb Gerald E¡scher:
>
>> Ist die aktuellste UEFI-Firmware drauf?
>
> version: MWPNT10N.86A.0132.2013.0726.1534
> date: 07/26/2013

Wie Bernd festgestellt hat, ja. Da würde ich annehmen, dass die gröbsten
Bugs beseitigt sind.

>> > 0000 habe ich gelöscht, da auf alter Platte.
>>
>> Würde ich nicht löschen sondern nur deaktivieren
>> (efibootmgr -A -b xxxx).
>
> Habe den gelöscht, damit ich freien platz auf den NVRAM bekomme.
> Er ist aber nach dem Neustart wieder da.

Das gehört so.
Hast du schon versucht, im Firmware-Setup auf die Werkseinstellungen
zurückzusetzen? Dabei sollten überflüssige Eintrage aus dem NVRAM
entfernt werden.

--
Gerald

[Marco Moock]

Am 15.11.2023 um 19:25:36 Uhr schrieb Gerald E¡scher:

> Marco Moock schrieb am 15/11/2023 14:46:

> > Habe den gelöscht, damit ich freien platz auf den NVRAM bekomme.
> > Er ist aber nach dem Neustart wieder da.
>
> Das gehört so.

Gehört das wirklich so, wenn man den mit dem efibootmgr entfernt?

> Hast du schon versucht, im Firmware-Setup auf die Werkseinstellungen
> zurückzusetzen?

Nein, da jetzt alles geht auch nicht mehr nötig.

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Wed, 15 Nov 2023 09:36:29 +0100:

[efi-Variablen]

> > > Kann man die bedenkenlos löschen (ich will kein SecureBoot nutzen)?

...

> Viele sind mit chattr +i geschützt.
> Grund soll wohl sein, dass es nichtstandardisierte Variablen gibt, die
> das MB bricken, wenn die gelöscht werden.

Das sind zum einen sowieso keine regulären Dateien, das efivarfs ist ein
_virtuelles_ Filesystem, für das ein Treiber die BIOS-Einträge in Dateiform
zur Verfügung stellt. Daß da einige speziell geschützt sind, "dürfte seine
Gründe haben".

Außerdem interessieren Dich die eigentlich (fast) alle garnicht, wenn Du
einen _Boot_-Eintrag ändern willst - dafür sind nur die zuständig, die auch
die Zeichenfolge "Boot" im Namen haben. Und um _die_ zu manipulieren, gibt
es das spezielle Programm "efibootmgr" mit seinen Optionen. Das kann diese
Boot-Einträge anlegen, aber auch löschen.

...

> Ich hoffe, dass das klappt, sonst muss ich wohl versuchen, das System
> auf BIOS-Boot umzustellen und das wird wegen der GPT-Tabelle und der

Mit "traditionellem" BIOS-Boot brauchst Du einen Kompatibilitäts-MBR, dann
ist eine GPT auch kein Hindernis.

> dann nötigen bios_grub-Partition auch unschön. Oder ich lagere das halt
> auf nen Stick aus, würde auch gehen.

Naja, klar, warum direkt, wenn's auch umständlich geht...

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Wed, 15 Nov 2023 12:59:08 +0100:

> > Die Booteinträge sollte die UEFI-Firmware automatisch eintragen sobald
> > sie eine neue Platte und/oder EFI-Partition findet.
>
> Wäre mir neu, denn dann müsste das bei jedem Stick auch passieren.

Doch, das tut die UEFI-Firmware durchaus, daraus wird ja das bei den
meisten Main-Boards verfügbare Boot-Menü erstellt. Wenn der Stick dann
beim nächsten Start nicht mehr da ist, wird der sogar (meistens?) wieder
entfernt.

> > Was sagt efibootmgr -v?
>
> root@srv1:~# efibootmgr -v
> BootCurrent: 0000
> No BootOrder is set; firmware will attempt recovery
> root@srv1:~#
>
> 0000 habe ich gelöscht, da auf alter Platte.

Könnte "ungünstig" sein, mußt Du jetzt über das Boot-Menü starten? Da
könnte dieser spezielle "BOOTX64"-Eintrag nützlich bis notwendig sein.

> > > grub-install: warning: efivarfs_set_variable: writing to fd 6
> > > failed: No space left on device. grub-install: warning:
> > > _efi_set_variable_mode:
> >
> > Welches device?
>
> Ich vermute das NVRAM des EFI.

Könnte sein, da scheint das UEFI-Zeugs in rechter MS-Apple-intel-IBM-Manier
zu funktionieren, d.h. nie aufzuräumen, bis nix mehr geht.

...

> > Zum Manipulieren der EFI-Variablen fürs Booten ist efibootmgr da.
>
> Das kann aber sich nicht die MOK ändern, dafür gibt es mokutil. Das tut

Was ist "mokutil"? Kenn'ich nicht, habe ich hier nicht und gibt's für meine
Distribution offenbar auch nicht. Ist das was spezielles für Deine Maschine?

> aber nicht, weil SecureBoot nicht unterstützt wird (vermutlich nur
> deaktiviert).

Für SecureBoot? Naja, kann vielleicht sein, mein Brett hier ist auch schon
ein paar Jahre alt...
Und irgendwelche "mok..."- oder "MOK..."-EFI-Variable gibt's hier überhaupt
nicht.
Ich wäre jedenfalls _sehr_ vorsichtig, im EFI-Bereich was zu löschen oder
auch nur zu ändern, was nicht eindeutig dafür vorgesehen ist (wie z.B. die
Boot-Einträge).

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Wed, 15 Nov 2023 17:12:09 +0100:

> > "no space left on device"
> >
> > Wieviel Platz ist da denn vorhanden?
>
> Keine Ahnung.
> Das ist das NVRAM.
>
> *-firmware
> description: BIOS
> vendor: Intel Corp.
> physical id: 4
> version: MWPNT10N.86A.0132.2013.0726.1534
> date: 07/26/2013
> size: 64KiB
> capacity: 1MiB

^^^^^^^^^^^^^^
Das dürfte die relevante Angabe sein, aber das ist wahrscheinlich halt nur
das Flash-EP_ROM_. Die EFI-Variablen sitzen aber in einem (gepufferten) RAM
oder einem EEPROM. Ob das mit dem "size: 64KiB" gemeint sein könnte, wird
aus der obigen Ausgabe nicht klar.

> Ob das aber nur der Platz für die Firmware ist oder auch den anderen
> Kram, weiß ich nicht.
>
> du kann das auch in dem Verzeichnis nicht anzeigen.

Wäre auch verwunderlich - die Größenangaben für die "Files" sind reine
Phantasiewerte.

> ls -la zeigt aber die Größen der einzelnen Dateien in
> /sys/firmware/efi/efivars

Das wird auch nicht mehr Information liefern, auch wenn die recht
verläßlich ausschauen.
Was kommt denn bei Dir überhaupt 'raus? Weniger als 64KiB?

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Wed, 15 Nov 2023 14:46:13 +0100:

> > > 0000 habe ich gelöscht, da auf alter Platte.
> >
> > Würde ich nicht löschen sondern nur deaktivieren
> > (efibootmgr -A -b xxxx).
>
> Habe den gelöscht, damit ich freien platz auf den NVRAM bekomme.
> Er ist aber nach dem Neustart wieder da.

Natürlich, der referenziert ja auch Deine Systemplatte. Du könntest den
aber mal durch einen Eintrag für Deinen grub ersetzen und den gleich aktiv
schalten. Dann wirst Du nächstesmal wahrscheinlich, neben einem
unmittelbaren Start ins grub-Menü, einen weiteren Eintrag für Deine "rohe"
Systemplatte finden.
(Jetzt wollte ich hier mein "kleines" Skript zuzm Eintragen eines EFI-Boot-
Eintrags reinkopieren, und dabei ist das auch schon wieder an die 80 Zeilen
lang...
Deswegen hier nur ein Aufruf, der einen Record für einen einfachen grub-
Start für BootNum 0000 setzt:
efibootmgr --bootnum 0 --create --label Grub --loader "\EFI\grubx64.efi"
--disk /dev/<Bootdisk> --part 1
Vorsicht: Die "\" (Backslashes) _müssen genau so_ angegeben werden, da die
in den Eintrag geschrieben und vom UEFI-Lader ausgewertet werden. UEFI ist
da halt mal MS/DOS-lastig. Falls "BootNum0000" schon existiert, geht das
aber AFAIR schief, der Eintrag muß dann ggfs. _vorher_ erst gelöscht
werden. Ist halt alles bisserl "hemdsärmlig", das Zeugs... Achja:
"DISCLAIMER: You use everything aforementioned on your VERY OWN risk!")

> Da konnte ich auch grub-install & Co. nutzen.
> Ich habe aber nix im UEFI geändert. Sehr komisch das Ganze.

Vielleicht ist auf dem Mainboard das RAM für die EFI-Variablen etwas knapp
bemessen, und es kann nur zwei, drei Boot-Einträge?

[Marco Moock]

Am 15.11.2023 schrieb Sieghard Schicktanz <Sieghard....@SchS.de>:

> Hallo Marco,
>
> Du schriebst am Wed, 15 Nov 2023 14:46:13 +0100:
>
> > > > 0000 habe ich gelöscht, da auf alter Platte.
> > >
> > > Würde ich nicht löschen sondern nur deaktivieren
> > > (efibootmgr -A -b xxxx).
> >
> > Habe den gelöscht, damit ich freien platz auf den NVRAM bekomme.
> > Er ist aber nach dem Neustart wieder da.
>
> Natürlich, der referenziert ja auch Deine Systemplatte.

Nein, das war der für debian, ergo nicht die Systemplatte, sondern
explizit bei der Installation erstellt.
So einen muss man per Definition löschen können.

> > Da konnte ich auch grub-install & Co. nutzen.
> > Ich habe aber nix im UEFI geändert. Sehr komisch das Ganze.
>
> Vielleicht ist auf dem Mainboard das RAM für die EFI-Variablen etwas
> knapp bemessen, und es kann nur zwei, drei Boot-Einträge?

Dann hätte das Anlegen ja geklappt, nachdem ich den alten mit
efibootmgr gelöscht habe (was aber nicht wirksam war).

Ist alles sehr komisch und erklärt irgendwie, dass es mehrere Versuche
brauchte, bis da ein OS installiert war.

[Marco Moock]

Am 15.11.2023 schrieb Sieghard Schicktanz <Sieghard....@SchS.de>:

> Hallo Marco,
>
> Du schriebst am Wed, 15 Nov 2023 12:59:08 +0100:
>
> > > Die Booteinträge sollte die UEFI-Firmware automatisch eintragen
> > > sobald sie eine neue Platte und/oder EFI-Partition findet.

> [...]

>
> Doch, das tut die UEFI-Firmware durchaus, daraus wird ja das bei den
> meisten Main-Boards verfügbare Boot-Menü erstellt. Wenn der Stick dann
> beim nächsten Start nicht mehr da ist, wird der sogar (meistens?)
> wieder entfernt.

Das macht Sinn und passierte auch beim Debian-Eintrag, als ich die
SSD abgesteckt hatte, auf die der zeigte.

> > > Was sagt efibootmgr -v?
> >
> > root@srv1:~# efibootmgr -v
> > BootCurrent: 0000
> > No BootOrder is set; firmware will attempt recovery
> > root@srv1:~#
> >
> > 0000 habe ich gelöscht, da auf alter Platte.
>
> Könnte "ungünstig" sein, mußt Du jetzt über das Boot-Menü starten? Da
> könnte dieser spezielle "BOOTX64"-Eintrag nützlich bis notwendig sein.

War alles nicht notwendig, nach dem Neustart, war der alte Eintrag
wieder da und ich konnte alles wieder einrichten im laufenden System.

> > > > grub-install: warning: efivarfs_set_variable: writing to fd 6
> > > > failed: No space left on device. grub-install: warning:
> > > > _efi_set_variable_mode:
> > >
> > > Welches device?
> >
> > Ich vermute das NVRAM des EFI.
>
> Könnte sein, da scheint das UEFI-Zeugs in rechter
> MS-Apple-intel-IBM-Manier zu funktionieren, d.h. nie aufzuräumen, bis
> nix mehr geht.

Wo ist das bei IBM der Fall?

> > > Zum Manipulieren der EFI-Variablen fürs Booten ist efibootmgr da.
> > >
> >
> > Das kann aber sich nicht die MOK ändern, dafür gibt es mokutil. Das
> > tut
>
> Was ist "mokutil"? Kenn'ich nicht, habe ich hier nicht und gibt's für
> meine Distribution offenbar auch nicht. Ist das was spezielles für
> Deine Maschine?

https://www.linux.org/docs/man1/mokutil.html
Das ist um die MOK (machine owner key) zu ändern, damit man SecureBoot
mit eigenen Keys nutzten kann. Funktioniert natürlich nur auf
UEFI-Systemen und nur, wenn Secureboot unterstützt und aktiv ist.

> > aber nicht, weil SecureBoot nicht unterstützt wird (vermutlich nur
> > deaktiviert).
>
> Für SecureBoot? Naja, kann vielleicht sein, mein Brett hier ist auch
> schon ein paar Jahre alt...

Wenn es mit Win 8 ausgeliefert wurde, hat es SB. Kann aber ggf.
deaktiviert sein.

[Marco Moock]

Am 15.11.2023 schrieb Sieghard Schicktanz <Sieghard....@SchS.de>:

> Hallo Marco,
>
> Du schriebst am Wed, 15 Nov 2023 09:36:29 +0100:
>
> [efi-Variablen]
> > > > Kann man die bedenkenlos löschen (ich will kein SecureBoot
> > > > nutzen)?
> ...
> > Viele sind mit chattr +i geschützt.
> > Grund soll wohl sein, dass es nichtstandardisierte Variablen gibt,
> > die das MB bricken, wenn die gelöscht werden.
>
> Das sind zum einen sowieso keine regulären Dateien, das efivarfs ist
> ein _virtuelles_ Filesystem, für das ein Treiber die BIOS-Einträge in
> Dateiform zur Verfügung stellt. Daß da einige speziell geschützt
> sind, "dürfte seine Gründe haben".

Hat es, denn man kann da das MB bricken, wenn man Dinge ändert, die der
Hersteller nicht vorsieht. Ebenso können zu große Einträge für einen
Overflow sorgen, der dann andere Speicherbereiche überschreibt.
Das zumindest sagen Leute in Foren.

> Außerdem interessieren Dich die eigentlich (fast) alle garnicht, wenn
> Du einen _Boot_-Eintrag ändern willst - dafür sind nur die zuständig,
> die auch die Zeichenfolge "Boot" im Namen haben. Und um _die_ zu
> manipulieren, gibt es das spezielle Programm "efibootmgr" mit seinen
> Optionen. Das kann diese Boot-Einträge anlegen, aber auch löschen.

Alles richtig, doch da angeblich kein Speicherplatz mehr frei war,
wollte ich halt wissen, was den ausnutzt und ob man da was löschen kann.
Nach nem Neustart ging das dann wie von Zauberhand problemlos.

> > Ich hoffe, dass das klappt, sonst muss ich wohl versuchen, das
> > System auf BIOS-Boot umzustellen und das wird wegen der GPT-Tabelle
> > und der
>
> Mit "traditionellem" BIOS-Boot brauchst Du einen Kompatibilitäts-MBR,
> dann ist eine GPT auch kein Hindernis.

Das braucht aber eine zusätzliche Partition.
https://de.wikipedia.org/wiki/BIOS-Bootpartition

Ich weiß aber nicht, ob die auch am Ende sein darf und wenn die an den
Anfang muss, müssten die anderen beiden verschoben werden, was sicher
ewig dauern würde.
Ich bleibe daher beim EFI-Boot, da der jetzt funktioniert. :-)

> > dann nötigen bios_grub-Partition auch unschön. Oder ich lagere das
> > halt auf nen Stick aus, würde auch gehen.
>
> Naja, klar, warum direkt, wenn's auch umständlich geht...

Weil es grottige EFI-Implementierungen (wie meine hier) gibt.
Der Debian-Installer bietet daher auch die Option an, den ganzen
EFI-Kram auf nen Stick auszulagern, falls das eigene System bei der
Platte Mucken macht.

[Gerald E¡scher]

Sieghard Schicktanz schrieb am 15/11/2023 21:19:

> Das dürfte die relevante Angabe sein, aber das ist wahrscheinlich halt nur
> das Flash-EP_ROM_. Die EFI-Variablen sitzen aber in einem (gepufferten) RAM
> oder einem EEPROM. Ob das mit dem "size: 64KiB" gemeint sein könnte, wird
> aus der obigen Ausgabe nicht klar.

Die EFI-Variablen befinden sich im selben Flash-ROM wie die Firmware.
Lässt sich mit flashrom auslesen.

--
Gerald

[Gerald E¡scher]

Marco Moock schrieb am 15/11/2023 20:49:

> Am 15.11.2023 um 19:25:36 Uhr schrieb Gerald E¡scher:
>
>> Marco Moock schrieb am 15/11/2023 14:46:
>
>> > Habe den gelöscht, damit ich freien platz auf den NVRAM bekomme.
>> > Er ist aber nach dem Neustart wieder da.
>>
>> Das gehört so.
>
> Gehört das wirklich so, wenn man den mit dem efibootmgr entfernt?

Ich kenne es nicht anders. Platten, die beim Systemstart von der
Firmware gefunden werden, trägt sie, falls noch nicht vorhanden, in den
Bootmanager ein.

--
Gerald

[Marco Moock]

Am 15.11.2023 um 21:19:12 Uhr schrieb Sieghard Schicktanz:

> Das wird auch nicht mehr Information liefern, auch wenn die recht
> verläßlich ausschauen.
> Was kommt denn bei Dir überhaupt 'raus? Weniger als 64KiB?

Kann man das ls irgendwie zusammenfassen lassen?
Ich will da jetzt ungern ein Skript schreiben.

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Thu, 16 Nov 2023 09:07:00 +0100:

> > [efi-Variablen]

> > Das sind zum einen sowieso keine regulären Dateien, das efivarfs ist
> > ein _virtuelles_ Filesystem, für das ein Treiber die BIOS-Einträge in
> > Dateiform zur Verfügung stellt. Daß da einige speziell geschützt
> > sind, "dürfte seine Gründe haben".
>
> Hat es, denn man kann da das MB bricken, wenn man Dinge ändert, die der
> Hersteller nicht vorsieht.

Jaja, sowas geht mit anderen Einstellungen auch. Wenn Du was - absichtlich
oder aus Unkenntnis - so verstellst, daß was kaputtgeht oder sich
verklemmt, hast Du das auch geschafft, undoft ganz ohne "efi-Variablen".

> Ebenso können zu große Einträge für einen
> Overflow sorgen, der dann andere Speicherbereiche überschreibt.
> Das zumindest sagen Leute in Foren.

Sicher können Einträge vor anderen, die mit zu vielen Daten gefüllt werden,
dann die nachfolgenden überschreiben - je nachdem, wie gut die Software
(und der Benutzer), die den Eintrag macht (machen), da auf die Bereiche
aufpasst. Ungezieltes Herum-Patchen in Speicherbereichen kann vielerlei
"Effekte" bewirken. Kannst ja mal mit "dd" ein paar Blöcke in Deiner
Kernel-Datei ausnullen oder was anderes dort 'reinschreiben...

> > Außerdem interessieren Dich die eigentlich (fast) alle garnicht, wenn

...

> Alles richtig, doch da angeblich kein Speicherplatz mehr frei war,
> wollte ich halt wissen, was den ausnutzt und ob man da was löschen kann.

Die Intention war, klarzustellen, daß das für die Funktion Deiner Maschine
_benötigte_ Daten sein _könnten_, die besser in Ruhe zu lassen wären, von
den für den Boot-Vorgang vorgesehenen abgesehen.

> Nach nem Neustart ging das dann wie von Zauberhand problemlos.

Kaum, da mußt Du schon vorher was "geeignetes" angestellt haben. Und da
wäre es halt schon günstig, zu wissen, _was_ da "geeignet" war und was
damit bewirkt wurde, vor allem für Dich.

...

> > Mit "traditionellem" BIOS-Boot brauchst Du einen Kompatibilitäts-MBR,
> > dann ist eine GPT auch kein Hindernis.
>
> Das braucht aber eine zusätzliche Partition.
> https://de.wikipedia.org/wiki/BIOS-Bootpartition

Seit wann? Das ist ein völlig unhaltbares Gerücht, das noch nie richtig
war. _GERADE_ ein "BIOS-Boot" braucht _keine_ extra Partition. Sowas war
lediglich gelegentlich eine Krücke, um verkorkste BIOSse o.ä. zu umgehen.
Erst jett, mit dem "großartigen" (U)EFI, braucht der Boot-Vorgang eine
eigene Partition, weil dieses Supersystem auf seinem eigenen Filesystem
(FAT) besteht. BIOS-Boot ging mit allem, was Daten in definierten Block-
Sequenzen speichern konnte, jedenfalls für Linux. Auch FAT und NTFS u.ä.

> Ich weiß aber nicht, ob die auch am Ende sein darf und wenn die an den
> Anfang muss, müssten die anderen beiden verschoben werden, was sicher
> ewig dauern würde.

Bei BIOS-Boot muß halt der Kernel oder der Boot-Manager (grub, u.v.a.)
für die BIOS-Ladefunktion erreichbar sein. Kann die nicht die ganze Platte
ansprechen (was vorkam), muß da halt irgendwas gemauschelt werden, damit
das zu ladende Startprogramm im erreicbaren Bereich zu liegen kommt.

> Ich bleibe daher beim EFI-Boot, da der jetzt funktioniert. :-)

Ist für die nächste Zeit sowieso anzuraten. Und sooo kompliziert ist das
ja jetzt auch nicht, braucht nichtmal 'nen M(aster)B(oot)R(ecord).

...

> > Naja, klar, warum direkt, wenn's auch umständlich geht...
>
> Weil es grottige EFI-Implementierungen (wie meine hier) gibt.

EFI _ist_ grottig. Ein kastriertes Nicht-Ganz-Betriebssystem, um ein
Betriebssystem zu laden, oder erst noch einen Betriebssytem-Lader, der
dann in einem nochmal weiteren Schritt das Betriebssystem lädt...
Warum einfach, wenn's auch umständlich geht.

> Der Debian-Installer bietet daher auch die Option an, den ganzen
> EFI-Kram auf nen Stick auszulagern, falls das eigene System bei der
> Platte Mucken macht.

Und noch'ne neue Variante davon - wieviele Kringel werden da denn noch
drumrumgestrickt werden?
(Wann kommt der dedizierte Computer-Boot-Computer?)

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Thu, 16 Nov 2023 08:51:37 +0100:

> > > > > 0000 habe ich gelöscht, da auf alter Platte.

...

> > > Er ist aber nach dem Neustart wieder da.
> >
> > Natürlich, der referenziert ja auch Deine Systemplatte.
>
> Nein, das war der für debian, ergo nicht die Systemplatte, sondern
> explizit bei der Installation erstellt.

Dann doch für die Systemplatte, auch wenn vom Debian-Installer dafür
erstellt - aber meistens trägt ein EFI-BIOS die Platten auch nochmal
separat direkt ein.

> So einen muss man per Definition löschen können.

Löschen kannst Du alle. Aber das EFI-BIOS trägt die Platten halt trotzdem
beim nächsten Start wieder ein. Nur ist dann nicht sichergestellt, daß
damit ein Boot-Vorgang funktioniert.

...

> > Vielleicht ist auf dem Mainboard das RAM für die EFI-Variablen etwas
> > knapp bemessen, und es kann nur zwei, drei Boot-Einträge?
>
> Dann hätte das Anlegen ja geklappt, nachdem ich den alten mit
> efibootmgr gelöscht habe (was aber nicht wirksam war).

Vielleicht _hat_ das ja auch geklappt, Du hast das bloß nicht gemerkt?

> Ist alles sehr komisch und erklärt irgendwie, dass es mehrere Versuche
> brauchte, bis da ein OS installiert war.

Naja, halt der (gehässig ausgedrückt) "wissenschaftliche" Weg, durch Versuch
und Irrtum einen komplexen Vorgang so steuern zu können zu lernen, daß man
einen gewünschten Vorgang einigermaßen reproduzierbar hinkriegt...


Du schriebst am Thu, 16 Nov 2023 08:57:20 +0100:

> > Könnte "ungünstig" sein, mußt Du jetzt über das Boot-Menü starten? Da

...

> War alles nicht notwendig, nach dem Neustart, war der alte Eintrag
> wieder da und ich konnte alles wieder einrichten im laufenden System.

War das _sicher_ _der_ alte Eintrag, oder nur _ein_ neuer mit gleicher
Nummer? Ein solcher Boot-Eintrag kann nämlich schon ein paar Angaben
enthalten, _was_ da im einzelnen passieren soll.

...

> > Könnte sein, da scheint das UEFI-Zeugs in rechter
> > MS-Apple-intel-IBM-Manier zu funktionieren, d.h. nie aufzuräumen, bis
> > nix mehr geht.
>
> Wo ist das bei IBM der Fall?

Das nicht-Aufräumen? Na, IBM ist "Business Machines", und "Business" ist
Buchhaltung, und Buchhaltung räumt nicht auf, sondern archiviert, d.h.
"perpetuiert".

...

> https://www.linux.org/docs/man1/mokutil.html
> Das ist um die MOK (machine owner key) zu ändern, damit man SecureBoot

Ahja. Danke für die Information, das kannte ich noch nicht, weil ich das
hier nicht habe. Das scheint's bei meinem Brett (weit vor W8) noch nicht
gegeben zu haben, weswegen ich das nicht vermisst habe. Mich wundert da
allerdings, daß es das, weil inzwischen ja sicher recht verbreitet und
nötig, bei "meiner" Distribution nicht gibt. Allenfalls ist das irgendwo
anders drin versteckt...

[Sieghard Schicktanz]

Hallo Gerald,

Du schriebst am 16 Nov 2023 12:04:20 GMT:

> Die EFI-Variablen befinden sich im selben Flash-ROM wie die Firmware.
> Lässt sich mit flashrom auslesen.

Im _Flash_-EPROM? Grundsätzlich?

Ähh. Ungut. Mehr fällt mir dazu jetzt nicht mehr ein...

[Marcus Jodorf]

Marco Moock <mm+s...@dorfdsl.de> schrieb:

>> Die Booteinträge sollte die UEFI-Firmware automatisch eintragen
>> sobald sie eine neue Platte und/oder EFI-Partition findet.
>

> Wäre mir neu, denn dann müsste das bei jedem Stick auch passieren.

Du wirst lachen, aber bei meinen relativ neuen (ca. ein Jahr alt) UEFI
passiert genau das.
Wenn ich da in die Firmware und ins Bootmenu gehe, sehe ich neue
Booteinräge, für alles, was es bei Start gefunden hat. Inklusive allem
USB Zeugs, Thunderbolt und was sonst noch so gefunden wird.
Jedwedes USB Zeugs, das bootfähig ist, wird automatisch eingetragen.

UEFI ist mittelerweile steinalt - und da gibt es durchaus offenbar noch
Fortschritte in der Entwicklung. Bei den älteren meiner Rechner ist das
noch durchaus noch etwas primitiver.

Also wenn ich irgendwas mit USB und EFI beim Start einstöpsele und dann
in die Firmware gehe, dann ist das vorhanden. Und wenn ich das an Spitze
der Liste setze, dann wird schlicht davon gebootet.

Da ich das System von SSD oder SSD via Thunderbolt fahre, zeigt das
nebenbei auch mal wieder, wie idiotisch die Argumentation pro-systemd
damals war wegen angeblich schneller booten. Ich habe selten was im IT
Bereich erlebt, was so schnell von der Realität und vom technischen
Fortschritt überholt wurde. Also letzlich Idioten mit Tunnelblick am
Werk.


Gruß,

Marcus
⚂⚃

[Marcus Jodorf]

Marco Moock <mm+s...@dorfdsl.de> schrieb:

>>> Habe den gelöscht, damit ich freien platz auf den NVRAM bekomme.
>>> Er ist aber nach dem Neustart wieder da.
>>
>> Das gehört so.
>
> Gehört das wirklich so, wenn man den mit dem efibootmgr entfernt?

Jedes halbwegs modernere UEFI trägt automatisch wieder ein, was es beim
Hardwarescan findet. Völlig normal. Und genauso werden Einträge
entfernt, wenn die Hardware nicht mehr gefunden wird.




Gruß,

Marcus
⚂⚃

[Marco Moock]

Am 16.11.2023 um 20:21:56 Uhr schrieb Sieghard Schicktanz:

> Du schriebst am Thu, 16 Nov 2023 09:07:00 +0100:

> > Nach nem Neustart ging das dann wie von Zauberhand problemlos.
>
> Kaum, da mußt Du schon vorher was "geeignetes" angestellt haben. Und
> da wäre es halt schon günstig, zu wissen, _was_ da "geeignet" war und
> was damit bewirkt wurde, vor allem für Dich.

grub-install wurde erfolglos genutzt, manuell an den Variablen habe ich
aber nichts geändert.

> > > Mit "traditionellem" BIOS-Boot brauchst Du einen
> > > Kompatibilitäts-MBR, dann ist eine GPT auch kein Hindernis.
> >
> > Das braucht aber eine zusätzliche Partition.
> > https://de.wikipedia.org/wiki/BIOS-Bootpartition
>
> Seit wann? Das ist ein völlig unhaltbares Gerücht, das noch nie
> richtig war. _GERADE_ ein "BIOS-Boot" braucht _keine_ extra
> Partition.

Bei GPT-Tabellen braucht der BIOS-Boot die aber, denn da gibt es nicht
so viel freien Speicher, den man für GRUB braucht.
https://de.wikipedia.org/wiki/BIOS-Bootpartition

> Sowas war lediglich gelegentlich eine Krücke, um verkorkste BIOSse
> o.ä. zu umgehen. Erst jett, mit dem "großartigen" (U)EFI, braucht der
> Boot-Vorgang eine eigene Partition, weil dieses Supersystem auf
> seinem eigenen Filesystem (FAT) besteht.

Vorteil des Ganzen: Es ist endlich mal spezifiziert und es wird nicht
Zeug an eine vermeintlich ungenutzte Stelle geschrieben.
Schrottsoftware von Flexnet hat sowas auch mal gerne gemacht mit allen
Folgen. Da ist mir UEFI mit einer eigenen Partition lieber.

> BIOS-Boot ging mit allem, was Daten in definierten Block- Sequenzen
> speichern konnte, jedenfalls für Linux. Auch FAT und NTFS u.ä.

Der BIOS-Boot hat sich doch für die Dateisysteme gar nicht
interessiert. Da wurde der GRUB geladen und danach war es dem BIOS
egal, was passiert.

> > Ich weiß aber nicht, ob die auch am Ende sein darf und wenn die an
> > den Anfang muss, müssten die anderen beiden verschoben werden, was
> > sicher ewig dauern würde.
>
> Bei BIOS-Boot muß halt der Kernel oder der Boot-Manager (grub, u.v.a.)
> für die BIOS-Ladefunktion erreichbar sein. Kann die nicht die ganze
> Platte ansprechen (was vorkam), muß da halt irgendwas gemauschelt
> werden, damit das zu ladende Startprogramm im erreicbaren Bereich zu
> liegen kommt.

Das ist eine andere Sache und hat mit der BIOS-Bootpartition für GPT
nichts zu tun.

> > Ich bleibe daher beim EFI-Boot, da der jetzt funktioniert. :-)
>
> Ist für die nächste Zeit sowieso anzuraten. Und sooo kompliziert ist
> das ja jetzt auch nicht, braucht nichtmal 'nen M(aster)B(oot)R(ecord).

Leider ist UEFI öfter störanfälliger (gerade bei älteren
UEFI-Mainboards) als das BIOS.

> > > Naja, klar, warum direkt, wenn's auch umständlich geht...
> >
> > Weil es grottige EFI-Implementierungen (wie meine hier) gibt.
>
> EFI _ist_ grottig. Ein kastriertes Nicht-Ganz-Betriebssystem, um ein
> Betriebssystem zu laden, oder erst noch einen Betriebssytem-Lader, der
> dann in einem nochmal weiteren Schritt das Betriebssystem lädt...
> Warum einfach, wenn's auch umständlich geht.

Ist denn der BIOS-Boot mit seinem mehrstufigen System (weil Bootloader
halt heute etwas größer sind) weniger komplex?

Es ist wohl auch möglich, per UEFI ohne GRUB Linux zu starten. Wird
aber aus mir derzeit unbekannten Gründen noch nicht so praktiziert.

> > Der Debian-Installer bietet daher auch die Option an, den ganzen
> > EFI-Kram auf nen Stick auszulagern, falls das eigene System bei der
> > Platte Mucken macht.
>
> Und noch'ne neue Variante davon - wieviele Kringel werden da denn noch
> drumrumgestrickt werden?

So viele, wie es halt noch schrottige Implementierungen gibt.

[Marco Moock]

Am 16.11.2023 um 20:49:39 Uhr schrieb Sieghard Schicktanz:

> Du schriebst am Thu, 16 Nov 2023 08:57:20 +0100:

> > War alles nicht notwendig, nach dem Neustart, war der alte Eintrag
> > wieder da und ich konnte alles wieder einrichten im laufenden
> > System.

> War das _sicher_ _der_ alte Eintrag, oder nur _ein_ neuer mit gleicher
> Nummer? Ein solcher Boot-Eintrag kann nämlich schon ein paar Angaben
> enthalten, _was_ da im einzelnen passieren soll.

Der hieß debian und der neue auch. Es könnte aber auch sein, dass der
Schreibvorgang von grub-install erfolgreich war und das mit dem
Speicherplatz gar nicht stimmte und der trotzdem geschrieben wurde.
Mit dem kann ich aber booten und der zeigt auf den aktuellen Ort der
EFI-Partition.

> ...
> > > Könnte sein, da scheint das UEFI-Zeugs in rechter
> > > MS-Apple-intel-IBM-Manier zu funktionieren, d.h. nie aufzuräumen,
> > > bis nix mehr geht.
> >
> > Wo ist das bei IBM der Fall?
>
> Das nicht-Aufräumen? Na, IBM ist "Business Machines", und "Business"
> ist Buchhaltung, und Buchhaltung räumt nicht auf, sondern archiviert,
> d.h. "perpetuiert".

Trifft das auch auf die Betriebssysteme von IBM zu?
AIX läuft doch recht stabil.

> > https://www.linux.org/docs/man1/mokutil.html
> > Das ist um die MOK (machine owner key) zu ändern, damit man
> > SecureBoot
>
> Ahja. Danke für die Information, das kannte ich noch nicht, weil ich
> das hier nicht habe. Das scheint's bei meinem Brett (weit vor W8)
> noch nicht gegeben zu haben, weswegen ich das nicht vermisst habe.
> Mich wundert da allerdings, daß es das, weil inzwischen ja sicher
> recht verbreitet und nötig, bei "meiner" Distribution nicht gibt.

Das ist wohl einfach nicht installiert, weil es bei der Installation
keinen Bedarf gab. Wenn du ein System mit BIOS-Boot installierst, ist
das ganze EFI-Geraffel wie efibootmgr auch nicht installiert.

[Marco Moock]

Am 17.11.2023 um 05:11:59 Uhr schrieb Marcus Jodorf:

> Also wenn ich irgendwas mit USB und EFI beim Start einstöpsele und
> dann in die Firmware gehe, dann ist das vorhanden. Und wenn ich das
> an Spitze der Liste setze, dann wird schlicht davon gebootet.

Das ist ja nachvollziehbar, aber ich dachte, als ich das gelesen habe,
dass sowas dann dauerhaft im NVRAM gespeichert wird.

Dass das temporär beim Booten der Fall ist, ist ja normal (sonst wäre ja
kein USB-Boot möglich).

[Marcus Jodorf]

Marco Moock <mm+s...@dorfdsl.de> schrieb:

> Am 17.11.2023 um 05:11:59 Uhr schrieb Marcus Jodorf:
>
>> Also wenn ich irgendwas mit USB und EFI beim Start einstöpsele und
>> dann in die Firmware gehe, dann ist das vorhanden. Und wenn ich das
>> an Spitze der Liste setze, dann wird schlicht davon gebootet.
>
> Das ist ja nachvollziehbar, aber ich dachte, als ich das gelesen habe,
> dass sowas dann dauerhaft im NVRAM gespeichert wird.

Wird es hier. Wenn ein USB Device angestöpselt wird, dann taucht es in
der Boot Devices Liste in der Firmware auf und mit efibootmgr kann ich
dann sehen, daß es auch ins NVRAM gespeichert wurde.

> Dass das temporär beim Booten der Fall ist, ist ja normal (sonst wäre
> ja kein USB-Boot möglich).

Früher ging das meist nur über „one-time bootmenu“. Also man mußte
z.B. F12 drücken, damit nach neuen angeschlossenen Sachen gesucht wurde
und dann bekam man ein temporäres Bootmenu (ohne NVRAM Eintrag).
Ab da konnte man das Gefundene dann auch für die reguläre Bootliste
auswählen (oder gleich ganz manuell eingeben).

Bei neuerer Hardware kann ich beobachten, daß anscheinend immer neu
gescannt wird und Sachen automatisch in der regulären Bootliste
auftauchen, sobald sie gefunden werden.
Bei wievielen Herstellern das jetzt so gehandhabt wird, kann ich nicht
sagen. Aber mir ist es bisher bei zwei, drei neueren Geräten aufgefallen,
daß man nicht mehr extra das one-time bootmenu triggern muß, damit neue
Sachen gefunden werden, also ein Scan stattfindet.


Gruß,

Marcus
⚂⚃

[Gerald E¡scher]

Sieghard Schicktanz schrieb am 16/11/2023 20:51:

> Du schriebst am 16 Nov 2023 12:04:20 GMT:
>
>> Die EFI-Variablen befinden sich im selben Flash-ROM wie die Firmware.
>> Lässt sich mit flashrom auslesen.
>
> Im _Flash_-EPROM? Grundsätzlich?

Grundsätzlich nicht. Früher war's im batteriegepufferten CMOS-RAM.

> Ähh. Ungut. Mehr fällt mir dazu jetzt nicht mehr ein...

Warum? Hat den Vorteil, dass bei Tausch der Knopfzelle die
Einstellungen im UEFI-Setup erhalten bleiben und nur die Uhrzeit
verloren geht.
So jedenfalls bei einem Fujitsu von 2015, ich meine aber, dass dies von
Intel als Entwickler des UEFI vorgegeben wird.

Wenn es dich interessiert:
# flashrom -p internal --ifd -i bios -r bios.bin

In bios.bin finden sich dann die EFI-Variablen (in einem Hex-Betrachter
nach "BootOrder" suchen).

--
Gerald

[Sieghard Schicktanz]

Hallo Gerald,

Du schriebst am 17 Nov 2023 13:51:37 GMT:

[EFI-Variablen]

> > Im _Flash_-EPROM? Grundsätzlich?
>
> Grundsätzlich nicht. Früher war's im batteriegepufferten CMOS-RAM.

Und Du bist Dir sicher, daß das die Variablen _selber_, also _mit_ Wert,
sind und nicht nur Zeiger in ein batteriegepuffertes CMOS-RAM?

> > Ähh. Ungut. Mehr fällt mir dazu jetzt nicht mehr ein...
>
> Warum? Hat den Vorteil, dass bei Tausch der Knopfzelle die
> Einstellungen im UEFI-Setup erhalten bleiben und nur die Uhrzeit
> verloren geht.

Hast Du sowas schonmal fertiggebracht? Normalerweise hat _wenigstens_ die
RTC einen Pufferkondensator, der bei einem _Tausch_ (innerhalb von weniger
als Stunden) die Uhrzeit weiterlaufen lassen kann. Was verloren gehen kann,
ist der RAM-Inhalt, und auch der tut das meistens nur dann, wenn man die
dazu vorhandenen "Reset"-Pins kurzschließt und damit den Kondensator
explizit entlädt. Da geht dann auch die Uhrzeit verlustig.

> So jedenfalls bei einem Fujitsu von 2015, ich meine aber, dass dies von
> Intel als Entwickler des UEFI vorgegeben wird.

Zeiger, "erweiterte Zeiger" mit zugehörigen Symbol-Records, nehme ich Dir
ab, da kann ich mir auch gut vorstellen, daß das so gefordert wird -
irgendwo muß ja schließlich die Bezeichnung auch bekannt sein. Aber ich
würde trotzdem eher erwarten, daß der _Wert_ (aka Inhalt) der Variablen in
einem gepufferten RAM steht.

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Fri, 17 Nov 2023 07:17:44 +0100:

> > > Nach nem Neustart ging das dann wie von Zauberhand problemlos.

...

> grub-install wurde erfolglos genutzt, manuell an den Variablen habe ich
> aber nichts geändert.

Anscheinend hat das aber trotzdem Erfolg gehabt, es hat nur irgendwie
einen Fehler erkannt oder gemeldet bekommen - einen fehlerhaften Fehler,
anscheinend.

[BIOS-Boot]

> > > Das braucht aber eine zusätzliche Partition.

...

> > Seit wann? Das ist ein völlig unhaltbares Gerücht, das noch nie

...

> Bei GPT-Tabellen braucht der BIOS-Boot die aber, denn da gibt es nicht
> so viel freien Speicher, den man für GRUB braucht.

Dann legt man den grub halt in die Partition. Der BIOS-Lader muß nur ein
paar Blöcke (allerdings zusammenhängend) von einer festen Stelle aus lesen
können, wo die genau liegen, ist ihm egal. Der könnte im Prinip auch gleich
den Kernal laden, aber da ist wohl die ladbare Größe nicht ausreichend und
noch die eine oder andere Unzulänglichkeit vorhanden.

...

> > o.ä. zu umgehen. Erst jett, mit dem "großartigen" (U)EFI, braucht der
> > Boot-Vorgang eine eigene Partition, weil dieses Supersystem auf
> > seinem eigenen Filesystem (FAT) besteht.
>
> Vorteil des Ganzen: Es ist endlich mal spezifiziert und es wird nicht
> Zeug an eine vermeintlich ungenutzte Stelle geschrieben.

Soweit schon, aber daß da "Zeug an eine vermeintlich ungenutzte Stelle
geschrieben" wurde, war halt auch eine Krücke zum Stützen der Krücke, daß
die BIOSse die immer größer werdenden Platten immer wieder mal nicht voll
nutzen konnten. Das war halt nie vorgesehen für solche Datenmengen...

...

> Der BIOS-Boot hat sich doch für die Dateisysteme gar nicht
> interessiert. Da wurde der GRUB geladen und danach war es dem BIOS
> egal, was passiert.

Nein, dem BIOS war das schon viel früher egal. Dem war es schon egal, _was_
da überhaupt geladen wurde, das BIS hat nur den MBR geladen und ausgeführt.
Was dann der (Code im) MBR gemacht hat, war schon egal. Der LILO hat dann
halt gleich den Kernel geholt, die erste Stufe vom grub dessen Menüsystem -
auch schon ein halbes Betriebssystem - und DOS und ältere Windows haben
gleich das System geladen. Windows hat AFAIK erst mit "2000" noch eine
Zwischenstufe gekriegt.

> > Bei BIOS-Boot muß halt der Kernel oder der Boot-Manager (grub, u.v.a.)
> > für die BIOS-Ladefunktion erreichbar sein. Kann die nicht die ganze

...

> Das ist eine andere Sache und hat mit der BIOS-Bootpartition für GPT
> nichts zu tun.

Doch, hat es. Hat es deswegen, weil GPT anders organisiert ist und i.a.
die Platten größer als die ("historisch gewachsenen") BIOS-Funktionen
ansprechen können. Dazu wurde halt eine "klein" Partition am Anfang des
Datenbereichs als "Sicherheitsbereich" eingeführt, damit das BIOS auch
alles schön im Griff behielte.

...

> Leider ist UEFI öfter störanfälliger (gerade bei älteren
> UEFI-Mainboards) als das BIOS.

Kann ich nicht beurteilen - ich habe mir meine EFI-Bretter so ausgesucht,
daß das EFI auch sinnvoll nutzbar ist. Beim letzten allerdings hatte ich
mal einen alternativen Hersteller probieren wollen (weil gesagt worden war,
daß das kein Problem wäre), und bin damit auf die Schnauze gefallen. Aber
glücklicherweise hat sich das Brett sehr schnell verabschiedet, irgendein
Defekt, und ich bin's wieder losgeworden. Nachfolger ist diese ASUS, äh,
Manufacturer: "ASUSTeK COMPUTER INC."
Product: "PRIME B350-PLUS"
Version: "Rev X.0x"
Das kann die EFI-Partition direkt ansprechen und auch Software von der
laden, die kein Systemkernel ist. "Sollte" allgemein so gehen, habe ich
aber bisher anderweitig noch nicht verifizieren können.

...

> > EFI _ist_ grottig. Ein kastriertes Nicht-Ganz-Betriebssystem, um ein

...

> Ist denn der BIOS-Boot mit seinem mehrstufigen System (weil Bootloader
> halt heute etwas größer sind) weniger komplex?

Viel weniger. Das mehrstufige System ist ja nicht Teil des BIOS, sondern
Teil der Boot-Lader oder System-Kernel. Aber das alte BIOOS ist halt recht
früh zu eng geworden, immer wieder und weiter ausgebaut und aufgebauscht,
und damit zu einem Dickicht an Erweiterungen geworden, das halt mit EFI -
"endlich" - bereinigt werden sollte. Was auch nicht ganz gelungen zu sein
scheint...

> Es ist wohl auch möglich, per UEFI ohne GRUB Linux zu starten. Wird
> aber aus mir derzeit unbekannten Gründen noch nicht so praktiziert.

Das _ist_ möglich und wird vom Kernel soagr direkt unterstützt. Mit
mehreren Boot-Einträgen in der EFI-Tabelle könnte man sogar eine Auswahl
einrichten, aber die Flexibilität vn grub, der ja dann doch im Genesatz
zum EFI das Linux-Filesystem kennt, ist damit halt doch nicht gegeben. Das
wäre dann etwa auf der Stufe des alten LILO, und den will offenbar keiner
mehr zurück.

...

> > Und noch'ne neue Variante davon - wieviele Kringel werden da denn noch
> > drumrumgestrickt werden?
>
> So viele, wie es halt noch schrottige Implementierungen gibt.

Ne, das war damit garnicht gemeint, da war eher gemeint, wieviele Schalen
von Hilfssoftware zur "leichteren Nutzung", "Benutzerfreundlichkeit" oder
"Automatisierung" es noch geben könnte, nachdem ja mit EFI und grub
schonmal 2 Ebenen unter jedem System-Kernel liegen, die schon einen guten
Teil von dessen Funktionen enthalten. Jetzt kommt vielleicht als nächstes
ein KI-Programm über den grub, das selbständig den zu ladenden Kernel
aussucht, und das kriegt dann einen internet-Anschluß zum Händie des
(erwarteten) Benutzers, das dessen aktuelle "Stimmung" meldet, und ...
naja, der Benutzer kriegt halt immer weniger zu sagen.

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Thu, 16 Nov 2023 20:30:48 +0100:

> > Was kommt denn bei Dir überhaupt 'raus? Weniger als 64KiB?
>
> Kann man das ls irgendwie zusammenfassen lassen?
> Ich will da jetzt ungern ein Skript schreiben.

Kein Tabellenkalkulator verfügbar?
Wenn doch: "ls -l | xclip -i" oder Ausgabe markieren, copieren und in
Tabellenkalkulator pasten, wo er dann spaltenweise geordnet erscheinen
oder eintragbar angeboten werden sollte, und dann die Spalte mit den Größen
aufsummieren -> Gesamtspeicherbelegungswert als untere Grenze des Bedarfs.
Hab' ich so gemacht und was in der Gegend von 48KB bei meiner Kiste
'rausgekriegt. Das passte also gut in 64KB "NV"RAM.

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Fri, 17 Nov 2023 07:22:55 +0100:

> > War das _sicher_ _der_ alte Eintrag, oder nur _ein_ neuer mit gleicher

...

> Der hieß debian und der neue auch. Es könnte aber auch sein, dass der
> Schreibvorgang von grub-install erfolgreich war und das mit dem
> Speicherplatz gar nicht stimmte und der trotzdem geschrieben wurde.

Ich würde da doch stark vermuten, daß dasso passiert sein dürfte...

...

> > > Wo ist das bei IBM der Fall?
> >
> > Das nicht-Aufräumen? Na, IBM ist "Business Machines", und "Business"

...

> Trifft das auch auf die Betriebssysteme von IBM zu?
> AIX läuft doch recht stabil.

Kann ich nix zu sagen, weil ich nix damit zu tun habe. Aber "aufgeräumt"
wurde da doch eher schon lange nix mehr, ganz im Gegensatz zum OS/2, das
recht gründlich "aufgeräumt" wurde...

[MOK (machine owner key)]

> Das ist wohl einfach nicht installiert, weil es bei der Installation
> keinen Bedarf gab. Wenn du ein System mit BIOS-Boot installierst, ist
> das ganze EFI-Geraffel wie efibootmgr auch nicht installiert.

Nein, es ist - wenn nicht versteckt - bei meiner Distribution einfach
nicht vorhanden. Und nicht nur "damals". als ich mein Brett neu
einrichtete, sondern auch jetzt in den neuesten Up-Dates.

[Marco Moock]

Am 17.11.2023 um 21:40:26 Uhr schrieb Sieghard Schicktanz:

> Nein, es ist - wenn nicht versteckt - bei meiner Distribution einfach
> nicht vorhanden. Und nicht nur "damals". als ich mein Brett neu
> einrichtete, sondern auch jetzt in den neuesten Up-Dates.

Slackware hat auch den efibootmgr:
https://packages.slackware.com/?r=slackware-current&p=efibootmgr-20191011_e8ce9fe-i586-4.txz

Musst du halt installieren.

[Gerald E¡scher]

Sieghard Schicktanz schrieb am 17/11/2023 20:46:

> Du schriebst am 17 Nov 2023 13:51:37 GMT:
>
> [EFI-Variablen]
>> > Im _Flash_-EPROM? Grundsätzlich?
>>
>> Grundsätzlich nicht. Früher war's im batteriegepufferten CMOS-RAM.
>
> Und Du bist Dir sicher, daß das die Variablen _selber_, also _mit_ Wert,
> sind und nicht nur Zeiger in ein batteriegepuffertes CMOS-RAM?

Ja.

>> > Ähh. Ungut. Mehr fällt mir dazu jetzt nicht mehr ein...
>>
>> Warum? Hat den Vorteil, dass bei Tausch der Knopfzelle die
>> Einstellungen im UEFI-Setup erhalten bleiben und nur die Uhrzeit
>> verloren geht.
>
> Hast Du sowas schonmal fertiggebracht?

Ja, bisher bei jedem Tausch der Knopfzelle.

> Normalerweise hat _wenigstens_ die
> RTC einen Pufferkondensator, der bei einem _Tausch_ (innerhalb von weniger
> als Stunden) die Uhrzeit weiterlaufen lassen kann.

Mag sein, meine Rechner auf PC-Basis sind nicht die allerneuesten und
Apple verwendet ohnehin langlebigere Knopfzellen, die musste ich sogar
in meinem MacBook von 2007 noch nicht tauschen.

>> So jedenfalls bei einem Fujitsu von 2015, ich meine aber, dass dies von
>> Intel als Entwickler des UEFI vorgegeben wird.
>
> Zeiger, "erweiterte Zeiger" mit zugehörigen Symbol-Records, nehme ich Dir
> ab,

Ich habe geschrieben, wie sich das Flash-ROM auslesen lässt. Wenn du das
nicht möchtest, dein Problem.

> da kann ich mir auch gut vorstellen, daß das so gefordert wird -
> irgendwo muß ja schließlich die Bezeichnung auch bekannt sein. Aber ich
> würde trotzdem eher erwarten, daß der _Wert_ (aka Inhalt) der Variablen in
> einem gepufferten RAM steht.

Im Flash-ROM stehen die selben Strings, die efibootmgr ausgibt. Zeiger
auf ein RAM sehen anders aus.

--
Gerald

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Sat, 18 Nov 2023 10:16:17 +0100:

> > Nein, es ist - wenn nicht versteckt - bei meiner Distribution einfach
> > nicht vorhanden. Und nicht nur "damals". als ich mein Brett neu

...

> Slackware hat auch den efibootmgr:

Sicher, weiß ich.

> Musst du halt installieren.

Womit, meinst Du, habe ich meinen Boot-Vorgang denn konfiguriert?
Natürlich, _genau_ mit dem efibootmgr: Von slackware. Und da gibt's keine
Spur von irgendwelchen "mok"-irgendwas. Auch nicht bei den Programmen für
den Zugriff auf die efivars. Wo hast Du die da gesehen?

[Marco Moock]

Am 18.11.2023 um 19:56:24 Uhr schrieb Sieghard Schicktanz:

> Natürlich, _genau_ mit dem efibootmgr: Von slackware. Und da gibt's
> keine Spur von irgendwelchen "mok"-irgendwas. Auch nicht bei den
> Programmen für den Zugriff auf die efivars. Wo hast Du die da gesehen?

Slackware macht das wohl anders, SecureBoot geht da aber auch:

https://docs.slackware.com/howtos:security:enabling_secure_boot

[Sieghard Schicktanz]

Hallo Gerald,

Du schriebst am 18 Nov 2023 15:49:04 GMT:

> > [EFI-Variablen]

> > Und Du bist Dir sicher, daß das die Variablen _selber_, also _mit_ Wert,
> > sind und nicht nur Zeiger in ein batteriegepuffertes CMOS-RAM?
>
> Ja.

Das muß ich jetzt doch mal nachprüfen, anschließend.

> >> > Ähh. Ungut. Mehr fällt mir dazu jetzt nicht mehr ein...
> >>
> >> Warum? Hat den Vorteil, dass bei Tausch der Knopfzelle die
> >> Einstellungen im UEFI-Setup erhalten bleiben und nur die Uhrzeit
> >> verloren geht.
> >
> > Hast Du sowas schonmal fertiggebracht?
>
> Ja, bisher bei jedem Tausch der Knopfzelle.

Das ist genau das Gegenteil dessen, was ich kenne undwas bei solchen
Schaltungen vorgesehen und beabsichtigt ist.
...

> Mag sein, meine Rechner auf PC-Basis sind nicht die allerneuesten und
> Apple verwendet ohnehin langlebigere Knopfzellen, die musste ich sogar
> in meinem MacBook von 2007 noch nicht tauschen.

Oder ist das eine Apple-Spezialität? _Die_ kenne ich - dann
glücklicherweise - garnicht. Bei den Kisten, die ich kenne - alles
_keine_ Apples - passiert das nicht, daß da immer die Uhrzeit verloren
geht, nichtmal dann, wenn schon die BIOS-Daten "angefressen" waren. Erst
wenn da _garnichts_ mehr passt, die Spannung kaum noch 2V beträgt, dann
geht auch die Uhr aus.

...

> Ich habe geschrieben, wie sich das Flash-ROM auslesen lässt. Wenn du das
> nicht möchtest, dein Problem.

Was heißt hier "nicht möchtest"? Erstmal muß ich _können_, und das geht
nicht ohne weiteres:

$ sudo flashrom -p internal --ifd -i bios -r bios.bin
sudo: flashrom: command not found

Muß ich also erstmal installieren. Anschließend.

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Sat, 18 Nov 2023 20:38:30 +0100:

> Slackware macht das wohl anders, SecureBoot geht da aber auch:

Ja, Danke. Will ich aber garnicht, brauch' ich auch nicht, mangels eines
derartiges fordernden Betriebssystems.
Aber trotzdem wohl gut zu wissen.

[Sieghard Schicktanz]

Hallo Gerald,

Du schriebst am 18 Nov 2023 15:49:04 GMT:

> > Und Du bist Dir sicher, daß das die Variablen _selber_, also _mit_ Wert,
> > sind und nicht nur Zeiger in ein batteriegepuffertes CMOS-RAM?
>
> Ja.
>
> >> > Ähh. Ungut. Mehr fällt mir dazu jetzt nicht mehr ein...

...

> Im Flash-ROM stehen die selben Strings, die efibootmgr ausgibt. Zeiger
> auf ein RAM sehen anders aus.

Nachdem ich das jetzt nachgeprüft habe, muß ich Dir recht geben. Ich bleibe
aber bei meiner Einschätzung, daß das "ungut" ist.

Sicher hat das für den Hersteller den "Vorteil", daß damit bei einer
Aktualisierung die Einstellungen prinzipiell auf die bekannten Werks-Werte
zurückgesetzt werden. Für den Benutzer hat das gleichzeitig den _Nachteil_,
daß damit alle seine darüber gemachten Einstellunge - insbes. auch
bezüglich des Systemstarts ("Boot") _verlorengehen_, was u.U. heißen
könnte, daß anschließend sein - ansonsten korrekt laufendes! - System nicht
mehr startet.
Da ist dann wohl das "eine Prozent" von Benutzern betroffen, die nicht die
(von den) "Industrie-Standard"-Sachen betreiben (betrieben werden).
Ungut, und nicht einmal wegen der begrenzten Schreibzyklen. Die sollten bei
seriellen Flash-EPROMs für alles ausreichen, was halbwegs sinnvoll ist.

[Gerald E¡scher]

Sieghard Schicktanz schrieb am 18/11/2023 20:58:

> Du schriebst am 18 Nov 2023 15:49:04 GMT:
>

>> Mag sein, meine Rechner auf PC-Basis sind nicht die allerneuesten und
>> Apple verwendet ohnehin langlebigere Knopfzellen, die musste ich sogar
>> in meinem MacBook von 2007 noch nicht tauschen.
>
> Oder ist das eine Apple-Spezialität?

Die langlebigen Knopfzellen? Es sind Lithiumzellen BRxxxx drin, die
haben noch weniger Selbstentladung als die üblichen CRxxxx.

> _Die_ kenne ich - dann
> glücklicherweise - garnicht. Bei den Kisten, die ich kenne - alles
> _keine_ Apples - passiert das nicht, daß da immer die Uhrzeit verloren
> geht,

Keine Ahnung, ob bei Macs díe Uhrzeit verloren geht. Wie gesagt, habe
ich bei denen noch nie die Knopfzelle tauschen müssen.
Aber ich habe nun bei meiner Linux-Kiste (MB Fujitsu D3222) die
Knopfzelle gegen eine BR2032 getauscht, in der Hoffnung, dass ich die
nie wieder angreifen muss und wie erwartet
"POST - Invalid date/time".
Die Einstellungen im Firmware-Setup sind dabei erhalten geblieben.

--
Gerald

[Gerald E¡scher]

Sieghard Schicktanz schrieb am 18/11/2023 23:09:

> Du schriebst am 18 Nov 2023 15:49:04 GMT:
>

>> Im Flash-ROM stehen die selben Strings, die efibootmgr ausgibt. Zeiger
>> auf ein RAM sehen anders aus.
>
> Nachdem ich das jetzt nachgeprüft habe, muß ich Dir recht geben. Ich bleibe
> aber bei meiner Einschätzung, daß das "ungut" ist.
>
> Sicher hat das für den Hersteller den "Vorteil", daß damit bei einer
> Aktualisierung die Einstellungen prinzipiell auf die bekannten Werks-Werte
> zurückgesetzt werden. Für den Benutzer hat das gleichzeitig den _Nachteil_,
> daß damit alle seine darüber gemachten Einstellunge - insbes. auch
> bezüglich des Systemstarts ("Boot") _verlorengehen_,

Warum? Das Flash-Programm kann vor dem Flashen die Einstellungen
auslesen und gemeinsam mit der neuen Firmware ins Flash-ROM schreiben.
Ob es so war, wie ich die Firmware aktualisiert habe, weiß ich nicht
mehr, aber die Motherboard-Hersteller würden sich sehr unbeliebt machen,
wenn nach einem Firmware-Update alle Einstellungen weg wären bis hin,
dass der Rechner nicht mehr bootet.


--
Gerald

[Sieghard Schicktanz]

Hallo Gerald,

Du schriebst am 20 Nov 2023 12:06:20 GMT:

> > Oder ist das eine Apple-Spezialität?
>
> Die langlebigen Knopfzellen? Es sind Lithiumzellen BRxxxx drin, die

Nein, die fehlende Pufferung der Uhrzeitdaten.

...

> Aber ich habe nun bei meiner Linux-Kiste (MB Fujitsu D3222) die
> Knopfzelle gegen eine BR2032 getauscht, in der Hoffnung, dass ich die
> nie wieder angreifen muss und wie erwartet
> "POST - Invalid date/time".

Du hast da offenbar eine ganz besondere Technik. Anscheinend drückst Du
beim Wechsel immer die Kontakte der Halterung gegeneinander.

> Die Einstellungen im Firmware-Setup sind dabei erhalten geblieben.

Wenn das ein EFI-System mit Flash-EPROM-residenten Variablen ist, sollte
das so der Fall sein. (Vielleicht wurde das auch so geändert, damit bei
anderen Benutzern nicht immer alle Einstellungen verloren gehen, wenn die
Pufferzelle getauscht werden muß. Was sowieso nur selten der Fall sein
sollte, da die eigentlich nur dann belastet wird, wenn die Maschine ohne
Stromversorgung steht.)

[Sieghard Schicktanz]

Hallo Gerald,

Du schriebst am 20 Nov 2023 12:30:35 GMT:

> Warum? Das Flash-Programm kann vor dem Flashen die Einstellungen
> auslesen und gemeinsam mit der neuen Firmware ins Flash-ROM schreiben.

Könnte es, sicher. Tut es das?

> Ob es so war, wie ich die Firmware aktualisiert habe, weiß ich nicht
> mehr, aber die Motherboard-Hersteller würden sich sehr unbeliebt machen,
> wenn nach einem Firmware-Update alle Einstellungen weg wären bis hin,
> dass der Rechner nicht mehr bootet.

Davon dürften nur wenige Benutzer überhaupt was mitkriegen, die halt, die
an diesen Einstellungen überhaupt "gedreht" haben. Mit guter Sicherheit
praktisch keine Windows-Benutzer, und bei funktionierendem "SecureBoot"
durch das Installations-Programm auch nicht extrem viele Benutzer anderer
Betriebssysteme. Zudem ist das doch "aus Sicherheitsgründen" sowieso nicht
ratsam?

[Marco Moock]

Am 20.11.2023 um 21:18:20 Uhr schrieb Sieghard Schicktanz:

> Was sowieso nur selten der Fall sein sollte, da die eigentlich nur
> dann belastet wird, wenn die Maschine ohne Stromversorgung steht.)

Gehen diese Zellen nicht nach einer gewissen Zeit einfach kaputt bzw.
entladen sich selbst?

[Sieghard Schicktanz]

Hallo Marco,

Du schriebst am Tue, 21 Nov 2023 08:27:32 +0100:

> > Was sowieso nur selten der Fall sein sollte, da die eigentlich nur
> > dann belastet wird, wenn die Maschine ohne Stromversorgung steht.)
>
> Gehen diese Zellen nicht nach einer gewissen Zeit einfach kaputt bzw.
> entladen sich selbst?

Nach einer "gewissen Zeit" sicherlich. Aber die ist bei Li-(Primär-)Zellen
durchaus recht lang, immerhin geben da sogar die Hersteller Mindestdauern
von 5 Jahren und mehr an - da kann man durchaus davon ausgehen, daß die das
vorher mal geprüft haben. Natürlich hängt das auch von den Umständen ab,
die Zelle in einem PC, der in einem Backhaus bei dauernd >33°C oder in
einer Gießerei mit vielleicht noch höhern Temeraturen steht, wird nicht
so lange durchhalten wie in einem gut klimatisierten Büro. Aber wirklich
leer werden die Zellen praktisch nur dann, wenn der PC lange ausgeschaltet
herumsteht.