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
Donating 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
Donating 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
Donating 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
Donating Member
sicuramente frequentatore, ma passivo....
mai avuto le capcità e conoscenze per essere un mini guru paperino61
Donating Member
Avevo dimenticato l'allegato :-(
paperino61
Donating 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
Donating 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...