robaq Napisano Sierpień 14, 2008 Zgłoszenie Share Napisano Sierpień 14, 2008 Dopiero co zainstalowałem Fedorę 8, i chciałbym zrobić upgrade do wersji 9. Problem w tym, że gdy wpisuję w terminal jakiekolwiek polecenie yuma (np. yum list, czy yum update), za każdym razem wywala bład: Could not retrieve mirrorlist http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386 error was [Errno 4] IOError: <urlopen error (-2, 'Ta nazwa lub usxc5x82uga jest nieznana')> Error: Cannot retrieve repository metadata (repomd.xml) for repository: updates. Please verify its path and try again Nie mogę więc zaaktualizować systemu, ani nic zainstalować. Pomocy ---- łączenie postów ---- Wywaliłem repozytorium updates. Pomogło, ale tylko częściowo. Teraz yum znajduje uaktualnienia i paczki, ale gdy chcę coś zainstalowac, za każdym razem na końcu wyskakuje: --> Finished Dependency Resolution Error: Missing Dependency: mono(glade-sharp) = 2.10.0.0 is needed by package banshee Error: Missing Dependency: mono(gtk-sharp) = 2.10.0.0 is needed by package banshee Error: Missing Dependency: mono(glib-sharp) = 2.10.0.0 is needed by package banshee Error: Missing Dependency: mono(gnome-vfs-sharp) = 2.16.0.0 is needed by package banshee Error: Missing Dependency: mono(gconf-sharp) = 2.16.0.0 is needed by package banshee Error: Missing Dependency: mono(gdk-sharp) = 2.10.0.0 is needed by package banshee Error: Missing Dependency: mono(gnome-sharp) = 2.16.0.0 is needed by package banshee Error: Missing Dependency: mono(pango-sharp) = 2.10.0.0 is needed by package banshee A jak wpisuję yum update albo yum upgrade, zawsze na końcu zapętla się: --> Package banshee.i386 0:0.13.1-1.fc8 set to be updated --> Processing Dependency: mono(gnome-vfs-sharp) = 2.16.0.0 for package: banshee --> Processing Dependency: mono(glib-sharp) = 2.10.0.0 for package: banshee --> Processing Dependency: mono(gconf-sharp) = 2.16.0.0 for package: banshee --> Processing Dependency: mono(gnome-sharp) = 2.16.0.0 for package: banshee --> Processing Dependency: mono(gtk-sharp) = 2.10.0.0 for package: banshee --> Processing Dependency: mono(glade-sharp) = 2.10.0.0 for package: banshee --> Processing Dependency: mono(pango-sharp) = 2.10.0.0 for package: banshee --> Processing Dependency: mono(gdk-sharp) = 2.10.0.0 for package: banshee ---> Package kdebase.i386 6:3.5.8-5.fc8 set to be updated --> Processing Dependency: libsensors.so.3 for package: kdebase --> Processing Dependency: libraw1394.so.8 for package: kdebase --> Processing Dependency: libldap-2.3.so.0 for package: kdebase ---> Package perl-Compress-Raw-Zlib.i386 0:2.008-40.fc10 set to be updated ---> Package perl-DateManip.noarch 0:5.44-4.fc8 set to be updated --> Processing Dependency: perl(:MODULE_COMPAT_5.8.8) for package: perl-DateManip ---> Package pinentry.i386 0:0.7.4-5.fc9 set to be updated ---> Package dirmngr.i386 0:1.0.2-1.fc10 set to be updated --> Processing Dependency: perl(:MODULE_COMPAT_5.8.8) for package: perl-DateManip ---> Package libksba.i386 0:1.0.3-2.fc9 set to be updated I tak w kólko. Co mam zrobić? ;[ Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
rafi6666 Napisano Sierpień 16, 2008 Zgłoszenie Share Napisano Sierpień 16, 2008 Mam ten sam problem ?? Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
@WalDo Napisano Sierpień 16, 2008 Zgłoszenie Share Napisano Sierpień 16, 2008 Mam ten sam problem ??Mnie się pytasz? Ja tam nie wiem... @robaq - jeśli dopiero co zainstalowałeś F8, to zamiast upgrade'u lepiej jest zrobić reinstalację - szybciej i pewniej a przy określonym (podawanym wiele razy na forum) układzie partycji właściwie bezbolesny. Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Baki Napisano Sierpień 16, 2008 Zgłoszenie Share Napisano Sierpień 16, 2008 Ja mam podobny problem! U mnie pojawia się coś takiego: Wczytane wtyczki: refresh-packagekit Could not retrieve mirrorlist http://mirrors.fedoraproject.org/mirrorlis...9&arch=i386 error was [Errno 14] HTTP Error 503: Service Temporarily Unavailable Błąd: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again Proszę o jakąś pomoc.... Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
@WalDo Napisano Sierpień 16, 2008 Zgłoszenie Share Napisano Sierpień 16, 2008 Baki poszukaj na forum. Dzisiaj jakaś epidemia jest czy co? Co drugi post z podobnym problemem Tak, serwer mirrorów nie działa. Pewnie coś się im zawaliło, trzeba poczekać. Jeśli masz jakiś "kolec" i nie możesz czekać, to przełącz sobie odpowiednie pliki *.repo z "mirrorlist" na "baseurl" (zakomentowanie jednej linii i odkomentowanie drugiej). P.S.Chyba zacznę wywalać takie posty do "Kosza". Ludzie, zapisując się na forum zobowiązaliscie się do przestrzegania "Regulaminu". Bądźcie tak łaskawi, uprzejmie proszę i przeczytajcie rozdz.II pkt.2.a-d. Regulamin jest TUTAJ Najłatwiej jest przeszukać forum przy pomocy Google - "site:fedora.pl <szukana fraza>" Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Adi1981 Napisano Sierpień 18, 2008 Zgłoszenie Share Napisano Sierpień 18, 2008 → http://www.redhat.com/archives/fedora-deve...t/msg00687.html → https://www.redhat.com/archives/fedora-anno...t/msg00008.html Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Adi1981 Napisano Sierpień 22, 2008 Zgłoszenie Share Napisano Sierpień 22, 2008 Last week we discovered that some Fedora servers were illegally accessed. The intrusion into the servers was quickly discovered, and the servers were taken offline. Security specialists and administrators have been working since then to analyze the intrusion and the extent of the compromise as well as reinstall Fedora systems. We are using the requisite outages as an opportunity to do other upgrades for the sake of functionality as well as security. Work is ongoing, so please be patient. Anyone with pertinent information relating to this event is asked to contact [email protected]. One of the compromised Fedora servers was a system used for signing Fedora packages. However, based on our efforts, we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key. Based on our review to date, the passphrase was not used during the time of the intrusion on the system and the passphrase is not stored on any of the Fedora servers. While there is no definitive evidence that the Fedora key has been compromised, because Fedora packages are distributed via multiple third-party mirrors and repositories, we have decided to convert to new Fedora signing keys. This may require affirmative steps from every Fedora system owner or administrator. We will widely and clearly communicate any such steps to help users when available. Among our other analyses, we have also done numerous checks of the Fedora package collection, and a significant amount of source verification as well, and have found no discrepancies that would indicate any loss of package integrity. These efforts have also not resulted in the discovery of additional security vulnerabilities in packages provided by Fedora. Our previous warnings against further package updates were based on an abundance of caution, out of respect for our users. This is also why we are proceeding with plans to change the Fedora package signing key. We have already started planning and implementing other additional safeguards for the future. At this time we are confident there is little risk to Fedora users who wish to install or upgrade signed Fedora packages. In connection with these events, Red Hat, Inc. detected an intrusion of certain of its computer systems and has issued a communication to Red Hat Enterprise Linux users which can be found at http://rhn.redhat.com/errata/RHSA-2008-0855.html. This communication states in part, "Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers." It is important to note that the effects of the intrusion on Fedora and Red Hat are *not* the same. Accordingly, the Fedora package signing key is not connected to, and is different from, the one used to sign Red Hat Enterprise Linux packages. Furthermore, the Fedora package signing key is also not connected to, and is different from, the one used to sign community Extra Packages for Enterprise Linux (EPEL) packages. We will continue to keep the Fedora community notified of any updates. Thank you again for your patience. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug Czyli w skrócie: Zostało dokonane włamanie na systemach Fedory. Jednym z tych systemów był system używany do podpisywania pakietów Fedory. Atak został szybko wykryty, a serwery odłączone od sieci. Nie ma żadnych dowodów na skompromitowanie kluczy Fedory, co stwierdzili z całą pewnością administatorzy i specjaliści od zabezpieczeń. Jednocześnie Fedora postanowiła wymienić wszystkie używane do tej pory klucze, do czego będzie potrzebna interakcja ze strony każdego właściciela/administratora systemu. Żaden z pakietów dystrybuowanych przez Fedorę nie został podmieniony ani zarażony backdorami, wirusami itp. W tej chwili trwa faza projektowania i wkrótce implementacji dodatkowych systemów zabezpieczeń na serwerach Fedory. Zaatakowane zostały również serwery Red Hata, ale dzięki systemom zabezpieczeń nie zostało w żadnym wypadku naruszone bezpieczeństwo RHN. Skutki ataku na Fedorę są zupełnie inne niż na Red Hata, jako że system podpisywania kluczy w Fedorze nie ma żadnego związku z pakietami RHEL. Wkrótce kolejne wiadomości. Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Rekomendowane odpowiedzi
Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto
Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.
Zarejestruj nowe konto
Załóż nowe konto. To bardzo proste!
Zarejestruj sięZaloguj się
Posiadasz już konto? Zaloguj się poniżej.
Zaloguj się