Seite 1 von 1

VU+ 4K MultiBoot

Verfasst: So 22. Sep 2019, 23:04
von BPanther
Diese Anleitung gilt für die folgenden Receiver: VU+ DUO 4K SE, VU+ DUO 4K, VU+ UNO 4K SE, VU+ ZERO 4K, VU+ ULTIMO 4K, VU+ SOLO 4K und VU+ UNO 4K.

Da die Receiver bezüglich MultiBoot gleich sind, habe ich die einzelnen Beiträge zu einem zusammengefasst.

Dank redblue-pkt ist es möglich, ähnlich wie bei der HD51 ein MultiBoot zu haben, was bis zu 4 Images ermöglicht. In Zusammenarbeit mit ihm konnten noch kleinere Fehler beseitigt werden, so daß es nun stabil funktioniert und auch so, wie es soll. Ich habe das Multiboot von der VU+ SOLO 4K auch auf die VU+ DUO 4K SE, VU+ DUO 4K, VU+ UNO 4K SE, VU+ ZERO 4K, VU+ ULTIMO 4K und VU+ UNO 4K adaptiert, so daß auch dort ein Multiboot möglich wurde. Die Partitionsgrößen betragen dabei 4x 921 MB für Root und 4x 6 MB für die Kernel. Der Rest verteilt sich auf STARTUP, Splash (das Haupt-Startlogo) und initrd ("2. Loader"). Aber auch der Normal-Betrieb hat eine leicht geänderte Partitionierung bekommen, so daß auch da für Root etwas mehr Speicher möglich wurde. Die neue initrd unterstützt somit beide Varianten und wird daher auch so im GIT statt der originalen initrd enthalten sein.

Allerdings sollte man folgendes beachten: Startet die Partition nicht mehr, von der gestartet wurde, so muß diese Partition neu geflasht werden, da es keine "Notfall-Umschaltung" zu einer anderen Partition gibt. Das könnte nur der Loader, aber der kennt ja kein MultiBoot. Das flashen der einzelnen Partition funktioniert jedoch problemlos vom USB Stick, ohne dabei die anderen Partitionen zu beeinflussen.

Die neuen Partitionen für Kernel und Root sind wie folgt angeordnet:
Partitionen VU+ DUO 4K SE VU+ DUO 4K VU+ UNO 4K SE VU+ ZERO 4K VU+ ULTIMO 4K VU+ UNO 4K VU+ SOLO 4K
Kernel 1 mmcblk0p9 mmcblk0p9 mmcblk0p4 mmcblk0p7 mmcblk0p4 mmcblk0p4 mmcblk0p4
Root 1 mmcblk0p10 mmcblk0p10 mmcblk0p5 mmcblk0p8 mmcblk0p5 mmcblk0p5 mmcblk0p5
Kernel 2 mmcblk0p11 mmcblk0p11 mmcblk0p6 mmcblk0p9 mmcblk0p6 mmcblk0p6 mmcblk0p6
Root 2 mmcblk0p12 mmcblk0p12 mmcblk0p7 mmcblk0p10 mmcblk0p7 mmcblk0p7 mmcblk0p7
Kernel 3 mmcblk0p13 mmcblk0p13 mmcblk0p8 mmcblk0p11 mmcblk0p8 mmcblk0p8 mmcblk0p8
Root 3 mmcblk0p14 mmcblk0p14 mmcblk0p9 mmcblk0p12 mmcblk0p9 mmcblk0p9 mmcblk0p9
Kernel 4 mmcblk0p15 mmcblk0p15 mmcblk0p10 mmcblk0p13 mmcblk0p10 mmcblk0p10 mmcblk0p10
Root 4 mmcblk0p16 mmcblk0p16 mmcblk0p11 mmcblk0p14 mmcblk0p11 mmcblk0p11 mmcblk0p11

Dateien des USB Stick für Normal-Boot (Standard)
- kernel_auto.bin -> Kernel des Wunsch-Images
- rootfs.tar.bz2 -> Root des Wunsch-Images
- initrd_auto.bin -> wahlweise die des Wunsch-Images oder die neue für "MultiBoot"
- splash_auto.bin -> optional, eigenes Bild
- reboot.update -> (0 Byte dummy) - optional, automatischer Neustart nach Update, nicht bei VU+ ZERO 4K und VU+ UNO 4K vorhanden
- mkpart.update -> (0 Byte dummy) - damit die Partitionen erzeugt werden
- force.update -> (0 Byte dummy) - Update direkt vom USB-Stick starten, nur bei VU+ ZERO 4K und VU+ UNO 4K notwendig da keine Powertaste vorhanden

Neue Dateien des USB Stick für MultiBoot, alle Partitionen gleichzeitig flashen, auch mit unterschiedlichen Images
- kernel1_auto.bin -> neues Kernel für MultiBoot
- kernel2_auto.bin -> wie 1 (auch für E2 das Neutrino-Kernel benutzen und nicht das von E2 mitgelieferte, sonst hängt der Bootvorgang!)
- kernel3_auto.bin -> wie 1 (auch für E2 das Neutrino-Kernel benutzen und nicht das von E2 mitgelieferte, sonst hängt der Bootvorgang!)
- kernel4_auto.bin -> wie 1 (auch für E2 das Neutrino-Kernel benutzen und nicht das von E2 mitgelieferte, sonst hängt der Bootvorgang!)
- rootfs1.tar.bz2 -> Root Wunsch-Image 1
- rootfs2.tar.bz2 -> Root Wunsch-Image 2
- rootfs3.tar.bz2 -> Root Wunsch-Image 3
- rootfs4.tar.bz2 -> Root Wunsch-Image 4
- initrd_auto.bin -> die neue für "MultiBoot"
- splash_auto.bin -> optional, eigenes Bild
- reboot.update -> (0 Byte dummy) - optional, automatischer Neustart nach Update, nicht bei VU+ ZERO 4K und VU+ UNO 4K vorhanden
- mkpart.update -> (0 Byte dummy) - damit die neuen Partitionen erzeugt werden
- rootfs.tar.bz2 -> (0 Byte dummy) - damit geflasht wird
- kernel_auto.bin -> (0 Byte dummy) - damit geflasht wird
- force.update -> (0 Byte dummy) - Update direkt vom USB-Stick starten, nur bei VU+ ZERO 4K und VU+ UNO 4K notwendig da keine Powertaste vorhanden

Wichtig
Beim ersten umstellen auf Multiboot müssen ALLE Partitionen mit einem Image geflasht werden, d.h. es müssen alle 4 rootfsX.tar.bz2 und kernelX_auto.bin vorhanden sein,
da ansonsten die Box auch nicht starten wird. Hierzu ggf. dazu das rootfs1.tar.bz2 nach rootfs2.tar.bz2, rootfs3.tar.bz2 und rootfs4.tar.bz2 umkopieren. Erst danach ist auch das
flashen der einzelnen Partitonen separat möglich.


Neue Dateien des USB Stick für MultiBoot, nur eine der 4 Partitionen flashen, hier für Partition 3
- kernel3_auto.bin -> neues Kernel für MultiBoot
- rootfs3.tar.bz2 -> Wunsch-Image für Partition 3
- initrd_auto.bin -> die neue für "MultiBoot"
- reboot.update -> (0 Byte dummy) - optional, automatischer Neustart nach Update, nicht bei VU+ ZERO 4K und VU+ UNO 4K vorhanden
- rootfs.tar.bz2 -> dummy (0 Byte) - damit geflasht wird
- kernel_auto.bin -> dummy (0 Byte) - damit geflasht wird
- force.update -> (0 Byte dummy) - Update direkt vom USB-Stick starten, nur bei VU+ ZERO 4K und VU+ UNO 4K notwendig da keine Powertaste vorhanden

Wichtig
Wer zurück auf den Normal-Betrieb will, nimmt die Dateien des zu flashenden Images, ABER es muß beim ersten umstellen auf Normal-Boot unbedingt die initrd_auto.bin von mir
benutzt werden, ansonsten wird das Image nicht starten, da der Startbereich noch falsch (auf Multiboot und nicht mehr existierender bzw. nun ungültiger Partition) eingestellt ist.
Erst danach kann man wie gewohnt ein "normales" Image flashen mit den vom Image mitgelieferten Dateien.


Hier mal einige Bilder, wie es mit MultiBoot bei mir auf den entsprechenden Receivern aussieht.
VU+ DUO 4K SE VU+ DUO 4K VU+ UNO 4K SE VU+ ZERO 4K VU+ ULTIMO 4K VU+ UNO 4K VU+ SOLO 4K

Das MultiBoot wurde bisher getestet mit den E2 Images:
- Original Image -> OK (ABER: stb-startup v1.04 benutzen mit manuellem fstab Eintrag und es ist die IPK des STB-Startup von Hand auszupacken und zu kopieren)
- openATV 6.3/6.4/6.5/7.0/7.1/7.2/7.3 -> OK - ab Neutrino rev18770 neues Kernel verfügbar für VUDUO4K/VUUNO4KSE/VUZERO4K, notwendig ab openATV 6.4 (Mai 2020)
- Hyperion 6.4 -> OK
- OpenVIX 5.3 -> OK
- OpenVIX 6.2 -> STARTET NICHT
- VTI 14.0.5 / 15.0.0 -> OK (ABER: stb-startup v1.04 benutzen mit manuellem fstab Eintrag)
- openPLI 7.1 -> OK
- EGAMI 10 -> OK

Im Prinzip sollte es keine Probleme mit den Images im Multibootbetrieb geben. Lediglich ein volles Upgrade z.B. von OATV 6.3 auf OATV 6.4 innerhalb des Images wird schief gehen, da zum einen das Flashprogramm von E2 keine Multiboot-Partitionen beherrscht und daher damit nicht umgehen kann und zum anderen ggf. auch das Kernel, was nicht Multiboot fähig ist, geflasht wird.

redblue-pkt hat das ofgwrite für die VU+ SOLO 4K angepasst (und ich entsprechend erweitert für die VU+ DUO 4K SE, VU+ DUO 4K, VU+ UNO 4K SE, VU+ ZERO 4K, VU+ ULTIMO 4K und VU+ UNO 4K), so daß auch hiermit wie bei der HD51 in andere Partitionen (mit -mX oder --multi=X), geflasht werden kann.

Wichtig
Es sollten auch mit ofgwrite immer die korrekten Kernel- und Root-Dateinamen benutzt werden und NICHT einfach nur kernel_auto.bin und rootfs.tar.bz2,
da das ansonsten ALLE Partitionen beschädigen kann und ein vollständiges neues flashen aller Partitionen dann notwendig macht. Das wäre dann so, als
wenn man neu von Normal- auf Multiboot umstellen würde. Ist aber dann notwendig, damit die Partitionen repariert werden können.

Und: Es muss ofgwrite von Neutrino verwendet werden, denn das von E2 unterstützt dieses Multiboot nicht.



Besten Dank auch an devil7 für das ausführliche testen auf der VU+ UNO 4K. Er hatte es nicht leicht mit mir. :mrgreen:

Es wird nur MultiBoot-Images geben - das "normale" Boot-Image ist nicht geplant.

Re: VU+ MultiBoot

Verfasst: So 22. Sep 2019, 23:45
von BPanther
Ich habe mal versucht, eine einfache Umschaltung aus E2 heraus zu ermöglichen. Dazu habe ich eine Plugin-Demo angepasst und mit dem E2 von openATV getestet.

In die Datei /etc/fstab muß folgende Zeile manuell hinzugefügt werden und nach einem Neustart steht die Partition für die Umschaltung zwischen den Partitionen zur Verfügung:

VU+ UNO 4K / VU+ UNO 4K SE / VU+ ULTIMO 4K / VU+ SOLO 4K

Code: Alles auswählen

/dev/mmcblk0p1       /boot                auto       defaults              1  1
VU+ ZERO 4K

Code: Alles auswählen

/dev/mmcblk0p4       /boot                auto       defaults              1  1
VU+ DUO 4K / VU+ DUO 4K SE

Code: Alles auswählen

/dev/mmcblk0p6       /boot                auto       defaults              1  1
plugin_bild1.png
plugin_bild2.png
plugin_bild3.png
Wie man sieht, sehr einfach gehalten. Es sollten hier nur STARTUP_1 bis STARTUP_4 ausgewählt werden für die Umschaltung der einzelnen Partitionen.

Nach der Auswahl einfach nur noch einen Neustart der Box durchführen.
plugin_bild4.png
enigma2-stb-startup_1.04-20200904_all.ipk
enigma2-stb-startup_1.05-20201017_all.ipk

Re: VU+ MultiBoot

Verfasst: So 20. Okt 2019, 23:02
von BPanther
Hier noch etwas für fortgeschrittene Benutzer, die ein serielles Kabel haben und entsprechend damit umgehen können.

Startet eine Partition nicht mehr, muß man diese neu flashen, weil die Box ja nicht mehr startet und man auch nicht umschalten kann. Nunja, das stimmt so nicht ganz, denn hier kommt das serielle Kabel ins Spiel. Man kann damit nämlich den Bootloader auch mit STRG-C unterbrechen beim starten, was dann in etwa so aussieht (gekürzt):

Code: Alles auswählen

CPU 0123
BCM74450040
...
GO!

    ,/
  ,'/___, BOLT v1.21 v1.21 LOCAL BUILD
.'__  ,'  (2017-12-15 11:39:14 Vuplus team)
   /,'    Copyright (C) 2017 Broadcom
  /'

Board: ULTIMO4K
SYS_CTRL: product=7444, family=7445e0, strap=000005b6,
otp @ 0xf0404030 = 0x822000e0: en_cr(0x00000060) en_testport(0x00000080) macrovision_disable(0x02000000) moca_disable(0x80000000) rv9_disable(0x00200000)
otp @ 0xf0404034 = 0x00000001: moca2_disable(0x00000001)
CPU: 4x B15 [420f00f3] 1503 MHz
SCB: 432 MHz
DDR0 @ 1200MHz, DDR1 @ 1200MHz, DDR2 @ 1200MHz
RESET CAUSE: 0x000200 software_master (1 of 21 possible causes)
******************************************
Automatic startup canceled via Ctrl-C
******************************************
...
Hier sieht man, STRG-C wurde akzeptiert, diese Meldung MUSS kommen. Dann kann man STRG-C loslassen.
...
readFrontKey 0 0
Check ignore.update file
Checking usbdisk0:/vuplus/ultimo4k/ignore.update......NO
Check force.update file
Checking usbdisk0:/vuplus/ultimo4k/force.update......NO
bolt update ...Checking usbdisk0:/vuplus/ultimo4k/bolt_auto.bin......NO
Checking usbdisk0:/vuplus/ultimo4k/rootfs.tar.bz2......NO
....NO
Checking usbdisk0:/vuplus/ultimo4k/splash_auto.bin......NO
Checking usbdisk0:/vuplus/ultimo4k/kernel_auto.bin......NO
BOLT>
So bleibt der dann stehen. Man kann nun einiges von Hand erledigen, aber auch die Box richtig schrotten wenn man was falsch macht. Daher ist das nur für Benutzer gedacht, die sich damit auch auskennen.

Um nun zu einer anderen Partition temporär (wird NICHT dauerhaft gespeichert) zu wechseln braucht man nur die passende boot-Zeile. Als Beispiel für Partition 4 der Ultimo4K:

Code: Alles auswählen

boot emmcflash0.kernel_4 'root=/dev/mmcblk0p11 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
Es startet dann sofort die Partition 4 durch.

Nun fragt sich der eine oder andere: Wozu das ganze? Man kann doch direkt auch die defekte Partition flashen ohne die anderen zu beeinflussen. Klar geht das, aber wenn das Backup nun ausgerechnet auf der internen HDD gespeichert ist und man die nicht extra ausbauen will (die Ultimo4K hat die richtig eingebaut, verschraubt) um an das Backup heranzukommen, bietet sich diese Art der temporären Umschaltung an. So kann man über das funktionsfähige Image entweder per Telnet flashen oder sich das Backup auf einen USB-Stick kopieren und dann mit diesem flashen.

Hier nun die gesamten Boot-Zeilen für alle 4K-Boxen. Welche Partition mit welcher Zeile gestartet wird sollte sich von selbst erklären.

Duo4K SE:

Code: Alles auswählen

boot flash0.kernel_1 'libata.force=1:3.0G,2:3.0G,3:3.0G root=/dev/mmcblk0p10 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
boot flash0.kernel_2 'libata.force=1:3.0G,2:3.0G,3:3.0G root=/dev/mmcblk0p12 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
boot flash0.kernel_3 'libata.force=1:3.0G,2:3.0G,3:3.0G root=/dev/mmcblk0p14 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
boot flash0.kernel_4 'libata.force=1:3.0G,2:3.0G,3:3.0G root=/dev/mmcblk0p16 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
Duo4K:

Code: Alles auswählen

boot flash0.kernel_1 'root=/dev/mmcblk0p10 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=500m bmem=891m@1156m bmem=575m@3520m'
boot flash0.kernel_2 'root=/dev/mmcblk0p12 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=500m bmem=891m@1156m bmem=575m@3520m'
boot flash0.kernel_3 'root=/dev/mmcblk0p14 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=500m bmem=891m@1156m bmem=575m@3520m'
boot flash0.kernel_4 'root=/dev/mmcblk0p16 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=500m bmem=891m@1156m bmem=575m@3520m'
Solo4K:

Code: Alles auswählen

boot emmcflash0.kernel_1 'root=/dev/mmcblk0p5 rw rootwait rootflags=data=journal debug coherent_pool=2M brcm_cma=504M@0x10000000 brcm_cma=260M@0x2f800000 brcm_cma=1024M@0x80000000'
boot emmcflash0.kernel_2 'root=/dev/mmcblk0p7 rw rootwait rootflags=data=journal debug coherent_pool=2M brcm_cma=504M@0x10000000 brcm_cma=260M@0x2f800000 brcm_cma=1024M@0x80000000'
boot emmcflash0.kernel_3 'root=/dev/mmcblk0p9 rw rootwait rootflags=data=journal debug coherent_pool=2M brcm_cma=504M@0x10000000 brcm_cma=260M@0x2f800000 brcm_cma=1024M@0x80000000'
boot emmcflash0.kernel_4 'root=/dev/mmcblk0p11 rw rootwait rootflags=data=journal debug coherent_pool=2M brcm_cma=504M@0x10000000 brcm_cma=260M@0x2f800000 brcm_cma=1024M@0x80000000'
Ultimo4K:

Code: Alles auswählen

boot emmcflash0.kernel_1 'root=/dev/mmcblk0p5 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
boot emmcflash0.kernel_2 'root=/dev/mmcblk0p7 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
boot emmcflash0.kernel_3 'root=/dev/mmcblk0p9 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
boot emmcflash0.kernel_4 'root=/dev/mmcblk0p11 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=622m bmem=630m@394m bmem=383m@1665m bmem=443m@2625m'
Uno4K:

Code: Alles auswählen

boot emmcflash0.kernel_1 'root=/dev/mmcblk0p5 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=633m bmem=637m@383m bmem=637m@2431m'
boot emmcflash0.kernel_2 'root=/dev/mmcblk0p7 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=633m bmem=637m@383m bmem=637m@2431m'
boot emmcflash0.kernel_3 'root=/dev/mmcblk0p9 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=633m bmem=637m@383m bmem=637m@2431m'
boot emmcflash0.kernel_4 'root=/dev/mmcblk0p11 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=633m bmem=637m@383m bmem=637m@2431m'
Uno4K SE:

Code: Alles auswählen

boot emmcflash0.kernel_1 'root=/dev/mmcblk0p5 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=666m bmem=641m@350m bmem=641m@2430m'
boot emmcflash0.kernel_2 'root=/dev/mmcblk0p7 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=666m bmem=641m@350m bmem=641m@2430m'
boot emmcflash0.kernel_3 'root=/dev/mmcblk0p9 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=666m bmem=641m@350m bmem=641m@2430m'
boot emmcflash0.kernel_4 'root=/dev/mmcblk0p11 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M vmalloc=666m bmem=641m@350m bmem=641m@2430m'
Zero4K:

Code: Alles auswählen

boot flash0.kernel_1 'root=/dev/mmcblk0p8 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M rw bmem=699m@1317m'
boot flash0.kernel_2 'root=/dev/mmcblk0p10 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M rw bmem=699m@1317m'
boot flash0.kernel_3 'root=/dev/mmcblk0p12 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M rw bmem=699m@1317m'
boot flash0.kernel_4 'root=/dev/mmcblk0p14 rootfstype=ext4 rootflags=data=journal rootwait rw coherent_pool=2M rw bmem=699m@1317m'
Nochmal der Hinweis: Jeder muß selbst wissen was er da macht und ist eigenverantwortlich und haftet selbst, wenn etwas dabei schief geht und die Box komplett tot ist weil z.B. der Bootloader überschrieben/beschädigt wurde. Ich gebe nur Hinweise, wie es funktionieren bzw. wie man es alternativ machen kann. Wer da nicht sicher ist, sollte es sein lassen und normal via USB-Stick flashen.

Re: VU+ MultiBoot

Verfasst: Mo 17. Feb 2020, 07:41
von BPanther
Noch ein kleiner Nachtrag: Es geht übrigens auch noch weitaus kürzer sofern die Startup-Partition intakt ist. Erspart das kopieren und man kann das auch ggf. von Hand eingeben. :)

DUO4KSE/DUO4K/ZERO4K:

Code: Alles auswählen

batch -fatfs flash0.startup:STARTUP_1
batch -fatfs flash0.startup:STARTUP_2
batch -fatfs flash0.startup:STARTUP_3
batch -fatfs flash0.startup:STARTUP_4
SOLO4K/ULTIMO4K/UNO4K/UNO4KSE:

Code: Alles auswählen

batch -fatfs emmcflash0.startup:STARTUP_1
batch -fatfs emmcflash0.startup:STARTUP_2
batch -fatfs emmcflash0.startup:STARTUP_3
batch -fatfs emmcflash0.startup:STARTUP_4

Re: VU+ MultiBoot

Verfasst: Sa 28. Mär 2020, 15:24
von BPanther
Ich habe das E2 Startup Plugin aus diesem Thread weiter oben aktualisiert, nun Version 1.01. Die Schrift ist nach dem Umschalten nun größer.

Re: VU+ MultiBoot

Verfasst: So 21. Jun 2020, 19:24
von BPanther
Ich habe das E2 Startup Plugin aus diesem Thread weiter oben erneut aktualisiert, nun Version 1.02. Im Titel ist nun die aktive Partition sichtbar.

Re: VU+ MultiBoot

Verfasst: Di 18. Aug 2020, 23:50
von BPanther
Ich habe das E2 Startup Plugin aus diesem Thread weiter oben erneut aktualisiert, nun Version 1.03. Diese Version ist mit Python 3 kompatibel, funktioniert aber auch unter Python 2 von OATV 6.4 oder älter. Die aktuelle Version 1.03 ist z.B. bei OATV 6.5 wichtig, da ältere Versionen dort nicht mehr funktionieren.

Re: VU+ MultiBoot

Verfasst: Fr 4. Sep 2020, 17:11
von BPanther
Ich habe das E2 Startup Plugin aus diesem Thread weiter oben erneut aktualisiert, nun Version 1.04. Kleinere Fehlerbehebungen bei der Anzeige der aktiven Partition.

Re: VU+ MultiBoot

Verfasst: Sa 17. Okt 2020, 17:28
von BPanther
Ich habe das E2 Startup Plugin aus diesem Thread weiter oben erneut aktualisiert, nun Version 1.05. Der Eintrag in /etc/fstab sollte nun nicht mehr notwendig sein.

Hinweis: Bei VTi ist weiterhin die v1.04 zu benutzen mit manuellem Eintrag in der fstab.

Re: VU+ 4K MultiBoot

Verfasst: Do 30. Jun 2022, 17:23
von BPanther
Ab openATV v7.x (Ende Juni 2022) ist das E2-STB-Startup Plugin nicht mehr notwendig. Anscheinend werden nun auch echte Partitionen unterstützt. Neutrino erscheint in der Multiboot-Liste, allerdings erst ab Neutrino rev19910 vom 01.07.2022. Wird eine ältere Neutrino Version benutzt kann mit der eingebauten E2 Funktion nicht dorthin umgeschaltet werden.
oatv70_mb.png

Das gilt übrigens auch für die HD51/H7/BRE/E4HDULTRA.


EDIT 02.10.2022: Bei der Duo4K und Duo4K SE braucht es etwas Nachhilfe unter OATV 7.x. Anbei eine angepasste Multiboot.py. Damit wird auch hier das Multiboot erkannt und das Menü eingeblendet.
Neuer Link zur Multiboot.py -> HIER

Re: VU+ 4K MultiBoot

Verfasst: Do 6. Okt 2022, 15:14
von BPanther
Ab rev20040 der VU4K Images wird es auch eine neue Version der initrd_auto.bin geben. Diese ermöglicht es, einen beschädigten STARTUP Bereich komplett neu aufzubauen. Es wird durch formatieren sowie dem neuen aufbauen der STARTUP-Dateien somit der STARTUP Bereich repariert. Es wird dabei nichts anderes gemacht, alle Images bleiben wie sie sind. Desweiteren kann man auch gleich eine Startpartition festlegen. Durchaus hilfreich wenn mal eine Partition nicht startet, man diese aber nicht gleich komplett flashen will, weil man davon noch etwas benötigt oder man diese von Hand über ein anderes Image reparieren will. Oder wenn E2 ein Kernelupdate versucht und somit den STARTUP Bereich beschädigt, da dieser früher mal der Kernel Bereich war.

Zur Reparatur der STARTUP Partition werden folgende Dateien auf dem USB Stick benötigt:
- startup.update -> Für die einzelne Reparatur des STARTUP Bereichs. Trägt man in dieser Datei eine Ziffer ein (1, 2, 3 oder 4) wird direkt beim Neustart der Box statt auf die erste auf die angegebene Partition umgeschaltet. Ansonsten kann die Datei auch leer sein, also ein 0 Byte dummy.
- initrd_auto.bin -> die neue für "MultiBoot"
- reboot.update -> (0 Byte dummy) - optional, automatischer Neustart nach Update, nicht bei VU+ ZERO 4K und VU+ UNO 4K vorhanden
- rootfs.tar.bz2 -> dummy (0 Byte) - damit geflasht wird
- kernel_auto.bin -> dummy (0 Byte) - damit geflasht wird
- force.update -> (0 Byte dummy) - Update direkt vom USB-Stick starten, nur bei VU+ ZERO 4K und VU+ UNO 4K notwendig da keine Powertaste vorhanden

Sollten sich noch andere Dateien auf dem USB Stick befinden, werden diese ignoriert, denn durch das Vorhandensein der startup.update wird auch nur der STARTUP Bereich repariert.

Ich habe eine fertige ZIP Datei vorbereitet für alle 7 VU+ 4K Boxen und in alle Verzeichnisse hochgeladen. Da die Datei für alle Boxen geeignet ist beträgt die Dateigröße rund 62 MB.

Re: VU+ 4K MultiBoot

Verfasst: Sa 12. Nov 2022, 13:41
von BPanther
Noch eine korrigierte Multiboot.py anbei. Diese ist unter OATV 7.x zu benutzen - für ALLE Boxen - wenn auch VTi installiert wird und/oder OATV 7.x auf einer VU DUO4K/VU DUO 4K SE verwendet wird. Da VTi eine "schlechte" /etc/issue verwendet führt das beim Multiboot unter OATV 7.x sonst zum Absturz. Das hat also nichts mit Neutrino zu tun und würde auch bei 4 E2 Images auftreten, das Problem liegt am VTi Image.
MultiBoot.zip

Wie auch die Vorgängerversion ist die Multiboot.py nach /usr/lib/enigma2/python/Tools/ zu kopieren. Anschließend eine vorhandene MultiBoot.pyo oder MultiBoot.pyc löschen und GUI oder Box neu starten.

Re: VU+ 4K MultiBoot

Verfasst: So 30. Jul 2023, 14:15
von BPanther
Anbei eine korrigierte Version ab OATV 7.3. Auf manchen Systemen gab es Probleme mit der älteren Version (thx esuo2).
MultiBoot.zip

Wie auch die Vorgängerversion ist die Multiboot.py nach /usr/lib/enigma2/python/Tools/ zu kopieren. Anschließend eine vorhandene MultiBoot.pyo oder MultiBoot.pyc löschen und GUI oder Box neu starten.

Re: VU+ 4K MultiBoot

Verfasst: Di 1. Aug 2023, 06:52
von BPanther
Ab rev20411 der VU4K Images wird es auch eine neue Version der initrd_auto.bin geben. Diese ermöglicht es, über die Datei mkpart.update die Anzahl der Partitionen statt wie üblich 4 auf 2 oder 3 zu ändern. Dazu die Datei mkpart.update editieren, den Inhalt löschen und dann nur die Ziffer 2 für 2 Partitionen oder die Ziffer 3 für 3 Partitionen eintragen. Die Größe der Root-Partitionen wird dabei wie vorher auch entsprechend gleichmäßig aufgeteilt. Der Ablauf ist ansonsten gleich wie mit 4 Partitionen, also ohne den Eintrag. Auch die Updates funktionieren wie gewohnt. Einzige Ausnahme: Es dürfen entsprechend der Partitionsanzahl auf dem USB-Stick auch nur die notwendigen Kernel- und Root-Dateien vorhanden sein.

Re: VU+ 4K MultiBoot

Verfasst: Mo 28. Aug 2023, 14:45
von BPanther
Die MultiBoot.py in OATV 7.3 wurde mal aktualisiert, gepatchte Version anbei.
MultiBoot.zip

Wie auch die Vorgängerversion ist die Multiboot.py nach /usr/lib/enigma2/python/Tools/ zu kopieren. Anschließend eine vorhandene MultiBoot.pyo oder MultiBoot.pyc löschen und GUI oder Box neu starten.