Installazione su sistema UEFI/GPT

[frakka]

Antipatica scoperta:

Aggiornato il bios all'ultima versione disponibile, ha segato tutte le registrazioni relative a boot loader GPT non Windows... Il bootloader windows non è stato toccato, le registrazioni che invece avevo inserito relative a Grub sono state cancellate.

Che @#@[#@!!!

[frakka]

Anche l'aggiornamento alla versione successiva fà lo stesso giochino... Questa discriminazione stà iniziando a dari sui nervi!!!

[EDIT:]
Volevo aprire una segnalazione sul loro forum ma mi è passata la voglia a metà del form da compilare... Che razza di sistema!!!

[frakka]

Anche questa volta c'è stato da impazzire...

Un piccolo "workaround": Anche se dopo l'aggiornamento del bios la mobo si perde le registrazioni nel firmware per tutto quello che non è Windows, si può aggirare il problema.
Il firmware, nel menù di uscita, prevede la voce "Load EFI Shell from filesystem device" o qualcosa del genere che può essere usata per avviare un file denominato "Shellx64.efi" (case sensitive!) da un supporto rilevato dal firmware (FAT/FAT32).

1_ Si mantiene una chiavetta usb con una copia del file grub.efi rinominato in Shellx64.efi a portata di mano. Ogni tanto si può aggiornare la copia ma non dovrebbe essere necessario;
2_ Rinominare direttamente il file grub.efi presente in sda1 in Shellx64.efi. La partizione infatti viene comunque rilevata da UEFI ma, dato che non ha più le registrazione per avviare un file con nome diverso da Shellx64.efi, il sistema non è in grado di avviare l'installazione di Linux. Questo semplice trucco è sufficiente per avviare il bootloader e far caricare Linux, non sono necessarie altre modifiche in grub o da altre parti. In teoria, si potrebbe anche lasciare il sistema così, senza la necessità di aggiornare le registrazioni nel firmware con efibootmgr.

[Totocellux]

a nome di tutti, grazie per:

1) tenerci sempre più aggiornati

2) di farlo anche nelle ore piccole, quindi a prezzo di ulteriori sacrifici

[frakka]

Ho tempo praticamente solo di notte... Quindi effettivamente i miei post sono spesso in orari impietosi!

Spero che queste informazioni possano essere utili a qualcun altro.

[frakka]

Di default, in verità, l'applicazione EFI non è esportabile in quanto manca di molti moduli e della configurazione di grub. A forza di test e prove mi sono accorto che i post precedenti, essendo dei test "on-the-road" contengono un sacco di errori ed inesattezze.


Sempre dal wiki di Arch (di nuovo, complimenti ai maintainer della documentazione: sempre molto completa e quasi sempre disponibile anche in italiano) per generare la versione "portable" dell'applicazione EFI il comando da usare e i parametri da conoscere/considerare sono i seguenti:

grub-mkstandalone --directory="/usr/lib/grub/x86_64-efi/" --format="x86_64-efi" --compression="xz" --output="/boot/efi/efi/arch_grub/grubx64_standalone.efi" "boot/grub/grub.cfg"

I seguenti parametri sono praticamente standard:

--directory
--format
--compression

Il valore di "directory" è in percorso in cui il tool può trovare i moduli da incorporare nell'applicazione EFI. In "/usr/lib/grub/x86_64-efi/" si trova una copia di tutti i moduli disponibili quindi usare questo valore non è mai sbagliato. Solo nel caso si vogliano aggiungere dei moduli non compresi nella distribuzione standard si può indicare un altro percorso oppure si può copiare da un'altra parte il contenuto di questa directory e aggiungere o modificare i moduli contenuti, per evitare di intaccare la versione "originale" della directory.
Il valore di "format" è la piattaforma su cui dovrà girare l'applicazione EFI: Anche questo valore, a meno di usare piattaforme non sparc, itanium o altro dovrà rimanere al valore indicato.
Il valore di "compression" è la compressione utilizzata per l'applicazione EFI.

I parametri che possono/devono essere personalizzati sono quindi "--output" e l'ultima parte, cioè gli eventuali file aggiuntivi. Con il parametro "output" indichiamo dove dovrà essere salvata l'applicazione EFI mentre con "boot/grub/grub.cfg" indichiamo di includere la configurazione esistente di grub nell'applicazione.

Quest'ultima opzione è particolarmente importante soprattutto per generare un'applicazione EFI di "recovery" che sia in grado cioè di funzionare anche lanciata da una chiavetta USB ed in caso di pasticci con le partizioni sul disco. Dato che l'applicazione EFI deve risiedere nella EFI System Partition, questa deve essere montata per potervi scrivere dentro (di defaul non è inserita in /etc/fstab quindi non viene montata al boot.)
Nella mia configurazione, il comando:

mount /dev/sda1 /boot/efi
grub-mkstandalone --directory="/usr/lib/grub/x86_64-efi/" --format="x86_64-efi" --compression="xz" --output="/boot/efi/Shellx64_StandAlone.efi" "boot/grub/grub.cfg"

monta la partizione sda1 in /boot/efi e il comando successivo dovrebbe creare l'applicazione funzionante nel percorso "/boot/efi/Shellx64_StandAlone.efi".

Come ben descritto nel wiki linkato prima, per una limitazione dello script grub-mkstandalone il percorso del file di configurazione di grub non deve essere fornito come percorso assoluto "/boot/grub/grub.cfg" ma come percorso relativo: Nel mio caso specifico, invece che copiare file e creare directory è sufficiente che il comando venga lanciato spostandosi nella "/" del filesystem, in modo da far coincidere i due percorsi...
L'applicazione efi che deriva da questo comando è la effettivamente notevolmente più grossa dell'applicazione standard:

-rwxr-xr-x 1 root root  119808 30 apr 21.18 Shellx64.efi
-rwxr-xr-x 1 root root 2961408  1 mag 16.07 Shellx64_StandAlone.efi

Il firmware della mia ASUS non permette di scegliere l'applicazione EFI da lanciare se si ricorre alla funzione "Load EFI Shell from filesystem device" quindi l'ideale sarebbe nominare il file "Shellx64.efi": In questo modo, dato che la partizione sda1 è una partizione formattata FAT32 e che quindi viene riconosciuta anche dal firmware EFI, la funzione di emergenza dovrebbe permettermi di avviare la mia installazione anche dopo che le registrazioni nel firmware sono saltate (ad esempio, a seguito di aggiornamento firmware).
Ovviamente, essendo portable, l'applicazione può essere copiata su chiavetta o altro per essere tenuta a disposizione per lo stesso scopo. Ovviamente, anche qui è necessario che il file di chiami "Shellx64.efi" e che il supporto sia in FAT/FAT32.


[ATTENZIONE: Per i MAC intel la procedura è diversa. Usare efibootmgr potrebbe rendere necessario rifare il flash del firmware della mobo!]
Per creare la registrazione nel firmware UEFI, come prima cosa è necessario accertarsi che i moduli dm-mod ed efivars sia no caricati. Non è invece indispensabile che la EFI System Partition sia montata:

modprobe efivars
modprobe dm-mod
efibootmgr --create --gpt --disk /dev/sda --part 1 --write-signature --label "Arch Linux (GRUB2)" --loader 'grubx64.efi'

Il device della "EFI System Partition" è indicato spezzato nei due parametri "--disk" e "--part 1", "--label" è il valore che viene mostrato nel firmware della mainboard mentre il percorso indicato in "--loader" è il percorso dell'applicazione EFI riferito alla radice della "EFI System Partition". In questa sintassi però, l'uso dei "backslash" è un pò particolare: A quanto ho potuto vedere, per esplorare la struttura delle directory dalla shell EFI è necessario specificare l'unità (fs0:, fs1:, etc...) e usare un solo "\" per passare da un livello all'altro ma se il file deve essere seguito, allora il primo "\" deve essere ripetuto... Non sò perchè funzioni in questo modo, è quello che è emerso dalle mie prove.

Quindi: dalla shell EFI 1.0 (la versione 2.0 non sembra funzionare sul mio hardware) per eseguire un'applicazione EFI che si trovi nella radice della EFI System Partition è sufficiente indicare il nome del file e premere "invio". Se invece l'applicazione si trova in una sottodirectory, per eseguirla è necessario raddoppiare il "\" all'inizio del comando. Per lanciare l'applicazione 'grubx64.efi' che si trova nella sottodirectory EFI\Arch, il comando da lanciare dalla shell è \\EFI\Arch\grubx64.efi se ci si trova nel device che contiene il file oppure fsX:\\EFI\Arch\grubx64.efi (con "X" ovviamente in base al device che ospita il file) se ci si trova in "shell:" o in un'altro device.

efibootmgr e shell UEFI per pc e Mac.

[frakka]

Un volta generata l'applicazione EFI (anzi... Andrebbe probabilmente fatto prima se si vuole generare un'applicazione portable) è necessario provvedere al file di configurazione di GRUB2.

Il vecchio "menu.lst" non esiste più ed è stato sostituito dal file "grub.cfg" che però non dovrebbe venire mai editato a mano. Il file è generato dal comando:

# grub-mkconfig -o </destinazione/del/file/grub.cfg>

che legge quando indicato nel file /etc/default/grub e negli script contenuti nel percorso "/etc/grub.d/".

Il file /etc/default/grub contiene le impostazioni generali e più a basso livello di grub, tramite invece gli script contenuti in /etc/grub.d vengono generate le voci del menù. Normalmente, gli script 00_header, 10_linux,20_linux_xen, 20_memtest86+ ed 30_os-prober sono riservati al sistema. Le voci personalizzate per gli utenti dovrebbero essere inserite nel file "40_custom" in modo che vengano elaborate dal sistema.

Questo è il mio:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Microsoft Windows7 x86_64 UEFI-GPT" {
    insmod part_gpt
    insmod fat
    insmod search_fs_uuid
    insmod chain
    search --fs-uuid --no-floppy --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1 B6BC-F8EA
    chainloader /efi/Microsoft/Boot/bootmgfw.efi
}

menuentry "Riavvia il computer." {
   reboot
}

menuentry "Spegni il computer." {
   halt
}

menuentry "Esci ed avvia dispositivo successivo nella catena di boot." {
    exit
}

Mentre le ultime 3 sono descrittive, la prima serve per avviare da grub l'applicazione EFI "bootmgfw.efi" nel percorso "/efi/Microsoft/Boot/" residente su un'altra unità e che è ovviamente, l'applicazione EFI Microsoft per avviare una installazione di Windows 7 in modalità UEFI/GPT, sempre ottenuta seguendo le istruzioni dell'ottimo wiki di Arch.
Richiede però qualche complicazione in più del normale chainload per l'avvio di un sistema mbr: Mentre la sezione iniziale e l'ultima riga sono standard, la riga "search" necessita dei riferimenti alla partizione in cui risiede il file "bootmgfw.efi".

Perchè il comando funzioni è necessario che la partizione sia montata da qualche parte e l'argomento da passare a "--target=fs_uuid" deve essere adeguato di conseguenza.
Il file "bootmgfw.efi" si trova nel percorso "/EFI/Microsoft/Boot" relativo alla radice della partizione EFI di Windows (nel mio caso è /dev/sdb1, ho fatto due installazioni separate, altrimenti potrebbe essere la stessa di grub).

Monto quindi la partizione EFI di Windows da qualche parte:

mount /dev/sdb1 Desktop/EFI-win7/

e ne ottengo l'UUID con il seguente comando (nel mio caso il risultato è "B6BC-F8EA"):

grub-probe --target=fs_uuid Desktop/EFI-win7/EFI/Microsoft/Boot/bootmgfw.efi

Preciso che si potrebbe ottenere lo stesso identico risultato aprendo gparted o un altro qualunque editor di partizioni e leggendo l'uuid dal menù "Informazioni" che si trova facendo click col tasto destro sulla partizione interessata...

Il comando successivo, serve ad ottenere i riferimenti alla partizione in un formato che sia comprensibile e grub e UEFI (Su questo punto il wiki contiene un errore: sembra che sia un unico comando e non comando e risultato, probabilmente hanno scordato un fine linea):

grub-probe --target=hints_string 

Nel mio caso il comando completo è

grub-probe --target=hints_string Desktop/EFI-win7/EFI/Microsoft/Boot/bootmgfw.efi

e da come risultato:

--hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1

L'unione di questi due risultati restituisce quello che dobbiamo inserire nella riga search:

search --fs-uuid --no-floppy --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1 B6BC-F8EA

Infine, per avviare un semplice sistema mbr la sezione da aggiungere è sempre la stessa del vecchio grub. Non l'ho mai usata ma dovrebbe essere una cosa del genere:

# (2) Windows XP
menuentry "Windows XP" {
    set root=(hd0,1)
    drivemap -s hd0 hd2
    chainloader (hd0,1)+1
}

Il caso di cui sopra presume che Windows sia installato nel disco hd2 in notazione grub (dovrebbe essere /dev/sdc). Da notare la riga "drivemap -s hd0 hd2": Questa opzione permette a Windows di credere di essere installato nel primo drive.
Ripeto, questo non l'ho mai provato.

Ovviamente, dopo ogni modifica è necessario rilanciare il comando

grub-mkconfig -o </destinazione/del/file/grub.cfg>

per vedere applicati effettivamente i cambiamenti.


[EDIT:]
Come non detto.
A seguito di ulteriori verifiche, ho potuto appurare che GRUB avviato in modalità UEFI non può fare il chainload di un sistema MBR. L'unico modo che ho trovato per avviare un sistema operativo MBR, in questo caso, è uscire da grub col comando "exit" ed impostare il sistema MBR come il dispositivo di avvio successivo nel firmware della mobo.
Nel caso fosse necessario un bootloader complesso, ad esempio per avviare più sistemi operativi, si può installare un bootloader nel MBR del dispositivo successivo ed, eventualmente, usare quello dopo essere usciti da Grub.

Inoltre, il seguente metodo è più rapido per completare la stringa "search". Sapendo qual'è il disco su cui si trova il bootloader che si vuole avviare (in questo caso, /dev/sdb) si può usare il seguente comando per ottenere l'UUID:

[root@arch-uefi boot]# blkid | grep "EFI system partition" | grep /dev/sdb
/dev/sdb1: UUID="0E8D-E06E" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="b63ce59d-b729-4dcd-8014-a74a8383c18d"

e basta questo comando per ottenere la "hints_string":

[root@arch-uefi boot]# grub-probe -d --target=hints_string /dev/sdb1
--hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1

[frakka]

Ho riassunto le informazioni principali in un'altro thread, per questioni di ordine...
http://www.nexthardware.com/forum/si...s-e-linux.html