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

Groups > de.comp.hardware.misc > #33298

Re: arm64 Bootprozess

Show all headers | View raw

Am 09.08.26 um 14:22 schrieb Marcel Mueller:
> 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.

Mir scheinen die Einstell-möglichkeiten eines UEFI gefühlt drastisch 
reduziert zu sein. Das finde ich dann nicht besser. Aber vielleicht hab 
ich auch nur die Falsche HW.

>> 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.

Wenn man den richtigen Bootmanager im MBR hatte (z.b. XF-Disc) dann ging 
sowohl DOS, Windows, OS/2 und eine gemeinsame Datenpartition. Das 
Entscheidende Stichwort ist /AutoHide. Eine Option des o.g. der nach der 
Auswahl des zu bootenden Systems die anderen Partitionen auf "versteckt" 
setzte. Damit hatte jedes gebootete system C: für sich, die anderen 
tauchten nicht auf und nur die Datenpartition war für alle dann D:

> 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.

Schon möglich. Als ich obiges nutzte gab es m.E. bestenfalls "Parallels" 
und Qemu war eher eine Nieschenlösung, KVM noch nicht entwickelt und 
wenn man das wirklich machen wollte; auf HW die kein VT o.ä. bot; ging 
nur Paravirtuell o.a. Hardware-nah oder unterstütztes. Hab ich so mal 
auf einem Proliant G4 mit Xeon (P4) Kernen versucht. Extrem träge und 
unerfreulich.

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

Der Shim war doch m.E. beim letzten "desaster" auch das Problem mit 
Linux. IMHO ist da was schiefgelaufen mit einer Signatur oder Zertifikat 
(das von MS stammte) so das Linux Systeme die das nutzen krachen auf die 
Nase flogen. MS wollte wohl bestimmte "Systeme" invalidieren" und das 
traf dann eben auch auf bestimmte Linux-Systeme zu... Hups! ;)

Ein bekannterer Schreiber(-ling) hatte mal ein Lustiges Essay über 
Windows NT verfasst. Sinngemäß "wie ein bootloader an den anderen Weiter 
reicht und dazu eine beruhigend blauer 'Don't Panic' Hintergrund gezeigt 
würde..." :-)

Fand ich vor xx Jahren mal im Web, IMHO im umfeld der c't irgendwo.



Bye/
   /Kay

-- 
Posted via Leafnode

Back to de.comp.hardware.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web