Jump to content
Sign in to follow this  
TrashyCoder

DNF - niepowodzenie instalacji Wine - Fedora 30

Recommended Posts

Chcę użyć programu z Windows na Linuxie, potrzebowałem zainstalować Wine:

sudo dnf install wine

Niestety w trakcie instalacji Wine zostałem wylogowany z systemu (Fedora 30) - gnome shell niespodziewanie zakończył działanie. Próba ponownej instalacji wywala następujące błędy:

Wykonywanie sprawdzania transakcji
Pomyślnie ukończono sprawdzanie transakcji.
Wykonywanie testu transakcji
Pobrane pakiety zostały zapisane w pamięci podręcznej do czasu następnej pomyślnej transakcji.
Można usunąć pakiety z pamięci podręcznej wykonując polecenie „dnf clean packages”.
Błąd: Błąd podczas sprawdzania transakcji:
  plik /usr/share/doc/glibc/NEWS z instalacji glibc-2.29-22.fc30.i686 jest w konflikcie z plikiem z pakietu glibc-2.29-15.fc30.x86_64
  plik /usr/share/doc/libxcrypt/NEWS z instalacji libxcrypt-4.4.9-1.fc30.i686 jest w konflikcie z plikiem z pakietu libxcrypt-4.4.7-1.fc30.x86_64

O ile dobrze rozumiem, Wine próbuje zainstalować biblioteki dla arch 64 oraz 32 bitowej, na co nie pozwalają ustawienia systemowe. W niektórych poradnikach widzę że trzeba włączyć wsparcie dla multiarch ale poradniki te są dla innych linusków niż fedora.

Pytania do Was:

1. Jak włączyć multiarch dla fedory 30?

2. Czy włączając 32 bity zaśmiecę system podówjnymi bibliotekami - dla 64 bit i 32 bit? Chciałbym zrobić jakoś tak, aby zainstalowano w systemie tylko te 32 bitowe biblioteki które są potrzebne w Wine do emulacji 32 bitowych programów Windowsa. Dodam że program jakiego chcę używać na Wine jest 64 bitowy a anie 32  bitowy. Podejrzewam że włączając multiarch wszystko będzie instalowane w sysemie i programach w 2 wersjach - 32 i 64 bity. Nigdy nie miałem do czynienia z multiarch...

Proszę pomóżcie...

 

Share this post


Link to post
Share on other sites

To raczej wygląda, że próbuje zainstalować biblioteki w różnych wersjach dla różnych architektur, a powinny być w tych samych wersjach.

Spróbuj jako root wykonać te polecenia

dnf clean all
dnf update
dnf install wine

 

Share this post


Link to post
Share on other sites

Niestety nie ma postępu nadal jest ten sam błąd:

Błąd: Błąd podczas sprawdzania transakcji:
  plik /usr/share/doc/glibc/NEWS z instalacji glibc-2.29-22.fc30.i686 jest w konflikcie z plikiem z pakietu glibc-2.29-15.fc30.x86_64
  plik /usr/share/doc/libxcrypt/NEWS z instalacji libxcrypt-4.4.9-1.fc30.i686 jest w konflikcie z plikiem z pakietu libxcrypt-4.4.7-1.fc30.x86_64

Coś ktoś?...

Share this post


Link to post
Share on other sites

Czy mam zrobić downgrade glibc i libcrypt ? Downgrade mnie trochę przeraża... Nie ma opcji aby zainstalować wine bez tych starszych bibliotek?

Edit:

Czy - o ile dobrze rozumiem - Wine chce zainstalować starsze bibloteki niż są w systemie?

Share this post


Link to post
Share on other sites

W domu spróbuję, bo mam ten problem na stacjonarnym kompie. To raczej nic nie da bo komunikat oznacza że biblioteki w systemie są nowsze niż te które chce zainstalować Wine.

Pytanie - zawsze sądziłem że jak w systemie są nowsze biblioteki niż te które wymaga dany program, to program zainstaluje się. Inaczej w odwrotnym przypadku. Czy faktycznie tak jest? Tak jest w windzie i tak  - o ile pamietam - było na starych linuxach (za czasów darmowego RedHata), choć w tych ostatnich ekspertem nigdy nie byłem.

Share this post


Link to post
Share on other sites

Zapewne instalacja Wine wymagała aktualizacji bibliotek glibc i libxcrypt, ale została przerwana przez crash Gnome Shell, więc w systemie zrobił się bałagan.

Jeżeli

dnf update --refresh

nie zadziała,  to sprawdź poleceniami

rpm -qa | grep glibc
rpm -qa | grep libxcrypt

czy nie masz zduplikowanych pakietów (tj. jednocześnie w wersjach 2.29-15 i 2.29-22 jeśli chodzi o glibc oraz 4.4.7-1 i 4.4.9-1 w przypadku libxcrypt).

Architekturami się nie przejmuj. Mają być jednocześnie wersje 64bit i 32bit.

Jeśli są zduplikowane, to usuń starsze wersje poleceniem

rpm -e --nodeps [pełna nazwa pakietu]

Share this post


Link to post
Share on other sites

dnf update --refresh nic nie dało.

Amos miał rację - crash spowodował że miałem 2 biblioteki w systemie, dziwne dnf powinien to chyba wychwycić i usunąć podwójne biblioteki przy refreshu... Wcześniej - przed Waszymi poradami - robiłem dnf update i nie dnf dawał znaków o duplikatach.

Po usunięciu zduplikowanych bibliotek udało się zainstalować wine - z jednym małym ale. Znowu nastąpił crash powłoki Gnome! Awaria nastąpiła pod mniej więcej koniec instalacji wine. Po awarii ponowiłem instalację wine i program się zainstalował, na razie działa, choć nie wiadomo czy nie wyjdą jakieś kwiatki w przyszłości.

1. Pytanie - gdzie znajdę jakiś dziennik z instalacji programu dnf-em? Czy mimo awarii menedżera (Gnome u mnie) udaje się to gdzieś zapisać? Chciałbym zobaczyś jaki pakiet powoduje crash gnome...

2. Pytanie - czy instalujecie programy dnf-em normalnie w środowisku graf? Zaczynam się zastanawiać czy w trakcie instalacji nie przejść na tryb teksowy...

3. Pytanie - polećcie jakiś dobry poradnik do zależności, widać sam dnf nie wystarczy. W ogóle to myślałem że w linuxach jest jak w Windows - nowsza biblioteka jest akceptowana, a okazuje się że niektóre programy na to nie pozwalają.

Coś za dużo mam tych awarii gnoma, tak czuję. Dwa razy przy wine, raz przy aktualizaji systemu. Coś chyba jest nie tak z systemem/kompem.

I jesxcze  dzięki za pomoc - sunrise i Amos

Share this post


Link to post
Share on other sites
4 godziny temu, TrashyCoder napisał:

Pytanie - gdzie znajdę jakiś dziennik z instalacji programu dnf-em?

dnf history oraz bardziej szczegółowo dnf history info <identyfikator>  gdzie identyfikator to numer transakcji z dnf history

4 godziny temu, TrashyCoder napisał:

Pytanie - czy instalujecie programy dnf-em normalnie w środowisku graf?

Ja tak instaluje.

 

4 godziny temu, TrashyCoder napisał:

Pytanie - polećcie jakiś dobry poradnik do zależności, widać sam dnf nie wystarczy.

Ja takiego nie znam, generalnie w przypadku nie rozwiązanych zależności dnf pomija kłopotliwy pakiet.

Share this post


Link to post
Share on other sites

W dnf history znalzłem transakcję i obejrzałem jej przebieg. Podejrzewam, że ostatni zapisany pakiet w historii to ten, który poprawnie się zainstalował, a nie ten który spowodował awarię Gnoma (albo przy instalacji którego nastąpiła awaria wywołana czymś innym).

Czy jest możliwe aby odnaleźć pakiet podczas instalacji którego nastąpiło niepowodzenie? Jeśli tak to jak?

Share this post


Link to post
Share on other sites

Oczywiście, przepraszam że tak długo:

[gosc@localhost ~]$ dnf history wine
Ident. | Wiersz poleceń           | Data i czas      | Działania      | Zmien.
-------------------------------------------------------------------------------
    16 | install wine             | 2019-09-17 18:34 | Install        |   34   
[gosc@localhost ~]$ dnf history info 16
Identyfikator transakcji   : 16
Czas rozpoczęcia           : wto, 17 wrz 2019, 18:34:15
Rozpoczęcie bazy danych RPM: 2018:b42eaeea7edab1430443d653d665ba609bf87bb0
Czas ukończenia            : wto, 17 wrz 2019, 18:34:50 (35 s)
Ukończenie bazy danych RPM : 2052:6ad1993d85bc65fb185b2d7a34da3ce65c9f8a8f
Użytkownik                 : Gosc <gosc>
Kod zwrotny                : Powodzenie
Releasever     : 30
Wiersz poleceń : install wine
Zmienione pakiety:
    Instalacja cairo-1.16.0-5.fc30.i686                           @updates
    Instalacja cups-libs-1:2.2.12-1.fc30.i686                     @updates
    Instalacja gnutls-3.6.8-1.fc30.i686                           @updates
    Instalacja gstreamer1-1.16.0-1.fc30.i686                      @updates
    Instalacja gstreamer1-plugins-base-1.16.0-1.fc30.i686         @updates
    Instalacja krb5-libs-1.17-14.fc30.i686                        @updates
    Instalacja libgphoto2-2.5.23-1.fc30.i686                      @updates
    Instalacja pango-1.43.0-4.fc30.i686                           @updates
    Instalacja sane-backends-drivers-cameras-1.0.27-24.fc30.i686  @updates
    Instalacja sane-backends-drivers-scanners-1.0.27-24.fc30.i686 @updates
    Instalacja sane-backends-libs-1.0.27-24.fc30.i686             @updates
    Instalacja wine-4.15-1.fc30.x86_64                            @updates
    Instalacja wine-alsa-4.15-1.fc30.i686                         @updates
    Instalacja wine-capi-4.15-1.fc30.i686                         @updates
    Instalacja wine-cms-4.15-1.fc30.i686                          @updates
    Instalacja wine-core-4.15-1.fc30.i686                         @updates
    Instalacja wine-ldap-4.15-1.fc30.i686                         @updates
    Instalacja wine-openal-4.15-1.fc30.i686                       @updates
    Instalacja wine-opencl-4.15-1.fc30.i686                       @updates
    Instalacja wine-pulseaudio-4.15-1.fc30.i686                   @updates
    Instalacja wine-twain-4.15-1.fc30.i686                        @updates
    Instalacja cyrus-sasl-lib-2.1.27-0.6rc7.fc30.i686             @fedora
    Instalacja harfbuzz-2.3.1-1.fc30.i686                         @fedora
    Instalacja libtasn1-4.13-7.fc30.i686                          @fedora
    Instalacja libverto-0.3.0-7.fc30.i686                         @fedora
    Instalacja libvisual-1:0.4.0-26.fc30.i686                     @fedora
    Instalacja libwayland-egl-1.17.0-1.fc30.i686                  @fedora
    Instalacja lockdev-1.0.4-0.29.20111007git.fc30.i686           @fedora
    Instalacja mpg123-libs-1.25.10-2.fc30.i686                    @fedora
    Instalacja nss-mdns-0.14.1-3.fc30.i686                        @fedora
    Instalacja openal-soft-1.19.1-2.fc30.i686                     @fedora
    Instalacja openldap-2.4.47-1.fc30.i686                        @fedora
    Instalacja opus-1.3.1-1.fc30.i686                             @fedora
    Instalacja pixman-0.38.0-1.fc30.i686                          @fedora
[gosc@localhost ~]$

 

Share this post


Link to post
Share on other sites

No ładnie. W logach dnf-a nie ma niczego, co wskazywałoby na nieprawidłowo zainstalowany pakiet. Bardzo możliwe, że Gnome się zwiesił, ale nie przeszkadza to ani trochę w instalacji oprogramowania. Na wszelki wypadek możesz zastosować

dnf update --best --allowerasing

w wolnym tłumaczeniu jest to "Guzik O Kurde". Jeżeli nie pomoże, to będziemy kombinować poziom niżej, czyli z RPMem.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×