Fedora 39

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

Bejelentés itt.

( laysoft v | 2023. 11. 08., sze – 09:37 )

Én Fedora KDE-t használok. Legutóbb a 37-ről 38-ra váltáskor command line-ból bohóckodtam, így aztán végül be sem indult a rendszer, nulláról kellett újrahúznom az egészet. Ezt most elkerülném. Viszont sehol sem találom hogyan lehetne Mancika módjára GUI-ból frissíteni 39-re.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Tegnap este minden gond nélkül frissítettem parancssorból is Fedora 38-ról 39-re, szintén KDE spin. A legtöbb idő a csomagok letöltésére ment el. Az --allowerasing kapcsolót meg kellett adnom, mert volt néhány egzotikus font, amit nem tudott frissíteni.

Akkor valamit nagyon rosszul csináltál. Nagyjából ennyi:

dnf --refresh upgrade
dnf check
dnf system-upgrade download --releasever 39 --allowerasing
sync
dnf system-upgrade reboot

A dnf check csak azért, hogy idejében kiderüljön, ha sérült az rpm adatbázis, például frissítés alatt lett elvéve tőle a tápfeszültség korábban.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, tudom, megvan a megoldás, linkelted neki. Fogalmam sincs, mit csinálhatott, amivel összeborította úgy az oprendszert, hogy újra kellett telepítenie. Fedora 18 óta nem telepítettem újra, pedig hardware-t cseréltem alatta. Volt, amikor csak HDD-ről SSD-re, volt, amikor teljes gépet, filerendszer topológiát, mindent. Sőt, olyan is volt, hogy system upgrade közben lett disk full azon az fs-en, ahol az rpm adatbázis volt, de még innen is sikerült visszahoznom. Mondjuk erre nem fogadtam volna tábla csokinál nagyobb összegben. :) Szerencsém volt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amit én írtam, az nem épp a system upgrade plugin? Annyit csinál, hogy az új release ugyanazon csomagjait teszi fel, mint amelyek a régiben vannak, kibogarássza a függőségeket, törli, ami nem kell, telepíti, ami meg igen. Ezen nem nagyon lehet mit elszúrni. Bootloader marad, ha valami nagyon elromlott, még a régi kernellel is be lehet boot-olni az új oprendszert átmenetileg, ami csak attól új, hogy az új csomagok vannak fenn.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ja, az lehet, hogy valahogy force-olta, hogy elfogadja az fc39-es csomagokat, aztán zagyvaság lett belőle. Vagy inkonzisztens volt az rpm adatbázis egy korábbi áramszünet miatt, nem nézett rá dnf check paranccsal, aztán ez lett belőle.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( vilmos.nagy | 2023. 11. 08., sze – 15:02 )

frissítettem, gond nélkül lefutott.

( Wooody | 2023. 11. 11., szo – 10:09 )

A workstation frisstése 20 perc dög unalom:) Ami meglepett a Gnome sebessége, kb néha csak pislogok mi történt. Egyenlőre eszméletlen gyors lett.

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

( ntomasz | 2023. 11. 11., szo – 22:58 )

Feltettem a félig új gépemre a Gnome verziót.

Néhány órás tapasztalat alapján:

- a Gnome sebessége sokat javult :)

- a pipewire kicsit fura még, szokni és tanulni kell, de az is lehet, hogy semmi köze a dologhoz, még nem volt időm utánajárni

- a "hivatalos" nvidia drivertől lefagy a rendszer bejelentkezésnél, ha törlöm és visszaállok nouveau driverre, akkor működik a bejelentkezés

- pár gnome-shell kiterjesztést nem találtam meg, amiket eddig használtam, gondolom még nincs az új gnomehoz vagy már nem is lesz :(

- mellesleg a gnome-terminal miért az F10-et használja a menü eléréséhez, és miért kapcsolják be alapértelmezetten? rohadt idegesítő volt...

nTOMasz
"The hardest thing in this world is to live in it!"

A lefagyós nvidia driver az a https://rpmfusion.org/Howto/NVIDIA?highlight=%28%5CbCategoryHowto%5Cb%29

oldalról lenne?

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

( solt87 | 2023. 11. 14., k – 12:02 )

Ez az újraindítás után, indulás közben telepítést befejezős, még egy újraindítást igénylő eljárás ez mi? Láttam már Linuxterjesztésnél is, de nem értem, hogy mire jó (azon kívül, hogy Windows-os érzést ad), főleg, hogy hagyományosan erre nincs is szükség. (Debian-vonalon pl. most is így van.) Nekem ez így nettó visszafejlődésnek tűnik.

Köszi. Ami a két újraindítást illeti, az általad linkelt cikk is és a fentebb linkelt Fedora-frissítős oldal is leírja, hogy újraindul a rendszer, systemd-s frissítős módban telepít, majd megint újraindul. Ez így nekem kettő, még ha a második automatikus is. Illetve továbbra sem értem, minek két újraindítás: azt, hogy ezt-azt újra kellene indítani, mert már új állományokat kellene használnia, azt a needrestart is megmondja. (Ahol eddig használtam, ott a parancssori és a grafikus frissítőkbe is gond nélkül beépült.) Az meg, hogy a hivatkozott cikk szerint a hagyományos frissítéstől mind meghalhatunk, hát, nem tudom, ez talán Fedoráéknál (meg Arch-éknál :P) igaz lehet. Debiant gond nélkül lehet frissíteni "hagyományos" módon, egyetlen újraindítással.

If the system that crashes happens to be DNF or systemd, then it might not be possible for the system to continue its update process. When this happens, even restarting the machine will not be enough to restore it.

Jól értem, eljutottak oda, hogy hiába a "transactional update", ha a DNF rosszul esik, akkor mégsem segít?

1) Feloldja a függőségeket, letölti a szükséges csomagokat, ellenőrzi, hogy valóban megvan-e a függőség szerint minden.

2) Speciális reboot, ami annyit tesz, hogy nem kapsz GUI-t, nincs hálózatod. Itt újra ellenőrzi, hogy megvannak-e a szükséges csomagok, ha igen, ebben a fázisban történik a csomagok upgrade-elése, a tényleges frissítés, file-ok felülírása, szükségtelenek törlése.

3) Elkészült, automatikus reboot, most már az új kernellel az új operációs rendszer indul az új konfigurációval.

Szerinted melyik felesleges?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mert akkor upgrade-eli a csomagokat. :) Ha ez nem lenne, akkor a user képes lenne valami memory leak-es alkalmazással felfalatni a memóriát, telerakni a háttértárat, video driver bugjába belahajszolni az oprendszert, ami ezáltal csontra fagy. És akkor ott vagy, hogy van egy oprendszered, amelynek 2427 csomagja fel van frissítve, 3544 csomagja meg még nincs, post install scriptek nem futottak le, cleanup-ok szintén nem, s akkor innen csinálj vele valamit.

Amúgy miért probléma az a reboot azért a biztonságért cserébe, hogy nem hagyja használni a gépet kritikusan érzékeny állapotban, amikor amúgy is sok RAM-ra, CPU-ra, I/O sávszélességre van szüksége?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem probléma, meg biztos van értelme, vagy van mellette érv, de én feleslegesnek érzem. Én általában úgy frissítek, hogy közben böngészgetek, zenét hallgatok, kb. észre sem veszem hogy frissít a gép, néha ránézek és ha végzett, akkor _én_ újraindítom a gépet. Nem volt még problémám, persze ettől még lehet gond. Amúgy ebben a spéci bootban nullponti energiával működik a gép, vagy mi van ha 2564 csomag frissítése után, amikor még hátravan 1856, akkor áramszünet lesz? hm? :P

Itt a kockázatok csökkentése a cél. Szünetmentes táp, ha nincs, akkor reménykedés, ha a remény is elfogyott, de notebook, akkor annak az akkumulátora. :)

Az a baj, hogy van egy rakás intelligens periféria saját firmware-rel. Ilyen a GPU, de a Wifi kártyák is. Ha egy ilyen mikrokontroller beleáll a földbe, s megfog valami buszt, nem reagál semmire érdemben - képzelj el egy I2C buszt, aminek akár az SDA, akár az SCL vonalát valaki lehúzza alacsony szintbe, aztán onnan senki sehova. És akkor az egész gép képes megpusztulni. Filmnézés szerintem nem való system upgrade alatt. Meg úgy semmi. Én örülök annak, hogy a Fedora így csinálja.

Az adott disztribúció release-en belüli frissítést már az alkalmazások használata közben teszi. Ott ha baj van, azt jó eséllyel meg tudod javítani manuálisan.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

2427 csomagja fel van frissítve, 3544 csomagja meg még nincs, post install scriptek nem futottak le, cleanup-ok szintén nem, s akkor innen csinálj vele valamit.

Ezek szerint a fenti kérdésemre ("Jól értem, eljutottak oda, hogy hiába a "transactional update", ha a DNF rosszul esik, akkor mégsem segít?") az a válasz, hogy igen, a DNF is visszafejlődött. (Vagy a tranzakciós működés eddig sem védett az áramszünet miatti leállás hatásaitól?) És ezért """kell""" a dupla újraindítás. ("Nem, Poettering, a frissítéshez nem kell egynél több újraindítás. Ötven pont a MicroHat-től." :) )
 

Amit lentebb írsz, hogy ez egy kokázatcsökkentő lehetőség, az kifejezetten jól hangzik. Másfelől pesszimista vagyok, és félek, hogy talán nem is olyan sokára ez már kötelező lesz, "hagyományos" frissítésre pedig nem lesz mód. Aztán majd a Debian és mások is átveszik, és akkor az sem ment meg, hogy nem használok Fedorát. (Ne legyen igazam.)

Nézd, eddig is ment nélküle, és nem vagyok meggyőződve a hozzáadott érték(?) jelentőségéről, tehát innentől nekem ez visszafejlődés. A trendeket meg látjuk. (Mondom ezt úgy, hogy nem vagyok innovácijó-hívő. :) ) Természetesen a lehetőség továbbra is jó, csak ne csináljanak belőle egyetlen lehetőséget. De azt hiszem, már ismétlem magam.

Ahogy fentebb írtam, én jónak látom, ha nincs a felhasználónak lehetősége arra, hogy terminálból pkill -KILL dnf, és ehhez hasonló szórakoztató parancsokat adjon ki. Vagy csak úgy bármi módon elhasaltassa a gépet. Az az egy reboot megvan egy percen belül.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2023. 11. 18., szo – 00:22 )

Volt egy olyan bug, ami külön-külön nem volna bug, de együtt inkompatibilitássá fajult.

A 6.6.1-es kernelben fixen engedélyezve van a microcode betöltésének támogatása, nincs a kernel configban engedélyezhetőség ehhez. A dracut meg azt hitte, hogy nincs kernel support a microcode betöltéséhez, így nem tette az initramba. Ki lett javítva, az új dracuttal erősen ajánlott egy ilyen root joggal:

dracut -f

A probléma biztonsági természetű.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE