Arch Linux

[umby213]

il fatto è che hai ancora conflitti nella dir /lib.. cosa c'è li dentro?

Codice: Seleziona tutto

ls /lib

[Sparmi]

Il force ha funzionato

[Sparmi]

Allora ora do la mia procedura completa, magari può servire a qualcuno.

1 - Prima di tutto ho spostato per intero il contenuto di /lib in /usr/lib.

2- Sono entrato in modalità singolo utente con i permessi di root con

Codice: Seleziona tutto

sudo init 1

3- Tramite questi comandi ho eliminato la /lib e symlinkato la /usr/lib

Codice: Seleziona tutto

/usr/lib/ld-2.16.so /bin/rm -rf /lib

Codice: Seleziona tutto

/usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib

4- Ok fatto questo sono rientrato nel sistema e ho dato questo comando consigliato in questa guida https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib:

Codice: Seleziona tutto

grep '^lib/' /var/lib/pacman/local/*/files | grep -v glibc

In questo modo ho visto che avevo lasciato il firmware brcm-80211.
L'ho disinstallato ed ho dato il force a glibc.
All works.
Ho reinstallato il firmware.



Grazie Ragazzi!

[kens]

Credo di aver fatto un discreto casino; il "migliore" da quando uso Arch. Mi sono dato del cretino da solo e ripetutamente; quindi vi prego di non infierire
Nessuna polemica, per carità; la colpa è mia ma certo è che, comunque, l'organizzazione e la gestione di questo upgrade non mi pare siano state tra le cose più cristalline...
La madre di tutte le -mie- stupidaggini è stata forzare l'upgrade nonostante le news -lette dopo ahimè...- dicessero di evitarlo assolutamente.
Poi, seguendo uno dei primi post sui forum Arch, ho cancellato "/lib" linkandola in "/usr/lib" ma così facendo ho perso "/lib/modules" Disastro!
Ho poi effettuato diversi smanettamenti, dei quali ho perso il controllo e, di kernel panic in kernel panic, sono arrivato allo stato attuale: il sistema inizia il boot -un miglioramento, no? - ma restarta continuamente dando (ho dovuto copiare l'output a manina):

Codice: Seleziona tutto

:: Starting UDev Daemon
:: Triggering UDev events
:: Loading User-specified modules
[     6.470963] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found
[     6.470964] [Firmware Bug]: powernow-k8: Try again with latest BIOS
:: Waiting fo UDev uevents to be processed
:: configure virtual consoles
[DONE]
:: Bringing up loopback interface
[DONE]
:: Unlocking encrypted volume
[DONE]
:: Checking Filesystems
[BUSY] fsck.ext2: symbol lookup error : fsck.ext2: undefined symbol: set_com_err_gettext
fsck.ext4: symbol lookup error : fsck.ext4: undefined symbol: set_com_err_gettext
[FAIL]

*****************REBOOT REQUIRED*************************
*                                                                                               *
*  The system will be rebooted automatically in 15 seconds.   *
*                                                                                               *
*****************************************************************

C'è speranza di recuperare in qualche modo?
Comunque avevo in programma da tempo di ricreare il sistema su un HDD più capiente e veloce ed i luttuosi eventi hanno accelerato il progetto ma... con la ISO attuale del CD di installazione (kernel 3.0 e GLIBC non certo aggiornato) non avrò gli stessi problemi (anche se stavolta sarò meno incauto...)?

Perdonate il "baccano" e grazie infinite, in anticipo

--

[ambro]

Se hai intenzione di reinstallare tutto per altri motivi (cambio hd) è il momento migliore. Se non devi reinstallare puoi perderci un po' di tempo per tentare di recuperare il sistema (in linux mai dire mai).
Comunque se reinstalli scegli l'immagine "netinstall" così da scaricare già i pacchetti aggiornati.

[Nemo]

Nel caso tu non possa usare l'immagine "netinstall" la procedura è comunque possibile anche se richiederà qualche smanettamento per sistemare i vari aggiornamenti (come è successo a me). Nel caso io ho risolto così:

1. La prima volta che lancerai l'aggiornamento, rigorosamente con

Codice: Seleziona tutto

# pacman -Syyu --ignore glibc --ignore filesystem

ti verrà chiesto se vuoi sospenderlo per aggiornare prima pacman: digli di no e fai proseguire il tutto..ti verrà detto che verranno aggiornati una sensantina di pacchetti, ma, probabilmente, il tutto andrà a buon fine solo per tre o quattro di essi..gli altri ti diranno che hanno bisogno di almeno glibc 2.15.

2. installa una versione più attuale di glibc così

Codice: Seleziona tutto

# pacman -U http://pkgbuild.com/~allan/glibc-2.16.0-1-<arch>.pkg.tar.xz

dove il parametro <arch> va sostituito con l'architettura della tua macchina.

3. ripeti

Codice: Seleziona tutto

# pacman -Syu --ignore glibc --ignore filesystem

sempre senza aggiornare pacman, ora dovrebbe installare tutti gli altri aggiornamenti senza problemi.

4. forza l'aggiornamento di filesystem con

Codice: Seleziona tutto

# pacman -Sf filesystem

nel caso dovesse restituirti un errore tipo "impossibile sostituire cartella /run/var o una cosa del genere provvedi a cancellarla manualmente e poi ridai il comando di aggiornamento di filesystem

5. riavvia il sistema poi esegui l'aggiornamento di tutto ciò che manca con

Codice: Seleziona tutto

# pacman -Syu --ignore glibc

potresti dover ripetere il comando due volte in quanto una sicuramente ti chiederà di sospendere il tutto per aggiornare pacman

6. finalmente dovrebbe esser tutto aggiornato compreso pacman quindi con

Codice: Seleziona tutto

# pacman -Su

rimarrà da aggiornare solo glibc e il sistema sarà in ordine.

Questo è l'unico modo che personalmente ho trovato per installare da zero arch in caso di impossibilità di usare l'immagine "netinstall". Ho dovuto provare almeno un paio di volte perché non facendo esattamente come ti ho scritto (almeno a me) non si riuscivano ad aggiornare tutti i pacchetti.

[kens]

Sbaglierò ma... attualmente non esistono ISO di Arch "immuni" dal problema. Netinstall compresa.
Davvero un bel pasticcio...

[Nemo]

Hai provato col metodo che ti ho descritto sopra? è esattamente per quelle ISO non ancora aggiornate a glibc 2.16.0-2 e che quindi recessitano di intervento manuale per l'aggiornamento.

[kens]

Si, Nemo; ho letto e ti ringrazio davvero ma... col sistema "in sfacelo" non riesco ad accedere alla rete (ora scrivo da una Slackware di emergenza).
Come faccio a dare un:

Codice: Seleziona tutto

# pacman -Syyu --ignore glibc --ignore filesystem

Non avrei un errore per mancata raggiungibilità dei mirror?
Grazie ancora...

[Nemo]

La procedura che ti ho scritto è per la reinstallazione totale del sistema senza un'immagine netinstall non per recuperare il sistema già installato (mi pareva di aver capito che volessi formattare, nel caso ho capito male scusa)..dopo averlo installato da immagine core devi comunque accedere alla rete..come ti connetti? wi-fi o via cavo? protezione? così vediamo di impostare la rete se non ci sei riuscito.

[veleno77]

sul wiki è stata postata una ottima nota su come aggiornare correttamente il sistema in caso di installazione da core 2011.08.19. direttamente dal blog di Allan Mcrae http://allanmcrae.com/2012/07/updating- ... e-install/

[kens]

Veramente volevo fare entrambe le cose, Nemo... installare un sistema "pulito" su un nuovo HDD e recuperare la vecchia installazione per poi effettuare la "migrazione" con comodo.
Mi connetto via cavo con indirizzo statico; sul sistema "corrotto" avevo attivato bind, per fare a meno dei DNS dei provider.
Per recuperare la vecchia installazione potrei usare l'immagine ISO (64bit) corrente e fare un chroot per tentare di usare pacman ma ho notato che anche facendo così la scheda di rete non viene riconosciuta (mancheranno i moduli? uhmmm..).
Leggo ora la segnalazione di Veleno; ci do un'occhiata...

P.S. Ho usato il CD "netinstall" per settare la rete e sto aggiornando (in chroot sul sistema "corrotto") seguendo quanto indicato da Allan (Grazie, Veleno...). Speriamo che non fallisca restituendo in uscita una carrettata di errori!

[kens]

Allora... vi tedio un altro po'
Col "metodo Allan" segnalato da Veleno sono riuscito a portare a termine l'aggiornamento; con qualche warning "non bloccante" ma ci sono riuscito.
Teoricamente dovrei essere quasi a posto ma il sistema continua a resettare subito dopo il boot; credo in seguito ad errori in sede di check iniziale dei filesystem (sicuramente per colpa di qualche mio smanettamento... "glibc", secondo me, non c'entra nulla).
Per comodità mostro di nuovo i messaggi a video durante la parte iniziale del boot (trascritti a manina visto che non potevo certo fare un copia-incolla).

Codice: Seleziona tutto

    :: Starting UDev Daemon
    :: Triggering UDev events
    :: Loading User-specified modules
    [     6.470963] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found
    [     6.470964] [Firmware Bug]: powernow-k8: Try again with latest BIOS
    :: Waiting fo UDev uevents to be processed
    :: configure virtual consoles
    [DONE]
    :: Bringing up loopback interface
    [DONE]
    :: Unlocking encrypted volume
    [DONE]
    :: Checking Filesystems
    [BUSY] fsck.ext2: symbol lookup error : fsck.ext2: undefined symbol: set_com_err_gettext
    fsck.ext4: symbol lookup error : fsck.ext4: undefined symbol: set_com_err_gettext
    [FAIL]

    *****************REBOOT REQUIRED*************************
    *                                                                                               *
    *  The system will be rebooted automatically in 15 seconds.   *
    *                                                                                               *
    *****************************************************************


Cosa potrebbe essere a dargli così fastidio?

--

[Hilinus]

Versione di e2fsprogs in uso?

[kens]

Secondo il sistema ho la 1.42.4.1 ma siccome ho pasticciato un bel po' nei tentativi scorsi non ci ho creduto l'ho comunque reinstallata e...
il boot è andato a buon fine!!! Anche se per ora ottengo soltanto il prompt della modalità testuale
Piallando incautamente "/lib" all'inizio di questa folle storia, ho perso anche la directory "modules" in essa contenuta (poi ricreata in /usr/lib ma certo non con gli stessi contenuti...); sarà per quello?
C'è da segnalare che durante gli aggiornamenti, sia pacman sia yaourt, ottengo diversi warning del tipo:

Codice: Seleziona tutto

ldconfig: /lib/libudev.so.0 is not a symbolic link

mi sa che c'è ancora qualcosa da sistemare

--

[kens]

.Aggiornamento:

Ora il sistema parte! Nel casino generale era cambiato il nome di "rc.conf" in "rc.conf~" !!! L'ho rinominato in modo corretto ed i benefici sono stati evidenti
Non parte però "X" e posso usare soltanto la modalità testuale da una delle TTY virtuali.
Segnalo però che da dette TTY non riesco a visualizzare le accentate e diversi caratteri "italiani".
Ho dato un'occhiata ai log di sistema ma non mi pare di aver trovato informazioni -per me...- "illuminanti".
Probabilmente nella ridda di librerie accumulatesi in "/usr/lib" ce ne sono alcune inutili o che si "sovrappongono"; esiste un modo per verificarlo?

Suggerimenti?

--

[ambro]

Ma /lib è un link simbolico oppure è ancora una cartella fisica?

Codice: Seleziona tutto

ls -al /

[kens]

Beh, ambro... sino a lì ci arrivo! certo che "/lib" è un link simbolico! A "/usr/lib", come vuole il nuovo corso
Scherzi a parte credo che ormai non rimangano che le "tossine" dei miei smanettamenti

Come ti dicevo tra i log non trovo grossi "casini". Il mio sistema usa GDM, lanciato da rc.conf e nemmeno lì si registrano messaggi di errore; semplicemente nella console TTY7, quella che ospita l'output "grafico", rimane il cursore "orologino" a tempo indeterminato senza che venga mai presentata la scelta degli utenti per il login

Secondo me la traccia che può condurmi a fare un altro passo in avanti è quella serie di messaggi come il seguente (ma sono diversi, anche se di stuttura praticamente identica) che, guarda caso, coinvolge le "lib":

Codice: Seleziona tutto

ldconfig: /lib/libudev.so.0 is not a symbolic link


Si presentano in discreta quantità a seguito dell'aggiornamento di uno o più pacchetti tramite "pacman"; anche se non causano il blocco degli aggiornamenti medesimi.

Grazie ancora della pazienza

--

[kens]

Allora...

Vi/mi aggiorno e al tempo stesso chiedo cortesemente aiuto

Cercando, riflettendo e ri-controllando -in piena filosofia Arch- ho fatto qualche bel passo avanti.
Mi sono accorto che l'orologino "imbambolato" della "tty7" era dovuto a GDM che non partiva più.
Così ho disabilitato l'avvio grafico e provato a lanciare "startx" dopo il login testuale e... MIRACOLO! La mia Arch è -sebbene un po' malconcia - tornata a vivere!
Prima del disastro avevo scelto di avviare GDM come demone "in coda" a "/etc/rc.conf" ma adesso non c'è proprio verso di farlo andare in quel modo. Se provo a lanciarlo da terminale ottengo:

Codice: Seleziona tutto

[nicola@k6_400 ~]$ gdm

** (gdm-binary:1483): WARNING **: Failed to acquire org.gnome.DisplayManager: Connection ":1.61" is not allowed to own the service "org.gnome.DisplayManager" due to security policies in the configuration file

** (gdm-binary:1483): WARNING **: Could not acquire name; bailing out


Al momento, pur senza capire perché si comporta così, ho optato per l'avvio di GDM da "/etc/inittab", come indicato anche nel Wiki:
https://wiki.archlinux.org/index.php/Di ... taliano%29
e funziona in modo apparentemente regolare (anche se l'ambiente grafico pare avviarsi un po' più lentamente del solito).

Rimane il problema del "disallineamento" dei link ad alcune librerie già citato in precedenza; ecco l'output di "ldconfig":

Codice: Seleziona tutto

[nicola@k6_400 ~]$ ldconfig
ldconfig: /lib/libshadow.so.0 non è un collegamento simbolico

ldconfig: /lib/libnilfs.so.0 non è un collegamento simbolico

ldconfig: /lib/libcryptsetup.so.1 non è un collegamento simbolico

ldconfig: /lib/libntfs-3g.so.81 non è un collegamento simbolico

ldconfig: /lib/libpcre.so.0 non è un collegamento simbolico

ldconfig: /lib/libudev.so.0 non è un collegamento simbolico

ldconfig: Impossibile creare il file temporaneo di cache /etc/ld.so.cache~: Permesso negato


Ora che ho fatto i compiti a casa e sostenuto gli esami di riparazione qualche dritta me la date?
Comunque sia... lunga vita ad Arch! E abbasso i cervelli all'ammasso...

--

[Sparmi]

La lentezza non è un problema
e4rat risolve anche questo.

Sei stato sfortunato ad aver perso il contenuto di /lib prima di essere symlinkata.
Magari prova a reinstallare udev, ntfs-3g, cryptsetup, pcre, nilfs-utils e shadow...
Dando:

Codice: Seleziona tutto

sudo pacman -S udev ntfs-3g cryptsetup pcre nilfs-utils shadow 

Che ne dite?

[kens]

Non so se dico scempiaggini, Sparmi ma...
Le varie librerie elencate, pur non essendo linkate in modo simbolico non hanno comunque -in qualità di file "fisici"- lo stesso nome?
Intendo dire che, forse, reinstallando i pacchetti da te elencati non risolverei la necessità di creare i link mancanti in quanto i nomi coinciderebbero.
Dovrei forse cancellare le voci interessate prima di lanciare l'aggiornamento pacman da te suggerito?

[Sparmi]

Io proverei prima a fare direttamente l'upgrade ....
Se non dovesse andare proverei a cancellarle come dici tu e poi a lanciare l'upgrade.
Naturalmente salverei le librerie in una cartella facilmente raggiungibile poi da shell di recovery in caso di problemi.

Se dovessi dire sciaperie picchiatemi:
Io credo che queste librerie puntino ad altre. Nel senso:
/lib/libudev.so.1 punta a /lib/libudev.so.nonsaprei XD

Con il fatto che bisogna symlinkare /usr/lib, questi symlink di librerie non si aggiornano automaticamente.
Basta provare nella cartella home, symlinkare una cartella qualsiasi e poi spostare il file originale... cade tutto.
Secondo me è accaduta la stessa cosa.

Oppure, l'upgrade forzato inizialmente forse ha corrotto questi file: /var/lib/pacman/local/*/files
Ho notato che per fare l'aggiornamento di glibc bisogna disinstallare i pacchetti che hanno librerie principali in /lib e reinstallarli al termine del symlink e upgrade di glibc.

Codice: Seleziona tutto

$ grep '^lib/' /var/lib/pacman/local/*/files

Che ne pensi?