Line 194: | Line 194: | ||
{{admon/note||E' possibile usare lo script [https://github.com/xsuchy/fedora-upgrade fedora-upgrade] per automatizzare tutti i passaggi (usare {{command|yum install fedora-upgrade}}). Come per il metodo manuale, non è raccomandato come metodo d'aggiornamento da Fedora.}} | {{admon/note||E' possibile usare lo script [https://github.com/xsuchy/fedora-upgrade fedora-upgrade] per automatizzare tutti i passaggi (usare {{command|yum install fedora-upgrade}}). Come per il metodo manuale, non è raccomandato come metodo d'aggiornamento da Fedora.}} | ||
{{Anchor|16-17}} | |||
=== Fedora 16 -> Fedora 17 === | === Fedora 16 -> Fedora 17 === |
Revision as of 19:38, 9 March 2013
Questa pagina descrive come eseguire un upgrade (avanzamento di versione) di Fedora usando yum
.
Aggiornamento di Fedora usando direttamente yum
Quando si fa un upgrade con yum o FedUp, non si avranno aiuti dagli stessi Anaconda o FedUp, ma con un sistema tipico si potrebbe essere in grado di aggiornare da remoto tramite SSH e con un downtime (tempo di inattività) limitato. (Si avrà ancora la necessità di riavviare per utilizzare il nuovo kernel ed i servizi attivi).
L'aggiornamento live funziona bene con un'installazione tipica e se si seguono i consigli di seguito.
Partecipare
Se si sta facendo un upgrade usando yum e si notano problemi generici di dipendenza, si prega di segnalarli in http://bugzilla.redhat.com. Leggere la presente pagina wiki, tutte le pagine di riferimento e fare una ricerca nall'archivio della mailing list e, certamente, mantenere questa pagina aggiornata.
Se si vuole aiutare a mantenere gli upgrade live funzionanti regolarmente, c'é il Live Upgrade Special Interest Group.
Istruzioni per l'aggiornamento usando yum
1. Backup del sistema
Eseguire un backup di tutti i dati personali su un disco esterno o un altro computer. Se si verificherà un errore irrecuperabile, un'installazione fresca permetterà di non perdere i propri dati.
2. Leggi i problemi ricorrenti
In una sezione successiva di questa pagina c'è un elenco di problemi comuni relativi alle specifiche versioni. Alcuni di questi richiedono attenzione prima di eseguire l'aggiornamento.
Consigli generali sull'aggiornamento di Fedora possono essere trovati alla pagina Updating. Si dovrebbe inoltre leggere la guida all'installazione e le note di rilascio della versione verso alla quale si intende aggiornarsi - questi documenti contengono importanti informazioni riguardo i problemi di aggiornamento. Infine, controllare l'elenco dei Common bugs (bug conosciuti).
3. Fare pulizia
Verificare ed eliminare tutti i file .rpmsave e .rpmnew prima e dopo l'aggiornamento. (Se è abilitato selinux, controllare il security context dei file di configurazione spostati.)
A questo punto è consigliabile rimuovere tutti i pacchetti non utilizzati - in particolare quelli non standard.
4. Fare l'aggiornamento
Se si hanno configurati repository da terzi, devono essere impostati per la nuova versione di Fedora. Passando da una versione all'altra di Fedora, spesso non c'é nulla da fare. Se si passa da una Fedora standard ad una rawhide (o viceversa), inoltre molto tempo servirà per installare gli RPM rawhide dai repository da terzi (o quelli standard, viceversa).
Da notare che l'upgrade può fallire in presenza di dipendenze obsolete da pacchetti non forniti dai repository di yum o da pacchetti non pronti per la nuova versione.
E' buona norma operare l'upgrade al di fuori della modalità grafica. Disconnettersi per poi
Usare una console testuale
ctrl + alt + F2
oppure
accedere come root e spostarsi in runlevel 3
# init 3
Aggiornare yum all'ultima versione disponibile
# yum update yum
Installare le nuove chiavi gpg per la versione Fedora alla quale aggiornare
Le chiavi possono essere trovate e verificate in
https://fedoraproject.org/keys
o vedere le istruzioni per uno specifico aggiornamento in basso.
Pulizia della cache
Rimuovere tutte le tracce della versione Fedora che si sta per lasciare nella cache di yum in /var/cache/yum
.
# yum clean all
Upgrade di tutti i pacchetti
# yum --releasever=<versione alla quale si vuole sincronizzare> distro-sync
Note: Nonostante sia raccomandato fare upgrade a versioni intermedie, se si aggiorna da versioni vecchie (ad esempio da Fedora 12 a 13, poi da 13 a 14), dipende da quale versione si parte, questo passaggio potrebbe fallire con errore sulla chiave gpg con formato sbagliato. Per superarlo, aggiungere l'opzione "--nogpgcheck" al comando 'yum distro-sync'.
Assicurarsi che Fedora sia aggiornata
Distro-sync solitamente assicura gli upgrade da repository da terzi abilitati.
yum repolist
conferma dopo il termine dell'upgrade. yum
potrebbe segnalare conflitti o richieste aggiuntive, probabilmente perché si sono usati repository o pacchetti non standard installati manualmente. Tentare di scovare quali creano i problemi (o almeno parte della catena di dipendenze), disinstallarli e provare ancora. Ricordarsi di installare nuovamente quelli essenziali.
Assicurarsi che tutti i (nuovi) pacchetti essenziali dalla nuova versione siano installati con
# yum groupupdate 'Minimal Install'
Verficare anche gli altri gruppi
# yum grouplist
Per esempio
# yum groupupdate "GNOME Desktop" \ "Development Tools" "Sound and Video" \ "Games and Entertainment" "Administration Tools" \ "Office/Productivity" "System Tools"
Preparazione al riavvìo
Prima di riavviare si dovrebbe solitamente installare il bootloader dal nuovo Grub con
/sbin/grub-install BOOTDEVICE
- dove BOOTDEVICE solitamente è /dev/sda
( se si ottiene errore allora '/dev/sda non ha un corrispondente dispositivo BIOS', allora provare /sbin/grub-install --recheck /dev/sda). Per Fedora 16 e successive, usare /sbin/grub2-install
invece di /sbin/grub-install
. Vedere sotto per importanti informazioni su come aggiornare a Fedora 16 da versioni precedenti.
Inoltre l'ordine degli script init potrebbe essere cambiato dalla versione precedente. Un comando per reimpostare l'ordine è
cd /etc/rc.d/init.d; for f in *; do /sbin/chkconfig $f resetpriorities; done
Ancora, avviare package-cleanup --orphans
per trovare i pacchetti che non sono stati aggiornati.
Note specifiche di versione
Dalla pre-release
Se si sta aggiornando ad una versione finale da una alpha, da una beta, da una anteprima o da altre Rawhide versioni, si prega di vedere Upgrading from pre-release to final (Aggiornamento da una pre-release ad una finale).
Aggiornamento ad una rawhide
Vedere la pagina di rilascio Rawhide per maggiori informazioni.
# yum install fedora-release-rawhide # yum-config-manager --disable fedora updates updates-testing # yum update yum # yum --releasever=rawhide distro-sync --nogpgcheck
Fedora 17 -> Fedora 18
Nota: Un utente ha riportato problemi con un'installazione su Intel Mac UEFI, inclusa la migrazione manuale del bootloader. Leggi
Prima di tutto installare la nuova chiave gpg Fedora 18
- rpm --import https://fedoraproject.org/static/DE7F38BD.txt
- Se si usa SELinux in modalità Enforcing, assicurarsi di aver aggiornato il pacchetto selinux-policy
- Aggiornare tutti i pacchetti:
su -c 'yum update yum'
su -c 'yum clean all'
su -c 'yum --releasever=18 --disableplugin=presto distro-sync'
- Ricostruire il database rpm:
su -c 'rpm --rebuilddb'
, necessario altrimentirpm -qa
non funzionerà a causa dell'upgrade del pacchetto rpm appunto.
Se non si aggiorna selinux-policy, si possono avere molti errori segnalati da yum nel momento in cui molti dei pacchetti tentano di creare utenti o gruppi; dopo l'aggiornamento si presenterebbero dei problemi, inclusi quelli legati al login via GDM (apparirebbe il solo cursore) e/o la richiesta dei privilegi dell'amministratore per fare certe operazioni. Tutto questo dipende dal bug #844167.
Se si incontra questo problema serve una reinstallazione dei pacchetti coinvolti con su -c 'yum reinstall (packagenames)'
ed il riavvìo. Tra i pacchetti affetti ci sono libvirt-daemon e polkit: su -c 'yum reinstall libvirt-daemon polkit'
A causa di Features/DisplayManagerRework, l'upgrade potrebbe lasciare disabilitato il display manager. Per risolvere il problema, usare su -c 'systemctl enable yourdm.service'
, rimpiazzando yourdm con il proprio display manager, ad esempio gdm
o kdm
.
Fedora 16 -> Fedora 17
Prima installare la chiave gpg per la nuova Fedora 17
# rpm --import https://fedoraproject.org/static/1ACA3465.txt
Fedora 17 colloca l'intero sistema operativo in /usr. Le cartelle /bin, /sbin, /lib, /lib64 saranno solo dei link simbolici:
/bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64
Alcuni dei motivi dietro a questo cambiamento si trovano qui:
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
Gli attuali sistemi installati necessitano di alcuni passaggi manuali per convertire il sistema in base alla nuova struttura di Fedora 17. Dopodiché il sistema può continuare ad essere aggiornato con yum come al solito.
Alcuni pacchetti RPM in Fedora 17 stanno implementando un sistema di sicurezza per le dipendenze, che assicurerà la loro installazione quando sono presenti i link simbolici /bin, /sbin, /lib, /lib64 invece delle normali cartelle come in Fedora 16 e precedenti versioni.
La struttura del filesystem base installato non può essere alterata in sicurezza, mentre il sistema stesso è in esecuzione su di essa. Dracut, l'initrmfs usato per trovare e montare il filesystem radice, può essere istruito per convertire il filesystem in modo da rispettare le aspettative di Fedora 17.
Se il il sistema ha una /usr separata, un punto di montaggio separato, la logica di conversione del montaggio di /usr nei NFS potrebbe non essere supportata; se /usr risiede in rete, si dovrebbe aggiungere l'opzione "rd.neednet=1" ed un'impostazione di rete come "ip=dhcp" nella riga kernel. /usr su iSCSI, FCoE, NBD sono suportati, fino a quando “netroot=...” è specificato nella riga di comando kernel per questi dischi (vedere man dracut.kernel(7)).
Se si ha /usr in un LVM, MD raid or DM raid, assicurarsi che la riga kernel contenga un'impostazione come "rd.lvm.lv=..." (in modo che /usr sia accessibile in dracut) o che vengano rimosse le restrizioni come "rd.lvm...", "rd.md...", "rd.dm...". In entrambi i casi servirebbe Anaconda per aggiornare se si hanno esperienze passate con un /usr separato.
Se si ha /var in una partizione separata, bisognerà convertire manualmente "/var/run" e "/var/lock" a link simbolici.
# mv -f /var/run /var/run.runmove~ # ln -sfn ../run /var/run # mv -f /var/lock /var/lock.lockmove~ # ln -sfn ../run/lock /var/lock
Qui ci sono i passaggi per preparare il sistema, per convertirlo e per permettere il normale aggiornamento con yum del sistema installato:
Scaricare ed installare l'rpm più recente di dracut:
# yum update dracut
Bisogna avere almeno dracut-009-15.fc15 per Fedora 15 o dracut-013-22.fc16 per Fedora 16.
Rimuovere tutte le impostazioni "hostonly" in /etc/dracut.conf*, se abilitate precedentemente.
Aggiornare l'immagine initramfs installata per il kernel in uso ed istruire dracut ad includere il 'dracut module' per convertire il filesystem corrente:
# dracut --force --add convertfs
Se il sistema ha un /usr split-off, un separato punto di montaggio, e non si conosce il parametro kernel da aggiungere, si può anche provare (dracut proverà a generarli automaticamente):
# dracut -H --force --add convertfs
Se dracut rileva ‘rd.convertfs’ alla riga kernel all'avvìo, inizia la conversione del filesystem del filesystem root. Se risulta già convertito, non farà nulla.
Cambiare il seguente parametro kernel direttamente nel menu del bootloader che è mostrato
durante il boot o editare la linea nel /etc/grub*.cfg
per rimuovere ro e rhgb ed aggiungere rw rd.info rd.convertfs enforcing=0
Spiegazione delle opzioni:
- rimuovere “ro” (sola lettura - read only) - aggiungere “rw” (scrittura lettura - read write) lasciare che dracut monti il root filesystem scrivibile - rimuovere “rhgb” (Red Hat graphical boot) per disabilitare il bootsplash grafico - aggiungere “rd.info” per ottenere maggiori informazioni da dracut - aggiungere “rd.convertfs” per abilitare lo script di conversione /usr-move in dracut - aggiungere “enforcing=0” per disabilitare SELinux
Durante l'avvìo dracut convertirà il filesystem e /lib, /lib64, /bin e /sbin dovrebbero poi essere tutti link simbolici alla corrispondenti sottocartelle in /usr.
Dopo la conversione, il sistema dovrà essere immediatamente aggiornato a Fedora 17. Nessun pacchetto da Fedora 15 o Fedora 16 o precedenti pacchetti rawhide dovrà più essere installato. Assicurarsi che nessun repository per Fedora 15 o 16 sia abilitato !
Qualsiasi file con nomi in conflitto che la conversione non può risolvere, saranno conservati come file chiamati *.usrmove~ residenti in /usr/lib, /usr/lib64, /usr/bin and /usr/sbin.
Verificare che dracut abbia effettivamente completato la conversione. I messaggi di log generati da dracut possono essere richiamati con:
# dmesg | grep dracut
Dopo una conversione ben riuscita, reimpostare come in origine il file di configurazione /etc/grub*.cfg alla riga kernel.
Poi:
# rm -f /var/lib/rpm/__* # rpm --rebuilddb # yum --releasever=17 update rpm # rm -f /var/lib/rpm/__* # rpm --rebuilddb # yum --releasever=17 --disableplugin=presto distro-sync # fixfiles onboot
Dopo l'upgrade tutto dovrebbe essere impostato e fatto.
Buon divertimento con il nuovo sistema e un arrivederci a /bin, /sbin, /lib, /lib64 in /usr.
Fedora 15 -> Fedora 16
Prima installare la nuova chiave gpg Fedora 16. Verificare il pacchetto in https://fedoraproject.org/keys ed il certificato ssl Fedora.
# rpm --import https://fedoraproject.org/static/A82BA4B7.txt
Poi avviare chkconfig --list
e annotare i servizi avviati; sarà necessario riabilitarli con systemctl enable xxxxx.service
dopo il riavvìo; siccome le impostazioni sysvinit
non verranno ereditate in systemd
. Vedere note di rilascio per maggiori dettagli.
Aggiornare tutti i pacchetti con
# yum update yum # yum clean all # yum --releasever=16 --disableplugin=presto distro-sync
Se il proprio sistema usa il BIOS, o si è installata Fedora tramite emulazione del BIOS in un sistema EFI (modalità EFI non nativa), è possibile cambiare al Grub di Fedora 16 seguendo le istruzioni di seguito. Se il sistema è stato installato nativamente con il boot EFI, non cambiare a Grub2 poiché il supporto EFI non è ancora affidabile. Il bootloader di Fedora 16 che supporta l'EFI è ancora grub-legacy quindi si dovrebbe semplicemente continuare ad usare il sistema senza modificarne il bootloader.
Per cambiare a Grub2, eseguire il comando su -c '/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg'
, poi procedere come descritto sopra con la reinstallazione del bootloader, usare poi grub2-install /dev/XXX
invece di grub-install /dev/XXX
.
Annotare i problemi specifici dell'upgrade (per problemi comuni far riferimento a quanto detto sopra)
- Bug 743022 - F15->F16 aggiornamenti yum non riusciti con IMSM (BIOS) raid
Fedora 14 -> Fedora 15
Prima installare la nuova chiave gpg Fedora 15. Verificare questo pacchetto in https://fedoraproject.org/keys ed il certificato ssl Fedora.
# rpm --import https://fedoraproject.org/static/069C8460.txt
Aggiornare tutti i pacchetti con
# yum update yum # yum clean all # yum --releasever=15 --disableplugin=presto distro-sync
- Non avviare all'interno di un terminale X. Test dimostrano che X potrebbe bloccarsi durante l'aggiornamento di pacchetti di font bitmap.
- Esistono i .drpms ma non corrispondono a causa di una cambio di formato, quindi è meglio disabilitare il plugin presto aggiungendo l'opzione "--disableplugin=presto" (senza virgolette) quando si avvìa yum.
- Lo
screen
F15 non è collegabile a quello di sessione F14. Quindi se si vuole aggiornare a schermo, o si dovrebbe aggiornare prima loscreen
come operazione separata o fare una copia delloscreen
da utilizzare durante tutto il processo. - mysql 5.5.20 distribuito per F15 usa InnoDB come motore di memorizzazione predefinito (default storage engine) . Dopo l'upgrade mysqld può non partire con l'errore Unknown/unsupported storage engine: InnoDB se impostato con skip-innodb nella riga di comando o nel file di configurazione /etc/my.cnf. Soluzioni alternative prevedono di eliminare la linea (InnoDB partirà come motore predefinito) oppure aggiungere l'opzione default-storage-engine impostando altri motori di memorizzazione (storage engine).
VirtualBox guest upgrade
I passaggi riportati sopra funzionano perfettamente negli upgrade di guest Fedora 14 a Fedora 15, ma è anche necessario rimuovere i Guest Additions. Se ci si dimentica, gli upgrade F14 --> F15 sembreranno fallire dopo il primo riavvìo. Se accade, loggarsi nella console con CTRL+ALT+F2 e reinstallare i guest additions manualmente:
# mount /dev/cdrom /media ## se /dev/cdrom non esiste, provare: # mount /dev/sr0 /media # /bin/sh /media/VBoxLinuxAdditions.run # reboot
Fedora 13 -> Fedora 14
Prima installare la nuova chiave gpg per Fedora 14. Verificare il pacchetto con https://fedoraproject.org/keys ed il certificato ssl di Fedora.
# rpm --import https://fedoraproject.org/static/97A1071F.txt
Aggiornare tutti i pacchetti con
# yum update yum # yum clean all # yum --releasever=14 distro-sync
- Se si usa VirtualBox dai repository Oracle, bisogna rimuovere il pacchetto VirtualBox-3.1 prima dell'upgrade. Al termine dell'upgrade installare VirtualBox-3.2 .
Se si usa SeLinux, si potrebbe essere esclusi dall'utilizzo della macchina e servirà l'avvìo in modalità single user per fissare il problema. Redhat bug 702865 descrive la risoluzione:
setenforce 0
yum remove selinux-policy selinux-policy-targeted
rm -rf /etc/selinux/targeted
Se dopo l'upgrade si rivuole SeLinux attivo:
yum install selinux-policy selinux-policy-targeted
fixfiles restore
reboot