Witaj na Forum Linuxiarzy
Zanim zalogujesz się, by pisać na naszym forum, zapoznaj się z kilkoma zasadami savoir-vivre'u w dziale Administracja.
Wiadomości z problemami zamieszczone w wątku "Przywitaj się" oraz wszelkie reklamy na naszym forum będą usuwane.

[ROZWIĄZANE] Przerwana aktualizacja z Fedorze.

Zaczęty przez ciubaka, Październik 08, 2019, 08:48:17 AM

Poprzedni wątek - Następny wątek

ciubaka

#15
Ok Paweł spróbuję wieczorem.
Teraz w robocie.
Tato, spokojnie, fedora była w celach samokształcenia, dla sportu.
Stawiać jej drugi raz nie będę, a naprawię albo łatwo albo wcale.
Wkurza mnie że tak żre ram, przed nieudaną aktualizacją też miała duże potrzeby, bez włączenia swapa ani rusz...
Poza tym byłaby w miarę sympatyczna.

pavbaranov

@TataPingu - Tak, masz absolutną rację, że szybciej system niekiedy postawi się od nowa, niż przywróci działanie skopanego. Niemniej jednak - wg mnie - warto wiedzieć jak to drugie zrobić, bowiem niekiedy po prostu będzie to nieodzowne. Oczywiście można backup, można timeshift itp. itd. Niemniej jednak istnieje prawdopodobieństwo graniczące z pewnością, że każdy użytkownik pewnego dnia stanie przed potrzebą:
- doprowadzenia do życia systemu, który padł był z jakiegoś powodu,
- nie istnieje ani backup, ani nie był zainstalowany timeshift, ani inne dziadostwo tego typu,
- opcja instalacji systemu na nowo nie wchodzi w grę z dowolnego powodu,
- uzdrowienie systemu jest konieczne.
No to kiedy się tego uczyć, jak nie wówczas, gdy jest to kompletnie bezpieczne, jak obecnie u @ciubaka? A raz nabyta wiedza (a w zasadzie jej schemat, mechanizm, bo tylko on będzie do wykorzystania na innej dystrybucji) procentuje w przyszłości.

@ciubaka - Po prostu wrzuć tu to co pluje ta dnfdragora przy próbie instalacji którejkolwek z tych felernych paczek.
Istnieją jeszcze inne metody doprowadzenia takiej felernej paczki do życia. Pierwsze - musisz się upewnić, że paczka lokalna jest prawidłowa. Pisałeś wcześniej, że problem jest związany z przerwaną aktualizacją. Istnieje zatem możliwość, że te paczki, które ściągnąłeś są "niekompletne" - na dysku widzisz ją jako prawidłową paczkę rpm, ale w istocie to nie jest ta sama paczka, która jest na serwerze. Zatem:
1. w pierwszej kolejności spróbować ją zainstalować bezpośrednio z serwera (a ogólnie - zaktualizować system),
2. jeśli powyższe się nie powiedzie, zdiagnozować co go boli (najlepsze w takich celach są konsolowe menedżery paczek, bo po prostu najczęściej lepiej widać komunikaty aktualizacji/instalacji), a następnie:
a. ściągnąć taką felerną paczkę na dysk i spróbować ją zainstalować lokalnie,
b. jeśli i z tym taki menedżer paczek sobie nie radzi można skorzystać jeszcze bezpośrednio z rpm.
Ogólna jednak uwaga: w pierwszej kolejności musisz się upewnić, czy paczka, którą chcesz zainstalować jest Ci do czegoś niezbędna. Jeśli to prosta aplikacja, to często lepiej odinstalować ją (jeśli się da) i ewentualnie zainstalować ponownie. Jeśli to jakaś paczka systemowa, a już w szczególności bazowa, to upewnij się, że w repozytoriach nadal ta paczka i w tej samej wersji jest dostępna. Może się bowiem zdarzyć tak, że masz - skutkiem przerwanej aktualizacji - system zaktualizowany częściowo i to w dodatku w ten sposób, że w systemie występują stare, porzucone już paczki i nowe, które tych paczek już nie potrzebują. Dopiero wyposażony w taką wiedzę możesz podjąć decyzję, czy należy owe paczki doprowadzić do życia w systemie, czy należy je odinstalować, czy też podjąć jakiekolwiek inne działania.

ciubaka

8 paczek wymaga aktualizacji nadal, niestety nie idzie ich popchnąć ani z palca indywidualnie, ani w komplecie razem. Nadal sypią albo pojedyńczym, albo całą listą błędów, zależy która. Jako że są tam systemowe, typu mate system monitor, to nie będę się z tym dalej szarpał. Matroski w sumie się nie boję, ale szkoda mi czasu czasu...

pavbaranov

Wrzuć to co pluje każda z paczek, przy próbie instalacji, bądź też - lepiej - gdy wszystkie je dasz do aktualizacji na raz.
PS: mate-system-monitor nie jest paczką systemową. To aplikacja należąca do MATE.

ciubaka

#19
pierwsza:

Błąd podczas wykonywania transakcji: plik /usr/share/doc/expat/Changes z instalacji expat-2.2.8-1.fc30.i686 jest w konflikcie z plikiem z pakietu expat-2.2.7-1.fc30.x86_64

druga:

Błąd podczas wykonywania transakcji: plik /usr/share/man/man1/gdk-pixbuf-query-loaders.1.gz z instalacji gdk-pixbuf2-2.38.2-1.fc30.i686 jest w konflikcie z plikiem z pakietu gdk-pixbuf2-2.38.1-1.fc30.x86_64

trzecia:

Błąd podczas wykonywania transakcji: plik /usr/share/doc/libebml/ChangeLog z instalacji libebml-1.3.9-1.fc30.i686 jest w konflikcie z plikiem z pakietu libebml-1.3.7-1.fc30.x86_64

czwarta:

Błąd podczas wykonywania transakcji: plik /usr/share/doc/libebml/ChangeLog z instalacji libebml-1.3.9-1.fc30.i686 jest w konflikcie z plikiem z pakietu libebml-1.3.7-1.fc30.x86_64
plik /usr/share/doc/libmatroska/ChangeLog z instalacji libmatroska-1.5.2-1.fc30.i686 jest w konflikcie z plikiem z pakietu libmatroska-1.5.0-1.fc30.x86_64

piąta:

Błąd podczas wykonywania transakcji: plik /usr/share/doc/libxcrypt/NEWS z instalacji libxcrypt-4.4.10-1.fc30.i686 jest w konflikcie z plikiem z pakietu libxcrypt-4.4.9-1.fc30.x86_









ciubaka

szósta siódma i ósma związane  mate to kobyły na kilkanaście wersów każda, odpuszczam zrzuty

TataPingu

#21
Cytat: ciubaka w Październik 21, 2019, 07:18:09 PM
jest w konflikcie z plikiem z pakietu

No to możesz mieć problem...
- w takim przypadku, jak już wspominałem, prędzej postawisz system na nowo, niż go przywrócisz do porządku...

Jasne, w niektórych przypadkach jest to nieodzowne i trzeba się "pomęczyć".
OK, i dla "wiedzy" można "podłubać", tylko, że...
- to nie są powtarzalne przypadki !

To, że Ciubace podczas aktualizacji "zrypało się" kilka przypadkowych paczek nie oznacza, że kiedykolwiek to jeszcze się komuś wydarzy (dokładnie te same paczki przy tej samej konstelacji zainstalowanego oprogramowania) i nawet znalezienie rozwiązania w tym akurat przypadku i tak niczego nie nauczy...
- po prostu, szkoda na to czasu...

Łatwiej będzie skopiować zmodyfikowane pliki konfiguracyjne (jeśli takowe są), postawić system na nowo i wkopiować je pod świeży system...

A ogólnie w takich przypadkach, gdy coś takiego występuje (konflikty), najlepiej jest wyinstalować do czysta dany program (czy nawet całą "gałąź", np. cały MATE) do którego należy paczka i ponownie go zainstalować...

pavbaranov

#22
Cytat: ciubaka w Październik 21, 2019, 07:18:09 PM
pierwsza:

Błąd podczas wykonywania transakcji: plik /usr/share/doc/expat/Changes z instalacji expat-2.2.8-1.fc30.i686 jest w konflikcie z plikiem z pakietu expat-2.2.7-1.fc30.x86_64
Tu sprawdź, czy nie możesz wymusić aktualizacji. Zwykle coś takiego oferuje jakiś przełącznik typu --force.
Cytat: ciubaka w Październik 21, 2019, 07:18:09 PM
druga:

Błąd podczas wykonywania transakcji: plik /usr/share/man/man1/gdk-pixbuf-query-loaders.1.gz z instalacji gdk-pixbuf2-2.38.2-1.fc30.i686 jest w konflikcie z plikiem z pakietu gdk-pixbuf2-2.38.1-1.fc30.x86_64
Również można spróbować dać jakieś "force" lub odinstalować paczkę i ponownie zainstalować. Oczywiście o ile jest Ci potrzebna.

Cytat: ciubaka w Październik 21, 2019, 07:18:09 PM
trzecia:

Błąd podczas wykonywania transakcji: plik /usr/share/doc/libebml/ChangeLog z instalacji libebml-1.3.9-1.fc30.i686 jest w konflikcie z plikiem z pakietu libebml-1.3.7-1.fc30.x86_64
Sforsować instalację.
Cytat: ciubaka w Październik 21, 2019, 07:18:09 PM
czwarta:

Błąd podczas wykonywania transakcji: plik /usr/share/doc/libebml/ChangeLog z instalacji libebml-1.3.9-1.fc30.i686 jest w konflikcie z plikiem z pakietu libebml-1.3.7-1.fc30.x86_64
plik /usr/share/doc/libmatroska/ChangeLog z instalacji libmatroska-1.5.2-1.fc30.i686 jest w konflikcie z plikiem z pakietu libmatroska-1.5.0-1.fc30.x86_64
Jak w przypadku drugim.
Cytat: ciubaka w Październik 21, 2019, 07:18:09 PM
piąta:

Błąd podczas wykonywania transakcji: plik /usr/share/doc/libxcrypt/NEWS z instalacji libxcrypt-4.4.10-1.fc30.i686 jest w konflikcie z plikiem z pakietu libxcrypt-4.4.9-1.fc30.x86_
Jak wyżej.

EDIT:
Ogólnie to tego typu błędy, jak widzisz, czyli np. że expat nie może być zainstalowany, albowiem... expat jest zainstalowany, ale w innej wersji, najczęściej są wynikiem niedokończonej, pełnej, aktualizacji systemu. W niektórych systemach, przynajmniej część programów jest pakowanych w taki sposób, że wymaga jakiejś paczki zależnej w określonej wersji. Np. expat jest zależnością choćby wayland (z paczek, które prawdopodobnie domyślnie Ci się instalują, bo to zależność gtk3, a tę paczkę instaluje Ci mate) i może się zdarzyć tak, że zainstalowana paczka wayland (nie ta, która jest na serwerze, ale ta, która jest lokalnie zainstalowana) wymaga expat w wersji 2.2.7. Nowa wersja - 2.2.8 nie będzie się wówczas chciała zainstalować, bo wersja 2.2.7 jest "trzymana" przez coś innego.
Znów się powtórzę zatem, ale system powinieneś mieć aktualny, a mieszanie wersji paczek z różnych momentów (tzw. częściowa aktualizacja systemu) zwykle nie jest najlepszym rozwiązaniem, zanim cokolwiek w tym celu zrobisz, to:
- udostępnij Twojej instalacji Fedory jej aktualne serwery (nie pamiętam jak to się na Fedorze robiło, ale zwykle albo to jest jakaś paczka, którą należy zainstalować, albo jest gdzieś na stronach Fedory generator serwerów, albo jest jakiś program, który umożliwia ich pobranie; sprawdź też, czy lista serwerów nie jest jakoś zakomentowana) - polecam tu wiki Fedory, bo niczego lepszego nie wymyślę,
- po upewnieniu się, że serwery są bieżące - dokonaj pełnej aktualizacji systemu - i znów odsyłam do wiki Fedory.
Dopiero gdy po tych dwu czynnościach system sam się nie naprawi (tj. nie zaktualizuje), to przystąp do jakichś działań uzdrawiających. Pamiętaj przy tym, że w przypadku, który u Ciebie wystąpił dobrze jest sprawdzać wersje plików bezpośrednio na serwerze Fedory (tj. w wyszukiwarce paczek) i sprawdzać, czy one aktualnie nadal są. Inna sprawa, że te pliki (nie paczki), które u Ciebie zatrzymują instalację, nie są bardzo istotne, bo to np. Changelog (czyli wykaz zmian wersji oprogramowania). Ostrożnie można w tego typu przypadkach pokusić się o to, o czym pisałem - sforsować aktualizację takiej paczki.
Możesz jeszcze spróbować puścić komendę:
dnf repoquery --unsatisfied
która winna Ci zwrócić paczki z problemami w zależnościach.
-

ciubaka

A mogę powywalać te expaty z systemu czy raczej strach? Pełnej aktualizacji Fedora zrobić jakoś nie chce ... Co gorsza nie podają kiedy wyjdzie oczekiwana na listopad wersja 31. To znaczy podają - że raczej nieprędko wyjdzie ...

pavbaranov

A możesz nam odpowiedzieć skąd my mamy wiedzieć, co pociągnie u Ciebie wywalenie "tych expatów"? :) Prawdopodobnie jedynie mogę stwierdzić, że akurat jeśli chodzi o tę paczkę (czyli expat), to jeśli ją spróbujesz wywalić, to wywalisz co najmniej połowę systemu i F. już nie wstanie.
Pokaż w końcu te logi z pełnej aktualizacji, bo tak to człowiek tylko zgaduje.

ciubaka

#25
Udało mi się posprzątać tę kupę wreszcie, chociaż nie wierzyłem już że to będzie szybko możliwe.
Ale udało się, bo jednak wyszła Fedora 31.
I siłowo udało mi się przepchnąć aktualizację z 30 na 31, chociaż teoretycznie nie jest to możliwe, o czym kilkukrotnie terminal mnie informował.
Zatem podaję dla zaciekawionych.
Aktualizację przeprowadziłem w terminalu (podobno można i z pena, nawet miałem gotowego, ale poszło bez i niego).
Wg metody opisanej w oficjalnym poradniku Fedory:


https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#Resolving_post-upgrade_issues
oraz
https://fedoramagazine.org/upgrading-fedora-30-to-fedora-31/


Oczywiście nie chciało, sypało błędami jak poprzednio, ale dało też wskazówkę, żeby zmienić TRZECIĄ komendę.
I należy ją napisać tak:


sudo dnf system-upgrade download --refresh --releasever=31 --allowerasing


I poszło, i po dwóch godzinach (!!! o losie ale długo to trwało ...) cieszyłem się nowym, sprawnym, aktualnym w pełni i działającym systemem.
Nawet jakiś lekko żwawszy mi się wydawał :-)



Zobacz najnowsze wiadomości na forum