Fixing MySQL tables in Fedora 17

I had some largish databases in my Fedora 16 installation so when I moved to Fedora 17 I copied back the files from the backup to /var/lib/mysql and tried to start MySQL as usual:

# systemctl start mysqld.service

Unfortunately, it got stuck attempting to start it, with syslog being filled with messages like this:

May 31 12:33:40 novo systemd[1]: mysqld.service holdoff time over, scheduling restart.
May 31 12:33:40 novo systemd[1]: Job pending for unit, delaying automatic restart.

so something was obviously wrong. First, I blamed wrong file permissions or SELinux. Unfortunately, the pair of commands:

# chmod -R mysql.mysql /var/lib/mysql
# restorecon -R /var/lib/mysql

did not fix it. Digging with Google it turns out I need to the mysql_upgrade command but that needs to connect to a running instance. uhm...
So the solution to this chicken-and-egg problem was to manually start mysql with the --skip-grant-tables options like this:

# su - mysql -c "/usr/libexec/mysqld --skip-grant-tables"

then running in another shell:

# mysql_upgrade -u root -p
# systemctl restart mysqld.service

Fedora 17 Release Pizza Party

Ci siamo quasi, pur avendo subito diversi ritardi (e qui metterei un applauso al team QA per l'importantissimo lavoro di valutazione, classificazione e verifica dei bug riportati durante lo sviluppo) ormai mancano pochi giorni al rilascio di Fedora 17, che è stato confermato avverrà il prossimo 29 Maggio.

E allora, quale migliore occasione per festeggiare?

L'appuntamento è per Sabato 9 Giugno a Roma per una bella pizzata in compagnia di Beefy Miracle...

Tutti gli utenti Fedora e, perchè no, anche di altre distribuzioni che hanno voglia di passare una serata in allegria sono invitati!

Cosa faremo? Principalmente sarà una serata all'insegna del divertimento, con pizza e birra a volontà. Si parlerà senz'altro di Fedora 17, delle sue feature e dei progetti per il futuro della nostra distribuzione preferita. Si sta pensando anche ad una qualche forma di contest, con premi e gadget (sperando che arrivino in tempo!). Chi ha un portatile con Fedora installato lo porti, ci potrebbero essere delle sorprese...

Infine, qualche coordinata: il party inizierà alle 21, la pizzeria prescelta (ringrazio fin da ora Antonio Gemelli per aver organizzato la logistica sul posto) si trova in zona Piazza di Spagna. Per semplificare la vita a tutti, ci si incontrerà in Piazza del Popolo (fermata metro A "Flaminio") alle 20.

Abitate fuori Roma? Niente paura, ho preparato una lista di Hotel in zona Termini per la notte del 9, tutti sotto i 100€ per la doppia.

Infine, per aiutare l'organizzazione dell'evento siete pregati di segnalare la vostra adesione su questo thread di FedoraOnline; sempre su FedoraOnline è possibile contattare Antonio per ogni domanda relativa all'evento (il suo nick è antowen)

Se volete invece rimanere direttamente in contatto con me, scrivetemi a giallu_at_fedoraproject.org e vi fornirò il mio numero di telefono e/o contatto chat.

Progressi al supporto Mac in Fedora 17

Sebbene la Apple non sia (giustamente) ben vista dalla comunità del software libero, l'hardware che produce è senz'altro il punto di riferimento per chi apprezza la convergenza tra design e tecnologia; per renderesene conto è sufficiente farsi un giretto per qualunque conferenza tecnica e contare quanti MacBook ci sono in giro.

Purtroppo installare Linux su queste macchine non è mai stato molto semplice per cui spero di portare buone notizie segnalando che in Fedora 17 il supporto alla installazione è decisamente migliorato; infatti grazie al lavoro di Matthew Garrett i supporti di installazione ora funzionano nativamente (ovvero si avviano in modalità EFI), essendo riconosciuti sia nelle preferenze "Disco di Avvio" che facendo il boot premendo "Opzione" (Alt).

Certamente questo è un ottimo risultato, ma allora perchè non è una Feature ufficiale di Fedora 17? In realtà, anche se ora l'avvio della installazione (o del LiveCD/USB) è semplicissimo, ci sono ancora diverse problematiche da risolvere. In particolare, sono supportati solo i Mac con firmware a 64bit (tutti quelli prodotti a partire grosso modo dal  2007); in più, ci sono diversi casi in cui lo schermo rimane nero a causa di bug non ancora identificati nel driver Radeon.

L'obiettivo è riuscire a fornire il supporto nativo all'hardware Mac in Fedora 18, per cui se avete un Mac su cui pensate di installare Linux nei prossimi mesi, il consiglio è di scaricare una Live di Fedora 17, provarla ed eventualmente riportare i problemi riscontrati.

Per molti altri dettagli sull'enorme lavoro svolto vi rimando al post di Matthew

Kernel 3.4, a quando su Fedora?

Domenica scorsa Linus ha rilasciato l'ultima versione del Kernel, la 3.4. Anche se è un po' che non parlo di nuovi kernel, anche perchè facilmente vengono fuori post un po' troppo tecnici, ho trovato questa release degna di nota per almeno tre motivi.

Il primo: dopo che la feature ha "abortito" in diverse release, btrfs sembra aver raggiunto la maturazione necessaria per arrivare veramente come filesystem di default su Fedora 18. In particolare, sono ora disponibili i tool per il recupero dati da filesystem danneggiati e una prima versione del programma per controllarne l'integrità (fsck), oltre a miglioramenti nel comportamento in caso di errore.

Il secondo: esistono diversi hardware a 64bit con risorse (in particolare RAM) limitate. In questi casi, spesso si sceglie di usare una distribuzione a 32bit per non incorrere in problemi dovuti al maggiore consumo di RAM delle varianti a 64bit, a scapito delle performance che questi ultimi garantiscono grazie alle tecnologie più avanzate di cui dispongono; non entro nei dettagli, ma con il kernel 3.4 gli sviluppatori hanno trovato un sistema per avere il meglio dei due mondi: rimane da vedere come le distribuzioni si organizzeranno per supportare questo tipo di installazioni.

Infine, il driver nouveau (quello delle schede NVidia) è uscito dall'area staging, ovvero dal gruppo dei driver "instabili" (fra virgolette perchè l'instabilità non si riferisce alla qualità del codice, quanto al numero ed entità dei cambiamenti tuttora in corso), per entrare a pieno titolo fra quelli ufficiali. Fra l'altro, per la prima volta una nuova serie di schede (la GeForce 600) è supportata ancora prima della sua uscita sul mercato, sebbene per ora il firmware e il resto dello stack grafico necessari  non siano disponibili nelle distribuzioni.

Per tutti i dettagli, consultate il sempre ottimo Linux Kernel Newbies

Come velocizzare l'avvio di Fedora

Se avete notato che l'avvio di Fedora è molto lento, la causa del problema potrebbe essere il servizio iSCSI che, in alcuni modelli di Notebook, rimane in attesa troppo tempo aumentando, anche in modo notevole, i tempi di caricamento del sistema.

iSCSI è un protocollo che permette di inviare comandi a dispositivi di memoria SCSI fisicamente collegati a server e/o altri dispositivi remoti.

Nel caso (piuttosto comune) in cui non abbiate bisogno di avere il supporto a tale tecnologia, potete semplicemente disattivare i servizi associati.

Per verificare se il problema è iSCSI basta, come utente root, digitare il comando

systemctl disable iscsi.service iscsid.service

In questo modo i servizi iSCSI saranno disattivati e dal prossimo riavvio potrebbero diminuire drasticamente i tempi di boot.

Per ripristinare la situazione precedente basta digitare, sempre come utente root, il comando:

systemctl enable iscsi.service iscsid.service

Fedora in pillole: come registrare il desktop?

Se usate Fedora nella versione di default con Gnome-Shell e avete la necessità di produrre uno screencast, pochi sanno che basta utilizzare la combinazione di tasti:

CTRL + SHIFT + ALT + R

per avviare una registrazione in formato WebM di ciò che viene visualizzato sul vostro schermo.

La combinazione di tasti vale sia per l'avvio che per l'arresto della registrazione.

Alla fine troverete nella vostra home directory un file chiamato shell-data_odierna-#.webm (ad esempio, shell-20120514-1.webm per il primo screencast registrato oggi)

Provare per credere :-)

Fedora 15 e 16: attenzione agli aggiornamenti automatici

Se avete installato Fedora 15 o 16 nella versione predefinita con Gnome, avrete nelle impostazioni di aggiornamento l'opzione:

Installa automaticamente: solo aggiornamenti di sicurezza

Questo significa che alcuni aggiornamenti molto importanti vengono scaricati e installati in modo silenzioso, senza che l'utente se ne accorga.

Il problema è che se spegnete o riavviate il sistema mentre sta avvenendo questa operazione silenziosa di aggiornamento (poiché al momento non c'è alcun tipo di avviso) è possibile che vengano corrotti dei dati, i quali, in alcuni sporadici casi, potrebbero non consentire più l'avvio del sistema.

Dopo aver notato questo problema, tempo fa ho creato un bug report su bugzilla, ed è stato ritenuto abbastanza importante da essere classificato come bloccante per Fedora 17 (ovvero uno di quei bug che se non risolti possono far ritardare l'uscita della prossima versione di Fedora).

Dopo approfondita discussione, si è deciso per Fedora 17 di cambiare solo l'opzione di default degli aggiornamenti automatici in: 

Installa automaticamente: Niente 

questo perché purtroppo, a causa dell'avanzato stato di sviluppo, non è più possibile apportare modifiche pesanti al codice della versione in uscita.

La buona notizia è che Lennart Poettering (già creatore di Avahi, PulseAudio, Systemd)  e Richard Huges (PackageKit, colord) sono già al lavoro per una soluzione più dinamica e completa, che consenta all'utente di poter usufruire degli aggiornamenti automatici senza alcun pericolo.

Con l'uscita di Fedora 18 quindi questo problema sarà totalmente risolto, anche con gli aggiornamenti automatici attivati.

Se avete Fedora 15 o Fedora 16 comunque, il consiglio è di disabilitare gli aggiornamenti automatici.

Anche con questa opzione disabilitata, vi compariranno comunque le classiche notifiche che vi informeranno quando sono disponibili nuovi aggiornamenti  che potrete applicare con i metodi consueti.

I LUG e la diffusione di Linux

Ricevo e pubblico integralmente un contributo di Gabriele Trombini (mailga su IRC e FedoraOnline) sul rapporto tra i LUG (Linux User Group) e la diffusione di Linux. E' evidente che la sua esperienza al riguardo non è stata positiva, ma mi domando se anche altri hanno riscontrato le stesse problematiche nei LUG della propria zona. Fatemi sapere!