Chrome non si avvia

Fedora Linux Programmi
#1

Salve!
L’unico programma che non parte nella mia nuovissima F18 è, stranamente, Chrome:

[aiace@Adel ~]$ google-chrome /usr/bin/google-chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory
mentre in modalità grafica l’icona saltella qualche secondo (utilizzo KDE), poi scompare…

Nei repo ho attivo anche quello specifico

/etc/yum.repos.d/google-chrome.repo

e ho aggiornato poco fa.

Manca una libreria specifica (libudev o qualcosa di simile?).
Grazie

#2

Ciao,
prova con

# yum install libgudev1

~/tradis

#3

grazie, ma ce l’ho già (non credo di aver bisogno anche di quelli per i686):

[code][aiace@Adel ~]$ yum list libgudev1
Plugin abilitati:fastestmirror, langpacks, presto, refresh-packagekit
Loading mirror speeds from cached hostfile

  • fedora: ftp.informatik.uni-frankfurt.de
  • rpmfusion-free: mirror.switch.ch
  • rpmfusion-free-updates: mirror.switch.ch
  • rpmfusion-nonfree: mirror.switch.ch
  • rpmfusion-nonfree-updates: mirror.switch.ch
  • updates: ftp.informatik.uni-frankfurt.de
    Pacchetti installati
    libgudev1.x86_64 197-1.fc18.2 @updates
    Pacchetti disponibili
    libgudev1.i686 197-1.fc18.2 updates [/code]

C0s’altro potrebbe mancare?

#4

Da quello che ho capito delle distro linux è che se una dipendeza è installata di default dall’os (quindi quando installi l’os installi anche la dipendenza) ma un programma te la richiede lo stesso, sarà sicuramente una questione di architettura differente, e se hai un OS 64 bit, quasi sicuramente l’architettura sarà: i686.

Comunque, ti basta dare: yum provides libudev.so.0 , per vedere se manca quella dipendenza o no.

#5

Se hai aggiornato da Fedora 17 a Fedora 18, sono stati riscontrati problemi simili http://forum.fedoraonline.it/viewtopic.php?id=19848 e http://forum.fedoraonline.it/viewtopic.php?id=19837. Nel mio caso, credo di aver risolto (vedi post 5 di http://forum.fedoraonline.it/viewtopic.php?id=19961 discussione) con

# yum distro-sync
#6

[quote=iGoblin]
(…) ti basta dare: yum provides libudev.so.0 , per vedere se manca quella dipendenza o no.[/quote]

grazie, ma non è il mio caso:

[code][aiace@Adel ~]$ yum provides libudev.so.0
Plugin abilitati:fastestmirror, langpacks, presto, refresh-packagekit
adobe-linux-i386 | 951 B 00:00:00
adobe-linux-x86_64 | 951 B 00:00:00
fedora/18/x86_64/metalink | 31 kB 00:00:00
google-chrome | 951 B 00:00:00
rpmfusion-free-updates | 3.3 kB 00:00:00
rpmfusion-nonfree-updates | 3.3 kB 00:00:00
updates/18/x86_64/metalink | 28 kB 00:00:00
virtualbox | 951 B 00:00:00
rpmfusion-nonfree-updates/primary_db | 75 kB 00:00:00
Loading mirror speeds from cached hostfile

  • fedora: ftp.informatik.uni-frankfurt.de
  • rpmfusion-free: mirror.switch.ch
  • rpmfusion-free-updates: mirror.switch.ch
  • rpmfusion-nonfree: mirror.switch.ch
  • rpmfusion-nonfree-updates: mirror.switch.ch
  • updates: mirror.switch.ch
    rpmfusion-nonfree-updates/filelists_db | 165 kB 00:00:00
    No Matches found
    [/code]

@marcomotta
sì, ho eseguito un passaggio da F17 a F18 tramite fedup, però stranamente a me sia ktorrent sia K3b partono e funzionano regolarmente…

Adesso eseguirò il tuo suggerimento

[quote]# yum distro-sync[/quote], che francamente non conoscevo, e se non dovesse funzionare, disinstallerò e reinstallerò Chrome.

Vi terrò poi aggiornati sugli esiti dell’operazione.

#7

dai il comando da root:

# ln -s /usr/lib/libudev.so.1 /usr/lib/libudev.so.0

poi riprova.

#8

sgrunt, sembra che ci sia qualche problema più grosso…

ho provato sia la soluzione-marcomotta:

# yum distro-sync

che ha modificato alcuni pacchetti:

[code]Eliminato:
crash.x86_64 0:6.1.0-1.fc17 fedup.noarch 0:0.7.2-1.fc17 fftw-libs.x86_64 0:3.3.3-5.fc17 fftw-libs-double.x86_64 0:3.3.3-5.fc17
fftw-libs-long.x86_64 0:3.3.3-5.fc17 fftw-libs-quad.x86_64 0:3.3.3-5.fc17 fftw-libs-single.x86_64 0:3.3.3-5.fc17 grub-efi.x86_64 1:0.97-93.fc17

Installato:
crash.x86_64 0:6.0.8-2.fc18 fedup.noarch 0:0.7.1-1.fc18 fftw-libs.x86_64 0:3.3.3-4.fc18 fftw-libs-double.x86_64 0:3.3.3-4.fc18
fftw-libs-long.x86_64 0:3.3.3-4.fc18 fftw-libs-quad.x86_64 0:3.3.3-4.fc18 fftw-libs-single.x86_64 0:3.3.3-4.fc18 grub-efi.x86_64 1:0.97-91.fc18

Aggiornato:
akmod-nvidia.x86_64 1:304.64-7.fc18[/code]

sia quella (ri)proposta da virus (che non avevo letto prima di effettuare la sincronizzazione):

# ln -s /usr/lib/libudev.so.1 /usr/lib/libudev.so.0

ma nessuna delle due riesce a sbloccare Chrome:

[aiace@Adel ~]$ google-chrome /usr/bin/google-chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

Più tardi riavvierò, forse basterà (magari anche solo per attivare il link simbolico)?

#9

se la tua è una 64 bit allora quel link simbolico non va bene, vediamo:

[code]# updatedb

locate libudev.so[/code]

#10

Non uso google-chrome, comunque questo è un bug specifico nel packaging da parte di google.
Vedi qua la http://fedoraproject.org/wiki/FedUp#Cleaning_Up_Post_Upgrade e qua il https://bugzilla.redhat.com/show_bug.cgi?id=888085.

La soluzione, come indicata nella wiki lincata sopra, sarebbe

# yum remove google-chrome-\* && yum install google-chrome-[beta,stable,unstable]

EDIT: questo avvalora tra l’altro il primo thread richiamato da marcomotta, http://forum.fedoraonline.it/viewtopic.php?id=19848

#11

Ho riavviato, ma ancora nulla, però ho risolto.
Qui sotto provo a spiegare come, a beneficio di altri.

@tempus
grazie, link molto istruttivi.
Ho utilizzato la stringa consigliata

yum remove google-chrome-\* && yum install google-chrome-[beta,stable,unstable]

scegliendo stable dalla pagina su Fedup del Fedora Project.
Adesso Chrome riparte normalmente :hammer: :clap:
Da quello che ho capito fra tutte le pagine linkate, è che si tratta di un problema di Chrome, legato a un repo per F17:

[code]–> Running transaction check
—> Package google-chrome-stable.x86_64 0:25.0.1364.97-183676 will be erased
–> Finished Dependency Resolution
Dependencies Resolved

=======================================================================================================
Package Arch Version Repository Size

Removing:
google-chrome-stable x86_64 25.0.1364.97-183676 @google-chrome/17 152 M
[/code]
Il comando suindicato disinstalla la versione ‘sbagliata’ e reinstalla in una sola ‘mandata’ quella corretta.

Per completezza e cortesia:

sì, ho un processore AMD Phenom II X4 965:

[root@Adel ~]# updatedb

non ha restituito messaggi (salvo avvisarmi, giustamente, all’esecuzione di yum remove ecc.:

Warning: RPMDB altered outside of yum.

E poi

[root@Adel ~]# locate libudev.so /usr/lib/libudev.so.0 /usr/lib/libudev.so.1 /usr/lib/libudev.so.1.2.1 /usr/lib64/libudev.so.1 /usr/lib64/libudev.so.1.2.1
Nel commento 7 (di Will Woods) della summenzionata pagina su Fedup, trovo anche scritto:

[quote]if there’s a problem with the libudev symlinks that’s a problem with the package that owns libudev.
The tricky bit here is that in F17, libudev is provided by the ‘libudev’ package (which is a subpackage of udev). In F18, libudev is in systemd-libs.
Somewhere between the two, a symlink is being lost (or not properly recreated).[/quote]
ma è del 2 gennaio 2013. Visto l’output di locate, forse qualcosa è cambiato nel frattempo?

INFINE
Mi piacerebbe anche sapere se devo eliminare quel simlink, e in caso affermativo come posso farlo. Detto altrimenti: lasciandolo così, ci saranno problemi con altri programmi?

Grazie a tutti, per me si può scrivere risolto (e magari farne una miniguida?)

#12

Al post #7 di quella conversazione risponde il post #14; quanto all’output di locate, mi pare strano tu abbia /usr/lib e /usr/lib64 popolate da (apparentemente) systemd-libs.i686 e systemd-libs.x86_64.

$ rpm -qa|grep ^systemd-libs
$ for i in /usr/lib*/libudev.so*; do echo $i; rpm -qf $i; done

Il symlink dovrebbe essere senz’altro rimuovibile se, come dovrebbe, è “orfano”. Lasciarlo dov’è non dovrebbe d’altra parte e in linea di principio creare problemi.

#13

[quote=tempus]Al post #7 di quella conversazione risponde il post #14; quanto all’output di locate, mi pare strano tu abbia /usr/lib e /usr/lib64 popolate da (apparentemente) systemd-libs.i686 e systemd-libs.x86_64.

$ rpm -qa|grep ^systemd-libs
$ for i in /usr/lib*/libudev.so*; do echo $i; rpm -qf $i; done

Il symlink dovrebbe essere senz’altro rimuovibile se, come dovrebbe, è “orfano”. Lasciarlo dov’è non dovrebbe d’altra parte e in linea di principio creare problemi.[/quote]

grazie di avere risposto in maniera circostanziata, ma avrei bisogno di qualche chiarimento.

Il primo comando mi restituisce soltanto i (due) programmi (presumibilmente) installati sulla mia macchina:

[aiace@Adel ~]$ rpm -qa|grep ^systemd-libs systemd-libs-197-1.fc18.2.x86_64 systemd-libs-197-1.fc18.2.i686
senza indicarmi, però, dove stanno…

mentre l’altro (che, intuisco vagamente, dovrebbe visualizzare i files libudev.so e poi aggiornarli) non so come utilizzarlo, dato che al prompt mi si apre una riga successiva con un cursore angolare >
da cui non riesco a uscire, se non ‘stroncando’ la finestra/scheda del terminale.
E’ normale?
Grazie

#14

Non capisco perché tu debba avere la versione i686 di systemd-libs.

Il secondo comando probabilmente ti restituiva un “>” per un apice che potrebbe esserti scappato da qualche parte. Copia-incollalo e dovrebbe restituire un output senza problemi. Quello che fa è interrogare tutti i libudev.so installati chiedendo loro “Chi ti ha installato? Da dove vieni? Chi ti vuole qua?”
Se nell’output ottieni

...] il file /usr/lib/libudev.so.0 non è posseduto da alcun pacchetto ...]
rimuovi detto file.
Se nell’output gli altri file risultano essere di pertinenza dei systemd-libs (è così a questo punto con una probabilità del 100%), rimuovi il systemd-libs.i686:

# yum remove --setopt=clean_requirements_on_remove=1 systemd-libs.i686 --assumeno

se si tira dietro il mondo, è meglio aprire un altro thread. Altrimenti direi che hai finito, magari a chiusura i soliti

# package-cleanup --problems
# rpmconf -a

non guastano

#15

wow, che tecnica (no, davvero, non sto scherzando: complimenti – io sono un vecchio umanista…)

Preferisco fare un passetto alla volta: il primo è stato semplice, avevi ragione, avrò sbagliato a ridigitare qualcosa, comunque adesso ha funzionato

[aiace@Adel ~]$ for i in /usr/lib*/libudev.so*; do echo $i; rpm -qf $i; done /usr/lib64/libudev.so.1 systemd-libs-197-1.fc18.2.x86_64 /usr/lib64/libudev.so.1.2.1 systemd-libs-197-1.fc18.2.x86_64 /usr/lib/libudev.so.0 il file /usr/lib/libudev.so.0 non è posseduto da alcun pacchetto /usr/lib/libudev.so.1 systemd-libs-197-1.fc18.2.i686 /usr/lib/libudev.so.1.2.1 systemd-libs-197-1.fc18.2.i686

Per rimuoverlo dovrei dare un comando come

# yum remove /usr/lib/libudev.so.0

giusto? Aggiungo qualche parametro/opzione o è inutile?

La situazione degli altri mi pare un po’ incasinata:
ci sono due binari, cioè libudev.so.1 e libudev.so.1.2.1
Entrambi si trovano sia in /usr/lib/, sia in /usr/lib64/
ma (da quello che capisco rispetto all’output) sono di pertinenza tanto di systemd-libs-197-1.fc18.2.i686, quanto di systemd-libs-197-1.fc18.2.x86_64.

Come consigli di procedere, per evitare casini?
Intanto grazie

#16

Per rimuovere il file che non è posseduto da alcun pacchetto usa semplicemente

# rm /usr/lib/libudev.so.0

(se non è posseduto da alcun pacchetto, i comandi yum ed rpm non hanno potere su di esso). Quel file è il symlink che hai creato manualmente nel cercare inizialmente di far funzionare chrome; rpm conferma di non conoscerlo.

libudev.so.1 è un collegamento simbolico per libudev.so.1.2.1; controlla pure con

$ ll /usr/lib64/libudev.so*

Quindi ci sono due binari (due libudev.so.1.2.1) assistiti da altrettanti collegamenti simbolici.
I file sotto /usr/lib64 sono di pertinenza del solo systemd-libs.x86_64; i file sotto /usr/lib sono di pertinenza del solo systemd-libs.i686; originariamente volevo controllare che non ci fossero rimasugli di pertinenza del e.g. vecchio libudev, essendo il sistema un recente upgrade da F17; e comunque che fosse tutto come immaginato.
Il mio consiglio resta quello del post precedente; dopo aver rimosso /usr/lib/libudev.so.0 (con rm, non con yum), vai con

# yum remove --setopt=clean_requirements_on_remove=1 systemd-libs.i686 --assumeno

(e poi le pulizie di primavera)
Qua siamo già potenzialmente un po’ off topic rispetto alla questione originaria, per cui ti suggerivo di aprire un nuovo thread se quest’ultimo comando avesse preteso di rimuovere “troppo”

#17

ok, tutto chiarissimo

eseguo e ancora grazie, prima che veniamo richiamati all’ordine per aver ‘sforato’ rispetto al topic… :ontopic:
ma, d’altra parte, IMHO tutte queste ‘lungaggini’ = spiegazioni, in realtà :doc: ] possono aiutare anche altri: mica mi ci sarò trovato soltanto io, in questa situazione, no?)
:wink: