pierluigi.netsons.org

Questo post per avvisare gli utenti del mio repo personale che (come forse avranno già notato) è un periodo che non aggiorno.

Ho iniziato a mettere mano al config del kernel26-zen per adattarlo alla mia specifica configurazione hardware, e allo stesso tempo ho messo mano ai flag in /etc/makepkg.conf per produrre pacchetti strettamente ottimizzati sulla mia macchina.

A questo aggiungiamo la recente difficoltà a stare dietro a tutti pacchetti dei moduli aggiuntivi (che tra l'altro nemmeno uso personalmente! a parte nvidia-beta), moduli che non sempre compilano, visto il naturale frequente aggiornamento del kernel zen (è syncato alle rc del kernel vanilla).

Ho deciso di mettere per iscritto che per ora si tratta di un semplice freeze, il repo non chiude ma rimane congelato, sperando di avere al più presto tempo e voglia di riprenderlo in mano.

Ho rimosso i pacchetti klibc-zen e v86d-zen in quanto inutili. In [core] si trovano già klibc (linkato ad un kernel compilato con uvesafb) e si trova anche v86d.

Per un certo motivo qualche ora fa mi sono trovato a dover collegare un hard disk esterno (usb) al muletto (sempre lui, muloserver).

Una volta collegato mi sono accorto che il modulo usb_storage non veniva caricato.

Considerato l'uptime della macchina (100 giorni e spiccioli) ho immaginato quale potesse essere il problema: il kernel in esecuzione - 2.6.23-ARCH - differiva dal kernel installato con pacman (ovvero kernel26) - 2.6.24-ARCH -

Effettivamente era andata proprio così: i vari aggiornamenti del pacchetto kernel26 hanno sovrascritto (com'è giusto che sia, d'altronde) i moduli del kernel correntemente in esecusione, e questo su una macchina che non viene riavviata di frequente è un bel problema, visto che la versione dei moduli installati non coincide con il kernel attivo.

Per ora ci ho messo una pezza aggiungendo

IgnorePkg = kernel26

in pacman.conf. Ovvero evito di aggiornare il kernel, cercando di aggiornarlo selettivamente solo in caso di reboot.

Se qualcun'altro avesse idee migliori, o se mi dovesse sfuggire qualcosa, sono ben accetti consigli.

Sembra che klibc abbia dei problemi con l'ultimo kernel (2.6.24).

In particolare, mi sono imbattuto in un kernel panic in fase di boot dovuto all'uso di uvesafb (e quindi v86d compilato su klibc e linkato nell'immagine di initcpio).

Se ne parla anche sul forum ufficiale di arch, e questo bug conferma l'esistenza di problemi tra klibc e il kernel 2.6.24 (http://bugs.archlinux.org/task/9482)

Di conseguenza, fino a che non sarà fixata la situazione, ho provveduto a rimuovere il supporto a uvesafb dal kernel26zen che distribuisco nel mio repo. Inoltre ora kernel26zen risulterà in conflitto con klibc-zen.

Solo per informare gli utilizzatori del mio repo: sto mantenendo i binari di kernel26kamikaze e di tutti i moduli accessori.

English readers: see below

Un po' a malincuore, ho constatato di non potermi più permettere così tanto tempo libero da dedicare al patchset -pierlo.

Inoltre il patchset kamikaze (dal quale prendevo la maggior parte delle patch) sta dimostrando una continua evoluzione, e sembra andare proprio nella direzione che speravo di prendere io con il mio patchset.

Ho pensato quindi di concentrare le eventuali poche forze disponibili nel contribuire come meglio posso allo sviluppo di kamikaze.

Colgo l'occasione per ringraziare i numerosi utenti che hanno avuto il coraggio di sperimentare con il mio patchset, e coloro che con i loro preziosi suggerimenti hanno contribuito a migliorarlo.

Un ringraziamento molto speciale va anche a imachine aka Mateusz Jedrasik, per il continuo aiuto (in modo specifico per quanto concerne la piattaforma x86_64)

English:I have decided to stop the development of -pierlo patchset due to time constrains.

The kamikaze patchset (which was the main source of the patches I included in -pierlo) is getting better day after day. I hope to be able to concentrate my (reduced) forces in improving it.

Thank you all for using -pierlo, reporting bugs, giving me suggestions.

I want to say "thank you" in particular to imachine aka Mateusz Jedrasik for his big help (especcially about the x86_64 platform)

Ho messo su un patchset per il kernel, nulla di incredibile. Si basa sul patchset kamikaze, al quale però ho tolto alcune patch (ad esempio quella per avere lo stack a 4k invece che a 8k, perchè poco compatibile con ndiswrapper, ipw3945 e gspca1 perchè tanto abbiamo il pacchetto con il modulo a parte).

Alle patch di kamikaze ho aggiunto poi qualche piccola patch da ragnarok e le patch presenti in kernel26 (kernel ufficiale archlinux).

Questo è quanto, per il momento. Il tutto è disponibile in aur (kernel+moduli) e nel mio repo personale.

Da notare che ancora non è pronto il supporto a x86_64 (basta preparare il config, ma non ho macchine su cui testarlo), e che il logo è ancora quello del kernel viper, il logo con il tag aggiornato l'ho preparato e verrà shippato con la terza release.

Graditissimi i commenti.

In attesa di capire che cosa ne sarà di tutto il codice targato -ck, ci sono buone notizie per quanto riguarda kernel26viper. Ho trovato un utente (Mateusz) disposto a occuparsi del testing per l'architettura x86_64: preparerà quindi un config quanto più simile possibile a quello per x86, ovviamente ottimizzato per i 64 bit .

Ho deciso inoltre di riportare come default vesafb al posto di vesafb_tng perchè quest'ultima:

• non è compatibile con i 64 bit
• a fronte di pochi vantaggi (maggiore semplicità di configurazione e in certi casi velocità) risulta essere problematica per certi utenti

Ovviamente il kernel rimarrà patchato per supportare vesafb_tng, ma questa non sarà abilitata nel config di default e di conseguenza nemmeno nei binari che metto a disposizione nel mio repo.

Quanto questo cambiamento avverrà, un apposito messaggio nel post_upgrade vi informerà di aggiornare la stringa della risoluzione nel bootloader.