0.6.0 USB-Installation [gelöst => "dd" verwenden!]

  • ich nehme alles zurück - auch mit der von mir beschriebenen Methode gibt es Probleme - die Installationsroutine bricht nun bei "Paketmanager konfigurieren" ab.


    Nun habe ich mal das yavdr64-0.6.0-efi.iso mit dem Ubuntu-eigenem 'Startmedienersteller' (aus 15.10) auf den USB-Stick geschrieben, den ich vorher in diesem Tool gelöscht habe.


    Immerhin bin ich nun schon mal problemlos bis zum preseed gekommen - die Installation läuft noch...

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, Sundtek MediaTV Digital Home (DVB-C/T), KNC One DVB-C, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive Asus GT610, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD

  • UEFI wird überbewertet. :D


    Frohes Neues und Danke für die Arbeit. Ich hoffe, ich kann damit was anfangen...


    Lars

  • Moin und ebenfalls ein frohes neues Jahr! :sleep


    Die Installation ist erfolgreich durchgelaufen. Der Faktor, um den sich durch UEFI die Bootgeschwindigkeit verbessert, höngt individuell vom Board ab. Bei manchen ist es eine wahre Offenbarung. Bei meinem Desktop-Rechner habe ich wenige Sekunden nach dem Einschalten eine aufgebaute Xfce-Oberfläche. Ohne UEFI dauert es fast 30 Sekunden mehr.

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, Sundtek MediaTV Digital Home (DVB-C/T), KNC One DVB-C, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive Asus GT610, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD

  • Betrifft das denn nur die Installation von einem USB-Medium oder auch die Installation von einer CD mit Überlänge bzw. einer DVD?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • UEFI wird überbewertet. :D


    Ich kann kein UEFI leiden. (Das sagen übrigens alle Ahnungslosen über unbekannte Sachen)



    -easyVDR kann UEFI weil es auch schon seit nem Jahr Mainboards ohne CSM gibt.
    -Das Booten mit EFi geht etwas schneller.
    -Zumindest ich habe keine gute Lösung für das Wechseln von Festplatten zu Testzwecken. Meiner Meinung nach solle alles auf der Festplatte sein was man braucht um zu booten. Bei UEFi nehme ich Boot-Repair nach nem Festplattentausch.Das kanns ja nicht sein...



    Ach ja: Meine Methode funktioniert mit CD, DVD, Stick. (was ich noch unterschlagen habe nach dem ISO bauen: ein "isohybrid -u neues.iso")
    Für nen Stick erstellen sehe ich nur zwei Möglichkeiten als Distributor: dd, Win32DiskImager. Die ganzen anderen Frickeltools verändern etwas was der Distributor nicht im Griff hat. Ausnahme das oben als Abkürzung genannte easy2boot. Das ist super um sich einen Werkzeugstick zu erstellen. Da kann das ISO ggf. auch nur direkt auf den Stick kopiert werden. Aber auch das kann nicht von einem dritten supportet werden.

  • -Zumindest ich habe keine gute Lösung für das Wechseln von Festplatten zu Testzwecken. Meiner Meinung nach solle alles auf der Festplatte sein was man braucht um zu booten.

    Eigentlich kann man auf jeder Platte eine dazugehörige UEFI-Boot Partition anlegen (nur Windows kommt damit nicht zurecht, wenn es mehrere davon zum Zeitpunkt der Installation gibt).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ich nehme alles zurück - auch mit der von mir beschriebenen Methode gibt es Probleme - die Installationsroutine bricht nun bei "Paketmanager konfigurieren" ab.


    Nun habe ich mal das yavdr64-0.6.0-efi.iso mit dem Ubuntu-eigenem 'Startmedienersteller' (aus 15.10) auf den USB-Stick geschrieben, den ich vorher in diesem Tool gelöscht habe.


    Immerhin bin ich nun schon mal problemlos bis zum preseed gekommen - die Installation läuft noch...


    Muss dann der Stick trotzdem noch vorbereitet werden wenn der Startmedienersteller von Ubuntu genutzt wird oder kann man direkt dass per generierte efi-iso nutzen?


    Habe mir gerade mal HW für einen neuen VDR bestellt, mit einer einer NVMe m.2 SSD. Mit komplett abgeschaltetem CSM sind da wahnsinnige Boot-Geschwindigkeiten drin.

  • ich glaube es reicht, im Startmedienersteller die Löschfunktion zu verwenden, so dass er als leer erkannt wird.

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, Sundtek MediaTV Digital Home (DVB-C/T), KNC One DVB-C, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive Asus GT610, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD

  • mkisofs --help meldet bei mir (Ubuntu 15.10) in der Liste der options

    Code
    1. -e FILE, -efi-boot FILE Set EFI boot image name

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, Sundtek MediaTV Digital Home (DVB-C/T), KNC One DVB-C, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive Asus GT610, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD

  • Ok, habe mich mal durch den cdrtools-Wust gequält:
    Das eigentlich mkisofs (aus den cdrtools) kennt die Optione "-e" nicht. Debian hat cdrtools irgendwann geforked und mkisofs in genisoimage umbenannt, danach sind auch neue Optionen u.a. das "-e" hinzugekommen.
    Beim "Original" mkisofs geht es mit "-eltorito-platform efi -b boot/grub/efi.img" anstatt "-e boot/grub/efi.img".


    Habe das iso auch mit dem usb-creator auf den Stick gebracht, /cdrom musste ich per "mount -o bind /media /cdrom" einbinden, sonst ging es nicht weiter.
    Jetzt scheitere ich aber an zwei Problemen:


    - Grub installiert sich nicht: meckert was von "grub-efi-amd64-signed konnte nicht nach /target/ installiert werden" (grub-efi-amd64-signed failed to install into /target/)
    - yavdr spuckt beim seed einen Fehler 127, eventuell ein Folgefehler aus der fehlgeschlagenen Grub Installation oder etwas anderes? Gibt es ein Log wo man Details dazu finden könnte? (Mein zweiter Tip wäre das Nichtvorhandensein von /dev/sd<irgendwas>, ich hab nur /dev/nvme0ns1 (NVMe SSD))

  • Nimm den Startmedienersteller von Ubuntu!

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, Sundtek MediaTV Digital Home (DVB-C/T), KNC One DVB-C, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive Asus GT610, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 18.04 per SSD

  • Die einzige wirklich zuverlässige Variante das yavdr.iso auf einen USB Stck zu bekommen ist dd, ich habe in der Vergangenheit diverse Tools unter Windows probiert und auch das Ubuntu Tools verwendet. Keine konnten zuverlässig einen yaVDR USB Stick erstellen, die Installation wurde immer abgebrochen beim "preseed".


    Mit folgendem Befehl hat es aber immer geklappt:

    Code
    1. dd if=yavdr64-0.6.0.iso of=/dev/sdx bs=1M

    Gruß
    Frodo

  • Die einzige wirklich zuverlässige Variante das yavdr.iso auf einen USB Stck zu bekommen ist dd

    Für Konsolenallergiker gibt es auch die Möglichkeit über ein Programm mit GUI zu gehen - das gnome-disk-utility kann z.B. auch Images 1:1 auf USB-Sticks schreiben.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Damit bekommt man aber kein UEFI boot oder?


    Ich hatte bisher noch keine Probleme mit UEFI allerdigs können alle BIOSe die ich aktuell habe auch noch den Legacy Mode. Solange der USB Stick aber als socher erkannt wird und nicht eine HDD darstellt sollte es aber auch bei einem UEFI Only System kein Problem sein.
    Vorrausgesetzt das BIOS ist nicht vermurkst.

    Gruß
    Frodo

  • Da verkennst Du leider einige Abhängigkeiten. Zwar "können" aktuelle BIOSe auch noch (sogenannter CSM Modus) normal booten, aber das ist (im Vergleich zu nativ UEFI/Fast-Boot) nicht nur langsam sondern ggf. inkompatibel mit parallel installierten Systemen und/oder GPT. Für UEFI Boot muss, je nach Datenträgertyp, eine Voraussetzung erfüllt werden, das hat nicht mit einem "Buggy BIOS" zu tun. Für CD-Boot (und das betrifft imho auch per dd o.ä. auf USB-Sticks geschriebene ISOs) muss ein entsprechender Eintrag im ISO-Header sein. Der ist beim yavdr 0.6.0 nicht vorhanden, deswegen die Vorbehandlung mit mkisofs.
    Für den Boot als Datenträger muss es ein entsprechendes Verzeichnis mit einem Bootloader geben, bin mir nicht sicher ob das beim "Original" yavdr ISO dabei ist, aber anscheinend funktionieren dann einige Zuordnungen nicht.


    An den Moderator: Macht es evtl Sinn die UEFI Diskussion in einen neuen Thread zu verschieben? Das ursprünglich Problem ist ja gelöst...