diciamo che invece, all'esatto opposto, tu ne hai avuta fin troppa: complimenti anche per la perseveranza e la determinazione al risultato
mmhh, mi trovo non completamente a mio agio con questa domanda.
Non vorrei sbagliare me se non ricordo male era addirittura limitato, per motivi di compatibilità, ad un set minimo di caratteri: uppercase-only, per quelli alfabetici, più i numeri e i soliti speciali.
Ma non ci scommetterei.
Risolto parte dell'arcano:
Effettivamente è un problema di "case sense", nel senso che infilare la stessa applicazione efi denominata come "grub.efi" oppure come "shellx64.efi" nella root della partizione indicata nella stringa che definisce al firmware la periferica di boot funziona in entrambi i casi, quindi almeno il "nome" da assegnare all'applicazione non è un problema (almeno nella notazione 8+3, oltre non ho provato!).
Il problema sono quindi i caratteri utilizzati per indicare il percorso, nel caso questa applicazione non si trovi nella root della partizione di boot.
Quindi questo funziona (applicazione nella root di sda1):
efibootmgr --create --disk /dev/sda --part 1 --label Arch_3 --loader "shellx64.efi" --gpt --write-signature
ma questo:
efibootmgr --create --disk /dev/sda --part 1 --label Arch_3 --loader "\\EFI\\shellx64.efi" --gpt --write-signature
è diverso da questo:
efibootmgr --create --disk /dev/sda --part 1 --label Arch_3 --loader "\\efi\\shellx64.efi" --gpt --write-signature
almeno con il filesystem FAT16. Devo riformattare la partizione e provare a rifarla in FAT32.
Inoltre non funziona il timer di grub e questo è molto strano.
Poi manca solo il multiboot direi, giusto?
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Stò facendo i test sulla partizione efi. L'ho riformattata in FAT32 e riflaggata come bootabile, copiando i file che erano presenti nella partizione precedente in questa.
Nel dubbio, procedo comunque alla reinstallazione del bootloader EFI per grub2 nella nuova partizione...
Ora voglio aggiornare i puntamenti registrati nel menù UEFI della mainboard. Questo non dovrebbe essere strettamente necessario perchè questi puntamenti non solo altro che dei link ad un file indicato con il suo percorso e nome, però devo ancora chiarire il discorso del "case sense".[root@arch-UEFI profile.d]# grub_efi_x86_64-install --boot-directory=/boot/efi/efi --bootloader-id=grub --no-floppy --recheck
Installation finished. No error reported.
Per gestire il menù UEFI dal sistema operativo si usa il comando efibootmgr. In alternativa, il sistema dovrebbe essere in grado di riconoscere autonomamente alcune opzioni ma non ne sono così sicuro e comunque solo nel caso il cui l'applicazione EFI da avviare si trovi nella root di una partizione FAT/FAT32 su un disco GPT.
Per usare efibootmgr è però necessario che il modulo del kernel "efivars" sia caricato. Per verificarlo è sufficiente elencare i moduli attivi oppure verificare che la directory "/sys/firmware/efi/vars" esista e contenga qualcosa. Se il modulo non è stata avviato la directory "/sys/firmware/efi" non esiste. Si può inserirlo nei moduli da caricare al boot ma non è un modulo indispensabile per il funzionamento del sistema, una volta terminata la configurazione.
Per avviare il modulo si può usare il comando
che, salvo errori, dovrebbe semplicemente tornare a capo, senza restituire nulla. Ora la directory "/sys/firmware/efi/vars" dovrebbe esistere ed essere popolata.[root@arch-UEFI profile.d]# modprobe efivars
Ora la mia situazione è questa:[root@arch-UEFI matteo]# efibootmgr -h
efibootmgr: invalid option -- 'h'
efibootmgr version 0.5.4
usage: efibootmgr [options]
-a | --active sets bootnum active
-A | --inactive sets bootnum inactive
-b | --bootnum XXXX modify BootXXXX (hex)
-B | --delete-bootnum delete bootnum (hex)
-c | --create create new variable bootnum and add to bootorder
-d | --disk disk (defaults to /dev/sda) containing loader
-e | --edd [1|3|-1] force EDD 1.0 or 3.0 creation variables, or guess
-E | --device num EDD 1.0 device number (defaults to 0x80)
-g | --gpt force disk with invalid PMBR to be treated as GPT
-H | --acpi_hid XXXX set the ACPI HID (used with -i)
-i | --iface name create a netboot entry for the named interface
-l | --loader name (defaults to \EFI\grub\grub.efi)
-L | --label label Boot manager display label (defaults to "GRUB2")
-n | --bootnext XXXX set BootNext to XXXX (hex)
-N | --delete-bootnext delete BootNext
-o | --bootorder XXXX,YYYY,ZZZZ,... explicitly set BootOrder (hex)
-O | --delete-bootorder delete BootOrder
-p | --part part (defaults to 1) containing loader
-q | --quiet be quiet
| --test filename don't write to NVRAM, write to filename.
-t | --timeout seconds set boot manager timeout waiting for user input.
-T | --delete-timeout delete Timeout.
-u | --unicode | --UCS-2 pass extra args as UCS-2 (default is ASCII)
-U | --acpi_uid XXXX set the ACPI UID (used with -i)
-v | --verbose print additional information
-V | --version return version and exit
-w | --write-signature write unique sig to MBR if needed
-@ | --append-binary-args file append extra args from file (use "-" for stdin)
Il numero 0001 credo sia un'opzione di "compatibilità" per avviare i dischi mbr.[root@arch-UEFI matteo]# efibootmgr
BootCurrent: 0005
Timeout: 3 seconds
BootOrder: 0005,0004,0003,0000,0001,0002
Boot0000* UEFI: arch_UEFI
Boot0001* Hard Drive
Boot0002 CD/DVD Drive
Boot0003* Arch_1
Boot0004* Arch_2
Boot0005* Arch_3
Per ora, ho configurato i numeri 0003, 0004 e 0005, rispettivamente con queste opzioni:
E di queste la "3" funziona... La "0" è un vecchio tentativo che onestamente neppure ricordo.0003
efibootmgr --create --disk /dev/sda --part 1 --label Arch_3 --loader "grub.efi" --gpt --write-signature
0004
efibootmgr --create --disk /dev/sda --part 1 --label Arch_3 --loader "\\efi\\grub.efi" --gpt --write-signature
0005
efibootmgr --create --disk /dev/sda --part 1 --label Arch_3 --loader "\\efi\\shellx64.efi" --gpt --write-signature
Per eliminare i riferimenti esistentiù e fare un pò di pulizia uso il comando:
sostituendo " numero_da_eliminare" rispettivamente con 0000, 0003, 0004 e 0005.[root@arch-UEFI matteo]# efibootmgr -B -b numero_da_eliminare
E questa è la situazione ripulita:
Grub ha creato l'applicazione efi nel percorso "/boot/efi/efi/grub/grub.efi". Nel mio sistema, /dev/sda1 è montata in /boot/efi quindi devo "sottrarre" queste directory al percorso da indicare per il loader. In termini relativi alla radice della partizione sda, il tree da indicare per il loader sarà quindi "efi -> grub -> grub.efi"[root@arch-UEFI matteo]# efibootmgr
BootCurrent: 0005
Timeout: 3 seconds
BootOrder: 0001,0002
Boot0001* Hard Drive
Boot0002 CD/DVD Drive
UEFI usa per indicare la gerarchia del filesytem usa una notazione particolare: Invece dello "/" Unix usa lo "\" come Windows però raddoppiato. Il percorso da indicare diventa quindi "\\efi\\grub\\grub.efi" ed essendo ora la partizione FAT32 dovrebbe essere "case insensitive".
In teoria ne basta una sola, ne creo 4 perchè credo che quella corretta sia la seconda, nonostante quanto indicato nella guida di Arch. Il nome da dare all'applicazione EFI non è un problema, almeno finchè non si superano gli 8+3 caratteri quindi approfitto della terza per provare.# efibootmgr --create --disk /dev/sda --part 1 --label "UEFI: Arch" --loader "\\EFI\\grub\\grub.efi" --gpt
# efibootmgr --create --disk /dev/sda --part 1 --label "UEFI: Arch_1" --loader "EFI\\grub\\grub.efi" --gpt
# efibootmgr --create --disk /dev/sda --part 1 --label "UEFI: Arch_10car" --loader "1234567890.efi" --gpt
# efibootmgr --create --disk /dev/sda --part 1 --label "UEFI: Arch radice" --loader "grub.efi" --gpt
L'ultima serve per riavviare il sistema in caso di problemi. Ovviamente devo anche ricordarmi di copiare "/boot/efi/efi/grub/grub.efi" in "/boot/efi/grub.efi"
[root@arch-UEFI efi]# efibootmgr
BootCurrent: 0005
Timeout: 3 seconds
BootOrder: 0005,0004,0003,0000,0001,0002
Boot0000* UEFI: Arch
Boot0001* Hard Drive
Boot0002 CD/DVD Drive
Boot0003* UEFI: Arch_1
Boot0004* UEFI: Arch_10car
Boot0005* UEFI: Arch radice
Ultima modifica di frakka : 21-12-2011 a 00:25
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Nessuna di queste due funziona, entrambe ritornano al menù. Peccato non mi riconosca più la corsair come un "Flash USB Drive" altrimenti avrei postato uno screen...# efibootmgr --create --disk /dev/sda --part 1 --label "UEFI: Arch" --loader "\\EFI\\grub\\grub.efi" --gpt
# efibootmgr --create --disk /dev/sda --part 1 --label "UEFI: Arch_1" --loader "EFI\\grub\\grub.efi" --gpt
Le altre due funzionano, quindi il nome del file non è un problema neppure oltre gli 8 caratteri. Non ho provato con gli spazi ma non esageriamo...
Appunto:
Non fate i grulli come me: dopo aver riformattato una partizione e aggiornato l'applicazione EFI per correggere il nuovo GUID aggiornate anche fstab... O almeno tenete a portata di mano un livecd!!!
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Niente fare, non è un problema di "case". Anche indicando il percorso come
dà lo stesso problema.# efibootmgr --create --disk /dev/sda --part 1 --label "UEFI: Arch" --loader "\\efi\\grub\\grub.efi" --gpt
Sembra più una limitazione del firmware ASUS, però...
Provo a scaricarmi una shell UEFI dal sito del progetto tianocore e vediamo...
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
La homepage di UEFI con le relative specifiche.
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Trovato il bandolo, anche se non capisco cosa sbaglio: Ho avviato il sistema con la shell tianocore e ne ho approfittato per esplorare un pò quello che questa shell riesce ad individuare. Dall'elenco dei device montati ottenuto con il comando "map" vedo la mia partizione sda1 come unico dispositivo a blocchi montato (associato agli alias fs0 e blk0), il che significa che è l'unico filesystem che riesce ad individuare.
Spostandomi in questi filesystem con il comando "blk0:" (simile al C: usato dal dos per cambiare unità) e lanciando un "dir" o "ls" vedo i file .efi contenuti nella root della partizione (tianocore.efi e grub.efi) e la directory a cui puntano gli altri tentativi che ho fatto ma questa directory non è esplorabile. Me la indica a zero come dimensione e non ci posso entrare...
[EDIT:]
Boh...
La struttura delle directory è questa:
/dev/sda1 -> /boot/efi
la directory contiene le directory efi ed efi_app ed i files grub.efi e tianocore.efi.
Se configuro una entry per lanciare le applicazioni grub.efi e tianocore.efi funzionano perfettamente sia che si trovino in /boot/efi/ che in /boot/efi/efi_app/
Solo all'interno di /boot/efi/efi/ non funzionano... Eppure non dovrebbero esserci problemi di permessi... Boh!!!
[root@arch-UEFI efi]# ls -al
totale 877
drwxr-xr-x 4 root root 512 1 gen 1970 .
drwxr-xr-x 5 root root 1024 22 ott 12.52 ..
drwxr-xr-x 3 root root 512 22 ott 15.19 efi
drwxr-xr-x 2 root root 512 22 ott 16.50 efi_app
-rwxr-xr-x 1 root root 131584 22 ott 14.35 grub.efi
-rwxr-xr-x 1 root root 763360 22 ott 15.22 tianocore.efi
Ultima modifica di frakka : 22-10-2011 a 17:39
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Ammettendo che terrò così com'è il menù di boot, che va benissimo lo stesso, ho capito anche perchè non funzionava il timer in grub:
Lo script di configurazione, di default assume che la directory di grub sia /boot/grub/ che in caso di sistemi UEFI non è vero ed il comando
crea il file di configurazione che grub andrebbe a leggere se fosse installato su un sistema bios.grub-mkconfig -o /boot/grub/grub.cfg
Cambiando il comando in
effettivamente le modifiche si riflettono anche sul mio grub ma devo guardarci con calma, prima che la morosa mi meni....grub-mkconfig -o /boot/efi/efi/grub/grub.cfg
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Questo comando, lanciato dal percorso /boot/efi/efi/grub, dovrebbe generare un'applicazione efi personalizzata in /boot/efi/ e denominata "grub2_pers.efi", includendo tutti i moduli disponibili nella partizione /boot/efi/efi/grub (supporto ai temi png, jpg, e tante altre cosine...). In effetti, risulta decisamente più grande dell'applicazione efi generata di defalt.grub-mkimage -d /usr/lib/grub/x86_64-efi -O x86_64-efi -p "" -o /boot/efi/grub2_pers.efi `find *.mod | xargs | sed -e 's/.mod//g'`
-rwxr-xr-x 1 root root 2768384 23 ott 17.03 grub2_pers.efi
-rwxr-xr-x 1 root root 131584 22 ott 14.35 grub.efi
EDIT:
Meglio lanciare il comando da /usr/lib/grub/X86_64-efi per avere l'elenco completo dei moduli disponibili.
La guida che ho seguito indicava di usare -p "" per ottenere un grub.efi "portabile", però in fase di avvio ho una serie di problemi di che segnalano l'impossibilità di accedere al disco efi ed un problema di licenza... Credo che specificare il valore di -p "" sia essenziale in quanto il valore predefinito è /boot/grub che è corretto solo per i sistemi bios... Il parametro indica la directory di grub_prefix quindi nel mio caso dovrebbe essere /boot/efi/efi/grub. Però /boot è una partizione (sda2) mente /boot/efi (sda1) punta su un'altra partizione.
grub-mkimage -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi -p "/efi/grub" -o /boot/efi/grub2.efi `find *.mod | xargs | sed -e 's/.mod//g'`
Ultima modifica di frakka : 23-10-2011 a 17:53
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Il media di Windws 8 developer preview è meno rognoso per quanto riguarda UEFI del suo predecessore. La voce di boot "UEFI" nel firmware è comparsa subito senza dover rigenerare il disco.
In compenso, se il disco su cui vado ad installare Windows non è impostato come periferica di boot in UEFI l'installer si lamenta: Avevo pre-inizializzato il disco in GPT e, selezionadolo per l'installazione, l'installer ha creato tutte le partizioni UEFI necessarie. Peccato che al momento di indicare la partizione per l'installazione di Windows mi restituisse sempre un errore che riportava, grosso modo:"Windows non può essere installato in questa unità perchè il tuo hardware potrebbe non essere in grado di avviare Windows, blah, blah, blah...".
Riavviato il sistema, impostato il disco di installazione come primo elemento nella catena di boot (nello screen, "Boot option #1") ed errore scomparso... L'installazione è andata avanti liscia. Peccato che lam ia esperienza con Windows 8 sia durata circa 12 minuti... Ho cercato di installare i driver di Windows 7 ed, al reboot, il sistema è entrato in un loop di "Schermate tristi"... Il driver AHCI ha fatto un casino e non veniva più rilevato il dispositivo di boot.
Un buona notizia per chi usa sistemi multiboot: L'installer di Windows (una volta tanto!!) non introia la catena di avvio. Ho usato due dischi diversi per l'installazione (non oso immaginare cosa possa succedere condividendo la partizione EFI tra due Windows e Linux) ma almeno non ha piallato le voci di avvio nel firmware della mobo...
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
