Penso anch'io sia proprio cosi, in quanto molto simile al 8000sf octagon (che ho)
Installazioni immagini in multiboot
- Thread starter paperino61
- Start date
paperino61
Active member
Si in effetti era come detto da Liquid..... però nel frattempo ho restituito il Gigablue ed ho preso un VU+DUO44se
NON ho capito come/cosa fai esattamente, ma io, che di vuplus ne ho e ne ho avuti parecchi, eseguo un backup della immagine su hdd, lo estraggo con il PC con un client FTP (filezilla).
Se per qualsiasi motivo il box non si avvia, formatto una penna usb ( FAT o FAT32) e estraggo la cartella 'VUPLUS' contenuta nello .ZIP nella penna USB
- spegni tutto
- penna dentro
- avvia
- su messaggio premi power, tocca ripetutamente il tasto LED sul frontalino
- ad operazione conclusa, il led lampeggia veloce, e puoi spegnere, estrarre la penna, riavviare
Diversamente, se il box si avvia ancora e vuoi ripristinare un backup immagine su uno dei slot liberi, ma anche occupati,
MENU
Gestione dei Backup
Backup immagine completo ( devo vedere se mi viene in mente qualcosa per facilitarne la comprensione, del tipo: Backup, Flash immagine completa)
Seleziona il backup o immagine scaricata
Tasto blu FLASH
Seleziona slot, non a forza uno libero
ciao
Ps.: sei un fu angels?
Last edited:
paperino61
Active member
ciao.... si è tutto chiarissimo ed è ciò che faccio anch'io.
quel che ho necessità di fare è, nel caso ad esempio la IMG posizionata in solot3 non parta più, è di accedere al recovery startup per, sempre ad esempio, far partire la IMG in slot 1. Nelle istruzioni Ev0, dove descrive il mutiboot della 5.2, spiega di inserire una penna con all'interno un file vuoto di nome STARTUP_RECOVERY. Quel che succede a me, è che non parte nulla e sembra azzerare tutto per il recovery, infatti devo ripartire riflasciando il VU e poi posso, dai backup, ripristinare le mie immagini
no sono un fu angels
ciao
paperino61
Active member
Ciao, questo è quanto trovo dopo aver inserito una penna con un file vuoto "STARTUP_RECOVERY" con altra usb e HDD staccati.
Il file esiste sulla penna; non succede nulla, ma la cosa brutta è che mi ritrovo con IL VU che non riparte e sono obbligato a riflashare e poi posso ripristinare le varie immagini dai backup
Boh????
paperino61
Active member
sicuramente frequentatore, ma passivo....
mai avuto le capcità e conoscenze per essere un mini guru paperino61
Active member
Avevo dimenticato l'allegato :-(
paperino61
Active member
Ciao Blu8, cosa intendi per "si flasha solo il kernel"?
KEXEC-1ST STAGE: STARTUP_RECOVERY not present in /dev/sda
KEXEC-1ST STAGE: STARTUP_RECOVERY not present in /dev/sda1
KEXEC-1ST STAGE: /dev/sdb is not a block device... skip
KEXEC-1ST STAGE: /dev/sdb1 is not a block device... skip
KEXEC-1ST STAGE: /dev/sdc is not a block device... skip
KEXEC-1ST STAGE: /dev/sdc1 is not a block device... skip
KEXEC-1ST STAGE: /dev/scdd is not a block device... skip
KEXEC-1ST STAGE: /dev/sdd1 is not a block device... skip
dal log sembra non stia proprio trovando il file...
prova a mettere la chiavetta sul decoder,
prova a dare i seguenti comandi da telnet e incolla qui quello che di risponde il decoder
cd /hdd
df -h .
ls -la
Togli dalla IMG il file pesante, sto fuori casa e non posso guardare, ma ha un nome del tipo rootfs tar.gz. o giù di li.
Flasha
paperino61
Active member
Ciao, questo è l'output di quanto chiesto
Using username "root".
root@vuduo4kse:~# cd /hdd
root@vuduo4kse:/hdd# df -h
Filesystem Size Used Available Use% Mounted on
/dev/mmcblk0p9 3.5G 1.9G 1.4G 58% /boot
/dev/mmcblk0p9 3.5G 1.9G 1.4G 58% /
tmpfs 790.6M 776.0K 789.8M 0% /var/volatile
tmpfs 790.6M 776.0K 789.8M 0% /sys/firmware/devicetree/base/chosen/bootargs
tmpfs 790.6M 776.0K 789.8M 0% /proc/cmdline
devtmpfs 781.6M 8.0K 781.6M 0% /dev
tmpfs 64.0K 0 64.0K 0% /media
/dev/sda1 931.1G 509.1G 422.0G 55% /media/hdd
/dev/sdb1 14.4G 612.5M 13.6G 4% /media/usb
none 790.6M 0 790.6M 0% /dev/shm
/dev/sdc1 7.5G 130.7M 7.4G 2% /media/sdc1
root@vuduo4kse:/hdd# ls -la
drwxr-xr-x 18 root root 4096 Nov 4 14:22 .
drwxrwxrwt 12 root root 240 Nov 6 22:38 ..
drwxr-xr-x 7 root root 4096 Feb 15 2024 .kodi
-rw------- 1 root root 0 Dec 9 2016 .python-history
drwxr-xr-x 496 root root 20480 Oct 24 2020 MP3
drwxr-xr-x 6 root root 4096 Jan 24 2021 TuneinRadio
drwxr-xr-x 2 root root 4096 Feb 8 2024 WgConfig
drwxr-xr-x 2 root root 4096 Nov 6 07:10 backup
drwxr-xr-x 2 root root 4096 Oct 21 11:35 backup_openatv_vuduo4kse
drwxr-xr-x 2 root root 4096 Jul 9 01:24 camo3FS
drwx------ 3 root root 4096 Nov 25 2016 chromium
drwxr-xr-x 2 root root 4096 Nov 6 08:22 imagebackups
drwxr-xr-x 2 root root 4096 Nov 6 07:57 images
drwxr-xr-x 2 root root 4096 Jun 22 2020 logs
drwx------ 2 root root 16384 Jan 1 1970 lost+found
drwxr-xr-x 9 root root 81920 Nov 6 21:25 movie
drwxr-xr-x 2 root root 4096 Oct 27 16:18 screenshots
drwxr-xr-x 2 root root 4096 Nov 6 22:02 timeshift
drwxr-xr-x 13 root root 4096 Jul 10 2018 tuner
root@vuduo4kse:/hdd#
ma credo che "ls -la" dovesse essere fatto su /meda/sdc1 che è il percorso della usb che contiene STARTUP_RECOVERY
root@vuduo4kse:/media/sdc1# ls -la
drwxrwxrwx 3 root root 4096 Jan 1 1970 .
drwxrwxrwt 12 root root 240 Nov 6 22:38 ..
-rwxrwxrwx 1 root root 0 Apr 26 2024 STARTUP_RECOVERY
drwxrwxrwx 2 root root 4096 Oct 9 00:02 System Volume Information
ciao e grazie
si esatto....
Ho il sospetto che la chiavetta sia un po' "lenta" nell'inizializzazione
e i 2 secondi che ci sono nell'init-kexec non sono sufficienti ad inizializzarla.
Aumentare quel timeout potrebbe diventare fastidioso, quindi ti suggerisco di provare con qualche altra chiavetta...
paperino61
Active member
eccomi di nuovo... ho rifatto la prova da zero, con altra chiavetta, ma pur sembrando il log corretto (allego sotto), il risultato è stato lo stesso: il STB riparte, fa la fase di boot e si ferma in "starting enigma2" e da lì non si schioda mai (raggiungibile da telnet); se spengo e riaccendo si ferma sempre allo stesso punto: per ripartire devo riflashare (il suggerimento di Blu8 di riflashare solo il kernel, in questo caso non ha nessun effetto: alla ripartenza si blocca sempre lì)
Mi arrendo :-( sicuramente sto sbagliando io qualcosa ma non capisco cosa.....
contenuto del file di log
root@vuduo4kse:/boot# cat kexec-multiboot.log
KEXEC-1ST STAGE: STARTUP_RECOVERY not present in /dev/sda
KEXEC-1ST STAGE: STARTUP_RECOVERY not present in /dev/sda1
KEXEC-1ST STAGE: STARTUP_RECOVERY not present in /dev/sdb
KEXEC-1ST STAGE: STARTUP_RECOVERY found on /dev/sdb1
KEXEC-1ST STAGE: copying STARTUP_RECOVERY into STARTUP
KEXEC-1ST STAGE: loading STARTUP from /dev/mmcblk0p9...
KEXEC-1ST STAGE: STARTUP: kernel=/zImage root=/dev/mmcblk0p9 rootsubdir=linuxrootfs0
KEXEC-1ST STAGE: Found kernel /zImage
KEXEC-1ST STAGE: Found root /dev/mmcblk0p9
KEXEC-1ST STAGE: Found rootsubdir /linuxrootfs0
KEXEC-1ST STAGE: WAITING
KEXEC-1ST STAGE: ##############################################################################
KEXEC-1ST STAGE: booting kernel: /newroot//zImage
KEXEC-1ST STAGE: booting initrd: /newroot/STARTUP.cpio.gz
KEXEC-1ST STAGE: ##############################################################################
KEXEC-2ND STAGE: loading STARTUP from /dev/mmcblk0p9...
KEXEC-2ND STAGE: STARTUP: kernel=/zImage root=/dev/mmcblk0p9 rootsubdir=linuxrootfs0
KEXEC-2ND STAGE: Found kernel /zImage
KEXEC-2ND STAGE: Found root /dev/mmcblk0p9
KEXEC-2ND STAGE: Found rootsubdir linuxrootfs0
KEXEC-2ND STAGE: WAITING
KEXEC-2ND STAGE: ##############################################################################
KEXEC-2ND STAGE: Hack to override vuplus static cmdline
KEXEC-2ND STAGE: ##############################################################################
KEXEC-2ND STAGE: kernel v4
KEXEC-2ND STAGE: ##############################################################################
KEXEC-2ND STAGE: Mounting /newroot to /newroot/boot to expose STARTUP_RECOVERY
KEXEC-2ND STAGE: ##############################################################################
KEXEC-2ND STAGE: mount -o bind /newroot /newroot/boot/
KEXEC-2ND STAGE: mount devtmpfs to /newroot/dev
KEXEC-2ND STAGE: ##############################################################################
KEXEC-2ND STAGE: Executing switch_root /newroot with root /dev/mmcblk0p9 and rootsubdir linuxrootfs0
KEXEC-2ND STAGE: ##############################################################################
root@vuduo4kse:/boot#
s8un3no
Active member
Da telnet dai questi comandi
init 4
init3
Per spiegare, init 4 spegne enigma2 mentre init 3 lo riaccende, aspetta qualche secondo a dare init 3.
Se vai in var/log trovi il file dmesg, se lo leggi potresti trovare il perché enigma2 non si avvia. C'è anche il file messages che è più lungo ma con maggiori informazioni
init 4
init3
Per spiegare, init 4 spegne enigma2 mentre init 3 lo riaccende, aspetta qualche secondo a dare init 3.
Se vai in var/log trovi il file dmesg, se lo leggi potresti trovare il perché enigma2 non si avvia. C'è anche il file messages che è più lungo ma con maggiori informazioni
Potresti provare a dare anche
init 2
enigma2
E vedere che esce.
È comunque molto probabile che sia danneggiata l'immagine di recovery. È per quello che consigliamo di utilizzarla solo per flashare gli slot e dimenticarla.
paperino61
Active member
Grazie ad entrambi per le dritte......
sul fatto che sia danneggiata l'immagine di recovery, mi sembra strano perchè avrò già provato una decina di volte e tutte le volte ho dovuto riflashare di nuovo, quindi vorrebbe dire che ogni volta l'immagine è danneggiata
Appena ho un po' di tempo, riprovo il tutto verificando anche i log suggeriti da s8un3no
ciao e grazie
Oddio, enigma non crasha, ma da quanto riporta, manco si avvia, quale log vuoi venga scritto..
.. e se anche venisse scritto, come lo prende se enigma non si avvia?
Ciao
PS. Io flashando il solo kernel lo ho ripreso parecchie volte, ma, passatemi il termine, la inutilità del Multiboot, ancora non stava dentro.
Potrebbe fare comodo a pochi, a me per esempio, per i Files locali.
Per il resto, una immagine si avvia, e quella guardi.
Se scrivi ancora che il multiboot è inutile ti banno (l'ho implementato io)...