SeeM

Z różnych internetów wyczytałem, że im nowszy Grub, tym ten błąd rzadziej występuje. Czasami dysk jest za dla niego za szybki. Spróbuj zainstalować Fedorę 40. Bardziej stabilna już nie będzie, bo jest gotowa do wydania.

Bez root-a trzeba się wówczas ratować z płytki instalacyjnej. Nic bardzo trudnego, ale trzeba jakiś niepotrzebny pendrive znaleźć. Instalator Fedora Server chyba jeszcze umie wyklikać odblokowanie użytkownika root. Dla Workstation już tego nie robią.

Zajrzyj do pliku /etc/shdow i zobaczysz tam, że hasło root-a - już pomijając, że jest puste - zaczyna się od wykrzyknika. Nie ma takiego hasha, który zacznie się wykrzyknikiem, więc żadne hasło nie pasuje, więc konto jest efektywnie zablokowane. Jeżeli chcesz logować się jako użytkownio root, ustaw mu hasło i odblokuj. sudo passwd root sudo usermod -U root Wadą powyższego jest otwarcie nowych wwktorów ataku. Każdy soan będzie próbował zalogować się jako root, bo każdy wie, że taki użytkownik istnieje. Dlatego w domyślnej konfiguracji Fedory nie można się na niego zalogować.

Spoko. Systemy plików nie padają jak muchy, więc to zwykle ostatnie, co się sprawdza.

https://fedoraproject.org/wiki/Changes/ReproduciblePackageBuilds https://discussion.fedoraproject.org/t/f41-change-proposal-reproducible-package-builds-system-wide/112740 Może będzie jak w Debianie, albo nawet lepiej, bo nie w Perlu. (-: Jest taki pomysł, żeby to pożenić z masowy przebudowywaniem pakietów, które zwykle występują na początku cyklu wydania.

Nazwa użytkownika nie ma znaczenia. Znaczenie mają identyfikatory uid oraz guid oraz ewentualnie kontekst selinuksa na plikach w katalogu home. Sprawź za pomocą ls -alZ , czy użytkownik o uid odczytanym z pliku /etc/passwd ma na pewno uprawnienia do plików swojego katalogu domowego oraz czy mają one kontekst home_dir cośtam. Zapomniałem dokładnie nazwy. Wątek sprzed 12 lat odgrzebałeś. (-: Nie pamiętałem, że to forum jest aż tak stare.

A co masz wybrane w winecfg w ustawieniach dzwieku?

Trzeba przyznać, że ładnie przycfaniakowali. Przymilali się do xz, bo opiekun projektu trochę się pochorował i tym łatwiej przekazał swój projekt w ręce, które coś tam przy nim robiły. A potem pojawiła się tak zachwalana przez "autora" wersja 5.6, że pare dystrybucji już ją łyknęło. Przy okazji rozwinął się ładny tasiemiec na liście mailowej devel - https://lists.fedoraproject.org/archives/list/[email protected]/thread/YWMNOEJ34Q7QLBWQAB5TM6A2SVJFU4RV/ Debiany też dumają, jak się pozbyć xz, ale cały dpkg na tym stoi i trudno im cofnąć wersję do xz jakiegoś 5.2.x. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024

Zróbcie o to szum, gdzie tylko możecie. xz od wersji 5.6 należy traktować jako atak na wasze systemy, gdzie by go nie było: pakiety rpm, deb, kontenery, cokolwiek. Należy wrócić do wersji 5.4 *teraz*. Do Fedory 40 oraz rawhide są już stosowne instrukcje. https://fedoramagazine.org/cve-2024-3094-security-alert-f40-rawhide/ Co prawda na bigtrackerze SuSE podnosi się wątek, że wersja 5.4 została również opublikowana w podejrzany sposób, ale to jeszcze nic pewnego. https://build.opensuse.org/request/show/1163302#comments Sprawdziłem właśnie na Fedorze Rawhide i po wykonaniu dnt5 update xz jest opuszczony do wersji 5.4. Sprawdziłem też Fedorą 40 i równiez jest opuszczany do 5.4

Linux lepiej i gorzej wspiera wiele systemów plików, ale nie wszystkie potrafi naprawić w razie ich uszkodzenia, czy ponadprzeciętnej fragmentacji. Tutaj bezpieczniejszy będzie ext4 i xfs. Na maszynach z Windowsem można używać ext4, chociażby wtyczką ext4tc to Total Commamdera. A po zainstalowaniu jakiegoś Linuksa ze sklepu MS z aplikacjami, to już dowolnny uniksowy system plików jakoś się obsłuży.

lsusb pokaże dokładnie z jaki to model chipsetu tak średnio działa.

Kilka testów możesz zrobić zwykłym pingiem. Popinguj bramę domyślną (zwykle w domowych warunkach to jest router) i zacznij aktualizować. Sprawdź, czy są straty pakietów. Potem zrób to samo ze skonfigurowanymi na używanych przez ciebie serwerach DNS. A potem pinguj na przykład python.org i zacznij aktualizację. Jeżeli straty pkietów będą już na routerze, to coś jest nie tak z połączeniem wifi. Jeżeli z dns-ami, to zmień je na inne. Jeżeli z pythonem, to problem może, ale nie musi, być po drugiej stronie kabla, czyli u ISP. Trzeba mieć z tyłu głowy, że dnf pobiera kilka pakietów jednocześnie i z różnych serwrów jednocześnie. Możesz również w inny sposób sztucznie wywołać duży ruch w swojej sieci. Zacznij pobierać jednocześnie 5 torrentów z obrazami iso od różnych dystrybucji Linuksa. I wtedy również pinguj. Możesz też użyć lepsiejszego pinga, czyli mtr: mtr python.org który pokaże pingi do wszystkich tzw. hop nodów od twojego komputera, do strony python.org .

Nie mam Windowsa na komputerze od jakiś 10 lat i nie jestem na bieżąco z ntfs, ale słyszałem, że ma się dobrze i nawet shadow copy obsługuje. Byłem przekonany, że montujesz partycje z roota, lub co najmniej korzystając z sudo. Rzeczywiście dopisanie tej partycji do fstab z opcją user w kolumnie przed "0 0" by pomogło. Dobrze gada. To by było jakoś tak: /dev/sda1 /mnt/windows ntfs-3g rw,user,noexec 0 0 Uzytkownicy będa mogli montować i odmontowywać /mnt/windows. Nie wiem tylko, czy to już wystarczy, by mogli tam zapisywać.

Bardziej z konsoli poprosimy, będzie więcej danych mount -t ntfs-3g /dev/[partycja ntfs] /mnt/partycjantfs

Mały epilog do tej przygody. Mi znikł klawisz S na klawiaturze, ale wada okazała się czysto mechaniczna i transplant z pause/break rozwiązał problem.