HILFE bei UEFI Installation auf Asrock Motherboard

[Rico81]

Moin zusammen

Ich versuche seit einer Woche Linux auf einen vormaligen Win PC zu installieren und bin kurz davor die Kiste anzuzünden.

Was möchte ich tun:
Am Ende des Ganzen möchte ich eine Linux Distribution (Home Assistant OS) auf einen alten PC bekommen.
Um diese auf die SSD zu bekommen, brauche ich ein anderes Linux mit dem ich das Image dann drauf schreiben kann.
Alternativ ginge auch die SSD ausbauen und woanders das Image drauf ziehen. Hab ich auch schon gemacht, behebt aber das Grundproblem nicht, siehe weiter unten.
Der PC besteht aus einem Asrock H81M-ITX mit Pentium G3220 und einer 60 GB SSD.

Was hab ich für Möglichkeiten:
Ich kann die SSD ausbauen und an einem anderen Win PC bearbeiten; außerdem hab ich mehrere USB Wechselspeicher, mit denen ich arbeiten kann.

Woran scheitert es aktuell?
Am Schritt -1. Ausgangslage für alle Beschreibungen die ich so finden kann, ist ein Linux OS (Live Stick oder installiert) als UEFI; und genau das bekomme ich nicht hin.
Stelle ich im BIOS CSM aus, sehe ich keines meiner Speichermedien mehr. Und somit kann ich alles danach immer nur als Legacy machen und damit kriege ich nie eine EFI Partition hin und alles danach kann schon nicht mehr werden. Ich habe wohl schon gelesen, dass Asrock Boards dabei zickig sein sollen. Aber grundsätzlich gehen die dafür und die meisten Threadsteller haben es dann auch immer irgendwie hinbekommen.
Bevor mir gleich jemand mit "GOOGLE FRAGEN!!! " kommt; hab ich zigfach gemacht. Aber das geht eben alles bei Schritt eins los und ich muss erstmal die Ausgangslage dafür bereiten.
Und wenn's doch irgendwo genau die Antwort darauf zu finden gibt, gern einfach verlinken und gut ist.

Was hab ich zuletzt gemacht?
Alle Medien (GPT) formatiert, einen Debian Stick erstellt und dann versucht mit Gparted was hinzubekommen. Aber wie gesagt - kann nie eine EFI Partition erstellen, da ich den Stick ja schon als Legacy booten muss, weil er sonst gar nicht erkannt wird.

Bin dankbar für jeden Hinweis.

P.S. Meine Linux Skills sind sehr basic.

Rico

[debilian]

Ich habe wohl schon gelesen, dass Asrock Boards dabei zickig sein sollen. Aber grundsätzlich gehen die dafür und die meisten Threadsteller haben es dann auch immer irgendwie hinbekommen.

ist das BIOS aktuell?

[rhHeini]

Du brauchst keine Live-Distri um eine efi-Installation hinzukriegen. Das geht mit einem ganz stinknormalen netinstall ohne Live, zu finden z.B. hier: https://www.debian.org/distrib/

Den Download kopiert man unter Linux einfach mit dd auf den Stick:

Code: Alles auswählen

# dd if=boot.img of=/dev/sdx

Dabei musst Du für boot.imag den Dateinamen Deines Downloads nehmen und bei sdx sicherstellen dass Du das x mit dem richtigen Buchstaben ersetzt der auf den Zielstick zeigt. Und wichtig, nur auf sdx, nicht auf sdx1 schreiben.
Bei Windows-Tools wie Rufus oder Balana-Etcher weiss man nie was rauskommt. Brauchbar ist ein Ventoy-Stick, wäre eine Alternative.

Im Bios schaltest Du Secure Boot aus bzw. weg von "Microsoft Windows" auf "Other OS", oder wie auch immer ASROCK das benannt hat. Ich lösche auch alle SB-Keys (wenn
das Bios das zulässt). CSM aus, wenn es Treibereinstellungen gibt die auf "UEFI Driver first" stellen.

Und booten musst Du im Bootmenu das Medium mit dem UEFI als Prefix.

Im Installer kannst Du dann im Partitionierungsmenu eine ESP anlegen.

[MSfree]

Was möchte ich tun:
Am Ende des Ganzen möchte ich eine Linux Distribution (Home Assistant OS) auf einen alten PC bekommen.
Um diese auf die SSD zu bekommen, brauche ich ein anderes Linux mit dem ich das Image dann drauf schreiben kann.

Nein, das ist falsch. Wenn du die Anleitungen bei Home Assistant gelesen hättest, wäre dir klar geworden, daß dieser Home Assistant in einer virtuellen Maschine laufen soll. Das Image der virtuellen Maschine überschreibt keineswegs das vormals installierte Betriebssystem, das Image wird nur auf der Platte als Datei abgelegt.

Die Beschreibung zielt auf Nutzungf von VirtualBox oder LinuxKVM (libwirt) ab. Für beide Virtuealisierungen werden verschiedene Images angeboten.

VirtualBox kann man übrigens auch unter Windows laufen lassen. Die Installation eines Linux als Hostsystem ist also im Grunde gar nicht nötig.

Alternativ ginge auch die SSD ausbauen und woanders das Image drauf ziehen.

Nein, das hast du völlig falshc verstanden.

Wenn du schon ein Linux als Hostsystem verwenden willst, dann ist es völlig wurscht, ob das im BIOS-Modus oder im UEFI-Modus installiert wird. Beides würde funktionieren.

[wanne]

Home Assistant OS macht vieles anders als andere Distributionen. Ich finde nicht schlechter sogar eher einfacher. Die Beschreibung halte ich dagegen für wirklich unmöglich kompliziert.
Kurz wie das funktionieren sollte:

1. Secure Boot abschalten.
2. Debian booten als root folgendes ausführen

   Code: Alles auswählen

   fdisk -l

   Um zu gucken welche Platte die SSD ist (Ich nenne sie im folgenden /dev/sdx)

   Code: Alles auswählen

   wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" -O - | xz -d > /dev/sdx

3. Rebooten
4. UEFI Mode anschalten
5. USB-Stick abziehen
6. Beten dass alles funktioniert "HAOS" in der Bootauswahl auftaucht.

Troubleshooting
Home Assistant OS nutzt da einen Hack und booted die Platte als externe Festplatte um die Installation zu vereinfachen.
Sauber müsste man nach dem wget noch das ausführen:

Code: Alles auswählen

efibootmgr --create --disk /dev/sdx --part 1 --label "HAOS" --loader '\EFI\BOOT\bootx64.efi'

Achtung da ist wieder ein /dev/sdx drin, dass ersetzt werden muss.
Das funktioniert aber nur, wenn man schon zuvor auf UEFI umgestellt hat. (Deswegen ist Punkt 4 im Orignal ganz am Anfang.) Wie du schon gemerkt hast tut das nicht. Das sollte™ nicht passieren. Ist aber kein unübliches Problem. Leider sind viele EFIs sehr picky.
Sachen die bei mir schon geholfen haben:

• Meide USB-3-Löcher! USB-2 Support ist meist deutlich zuverlässiger. Aber auch sonst: Alle löcher mal durchprobieren hilft. Oft genug sind die beiden Löcher die im EFI-Modus tun dann die, die im BIOS-Modus nicht tun und der eine Stick der am USB-3 tut, will am USB-2 nicht.
• Rechner eine Sekunde aus und wieder einstecken dann den USB-Stick erneut einstecken. – Ja wirklich.
• Anderen (älteren) USB-Stick nutzen.
• Gucken ob irgend eine Sicherheitsoption ansatzweise so klingen könnte als würde sie das Booten von Wechselmedien verbieten.

Ein paar Sachen zum klarstellen/Pfennig-Fuchsen

Stelle ich im BIOS CSM aus, sehe ich keines meiner Speichermedien mehr.

EFI sollte Betriebssysteme anbieten keine Speichermedien. So kannst du beliebig viele Betriebssysteme auf ein Speichermedium hauen ohne wrapper wie Grub zu brauchen, die dann wieder nicht alle Betriebssysteme kennen. Ich nehme an, auch die siehst du nicht.

und damit kriege ich nie eine EFI Partition hin

Selbstverständlich kannst du jederzeit eine EFI-Partition erstellen fdisk Naheinander tippen:

Code: Alles auswählen

g
n
1
2048
+40M
t
1
w

Nutzen tut dir das aber nichts, da du dein OS im EFI registrieren musst und das nicht kannst, wenn du BIOS-Gebooted hast.
Du solltest aber auch gar keine EFI-Partitionen selbst erstellen!

Nein, das ist falsch. Wenn du die Anleitungen bei Home Assistant gelesen hättest, wäre dir klar geworden, daß dieser Home Assistant in einer virtuellen Maschine laufen soll.

Also ich sehe da ganz fett auf der Startseite eine Anleitung für bare metal verlinkt. Ziemlich direkt nach der "Hardware-Kaufen" option.
https://www.home-assistant.io/installat ... ric-x86-64

Die Beschreibung zielt auf Nutzungf von VirtualBox oder LinuxKVM (libwirt) ab. Für beide Virtuealisierungen werden verschiedene Images angeboten.

Kommt zwar auch irgend wo, da das aber am Ende defakto "nur" ein Container-Manager ist, zweifele ich am Sinn das in einer VM laufen zu lassen. Auch wenn es immer üblicher ist: Container in VMs sind nicht wirklich die performanteste Variante, die man sich vorstellen kann.

Wenn du schon ein Linux als Hostsystem verwenden willst, dann ist es völlig wurscht, ob das im BIOS-Modus oder im UEFI-Modus installiert wird. Beides würde funktionieren.

Ich würde da mal zweifel anmelden. Gibt immer mehr Kernel Code, der UEFI voraussetzt. Am Ende macht das doch ein paar low-level Sachen. Auch wenn das meist eher rand-features sind, würde ich jetzt nicht vollständig ausschließen, dass das Gründe hat, warum die das vorschreiben. Kann aber natürlich auch nur Bullshit sein um die Installation zu vereinheitlichen.

Du brauchst keine Live-Distri um eine efi-Installation hinzukriegen.

Achtung, der will kein Debian installieren sondern ein anderes OS, das (wie Gentoo) eine Live-CD für die Installation voraussetzt. Im Netinstaller mögen die nötigen Tools drin sein, angenehme ist das aber nicht.

Den Download kopiert man unter Linux einfach mit dd auf den Stick:

Mein Lieblingsthema: Warum nicht:

Code: Alles auswählen

cp boot.img /dev/sdx

Viel verständlicher.

[Rico81]

@wanne: vielen Dank für deine ausführliche Antwort.
Leider bekomme ich beim Versuch das Image herunterzuladen einen broken-pipe Error.
Beim Versuch das mit sudo zu machen, erhalte ich trotzdem die Meldung zum Schreiben nicht berechtigt zu sein.

Danach habe ich das Herunterladen und kopieren des Images auf das Laufwerk probiert, so wie @rhHeini das vorgeschlagen hat. #
(so etwas ähnliches hatte ich ja schon auf anderem Weg gemacht, als ich die SSD ausgebaut hatte und dort das Image drauf geschrieben habe)
Jedenfalls bekomme ich dann wieder das Ergebnis, dass dies dann nicht bootet, wenn CSM ausgeschaltet ist. Und dieses Image will halt zwingend UEFI boot.

[kreuzschnabel]

Beim Versuch das mit sudo zu machen, erhalte ich trotzdem die Meldung zum Schreiben nicht berechtigt zu sein.

Bitte gib uns – und das gilt ab jetzt immer – exakt das, was du eingegeben hast, mit der exakten Antwort des Systems. Aus dem Terminalemulator gecopypastet. Und das als Codeblock. Etwa so:

Code: Alles auswählen

volker@marvin:~$ dd if=./image.iso of=/dev/sda status=progress
dd: konnte '/dev/sda' nicht öffnen: Keine Berechtigung
volker@marvin:~$ 

Damit kann man als Helfer was anfangen.

--ks

[Rico81]

Klaro, mache ich - bin ja froh dass ihr so hilfreich bei Seite steht.

Code: Alles auswählen

$ wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" -O - | xz -d > /dev/sda
bash: /dev/sda: Keine Berechtigung
--2024-12-13 15:57:12--  https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz
Auflösen des Hostnamens github.com (github.com)… 140.82.121.3
Verbindungsaufbau zu github.com (github.com)|140.82.121.3|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 302 Found
Platz: https://objects.githubusercontent.com/github-production-release-asset-2e65be/115992009/9855e481-65a6-466b-ac4d-195134d0715f?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20241214%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20241214T145718Z&X-Amz-Expires=300&X-Amz-Signature=075e8b021fce8e23a5f5a4ad78218983173df9e0810cf2e6da4b7838762f61fa&X-Amz-SignedHeaders=host&response-content-disposition=attachment%3B%20filename%3Dhaos_generic-x86-64-14.0.img.xz&response-content-type=application%2Foctet-stream [folgend]
--2024-12-13 15:57:12--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/115992009/9855e481-65a6-466b-ac4d-195134d0715f?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20241214%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20241214T145718Z&X-Amz-Expires=300&X-Amz-Signature=075e8b021fce8e23a5f5a4ad78218983173df9e0810cf2e6da4b7838762f61fa&X-Amz-SignedHeaders=host&response-content-disposition=attachment%3B%20filename%3Dhaos_generic-x86-64-14.0.img.xz&response-content-type=application%2Foctet-stream
Auflösen des Hostnamens objects.githubusercontent.com (objects.githubusercontent.com)… 185.199.109.133, 185.199.110.133, 185.199.111.133, ...
Verbindungsaufbau zu objects.githubusercontent.com (objects.githubusercontent.com)|185.199.109.133|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 401024908 (382M) [application/octet-stream]
Wird in »STDOUT« gespeichert.

-                           0%[                                      ]       0  --.-KB/s    in 0s      


Schreiben nach »-« nicht möglich (Datenübergabe unterbrochen (broken pipe)).

Das ist das Ergebnis nach 1:1 Anleitung.
Versuche ich das mit sudo, siehts so aus:

Code: Alles auswählen

$ sudo wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" -O - | xz -d > /dev/sda
bash: /dev/sda: Keine Berechtigung

Ausgabe wird nach »wget-log.3« umgeleitet.

Das Kopieren des Images sieht dann so aus:

Code: Alles auswählen

cp /home/enrico/Downloads/haos_generic-x86-64-14.0.img.xz /dev/sda
cp: reguläre Datei '/dev/sda' kann nicht angelegt werden: Keine Berechtigung

Das letzte mit sudo läuft dann durch (zumindest wird kein Fehler ausgeworfen), bootet aber danach nicht.

[wanne]

Mist habs schon aufm Handy gelesen und war zu lahm zum antworten:
Bitte die Ausgabe von

Code: Alles auswählen

fdisk -l

und eventuell

Code: Alles auswählen

ls -l /dev/sda
blkid /dev/sda

mitgeben.

[Rico81]

Code: Alles auswählen

$ sudo fdisk -l
[sudo] Passwort für enrico: 
Festplatte /dev/sda: 55.9 GiB, 60022480896 Bytes, 117231408 Sektoren
Festplattenmodell: KINGSTON SV300S3
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes


Festplatte /dev/sdb: 931.51 GiB, 1000204884480 Bytes, 1953525165 Sektoren
Festplattenmodell: External USB 3.0
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x88655b34

Gerät      Boot     Anfang       Ende   Sektoren  Größe Kn Typ
/dev/sdb1  *          2048 1937329612 1937327565 923.8G 83 Linux
/dev/sdb2       1937329613 1953520064   16190452   7.7G 82 Linux Swap / Solaris

Code: Alles auswählen

$ ls -l /dev/sda
blkid /dev/sda
brw-rw---- 1 root disk 8, 0 Dec 14 09:54 /dev/sda
bash: blkid: Kommando nicht gefunden.

Mit sudo läuft es durch, ohne Ausgabe:

Code: Alles auswählen

$ sudo blkid /dev/sda

Code: Alles auswählen

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0  55.9G  0 disk 
sdb      8:16   0 931.5G  0 disk 
├─sdb1   8:17   0 923.8G  0 part /
└─sdb2   8:18   0   7.7G  0 part [SWAP]

[wanne]

Ah. Oops: Hätte mir vorher auffallen müssen. root wirst du unter Debian-Live ohne Passwort mit

Code: Alles auswählen

su -

Unter Ubuntu-Live mit:

Code: Alles auswählen

sudo su -

Wenn du mit sudo arbeiten willst:

Code: Alles auswählen

wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" -O - | sudo -u \#0 xz -d > /dev/sda

Macht den download als dein User das Enpacken (und damit implizit das schreiben, da ja erst das Entpackprogramm schreibt) als root. Password ist unter debian live wenn ich mich rechte entsinne "live" unter Ubuntu wird keines benötigt.

Dein:

Code: Alles auswählen

sudo wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" -O - | xz -d > /dev/sda

Downloaded als wer auch immer in der /etc/sudoers steht (vermutlich root) und entpackt als abgemeldeter user (vermutlich debian/ubuntu).

[Rico81]

Still no joy

Code: Alles auswählen

wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" -O - | sudo -u \#0 xz -d > /dev/sda
bash: /dev/sda: Keine Berechtigung
--2024-12-14 18:05:57--  https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz
Auflösen des Hostnamens github.com (github.com)… 140.82.121.4
Verbindungsaufbau zu github.com (github.com)|140.82.121.4|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 302 Found
Platz: https://objects.githubusercontent.com/github-production-release-asset-2e65be/115992009/9855e481-65a6-466b-ac4d-195134d0715f?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20241215%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20241215T170602Z&X-Amz-Expires=300&X-Amz-Signature=7ead4afe57cf524f0be207ca1279bf490f9db652b3e0f329a0c93a6d32ad9e71&X-Amz-SignedHeaders=host&response-content-disposition=attachment%3B%20filename%3Dhaos_generic-x86-64-14.0.img.xz&response-content-type=application%2Foctet-stream [folgend]
--2024-12-14 18:05:57--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/115992009/9855e481-65a6-466b-ac4d-195134d0715f?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20241215%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20241215T170602Z&X-Amz-Expires=300&X-Amz-Signature=7ead4afe57cf524f0be207ca1279bf490f9db652b3e0f329a0c93a6d32ad9e71&X-Amz-SignedHeaders=host&response-content-disposition=attachment%3B%20filename%3Dhaos_generic-x86-64-14.0.img.xz&response-content-type=application%2Foctet-stream
Auflösen des Hostnamens objects.githubusercontent.com (objects.githubusercontent.com)… 185.199.108.133, 185.199.109.133, 185.199.110.133, ...
Verbindungsaufbau zu objects.githubusercontent.com (objects.githubusercontent.com)|185.199.108.133|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 401024908 (382M) [application/octet-stream]
Wird in »STDOUT« gespeichert.

-                           0%[                                      ]       0  --.-KB/s    in 0s      


Schreiben nach »-« nicht möglich (Datenübergabe unterbrochen (broken pipe)).

Hab das noch mit:
sudo -su
su -
sudo su-
probiert, aber immer das gleiche Ergebnis.

[wanne]

Still no joy

Sorry sudo macht wohl die shell selbst, in der das xz läuft als ursprünglicher user auf. Wenn du dich so für sudo insteressierst solltest du eventuell echt mal in nem Ubuntu-Forum fragen.
in sofern:

Code: Alles auswählen

sudo usermod -a -G disk debian
wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" -O - | xz -d > /dev/sda

Code: Alles auswählen

su -

Kannst du davon mal nen Screenschot schicken?
Ich zweifele stark.

[cosinus]

Warum muss denn alles in einen Befehl gepresst werden?
Probieren wir es doch mal Schritt für Schritt. Erstmal nur der Download:

Code: Alles auswählen

wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" /var/tmp

Das hat den Vorteil, dass das Image nicht jedes Mal neu runtergeladen werden muss. Funktioniert das?

[MSfree]

Warum muss denn alles in einen Befehl gepresst werden?
Probieren wir es doch mal Schritt für Schritt. Erstmal nur der Download:

Wir wissen nicht, was für ein OS der OP gebootet hat, um diese Operation durchzuführen. Wenn das ein Rettungssystem ist, dann ist das /home-Verzeichnis read-only, ein Download kann also nicht erfolgreich ausgeführt werden.

[cosinus]

Wenn das ein Rettungssystem ist, dann ist das /home-Verzeichnis read-only, ein Download kann also nicht erfolgreich ausgeführt werden.

/var/tmp sollte beschreibbar sein
Ist auch nur ein Vorschlag, weil bisher kam er ja auch nicht weiter.

[Rico81]

Wenn du dich so für sudo insteressierst solltest du eventuell echt mal in nem Ubuntu-Forum fragen.

Mache ich gar nicht. Also mich extra für sudo zu interessieren.
Ich probiere laienhaft nur alles mögliche aus um zu gucken ob was davon klappt.
Am Ende will ich einfach nur das HA OS ans Laufen kriegen; egal wie.

Kannst du davon mal nen Screenschot schicken?
Ich zweifele stark.

Code: Alles auswählen

$ su -
Password: 

Nach der Passwortaufforderung nimmt das Keyboard keine Eingaben mehr an. Muss das Terminal erneut öffnen, dass überhaupt wieder was geht.
Hab aber was anderes hinbekommen. Hatte scheinbar die root-Rechte Befehle falsch verstanden.
Hatte dann:

Code: Alles auswählen

sudo su -

nochmal separat ausgeführt und damit dann Root Rechte bekommen (ohne Passwort).

Damit läuft dann auch dein Befehl von oben durch.

Code: Alles auswählen

wget "https://github.com/home-assistant/operating-system/releases/download/14.0/haos_generic-x86-64-14.0.img.xz" -O - | xz -d > /dev/sda

Ich kann dann auf Gparted sehen, dass da jetzt das OS drauf ist, inkl. EFI Partition.
Leider kann ich danach dann weiterhin nicht booten. Und der Versuch mit dem weiteren Befehl:

Code: Alles auswählen

efibootmgr --create --disk /dev/sdx --part 1 --label "HAOS" --loader '\EFI\BOOT\bootx64.efi'

funktioniert (wie du schon vermutet hast) leider auch nicht.

Code: Alles auswählen

efibootmgr --create --disk /dev/sda --part 1 --label "HAOS" --loader '\EFI\BOOT\bootx64.efi'
EFI variables are not supported on this system.
root@debian:~# 

Der Knackpunkt bleibt weiterhin, dass ich schon vorher UEFI gebootet haben muss. In dem Moment wo ich im BIOS auf UEFI umstelle, sind danach alle möglichen Bootoptionen verschwunden. Das einzige was im Zusammenhang mit UEFI und Boot überhaupt auftaucht, sind die zwei Einträge für Netzwerkbooten.
Mal für mein Verständnis: ich könnte jede Festplatte nehmen, die aktuell in anderen PCs funktioniert (also mit dem HA OS und allem pipapo); bei mir würde sie es aber nicht tun, weil das BIOS das nicht zulässt?! Ich muss es also irgendwie hinbekommen irgendein Betriebssystem als UEFI zu booten, richtig? Nur um danach dann einen Einstieg zu haben für alles andere.

Warum muss denn alles in einen Befehl gepresst werden?
Probieren wir es doch mal Schritt für Schritt. Erstmal nur der Download:

Das funktioniert, hatte ich vorher schon gemacht. Nur bin ich auch da jedes mal dadurch gestoppt worden, dass danach eben nichts bootet.

Warum muss denn alles in einen Befehl gepresst werden?
Probieren wir es doch mal Schritt für Schritt. Erstmal nur der Download:

Wir wissen nicht, was für ein OS der OP gebootet hat, um diese Operation durchzuführen.

Hab Debian 12 live auf einer externen HDD. Hatte nebenher nochmal eine Debian 12 auf eine externe HDD installiert und damit das alles probiert. Ändert aber nichts.
Ziel ist das OS auf die interne SSD (SATA) zu bekommen.

Männer vielen Dank schon mal, dass ihr so hilfreich antwortet. Das lässt mich hoffen.
Vorschläge nach diesem Post werde ich beruflich bedingt aber erst am Freitag probieren können.

[wanne]

Nach der Passwortaufforderung nimmt das Keyboard keine Eingaben mehr an.

Nein. Selbstverständlich wird das Passwort, dass du eingibst nicht angezeigt. So bald du eines eingetippt hast, wird dir das System sagen, dass es falsch ist, da root kein Passwort hat. Dachte dass man unter Debian wie unter knoppix su ohne Passwort ausführen kann.
Das war falsch. Mate bietet dir in der GUI ein root-Terminal an, KDE lässt dich in der GUI das root-passwort ändern. Aber mit dem standard-Image musst du dich mit sudo bash oder sudo su - am root login vorbei mogeln.
Bitte beachten: Endet dein Promt nicht auf # bist du unter Debian kein root. Befehle, die als root ausgeführt werden müssen (quasi alles mit dev/sd und efibootmgr) tun dann nicht.

Mal für mein Verständnis: ich könnte jede Festplatte nehmen, die aktuell in anderen PCs funktioniert (also mit dem HA OS und allem pipapo); bei mir würde sie es aber nicht tun, weil das BIOS das nicht zulässt?!

Zuerstmal: Ein Gerät aus nem anderen Rechner wird normalerweise nicht tun, weil das EFI nicht weiß, welche Datei es booten muss. Die legst du mit dem efibootmgr-Commando im EFI fest, dass du ja nicht ausführen kannst.

Hintergrund ist, dass man normalerweise das Passende OS im EFI einträgt. Nu hat man aber ein Henne-Ei-Problem: Zum Eintragen musst du ja ja schon was gebooted haben. Deswegen sollte im Zweifelsfall die Datei "\EFI\BOOT\BOOTx64.EFI" gebooted werden.*

Da debian-live die Datei nutzt nehme ich stark an, dass dein UEFI schlicht zu dämlich ist deine Datenträger zu lesen.

Denn um die passende Datei zu suchen/finden/lesen muss das EFI halt wirklich mit der Hardware sprechen können. Braucht also passende Treiber für jegliche Speicherhardware. Deswegen hat Intels EFI-Implementierung mittlerweile mehr Zeilen als Linux. Die meisten Mainboard-Hersteller nutzen die und frikeln da noch ihren eigenen Scheiß rein. Das tut meist mehr schlecht als recht und schon gar nicht mit neuerer Hardware. – Im Gegensatz zum BIOS schlicht der erste Block geladen und ausgeführt wird, wenn er auf 0x55AA endet. Da kann man vermutlich 5-6 Festplattenkategorieen finden, für die dann mit einer festen Sequenz von Befehlen funktioniert, die dann ohne Verstand gesendet werden. Das tut meist deutlich zuverlässiger aber halt auch bis zu einer gewissen Komplexität an Hardwareprotokollen, bei NVMEs ist meist Schluss mit BIOS Support.
Deswegen wie gesagt: Versuche andere/ältere Hardware. USB 2.0 wirkt meist Wunder, vielleicht hast du sogar noch ein CD-Laufwerk...

Hatte nebenher nochmal eine Debian 12 auf eine externe HDD installiert und damit das alles probiert.

Wird immer nur in dem EFI booten, in dem du das eingetragen hast. Aber du kannst die Live-CD drauf bügeln. (Also direkt mit "cp debian-live-12.8.0-amd64-standard.iso /dev/sdx" nicht installieren.) Im Expert-Netinstaller gibts auch ne Option, dass er sich passend benennt. (Install grub in removable media path..) Aber ich glaube das ist ziemlich aussichtslos. Vorgeschrieben ist nur boot von USB-Sticks. CDs sind noch ganz gerne supported. Aber ne externe Festplatte. Wenn ASrock schon das mindeste nicht hinbekommt... .

*Du siehst btw., dass HA OS cheated hier ein bisschen und trägt auch für den "normalen" boot einfach die "default" Datei ein. (Unter FAT sollte Groß- und Kleinschreibung ignoriert werden.) Davon machen Linux Live CDs offensichtlich Gebrauch: HA OS nennt die Datei \EFI\BOOT\bootx64.efi, Knoppix: /efi/boot/BOOTX64.efi, SystemrescueCD: /efi/boot/bootx64.efi , Debian /EFI/BOOT/BOOTX64.EFI...

Warum muss denn alles in einen Befehl gepresst werden?

Weil der Fragesteller sich selbst als Anfänger beschrieben hat und das halt die Variante ist, die am wenigsten Seiteneffekte hat, die durch "komisches" verhalten, wie ich mach das Terminal zu und Tipp den Befehl einfach ins nächste ein oder ich benenne die Datei anders und passe den nächsten Befehl nicht an verursacht werden kann.

[grubenlicht]

OT

...Wird immer nur in dem EFI booten, in dem du das eingetragen hast.

Einspruch. Kannst du leicht überprüfen in einer VM: Einfach eine neue VM anlegen und ein bereits installiertes Festplatten file anhängen. Das startet nicht nur (ohne irgend etwas dazu tun zu müssen), es wird aus dem Eintrag in der ESP auch ein passender NVRAM Eintrag (von der firmware) erzeugt.
/OT

[Rico81]

Wird immer nur in dem EFI booten, in dem du das eingetragen hast. Aber du kannst die Live-CD drauf bügeln. (Also direkt mit "cp debian-live-12.8.0-amd64-standard.iso /dev/sdx" nicht installieren.) Im Expert-Netinstaller gibts auch ne Option, dass er sich passend benennt. (Install grub in removable media path..) Aber ich glaube das ist ziemlich aussichtslos. Vorgeschrieben ist nur boot von USB-Sticks. CDs sind noch ganz gerne supported. Aber ne externe Festplatte. Wenn ASrock schon das mindeste nicht hinbekommt... .

Ok also kann es wirklich daran liegen dass ich aktuell von externen USB Platten boote?! Hatte eine USB Festplatte und einen USB Stick immer über einen Kamm geschoren.
Tatsächlich hatte ich anfangs einen Stick nehmen wollen; hab auch noch genügend alte, d.h. USB 2.
Bin dann irgendwann auf die externen Platten gekommen, weil die Images alle so groß waren. Ubuntu über 6 GB und so...
Werde also das ganze nochmal von einem USB Stick probieren.
Und ansonsten?!
Hab ich noch andere Optionen?
Hilft es was nochmal Windows zu installieren um so das Henne/Ei Problem zu durchbrechen?
Die Option der IPv 4 und 6 Netzwerkinstallation bietet das BIOS ja als UEFI Boot an. Ginge es also, darüber einen Server (Raspi) anzuzapfen, der dann ein OS als UEFI installiert?!

[cosinus]

Hab ich noch andere Optionen?

Also ich hab mich heute dran versucht und es war ganz easy in wenigen Minuten erledigt.

1. SATA-SSD per USB an meinem Debian-PC angeschlossen
2. Das entpackte HAOS-OS-Image auf die SSD geschrieben mit pv

Code: Alles auswählen

pv haos_generic-x86-64-14.0.img > /dev/sdx

3. Kurz überprüft ob die Partitionsstruktur erstellt wurde mittels lsblk -f
4. SSD ausgeworfen und in den ausgeschalteten Ziel-PC eingebaut
5. Ziel-PC bootete sofort im UEFI-Modus HAOS von der SSD.

[Rico81]

1. SATA-SSD per USB an meinem Debian-PC angeschlossen

Mit einem SATA USB Adapter hatte ich das ja schon auf meinem Win PC so gemacht. Mit dem obigen Ergebnis.
Aber wenn ein Debian PC den Unterschied macht, hätte ich noch einen Raspi mit dem ich das machen könnte.

[cosinus]

Mit einem SATA USB Adapter hatte ich das ja schon auf meinem Win PC so gemacht. Mit dem obigen Ergebnis.
Aber wenn ein Debian PC den Unterschied macht, hätte ich noch einen Raspi mit dem ich das machen könnte.

Dass das nicht booten konnte kann ja einige Ursachen haben. Ich muss hin und wieder auch unter Windows was machen, aber Images auf Disks schreiben mach ich grundsätzlich unter Linux weil man es da ganz einfach mit Boardmitteln im Terminal machen kann. Du musst auch nicht extra ein Debian installieren, ein Livesystem wie grml reicht doch schon. Du musst halt nur das Image runterladen, z.B. nach /tmp oder /var/tmp und dann auf die SSD schreiben. Wenn die Kiste genug RAM hat kannst du das gepackte Image mit der Endung img.xz erstmal mit xz entpacken, dann liegt es im "richtigen" Format vor, dann einfach nur noch mit pv oder dd auf die SSD schreiben. Ich bevorzuge pv wie oben schon erwähnt. Wenn fertig muss die SSD einfach nur in den Ziel-Rechner eingebaut sein und dieser muss auf EFI stehen, Secure Boot aus, CSM am besten auch deaktivieren.

[wanne]

Mit einem SATA USB Adapter hatte ich das ja schon auf meinem Win PC so gemacht. Mit dem obigen Ergebnis.
Aber wenn ein Debian PC den Unterschied macht, hätte ich noch einen Raspi mit dem ich das machen könnte.

Im allgemeinen ist das etwas fehleranfälliger. Aber mittlerweile gibt es auch da gute tools. Problem ist vermutlich eher die externe Festplatte beim Booten auf dem Zielsystem. Dass das UEFI Treiber für den USB zu SATA adapter hat halte ich jetzt mal für alles andere als gegeben.
Wie gesagt: Laut standard müssen mindestens USB-Sticks (die deutlich anders funktionieren) unterstützt werden. Und schon da hapert es oft.
Sobald der Eintrag mal da ist sieht es oft deutlich besser aus einen spezifischen Eintrag zu booten scheint einfacher zu sein als sich durchs Dateisystem zu wühlen. In sofern brauchst du ja keine X-GiB für HAOS sondern es reicht ein Stick mit 2GiB für dein debian Image.

[Rico81]

Als ich den Debian Live USB Stick eingesteckt hatte und das BIOS "UEFI USB" anbot, wusste ich schon, dass das jetzt klappen würde
Und so wars dann auch!
Die zwei Befehle von Wanne ausgeführt und nun schnurrt es...
Tausend Dank an euch alle; tausend und eins Dank an:

Wie gesagt: Laut standard müssen mindestens USB-Sticks (die deutlich anders funktionieren) unterstützt werden. Und schon da hapert es oft.

Der Unterschied USB Stick/USB Festplatte war also genau das ausschlaggebende!

Case closed