SeeM

Zgaduję, ale pewnie jestem blisko. Z jakiegoś powodu initramfs do nowych wersji kernela się źle wygenerował i brakuje w nim sterownika do obsługi systemu plików na partycji / , albo szyfrowania na nim zastsowanego. Pokaż zawartość plików /etc/fstab , /etc/mtab oraz /etc/crypt(cośtam, zapomniałem dokładnie).

Dwa słowa: dnf reposync. To tworzy lokalną kopię repozytorium, którą można potem przyrostowo aktualizować. Mam kilkanaście maszyn wirtualnych z CentOS 10 i oszczędza to kupę czasu. Pobrane pliki najlepiej wystawić w sieci lokalnej po http i poprawiać konfigurację dnf przed każdą cotygodnoową aktualizacją. Ja mam do tego prace ansiblowe: podmian konfiguracji dnf na wszystkich hostach, wyczyszenie cache dnf i aktualizacja na wszystkich hostach. Na reposync Fedory będziesz potrzebował z 500 gigabajtów przetrzeni dyskowej. Może więcej. Dawno nie sprawdzałem.

Możesz, bo instalator i tak sprawdza stosowne sumy kontrolne. Jak linuksowi się pozmienia tablica partycji na karcie sd, albo pejdrajwie, to graficzne menedżery plików trochę się gubią i czasem trzeba odmontować dysk z parametrem "lazy", albo po prostu wyciągnąć pendrajwa z gniazdka. Podręcznik programu umount wyjaśnia ten problem. Ja mam pecha do pendrajwów. Kupuję najtańsze szroty, które owszem działają dobrze do jakiejś połowy swojej pojemności, a potem bywa różnie i przekłamują zapisywane dane. Czasem szybciej mi jest wypalić płytę dvd i mam potem czystą tackę do mieszania farbek.

Na pulpicie nigdy nawet nie podchodziłem do niemutowalnych dystrybucji. Jestem typpwym dłubaczem i lubię mieć po swojemu. Jakoś w najbliższych dwóch tygodniach będę kubernetesa stawiał na Fedorze Core OS, bo na serwerach zwykle nie ma czasu na dłubanie. :-( Wypowiem się, jak to zadziała.

Ja mam zainstalowanego z RPM, ale to bardziej z przyzwyczajenia, niż przekonania.

Tak. Jeżeli ni gruchy, ni z pietruchy DNF zapyta o akceptację klucza dla pakietu pochodzącego z często używanego przez nas repozytorium, trzeba być podejrzliwym i sprawdzić, czemu ten klucz nie jest już taki sam jak wczoraj, czy tydzień temu. Trzeba brać pod uwagę, że prawie nigdy nie pobieramy pakietów RPM ze strony fedoraproject.org, ale z polskich serwerów, takich jak https://ftp.icm.edu.pl/pub/linux/distributions/fedora/linux/releases/42/Everything/x86_64/os/ . Możliwe, że nie mają one zabezpieczeń na poziomie projektu Fedory i komuś uda się wysłać tam podstawiony plik htop-[jakaśwersja].fc42.x86_64.rpm , ale jakby się ten ktoś nie starał, nie podpisze tego pliku właściwym kluczem kryptograficznym, bo owego klucza nie posiada. W takim wypadku dnf pokaże ostrzeżenie przy próbie instalacji pakietu htop. Zwykle projekty takie jak Fedora, Rpmfusion, EPEL, opiekunowie repozytoriuów różnych innych dystrybucji Linuksa publikują informacje o wymianie swoich kluczy kryptograficznych.

Pisałem z telefonu i nie trafiałem w odpowiednie litery. Poprawiłem kodowanie. (-: Ty możesz te ciągi udostępniać. Zespół Fedory nie może udostępniać swoich ciągów. Im dłużej używają konkretnych kluczy prywatnych, tym większa szansa na ich przypadkowe opublikowanie. Dlatego czasem te klucze są wymieniane. Dla nas wynikają z tego tylko dwie rzeczy: dnf pokazuje nam klucz do akceptacji podczas pierwszej instalacji czegokolwiek na nowym hoście z Fedorą, dnf pokazuje nam klucz do akceptacji, kiedy zespół Fedory zdecyduje się na ich wymianę po swojej stronie.

To jeat odcisk klucza kryptograficznego, którym są podpisywane pliki costam.rpm z repozytorium Fedory. Prawie każde repozytorium z plikami rpm ma owe pliki podpisane. Dnf jednorazowo pyta użytkownika o każdy odcisk, którego odpowiadającym kluczem nie został podpisany żaden lokalnie pobrany plik rpm. Możesz się na te klucze zgadzać, ale dobrą praktyką jest ich weryfikacja. Klucze gpg rpmfusion - https://rpmfusion.org/keys Klucze gpg Fedory - https://fedoraproject.org/security Problem jest taki, że te klucze nie mogą być używane bez przerwy, z kilku powodów. Pierwszy jest taki, że ludzie mają generalnie coraz lepsze komputery, więc można używać coraz to lepszych technik kryptograficznych do generowania tego klucza. Czas jego weryfikacja na komputerach z Fedorą nie powinien być zauważalny. Drugi jest bardziej prozaiczny. Jakby tych kluczy nie pilnować, czasem ktoś go (nie)chcący wyśle mailem, albo skopiuje do publicznie wystawionego zasobu. Prewencyjnie się je co jakiś czas wymienia, albo też możliwie szybko po zgłoszeniu takiego zdarzenia.

Można zacząć od uruchamiania Chroma w terminalu: google-chrome Niektóre aplikacje są w terminalu bardzo gadatliwe, kiedy coś im nie pasuje. Niektóre w ogóle nic nie wypisują.

Xorg nie jest potrzebny dla Gnoma oraz KDE, ale jak najbardziej jest dostępny. Możesz zainstalować sobie jakiś prościutki pulpit w rodzaju IceWM, który doinstaluje Xsy jako zależności. Takie małe pulpity nie są popularne i pewnie już bardzo mało testowane. Może zadziała, a może nie. Później pulpit oraz Xsy możesz odinstalować za pomocą dnf history dnf history undo [numer instalacji icewm]

Trzeba, ale nie trzeba. Uruxhomiony przez nieuprawnionego użytkownika dnf sam się wyeskaluje do root-a, zakładając, że ów użytkownik może używać sudo.

Wcalenie musisz mieć uprawnień do całego swojego katalogu domowego, jednak uruchamiane przez ciebie procesy takie uprawnienia mogą mieć. Służy do tego program unshare i kontenery na nich się opierają. Linuksowe przestrzenie nazw - w tym uprawnienia - wystrzeliły w kosmos od cgroup w wersji drugiej, autorstwa głównie zespołów pracujących dla facebooka. Izolacja dotyczy nie tylko katalogów z aplikacjami, ale też procesów, połączeń sieciowych. Ja już trochę za tym nie nadążam, ale unshare się nauczyłem dla kontenerów podman. Jest więc możliwe, mając skonteneryzowanego klienta poczty, że żaden inny proces na całym systemie operacyjnym nie będzie mógł czytać katalogów z zqpisanymi emailami w formie mbox (której Thunderbird chyba używa, ja jestem na Evolution). Łącznie z twoją własną sesją Basha w twoim własnym terminalu.

dnf zawsze instaluje pakiety rpm. flatpak zawsze instaluje flatpaki. Jak się klika po Gnome Software, to trzeba doczytać.

Aplikacje z pakietów RPM korzystają z tych samych wersji OpenSSL, GTK, ffmpeg i czego tam jeszcze potrzebują, co cała reszta systemu operacyjnego. Oszczędzamy miejsce na dysku i mamy pewność (no prawie, bo czasem ktoś się zagapi), że taki Thunderbird zostanie zaktualizowany za każdym razem, kiedy owe zależności również będą w nowszej wersji. Wszystko pasuje, działa i śmiga. Nie ma za to rozbudowanego systemu uprawnień, to znaczy Thunderbird może sobie korzystać z kamery i mikrofonu ile tylko chce. Flatpak dostarcza zależności z innych flatpaków, albo sam z siebie. To jest w gestii autora Flatpaka, żeby było bezpiecznie i żeby działało. Czasem autorem jest wydawca oprogramowania, więc tutaj można liczyć na solidność. Czasem losowy ktoś tam z internetu, który może mieć właśnie miesięczne wakacje. Zrobi, tylko czasem trochę później. Flatpak ma za to owe ACL dla aplikacji, więc może narzucić na nią ograniczenia: na korzystanie z GPS, kamery, mikforonu, udziałów sieciowych, niekórych katalogów domowych. W takim Androidzie, czy iPhonie każdy program bez tych ograniczeń zostałby wyśmiany i może nawet niewpuszczony do sklepów. Na pulpicie Linuksa takie ograniczenia dopiero pomału wchodzą.

Na Fedorze jest z flatpakiem trochę dziwnie. Mamy bowiem co najmniej dwa ich źródła: Fedora Flatpak oraz Flathub. A po co dwa? Flathub dopuszcza dystrybucję zamkniętego i objętego retrykcyjną licencją kodu, na co Fedora sobie nie pozwala. Flatpaki przygotowane przez zespół Fedory są budowane z tych samych źródeł, co pakiety RPM w ich tradycyjnym repozytorium. A jak są budowane te z Flathuba? No trzeba sobie doczytać dla każdej jednej umieszczonej tam aplikacji, bo odgórnie narzuconych zasad nie ma. Stąd mamy po killa tak samo nazwanych aplikacji. Gnome Softwaremoże dostanie kiedyś funkcjonalność informującą gdzie znalazło jaki program. Sytuacja jest opisana w artykule - https://blogs.gnome.org/mcatanzaro/2025/07/21/fedora-must-carefully-embrace-flathub/