Non si avvia più seamonkey: help

Forum dedicato ai Porting ufficiali e non di Slackware, vedi Slack/390, ARMedslack, Slamd64, Slackintosh, Ocsid, Sloox, Zenwalk, How-Tux, Slax etc etc

Moderatore: Staff

Regole del forum
1) Specificare nome e versione del porting.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3788
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Non si avvia più seamonkey: help

Messaggio da joe »

Stamattina ho avviato slax coma al solito.
Ma dopo aver dato startx kde non si avviava. S'è un po' bloccato lì. Sono allora tornato in init3 con ctrl atl backspace. E a quanto ho capito il problema stava nella cache di seamonkey, i files sembravano corrotti.
Allora ho riavviato la slax in fresh mode, ovvero totalmente live e ho eseguito un fsckeck sul file slaxsave.dat:
praticamente il sistema slax è contenuto uin un file formattato chiamato appunto slaxsave.dat. Tutti i cambiamenti del sistema vengono salvati lì e riutilizzati al riavvio.
Il filesyste che ho usato era reiserfs, così ho dato resiserfsck slaxsave.dat e ha trovato 5 errori ripristinabili solo con l'opzione rebuilt-tree. Ho quindi eseguito quel comando con l'opzione indicata e il filesystem sebra essere stato corretto.
Riavvio, usando il solito slaxsave.dat, quindi non totalmente live. Dò startx e kde si riavvia senza problemi.
Però provando a lanciare seamonkey, questo non funge, allora lo lancio da terminale:

Codice: Seleziona tutto

# seamonkey
/usr/bin/seamonkey-bin: error while loading shared libraries: /usr/bin/libplds4.so: invalid ELF header
Mah... Poi provo a lanciare seamonkey-bin:

Codice: Seleziona tutto

# seamonkey-bin
seamonkey-bin: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory
Ho provato a cercare i due errori in google, ma è veramente strano... da un giorno all'altro... misteri.
Ora seamonkey non è installato nel sistema, è solamente un modulo lzm di slax che praticamente viene montato in loop col comando "activate". Tale modulo lzm non risiede nel filesystem del sistema ma è salvato esterno in /mnt/sda2/saved-modules, e viene aganciato in loop al momento dell'attivazione,quindianche le sue librerie dovrebbero essere apposto:

Codice: Seleziona tutto

# losetup -a|grep sea
/dev/loop24: [0802]:133 (/mnt/sda2/saved-modules/seamonkey-2.0.3.lzm)
Mi dareste qualche dritta?

EDIT:
Aggiungo che ho notato un comportamento a dir poco bizzarro, prima del fix del filesystem avevo provato a rimuovere il contenuto della cache, perchè tentando di effettuare un backup con rsync quella directory non veniva copiata e saltavano fuori problemi di permessi (inspiegabili lavorando da root).
Così ho provato a cancellare il contenuto di .mozilla/seamonkey/blablabla/Cache/* E come per magia, il sistema si riavviava, non so per quale santo...

Dingo
Linux 0.x
Linux 0.x
Messaggi: 21
Iscritto il: sab 1 ago 2009, 12:32
Distribuzione: Puppy Linux
Contatta:

Re: Non si avvia più samonkey: help

Messaggio da Dingo »

una volta è capitato anche a me

prova (senza tentare di avviare seamonkey) a cancellare la directory nascosta .mozilla (che è in /root/ o nella tua /home/), naturalmente dovrai eventualmente recuperare e ripristinare le librerie o mancanti o danneggiate? e come si fa? un andrai su packages.debian.org alla loro ricerca (o le premdi da un'altra installazione funzionante)

peazip ti permette di aprire gli archivi .deb e di estrarne il cointenuto

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3788
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: Non si avvia più samonkey: help

Messaggio da joe »

Sì la prima cosa che ho fatto è stata proprio la rinomina della dir ".mozilla" in "mozilla.bk".
La situazione adesso però è stranamente cambiata!
(questo mi porta a pensare sempre più spesso che l'informatica non possa essere annoverata tra le scienze esatte).

Dunque adesso la rimozione del modulo:

Codice: Seleziona tutto

deactivate seamonkey-2.0.3
Ha finalmente avuto l'effetto atteso, infatti non vi è più /usr/bin/seamonkey e compagnia.
Però se ricarico il modulo a quanto pare la magagna persiste e gli errori che ho riportato sono sempre quelli.

Per scrupolo, ho provato a lanciare un "ldd /usr/bin/seamonkey-bin" anche se francamente non so precisamente come è organizata la faccenda in slax (cioè il fatto che il software venga montato in loop piuttosto che eessere installato alla maniera classica non vorrei che portasse a conclusioni errate...va bè). Ecco cosa è risultato:

Codice: Seleziona tutto

# ldd /usr/bin/seamonkey-bin|grep not
        libmozjs.so => not found
        libxpcom.so => not found
        libxpcom_core.so => not found
        libplds4.so => not found
        libplc4.so => not found
        libnspr4.so => not found
        libsmime3.so => not found
        libssl3.so => not found
        libnss3.so => not found
        libnssutil3.so => not found
        libsoftokn3.so => not found
        libldap60.so => not found
        libprldap60.so => not found
        libldif60.so => not found
        libsqlite3.so => not found
Ci credo che non si avvia...
La libreria mancante: libplds4.so è presente in realtà, ma si trova in /usr/bin piuttosto che in /usr/lib.
Ora, un modulo slax non è altro che una directory compressa in un pacchetto lzm, e attivandolo vine montato in loop praticamente andando a piazzare i files delle varie sottodir nei vari percorsi del sistema.
Chi ha creato il modulo in questione ha messo le librerie in /usr/bin, piuttosto che in /usr/lib.
Forse ha anche una certa logica per due motivi:
1) prima di tutto non è così scorretto perchè prima dell'altro giorno il modulo è sempre stato funzionante senza problemi. Quindi questo non può essere il solo motivo del mancato funzionamento attuale.
2) Ipotrebbe avere anceh una certa logica per evitare di sovrascrivere eventuali librerie che già lavorano sul sistema ed ovviamente si trovano dove ci si aspetta ovvero in /usr/lib e compagnia.

Tanto per fare una prova adesso faccio un link simboico in /usr/lib a /usr/bin/libmozjs.so e vediamo cosa succede.
In effetti ora cambia l'errore

Codice: Seleziona tutto

# seamonkey-bin
seamonkey-bin: error while loading shared libraries: libxpcom.so: cannot open shared object file: No such file or directory
Il problema quindi apparentemente è il seguente:
seamonkey cerca le librerie nelle dir predisposte penso da una qualche variabile d'ambiente, e probabilmente questa variabile non comprende /usr/bin...
Il fatto però è che prima funzionava, e come diavolo faceva?

A questo proposito provo ad aggiungere "/usr/bin" in:

Codice: Seleziona tutto

# cat /etc/ld.so.conf
/usr/local/lib
/usr/i486-slackware-linux/lib
/usr/bin

Codice: Seleziona tutto

# ldconfig
ldconfig: /usr/bin/libplc4.so is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /usr/bin/libnssutil3.so is not an ELF file - it has the wrong magic bytes at the start.

Codice: Seleziona tutto

ldconfig: File /usr/lib/libopenobex.so.1.3.0 is empty, not checked.
Compaiono strani errori che coinvolgono proprio libplc4 tra gli altri.
Ma il fatto èche il modulo di seamonkey è stato scaricato e ricaricato e anche se vi fosse stato un "trauma" al sistema che avesse danneggiato la libreria in questione, non avrebbe comunque coinvolto il pacchetto che se ne stava tranquillo fuori dal sistema... cioè ricaricaandolo la libreria dovrebbe essere come nuova...
Forse il discorso sta tutto qui, forse ho capito:
potrebbe anche essere che scaricando il modulo magari non vengano cancellati proprio tutti i files e che per esempio libplc4 resti nel sistema, non sapreri dire perquale santo ma proviamo ad ipotizzarlo per un attimo. Vado a verificare:
scompatto il pacchetto seamonkey-2.0.3.lzm in una dir $TESTDIR e vado a confrontare "diff" il file $TESTDIR/usr/bin/libplc4.so con l'eventuale rimasuglio presente sul sistema in /usr/bin. Ci sono due possibilità, il file presente sul sistema è ancora lì perchè fa parte di qualche altro modulo ancora caricato in memoria (improbabile vista la collocazione di una libreria in /usr/bin) oppure sta ancora lì perchè è corrotto edi in qualche modo non è possibile eliminarlo del tutto con la disattivazione del modulo, discorsi e ipotesi campati in aria forse, maproviamo a crderci e verifichiamo:

Codice: Seleziona tutto

# losetup -a|grep sea
# ls /usr/bin/libplc4.so
/usr/bin/libplc4.so
# diff /mnt/sdb2/slax-related/tests-tmp/usr/bin/libplc4.so /usr/bin/libplc4.so
Binary files /mnt/sdb2/slax-related/tests-tmp/usr/bin/libplc4.so and /usr/bin/libplc4.so differ
# activate /mnt/sda2/saved-modules/seamonkey-2.0.3.lzm
bash-3.1# losetup -a|grep sea
/dev/loop24: [0802]:133 (/mnt/sda2/saved-modules/seam diff /mnt/sdb2/slax-related/tests-tmp/usr/bin/libplc4.so /usr/bin/libplc4.so
Binary files /mnt/sdb2/slax-related/tests-tmp/usr/bin/libplc4.so and /usr/bin/libplc4.so differonkey-2.0.3.lzm)
CVD?
A pensar male si fà peccato ma ci s'azzecca a quanto pare...
In effetti quella libreria non viene cancellata alla disattivazione del modulo di seamonkey, inoltre alla riattivazione del modulo questa non viene sovrascritta infatti è differente da quella sana presente nella directory dove ho scompattato il pacchetto, In pratica in qualche modo fallisce il montaggio in loop.
Ora provo a forzare un attimo la mano disattivando nuovamente il modulo ed eliminando a mano la libreria incriminata:
Ho provato ma quando poi riattivo il modulo stessa storia, stessi errori.... strano... però non mi ha dato alcun errore quando ho cancellato il file con "rm".
Boh, se vi viene in mente qualcosa dite pure

Avatar utente
Ansa89
Iper Master
Iper Master
Messaggi: 2703
Iscritto il: mer 29 ago 2007, 17:57
Nome Cognome: Stefano Ansaloni
Slackware: 14.2 64bit
Kernel: 4.9.61
Desktop: XFCE 4.12
Località: Modena

Re: Non si avvia più samonkey: help

Messaggio da Ansa89 »

Io farei così:
1) disattivo il modulo di seamonkey.
2) controllo che le librerie non siano usato da qualche altro programma.
3) se non sono usate da nessun altro (come è molto probabile), faccio "rm -f /usr/bin/*.so".
4) riattivo il modulo di seamonkey e spero.

Offtopic: Piccola considerazione personale: non userei mai e poi mai una distro che mette delle librerie in un path destinato a degli eseguibili.

erio
Linux 4.x
Linux 4.x
Messaggi: 1354
Iscritto il: ven 9 ott 2009, 19:25
Slackware: 13.37
Kernel: 3.0.7
Desktop: kde

Re: Non si avvia più samonkey: help

Messaggio da erio »

e fidati che non lo fa.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3788
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: Non si avvia più samonkey: help

Messaggio da joe »

Infatti, non è tanto la distro che mette dele librerie lì. Più che altro è chi ha creato il modulo che ha scelto quella dir come desinazione delle librerie dopra. Il punto è che il pacchettizzatore dovrebbe procurare tutti questi danni in quanto il modulo in slax non viene installato sporcando il sistema ma semplicemente montato in loop... e scaricato all'occorrenza. E come ho già detto prima il fatto che quello stesso modulo ha funzionato per diversi mesi mi fa pensare che questa scelta del pacchettizzatore non è probabilmente la causa dell'inghippo. fermo restando che poteva anche scegliere /usr/local/lib come destinazione delle librerie...

Proverò a seguire il consiglio, solo una domanda, come faccio a verificare il punto (2) ovvero che le librerie non siano utilizzate da qualche altro programma?

Avatar utente
Ansa89
Iper Master
Iper Master
Messaggi: 2703
Iscritto il: mer 29 ago 2007, 17:57
Nome Cognome: Stefano Ansaloni
Slackware: 14.2 64bit
Kernel: 4.9.61
Desktop: XFCE 4.12
Località: Modena

Re: Non si avvia più samonkey: help

Messaggio da Ansa89 »

joe ha scritto:Proverò a seguire il consiglio, solo una domanda, come faccio a verificare il punto (2) ovvero che le librerie non siano utilizzate da qualche altro programma?
Non ne ho idea.
L'ho scritto per evitare che qualcuno eseguisse alla lettera e poi si ritrovasse con alcuni programmi non funzionanti.
Se non hai modo di verificarlo, dai per scontato che nessun altro software usi quelle librerie.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3788
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 15.0
Kernel: 5.15.38
Desktop: dwm

Re: Non si avvia più samonkey: help

Messaggio da joe »

Ho seguito il consiglio.
Alcune note: a quanto pare tutti i files *so presenti in /usr/bin sono anche presenti all'interno del pacchetto, pertanto li ho rimossi a mano dopo aver comunque disattivato il modulo.
PEr la cronaca ho fatto così:
find /usr/bin name "*.so" -exec basename "{}" \; >/tmp/systemseamoklibs
find /testdir/usr/bin name "*.so" -exec basename "{}" \; >/tmp/pkgseamoklibs
Poi ho confrontato la situazione con vi, erano 20 righe di roba.

C'è da dire che vi è anche la subdir /usr/bin/components che contiene files .js ecc, aanche quella roba resta sul sistema nonostante la disattivazione del modulo. Volendo si puù confronatre anche quella roba li col contenuto del pacchetto.
Ok quindi ho rimosso i files *.so presenti in /usr/bin, poi ho riattivato il modulo e ottengo il solito errore, ma se provo ad utilizzare il comando di launch "seamonkey", lo script per intenderci, con quello funziona, e anche avviandolo dal menu di fluxbox funge, quindi penso anche con kde nonci siano problemi....

Codice: Seleziona tutto

# seamonkey-bin
seamonkey-bin: error while loading shared libraries: libplc4.so: cannot open shared object file: No such file or directories
# seamonkey
^C
Ok. Ora vi sto scrivendo da seamonkey, quindi problema rientrato sembrerebbe.

Rispondi