Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.hardware.misc > #33272 > unrolled thread

arm64 Bootprozess

Back to article view | Back to de.comp.hardware.misc

Contents

  arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-07 21:00 +0200
    Re: arm64 Bootprozess Kay Martinen <usenet@martinen.de> - 2026-08-07 23:12 +0200
      Re: arm64 Bootprozess Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-08 08:48 +0200
        Re: arm64 Bootprozess Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2026-08-08 19:15 +0000
          Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-09 09:12 +0200
            Re: arm64 Bootprozess Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2026-08-10 18:12 +0000
      Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-08 11:21 +0200
        Re: arm64 Bootprozess Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-08 12:25 +0200
          Re: arm64 Bootprozess Ralph Aichinger <ra@h5.or.at> - 2026-08-08 12:05 +0000
            Re: arm64 Bootprozess Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-08 14:36 +0200
              Re: arm64 Bootprozess Kay Martinen <usenet@martinen.de> - 2026-08-08 15:05 +0200
                Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-08 17:18 +0200
                Re: arm64 Bootprozess Ralph Aichinger <ra@h5.or.at> - 2026-08-08 15:37 +0000
        Re: arm64 Bootprozess Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-08-08 14:25 +0200
          Re: arm64 Bootprozess Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-08 14:37 +0200
            Re: arm64 Bootprozess Kay Martinen <usenet@martinen.de> - 2026-08-08 14:55 +0200
              Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-08 17:19 +0200
            Re: arm64 Bootprozess Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-08-09 14:17 +0200
          Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-08 17:20 +0200
            Re: arm64 Bootprozess Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-08-09 14:22 +0200
              Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-09 17:50 +0200
                Re: arm64 Bootprozess Kay Martinen <usenet@martinen.de> - 2026-08-09 18:26 +0200
                  Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-10 16:37 +0200
                    Re: arm64 Bootprozess Kay Martinen <usenet@martinen.de> - 2026-08-10 19:37 +0200
              Re: arm64 Bootprozess Kay Martinen <usenet@martinen.de> - 2026-08-09 18:08 +0200
                Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-10 16:39 +0200
                  Re: arm64 Bootprozess Kay Martinen <usenet@martinen.de> - 2026-08-10 19:19 +0200
                    Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-10 20:24 +0200
    Re: arm64 Bootprozess Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-08 08:44 +0200
      Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-08 12:24 +0200
      Re: arm64 Bootprozess Kay Martinen <usenet@martinen.de> - 2026-08-08 14:46 +0200
        Re: arm64 Bootprozess Marco Moock <mm@dorfdsl.de> - 2026-08-08 17:15 +0200
      Re: arm64 Bootprozess Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2026-08-08 19:05 +0000

Page 1 of 2  [1] 2  Next page →

#33272 — arm64 Bootprozess

Hallo zusammen!

arm64-Systeme gibt es von verschiedenen Herstellern und auch einige 
Hoster (z.B. Hetzner) bieten VPS damit an.

Wie genau ist da der Bootprozess?
Gibt es ein BIOS oder UEFI, mit dem man den Bootprozess steuert?

-- 
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de

[toc] | [next] | [standalone]

#33273

Am 07.08.26 um 21:00 schrieb Marco Moock:

> arm64-Systeme gibt es von verschiedenen Herstellern und auch einige 
> Hoster (z.B. Hetzner) bieten VPS damit an.
> 
> Wie genau ist da der Bootprozess?
> Gibt es ein BIOS oder UEFI, mit dem man den Bootprozess steuert?

Wie beim PC wohl eher nicht, und wenn geht das meineslesens nach eher in 
richtung coreboot o.ä.

Nicht vom Raspberry Pi auf andere Arm-Systeme schließen. Beim Rpi bootet 
wohl erst der Grafikkern und zieht dann die eigentliche CPU hoch. 
Firmware, ja aber auch nichts PC-bekanntes.

Aber das wissen vielleicht andere genauer. Ich hab nur PCs und ein paar 
Rpi's. Bei letzteren Funktioniert z.b. der "Affengriff" nicht zum Reboot 
auslösen.

BIOS/UEFI sind doch prinzipiell auch eine Historisch gewachsene 
Kompatibilitäts-Krücke. Deren Fehler muß man auf einer neueren/anderen 
Plattform ja nicht wiederholen.

Suchst du eigentlich vielleicht nur danach wo/wann/wie die arm-Firmware 
an einen OS-Lader übergibt?

Bye/
   /Kay

-- 
Posted via Leafnode

[toc] | [prev] | [next] | [standalone]

#33275

Kay Martinen <usenet@martinen.de> wrote:
>Nicht vom Raspberry Pi auf andere Arm-Systeme schließen. Beim Rpi bootet 
>wohl erst der Grafikkern und zieht dann die eigentliche CPU hoch. 
>Firmware, ja aber auch nichts PC-bekanntes.

Ja, das ist richtig. Die Raspi-Firmware liegt dabei auf einer
FAT-Partition auf dem ersten Medium. Dort liegt auch eine config.txt
und noch ein paar andere Konfigurationsdateien, mit denen man den
Bootprozess steuern kann.

Über die config.txt kann direkt einen Linux-Kernel booten. Es gibt
aber auch noch andere Methoden, wie z.B. ein u-boot, das scriptbar
verschiedene Dinge, wie z.B. Linux booten kann. Neuere
u-boot-Versionen können aber auch eine EFI-Umgebung schaffen, in der
dann ein handelsüblicher grub-efi-arm64 laufen kann, weiter geht es
dann wie vom Desktop gewöhnt.

Dreimal dürft Ihr raten wie ich meine Raspis boote.

>Aber das wissen vielleicht andere genauer. Ich hab nur PCs und ein paar 
>Rpi's. Bei letzteren Funktioniert z.b. der "Affengriff" nicht zum Reboot 
>auslösen.

Der Affengriff ist ja auch originär PC-Gebastel.

>BIOS/UEFI sind doch prinzipiell auch eine Historisch gewachsene 
>Kompatibilitäts-Krücke. Deren Fehler muß man auf einer neueren/anderen 
>Plattform ja nicht wiederholen.

Wie soll man das sonst machen? Natürlich ist das PC-BIOS zu Recht
gestorben, aber UEFI finde ich schonmal gar nicht so verkehrt und ich
freue mich darüber dass sich das langsam auch auf arm durchsetzt. Ich
denke da hat Apple nicht unerheblich Anteil daran.

>Suchst du eigentlich vielleicht nur danach wo/wann/wie die arm-Firmware 
>an einen OS-Lader übergibt?

Das ist hochgradig systemabhängig.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#33293

Marc Haber schrieb am 8/8/2026 08:48:

> Wie soll man das sonst machen? Natürlich ist das PC-BIOS zu Recht
> gestorben, aber UEFI finde ich schonmal gar nicht so verkehrt und ich
> freue mich darüber dass sich das langsam auch auf arm durchsetzt. Ich
> denke da hat Apple nicht unerheblich Anteil daran.

Ja. Intel Macs verwendeten von Anfang an (ab 2006!) UEFI. Bei den arm64
Macs sind sie allerdings zu iBoot von iOS gewechselt.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#33294

Am 08.08.26 um 21:15 schrieb Gerald E¡scher:
> Marc Haber schrieb am 8/8/2026 08:48:
> 
>> Wie soll man das sonst machen? Natürlich ist das PC-BIOS zu Recht
>> gestorben, aber UEFI finde ich schonmal gar nicht so verkehrt und ich
>> freue mich darüber dass sich das langsam auch auf arm durchsetzt. Ich
>> denke da hat Apple nicht unerheblich Anteil daran.
> 
> Ja. Intel Macs verwendeten von Anfang an (ab 2006!) UEFI. Bei den arm64
> Macs sind sie allerdings zu iBoot von iOS gewechselt.

Wie funktioniert das?

-- 
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#33304

Marco Moock schrieb am 9/8/2026 09:12:

> Am 08.08.26 um 21:15 schrieb Gerald E¡scher:
>> 
>> Ja. Intel Macs verwendeten von Anfang an (ab 2006!) UEFI. Bei den arm64
>> Macs sind sie allerdings zu iBoot von iOS gewechselt.
>
> Wie funktioniert das?

Davon bekommt man als Anwender nichts mit. Man kam auch bei den
Intel-Macs nicht ins Setup vom UEFI, jedenfalls wüsste ich nicht wie.
Einen Bootmanager gibt es natürlich oder man konnte rEFInd
installieren, das läuft auch auf PCs.
https://sourceforge.net/projects/refind/

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#33276

Am 07.08.26 um 23:12 schrieb Kay Martinen:

> BIOS/UEFI sind doch prinzipiell auch eine Historisch gewachsene 
> Kompatibilitäts-Krücke. Deren Fehler muß man auf einer neueren/anderen 
> Plattform ja nicht wiederholen.

UEFI hat damit ja aufgeräumt. Mittlerweile ist das CSM auch draußen.

> Suchst du eigentlich vielleicht nur danach wo/wann/wie die arm-Firmware 
> an einen OS-Lader übergibt?

Mich interessiert der Vorgang selbst (ich will es einfach wissen) und 
mich interessiert, ob es da relevante Unterschiede gibt, sprich ob man 
einfach eine arm-VM mieten kann und die überall gleich sind (wie bei 
BIOS/UEFI) oder ob da jeder CPU-Hersteller eine eigene Suppe kocht, die 
das OS dann unterstützen muss, damit es gebootet werden kann.
-- 
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#33278

Marco Moock <mm@dorfdsl.de> wrote:
>Mich interessiert der Vorgang selbst (ich will es einfach wissen) und 
>mich interessiert, ob es da relevante Unterschiede gibt, sprich ob man 
>einfach eine arm-VM mieten kann und die überall gleich sind (wie bei 
>BIOS/UEFI) oder ob da jeder CPU-Hersteller eine eigene Suppe kocht, die 
>das OS dann unterstützen muss, damit es gebootet werden kann.

Ich würde erwarten, dass hier jeder Hardware-Hersteller seine eigene
Suppe kocht. Ich kann dazu leider nichts sagen, ich kenne nur die
ARM-VMs vom Hetzner. Wo gibt es noch ARM-VMs die man mieten könnte?
Ich wäre bereit etwas Geld für Wissensgewinn auszugeben.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#33279

Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
> ARM-VMs vom Hetzner. Wo gibt es noch ARM-VMs die man mieten könnte?

AWS hat das schon sehr lange.

> Ich wäre bereit etwas Geld für Wissensgewinn auszugeben.

Wenn man vorsichtig ist, dann kann man es kostenlos
testen:

https://aws.amazon.com/de/ec2/instance-types/t4/

/ralph

[toc] | [prev] | [next] | [standalone]

#33281

Ralph Aichinger <ra@h5.or.at> wrote:
>Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
>> ARM-VMs vom Hetzner. Wo gibt es noch ARM-VMs die man mieten könnte?
>
>AWS hat das schon sehr lange.

Ich habe Null Erfahrung mit AWS, würde aber erwarten, dass man dort
mit sochen Nebensächlichkeiten wie Bootprozessen nicht belästigt wird.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#33285

Am 08.08.26 um 14:36 schrieb Marc Haber:
> Ralph Aichinger <ra@h5.or.at> wrote:
>> Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
>>> ARM-VMs vom Hetzner. Wo gibt es noch ARM-VMs die man mieten könnte?
>>
>> AWS hat das schon sehr lange.
> 
> Ich habe Null Erfahrung mit AWS, würde aber erwarten, dass man dort
> mit sochen Nebensächlichkeiten wie Bootprozessen nicht belästigt wird.

Das einzige was ich darüber mal las war das man auf die Traffic & andere 
anfallende Kosten genau acht geben muß um nicht eine Hohe Rechnung 
anstehen zu haben.

Betrifft aber wohl primär öffentlich zugängliche Instanzen. Ich nehme an 
das meinte Ralph mit "wenn man vorsichtig ist".

Wichtigste Frage wäre wohl ob man das dann auch rein privat nutzen 
könnte und wie (Bindung an eine VPN-IP?) und ob dann auch von überall 
eintreffende Anfragen (as heard) NICHT zum Datenvolumen gezählt würden.

Da wäre ich auch skeptisch. Kleinvieh macht auch Mist, und bei IPv6 kann 
man ICMP doch auch nicht einfach abdrehen. Daher: Ping (Ingress) & Pong 
(egress) = $$$

@Ralph/Auskenner: Oder rechnen die bei AWS jetzt anders ab?


Bye/
   /Kay

-- 
Posted via Leafnode

[toc] | [prev] | [next] | [standalone]

#33287

Am 08.08.26 um 15:05 schrieb Kay Martinen:
> 
> Da wäre ich auch skeptisch. Kleinvieh macht auch Mist, und bei IPv6 kann 
> man ICMP doch auch nicht einfach abdrehen. Daher: Ping (Ingress) & Pong 
> (egress) = $$$

ICMP wird da zwingend für link-local-Traffic für das NDP benötigt. 
Ebenfalls muss man die unreachables reinlassen und ggf. selbst senden.

echo request ist wie bei IPv4 optional aus Sicht des Protokolls.

Bei IPv6 sind Pings und Portscans viel seltener als bei IPv4, auch bei 
öffentlich bekannten Adressen.

-- 
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#33290

Kay Martinen <usenet@martinen.de> wrote:
> Wichtigste Frage wäre wohl ob man das dann auch rein privat nutzen 
> könnte und wie (Bindung an eine VPN-IP?) und ob dann auch von überall 
> eintreffende Anfragen (as heard) NICHT zum Datenvolumen gezählt würden.
> 
> Da wäre ich auch skeptisch. Kleinvieh macht auch Mist, und bei IPv6 kann 
> man ICMP doch auch nicht einfach abdrehen. Daher: Ping (Ingress) & Pong 
> (egress) = $$$
> 
> @Ralph/Auskenner: Oder rechnen die bei AWS jetzt anders ab?

Meine Erinnerung ist nur mehr dunkel, aber Amazon verrechnet
so gut wie alles irgendwie. Oft nur absurd niedrige Beträge 
(keine Ahnung ein paar Cents für zigtausende DNS-Abfragen oder 
so), aber ohne ein hartes Zahlungslimit und ein gutes Monitoring
würde ich AWS auf keinen Fall nutzen. Irgendwas was du übersiehst
und die Kosten schießen in die Höhe. Bei irgendeinem Arbeitgeber
haben wir ein Backupskript gehabt, das in einem normalen Monat
20 oder 30 Euro gekostet hat, und dann hat wer einen Fehler 
gemacht und zuviel gebackupt (oder das falsche, ich weiß es nicht
mehr) und es waren an die 1000 Euro in dem Monat.

Der AWS Cost Explorer wird da schnell dein bester Freund. Und
wenn man das ganze im größeren Maßstab nutzt, dann zahlen sich
Consultants vermutlich schnell aus, die die Kosten optimieren.

/ralph

[toc] | [prev] | [next] | [standalone]

#33280

Am 08.08.26 um 11:21 schrieb Marco Moock:
>> BIOS/UEFI sind doch prinzipiell auch eine Historisch gewachsene 
>> Kompatibilitäts-Krücke. Deren Fehler muß man auf einer neueren/anderen 
>> Plattform ja nicht wiederholen.
> 
> UEFI hat damit ja aufgeräumt. Mittlerweile ist das CSM auch draußen.

Und dann laufen die Zertifikate ab, und man hat einen Ziegelstein, wenn 
man selbst oder der Hersteller nicht schnell genug mit den 
Stammzertifikatsupdates war.

Außer dass man dafür keinen Real-Mode der CPU mehr braucht, kann ich 
nicht erkennen, was UEFI besser macht als vorher. Es ist nur anders, und 
eben auch komplexer und damit anfälliger.


Marcel

[toc] | [prev] | [next] | [standalone]

#33282

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>Am 08.08.26 um 11:21 schrieb Marco Moock:
>>> BIOS/UEFI sind doch prinzipiell auch eine Historisch gewachsene 
>>> Kompatibilitäts-Krücke. Deren Fehler muß man auf einer neueren/anderen 
>>> Plattform ja nicht wiederholen.
>> 
>> UEFI hat damit ja aufgeräumt. Mittlerweile ist das CSM auch draußen.
>
>Und dann laufen die Zertifikate ab, und man hat einen Ziegelstein, wenn 
>man selbst oder der Hersteller nicht schnell genug mit den 
>Stammzertifikatsupdates war.

FUD.

>Außer dass man dafür keinen Real-Mode der CPU mehr braucht, kann ich 
>nicht erkennen, was UEFI besser macht als vorher. Es ist nur anders, und 
>eben auch komplexer und damit anfälliger.

Diese Diskussion hatten wir schon hundertmal. Ich sehe sehr viele
Vorteile bei UEFI und weine dem 50 Jahre alten BIOS-Ballast keine
Träne hinterher.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#33284

Am 08.08.26 um 14:37 schrieb Marc Haber:
> Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>> Am 08.08.26 um 11:21 schrieb Marco Moock:
>>>> BIOS/UEFI sind doch prinzipiell auch eine Historisch gewachsene
>>>> Kompatibilitäts-Krücke. Deren Fehler muß man auf einer neueren/anderen
>>>> Plattform ja nicht wiederholen.
>>>
>>> UEFI hat damit ja aufgeräumt. Mittlerweile ist das CSM auch draußen.
>>
>> Und dann laufen die Zertifikate ab, und man hat einen Ziegelstein, wenn
>> man selbst oder der Hersteller nicht schnell genug mit den
>> Stammzertifikatsupdates war.
> 
> FUD.

Nope! Ist doch passiert, letztes Jahr oder davor meine ich. Allerdings 
vorwiegend bei Windows Systemen aber es soll sich auch auf Linux 
Bootende ausgewirkt haben. Ging um die Krytografische Absicherung des 
Bootprozesses und einen "Shim"...? Mehr erinnere ich nicht, müßte ich 
erst nachlesen.

Seit dem soll der Linux 'fwupd' doch auch besser geworden sein. Bei 
Windows macht ja eher jeder Hersteller sein eigenes "Ding" was FW & 
Cert-Updates angeht.

Ursache=Wirkung?

Bye/
   /Kay

-- 
Posted via Leafnode

[toc] | [prev] | [next] | [standalone]

#33288

Am 08.08.26 um 14:55 schrieb Kay Martinen:
> Seit dem soll der Linux 'fwupd' doch auch besser geworden sein. Bei 
> Windows macht ja eher jeder Hersteller sein eigenes "Ding" was FW & 
> Cert-Updates angeht.

fwupdmgr ist eines der tollen Dinge, die unter Linux wesentlich besser 
sind als unter Windows.

-- 
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#33295

Am 08.08.26 um 14:37 schrieb Marc Haber:
> Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>> Und dann laufen die Zertifikate ab, und man hat einen Ziegelstein, wenn
>> man selbst oder der Hersteller nicht schnell genug mit den
>> Stammzertifikatsupdates war.
> 
> FUD.
> 
>> Außer dass man dafür keinen Real-Mode der CPU mehr braucht, kann ich
>> nicht erkennen, was UEFI besser macht als vorher. Es ist nur anders, und
>> eben auch komplexer und damit anfälliger.
> 
> Diese Diskussion hatten wir schon hundertmal. Ich sehe sehr viele
> Vorteile bei UEFI und weine dem 50 Jahre alten BIOS-Ballast keine
> Träne hinterher.
Bei uns in der Firma hat es ein vielleicht 1 Jahr altes Profi-Notebook 
erwischt. Da ging nichts mehr. Secure Boot tot, und Signatur-Updates auch.

Am Ende gab es tatsächlich mit mehrstündigem Support-Einsatz noch eine 
Lösung. Das UEFI-BIOS hatte einen Netzwerktreiber für Festnetz und 
Standard DHCP. Angeschlossen an einen Port mit freiem Internetzugang, 
konnte mit Mitteln des BIOS ein Update eingespielt werden, was das 
Problem behebt.

Ich habe dasselbe Modell, aber hatte den Neustart wegen Updates ein paar 
mal weggedrückt, und in der Zeit war das entscheidende Update vom 
Hersteller rein gelaufen.


Marcel

[toc] | [prev] | [next] | [standalone]

#33289

Am 08.08.26 um 14:25 schrieb Marcel Mueller:
> Außer dass man dafür keinen Real-Mode der CPU mehr braucht, kann ich 
> nicht erkennen, was UEFI besser macht als vorher. Es ist nur anders, und 
> eben auch komplexer und damit anfälliger.

Der Mist mit den Stages im Bootprozess ist weg. Es gibt eine ESP mit 
einer Binärdatei, die seitens des UEFI gebootet (und ggf. vorher 
ausgewählt) werden kann - nix mit Bootloadern, die an 3 Stellen verteilt 
sind und dann im Dualboot ggf. sich in die Quere kommen.

-- 
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#33296

Am 08.08.26 um 17:20 schrieb Marco Moock:
> Am 08.08.26 um 14:25 schrieb Marcel Mueller:
>> Außer dass man dafür keinen Real-Mode der CPU mehr braucht, kann ich 
>> nicht erkennen, was UEFI besser macht als vorher. Es ist nur anders, 
>> und eben auch komplexer und damit anfälliger.
> 
> Der Mist mit den Stages im Bootprozess ist weg. Es gibt eine ESP mit 
> einer Binärdatei, die seitens des UEFI gebootet (und ggf. vorher 
> ausgewählt) werden kann - nix mit Bootloadern, die an 3 Stellen verteilt 
> sind und dann im Dualboot ggf. sich in die Quere kommen.
Dual-Boot ist aber heutzutage eher ein Anwendungsfall für Freaks. Seit 
es VMs gibt, gibt man sich das nur noch in absoluten Notfall. Ich würde 
schätzen <1 ‰ der Rechner.

Und die Stages gibt es technisch immer noch. Bei Linux kommt halt Shim 
dazu. Und auch Windows hat schon immer einen mehrstufigen Bootloader.


Marcel

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.hardware.misc

csiph-web