Cała aktywność

Instalowałeś f42 z dysku (np. usb) bo prawdopodobnie jest to id repozytorium z tego dysku.

Mi chodzi o ten numer który pojawia się jak nazwa repozytorium. Cóż to jest?

Po aktualizacji Fedory do npwej wersji, czasami zostają jeszcze stare pakiety. Ze względu na kilka tysięcy nowych zależności, dnf czasami nie aktualizuje wszystkiego na raz. Druga możliwość jest taka, że rsyslog omyłkowo nie został przebudowany dla Fedory 43 i po prostu ten z 42 działał dobrze. To się czasami zdarza. Trzecia możliwość to trochę za bardzo rozbudowany, lokalny katalog /var/cache/dnf . Może wystarczy dnf clean all

Witam Aktualizuję sobie składniki/pakiety systemu Fedory 43 i takie repozytorium pojawia się jako dla poprzedniej wersji pakietu: d15e557246b143e68b4d7cf7c80 Widzę, że to jeszcze z Fedory 42 więc sobie myślę, że ok, ale: tu jest z 43. O co tu biega? Ktoś, coś? Radek Glebicki

Generalnie grozi tym, że będziesz wysyłał ciąg znaków nie do tego "pliku" co chcesz, a co się zdarzy, to już zależy od tego do jakiego "pliku". Jeżeli będzie to urządzenie znakowe (np. terminal lub port szeregowy) no to wyślesz do niego ten ciąg, a co on z nim zrobi to już zależy od procesu. A jak wyślesz do zwykłego pliku to program "się wykrzaczy" ponieważ to nie jest urządzenie znakowe i w tym prostym przykładzie nie ma napisanej obsługi błędów. np. przy zapisie do zwykłego pliku. # python tty.py zwykly_plik Traceback (most recent call last): File "/root/tty.py", line 7, in <module> fcntl.ioctl(fd, termios.TIOCSTI, char) ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ OSError: [Errno 25] Inappropriate ioctl for device

@sunrise jeszcze pytanko. Próbuję zrozumieć ten skrypt. Czytam manuale. Niepokoi mnie "w" czyli "write: w: Czym grozi pomyłka w ścieżce z sys.argv[1] dla pomylonego pliku/katalogu ? Pozdrawiam Radek Glebicki

Ciekawe jest, że myślisz, że to ja "zakładam, że tak to działa". Po prostu szukałem w necie i znalazłem to z echo, a nic z ioctl. to podpowiedź z dnf to odpada. Ja nie aktualizuję wszystkiego na raz. Gdzieś tu na forum zrobiłem wątek z użycia kdialog z wyborem pakietów do instalacji. Instaluję aktualizacje grupami ([y/N] wolę mieć, aby przerwać (użycie --assumeyes odpada) i co jakich czas sobie clonezillą zgrywam stan partycji / (root). Oczywiście popróbuję coś zdziałać z ioctl. Dzięki za podpowiedź. Radek Glebicki PS.: nawet sobie w Pythonie z użycie QT napisałem własny "kdialog list" z "live filter" i "grep -v" :-D

Zakładasz, że to działa tak jak Ci się wydaje, a tak nie jest Pisanie do stdin programu przez jego fd nie jest równe "pisaniu z klawiatury" czy nawet np. przekierowaniu "<" Aby "symulować" trzeba użyć ioctl dla terminali man ioctl_tty Prosty program wysyłający znak "y" w pythonie # tty.py import sys import fcntl import termios with open(sys.argv[1], 'w') as fd: for char in "y\n": fcntl.ioctl(fd, termios.TIOCSTI, char) Uruchomienie python tty.py /proc/PID_DNF/fd/0 PS. Może łatwiej podziel to na etapy dnf5 check-upgrade --refresh I jak Ci opowiada to uruchom sudo dnf upgrade --assumeyes

Aktualizuję sobie system dnf'em z użyciem kdialog (lista), a w konsoli wyskakuje co będzie się aktualizowało i czy potwierdzam lub rezygnuję: Podsumowanie transakcji: Aktualizowanie: 33 pakietów Zastępowanie: 33 pakietów Całkowity rozmiar pakietów przychodzących wynosi 97 MiB. Należy pobrać 97 MiB. Po tej operacji zostanie użyte dodatkowo 396 KiB (zainstaluje 353 MiB, usunie 353 MiB). Is this ok [y/N]: Mam pid'a dnf'a robiącego tę aktualizację. w drugim terminalu daję: echo -en "y\n" > /proc/[PID DNF'a]/fd/0 w terminalu aktualizacji wskakuje "y" i przełamuje Return tak jak by potwierdzenie wskakuje, ale proces nie idzie. Próbowałem też pid'a tego bash'a i pid'a okna konsoli KDE. Pojawia się "y" z Enterem, ale nie idzie. Co robię źle? Radek Głębicki PS: docelowo chcę wychwycić pojawianie się [y/N] i dać kdialog Yes No

Spróbuj utworzyć brakujący initramfs polceniem sudo dracut --kver 6.19.10-200.fc43.x86_64 Jak się uda to powinien się pojawić w katalogu /boot brakujący plik, możesz sprawdzić to poleceniem ls /boot/initramfs-* Jeżeli pojawia się błędy to wrzuć na forum.

Zaktualizowałem Fedorę 42 do 43 przez "oprogramowanie" w gnome. Niestety po instalacji gdy pojawiło się menu GRUB okazało się, że zaznaczona jest domyślnie inna wersja niż 43 czyli 42. Po próbie wejścia w pozycję Fedory 43 wyświetla się błąd. Teraz nie wiem czy to moja wina czy systemu. Gdy ściągnąłem przez Gnoma Fedorę 43 nim kliknąłem by się instalowała wszedłem na chwilę do terminala (wpisując komendę dnf update --refresh -y) by upewnić się (mimo że dziś aktualizowałem Fedorę 42) że wszystko jest aktualne. Z powodu natręctwa. Wszystko było ok. Wtedy kliknąłem uruchom ponownie czy tam zainstaluj nie pamiętam i komputer się wyłączył by instalować F43. Mam dziwne przeczucie, tak mi się pamięta, może to natręctwo, że system po kliknięciu by aktualizował system nie pytał mnie o hasło. Ale zupełnie tego pewny nie jestem. Bo zawsze jak się aktualizowało to zawsze pyta o hasło. Ale naprawdę może mi się tylko wydawać, często robię coś mechanicznie a później wydaje mi się, że tego nie robiłem.

Zaktualizowałem, dwie kolejne maszyn, w tym główną i wszystko odbyło się bez problemów

Rzeczywiście ciekawe. Ja jak zwykle zapomniałem o tej wtyczce do dnf i system aktualizował się w konsoli tekstowej z tmuxem dnf update --releasever=44 i jakoś poszło.

Update offline normalnie z konsoli przez dnf system-upgrade download i dnf system-upgrade reboot Pamięci jest 32GB więc to też nie to, żaden poprzedni kernel już nie działał prawdopodobnie z powodu, że już część nowych pakietów została zainstalowana, a jeszcze pozostała część starych. System zainstalowałem od nowa i działa. Ale pierwszy raz spotkałem się z Kernel Panic w środku aktualizacji.

A nie uśpił Ci się pulpit, jak nie machałeś myszką? Moim zdaniem co najmniej nie udał się initramfs. Może pamięci ram zabrakło. Uruchom system ze starszego kernela (albo z livecd i chroot) i wygeneruj go od nowa - https://wiki.baszarek.pl/doku.php?id=wiki:dracut

Dzisiaj próbowałem zaktualizować jedną ze starszych maszyn, w trakcie aktualizacji wszystko szło ok, wyłączyłem monitor, gdy był na etapie ok 200/11300, za jakiś czas włączam monitor, a tam piękny Kernel Panic! Po restarcie Kernel Panic! ponownie (co mnie nie zdziwiło), no cóż "dobry był z niego herbatnik" pamiętam czasy jeszcze Fedory 2x. Dyski sprawne, pamięć sprawna, system zainstalowany od nowa i działa, ale prawdę mówiąc pierwszy raz spotkał mnie tak poważny fuckup. PS. Ten nowy ekran Kernel Panic nie podoba mi się, nie widać ostatnich komunikatów, dzięki którym, mógłbym się dowiedzieć co się stało.

Przyszła mi jeszcze taka myśl. Co z rzeczami IoT – taka smart lodówka też przecież ma jakiś system operacyjny, przed otwarciem miałbym się leigtymować dowodem

Ja bym się nie przejmował. Meta mają istotnie problem, bowiem legislacja w poszczególnych krajach ma się ku 18+ dla mediów społecznościowych. Gdyby zrzucić deklarację na użytkowników - i nie jest to dla nich ważne, czy odpowiada rzeczywistości - problem sam się rozwiąże. U nas przyjęło się, że regulamin można zakceptować w wieku 13+, ponieważ w tym wieku można zawierać umowy. Stąd właśnie mamy deklarację wieku, ale opiera się ona tylko na - jak też Tomcio zauważa -jednostronnej deklaracji. Zdaje się, że to się będzie pomału kończyć. Nowe dowody mają wbite certfikaty i 5 darmowych podpisów co miesiąc. Technicznie zażądanie deklaracji wieku popartej takim podpisem to już nie jest problem. Lewe podpisy będą do kogoś tam należały, a składanie fałszywych oświadczeń to już nie jest kradzież piwa z dostawczaka. Problem jest po stronie biznesu, który napasł się młodymi profilami i nie zgodzi się dobrowolnie na ich weeyfikację.

Słyszałem ciekawą teorię (pewnie wyssaną z palca, ale kto wie), że za tym wszystkim stoi Meta która po cichu lobbuje i finansuje te przepisy - bo chcą zdjąć z siebie odpowiedzialność Ja w ogóle jestem przeciwko weryfikacji wieku gdziekolwiek - to rolą rodziców jest edukowanie dzieci i ich pilnowanie w własnym zakresie jeśli uznają to za konieczne, państwo jak chce pomóc to przez kampanie społeczne. W tej chwili chyba nijak nie da się tego zrobić chyba że przez jakiś moduł nfc i sczytywanie dowodu. Ewentualnie zabawa w jakieś kody z mobywatela i innych podobnych aplikacji - tylko to wymaga odpowiedniego softu, którego po stronie Linuxa nie ma. Więc póki co pozostaje deklaracja po stronie użytkownika (czyli efektywnie brak weryfikacji). Poza tym czy przeglądarki i inne programy wiedzą gdzie w systemie znaleźć potwierdzenie wieku usera, istnieje jakieś api do tego, jakaś implementacja przewidziana przez ustawodawców? Nie wydaje mi się. Prawo widmo uchwalone na kolanie - ot czym jest cała ta weryfikacja wieku A poza tym - co z serwerowniami, maszynami wirtualnymi i innymi systemami, których nie używa konkretny użytkownik albo używa cała masa - szkolne pracownie, biblioteki itp. - tu chyba co uruchomienie/odblokowanie powinna być weryfikacja

Jak w temacie. Dlaczego to ma być implementowane po stronie systemu , a nie stron internetowych? Jak to ma być wymuszane w naszym systemie? Pozdrawiam Radek Głębicki

Dzięki, że Ci się chciało napisać. Moje ostatnie KDE to było 3.5.

Wyciągam na wierzch bo w KDE 6.0 i 6.1 już działa. Mam czerwoną ramkę dla Konsoli root i Firefoxa w trybie Priv. Pozdrawiam Radek Głębicki

ok Działa. Ale działa też przekierowanie tylko 2>/dev/null Dlaczego napisałem wcześniej, że nie działa? Jest ok. Dzięki. Radek Głębicki

dnf check-update 2>&1 | egrep -v 'Aktualizowanie i ładowanie repozytoriów|Załadowano repozytoria'

Witam Dla przykładu filtruję glib: dnf check-update | grep glib wynik: Aktualizowanie i ładowanie repozytoriów: Załadowano repozytoria. glib2.i686 2.86.4-1.fc43 updates glib2.x86_64 2.86.4-1.fc43 updates glib2-devel.x86_64 2.86.4-1.fc43 updates glibc.i686 2.42-9.fc43 updates glibc.x86_64 2.42-9.fc43 updates glibc-all-langpacks.x86_64 2.42-9.fc43 updates glibc-common.x86_64 2.42-9.fc43 updates glibc-devel.x86_64 2.42-9.fc43 updates glibc-gconv-extra.i686 2.42-9.fc43 updates glibc-gconv-extra.x86_64 2.42-9.fc43 updates pulseaudio-libs-glib2.x86_64 17.0-9.fc43 updates Jak pozbyć się tych dwóch pierwszych linii. Przekierowanie 2>/dev/null nie pomaga. Po przekierowaniu do pliku to w pliku ich nie ma, ale w terminalu są. Czym są te linie? Po przekierowaniu do less są. "grep -v" nie działa na nie. Radek Glebicki