Fedora 29 5.0.3 kernel

 ( szkaresz | 2019. március 30., szombat - 13:18 )

Sziasztok !

Azt valaki tudja, hogy az új 5.0.3-as kernellel erre miért van szükség, esetemben majd másfél pecig?
SSD és egy 1 terrás HDD van a gépben. Csak az 5-ös kernel óta van.

Melléklet: http://www.fotokaresz.hu/kernel5.jpg

Köszi

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Erre feliratkozom. Illetve mesélek. Épp backup-ot csináltam, amikor arra lettem figyelmes, hogy a külső HDD LED-je nem villog, de az rdiff-backup sem tömörít, mert a CPU használata 0.0 %, a státusza nem megszakítható alvás. Néztem top-ot, elég magas volt az iowait. Na, akkor dmesg. Látom, hogy végtelen ciklusban próbálja a HDD-t reset-elni, inicializálni másodpercenként többször is. Na, mondom ez is megdöglött. Teljességgel megmagyarázhatatlan volt ugyanakkor, hogy a Thunar filemanagerből el tudtam érni a külső HDD-t. Jó, tudom, a disk cache magyarázhatná, de azoknak a könyvtáraknak, file-oknak a közelébe sem szagoltam korábban sem én, sem az rdiff-backup, amelyeket meg tudtam nyitni. Amúgy ezen a HDD-n btrfs a filerendszer.

Megöltem az rdiff-bakup-ot, lecsatoltam a filerendszert, eltávolítottam a külső HDD-t. A gép a továbbiakban gyanúsan viselkedett. Parancsok lassúak voltak. Láttam már ilyet, HDD vagy SSD pusztulásánál jellemző viselkedés. Van a gépben egy SSD, ez az sda, s egy HDD, ez az sdb. Az sdb-re láttam a dmesg-ben borzalmakat.

Na mondom húzzunk 19-re lapot, amikor épp a backup-om sincs rendben, a hardware is instabil - 11 éves a gép -, frissítettem Fedora 30-ra. A végén hasonlóképp bekerült egy végtelenített semmittevésbe. Ctrl-Alt-Del-re viszont szabályosan leállt, újraindult. Ekkor már csak a grub promptja fogadott, nem indult el a gép.

Azóta Fedora telepítő live alól szektorosan végigolvastam a HDD-t, az SSD-t, röviden RAM tesztet is futtattam, csináltam HDD-re is, SSD-re is short selftest-et, kiírattam a smartctl-lel a státuszokat. Az összes mérésem hibátlannak mondta a hardware-t. Tudom, ezek nem teljes tesztek voltak, de eléggé gyanús ez így.

Nem tartom kizártnak, hogy az 5-ös kernelbe belefejlesztettek valami oltári nagy marhaságot, vagy csak ring0-ból a kernel egy eltévedt pointer által szétkeffenti a RAM tartalmát.

Ugyanakkor Fedora 28-on - erről írok most - használok 5.0.5-ös kernelt, megy hiba nélkül. Ugyanilyen kis, munkahelyemen használt notebook-omon frisítettem Fedora 30-ra, 5.0.5-ös kernellel megy jól. Persze az a renderelési bug létezik Fedora 30-on, ami Fedora 29-ben mutatkozott be, s leginkább a conky használhatóságát öli meg. De ennek a problémáhnak semmi köze a fentiekhez.


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

Lehet, hogy meg van illetve megvolt a hiba.
Ma este bekepcs a gép bootol aztán 5 perc után megáll.
Többet nem tudtam elindítani arról az SSD-ről a rendszert.
Megnéztem usb-n keresztül fdisk -l alatt az SSD-t, látja a méretét, de nincs rajta partíciós tábla
A bios nem tud vele mit kezdeni.
A gparted szintén látja de az is azt mondja nincs partíciós tábla
A tesdisk ugyan ez.

Én viszont még ilyent nem láttam. Az SSD nincs 5 hónapos és természetesen pont olyan adat van rajta, amit még nem mentettem ki.

Bármilyen halovány, átlátszó, rózsaköd, esély van,hogy valamit ebből az ipari hulladékból visszakapjak?

--
Karesz
www.fotokaresz.hu

Szerintem engedd el. :( Nekem is döglött már meg SSD-m garanciaidőn belül. Azóta nem veszek TLC-set, csak MLC-set vásárolok. Szerintem megéri, hiába drágább.


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

Azert szogezzuk le itt, hogy a vezerlo halala es a tarolo cellak tipusa kozti korrelaciot felallitani kb. osszeeskuves-elmelet szint.

Nem nagyon bízom abban, ha egy MOSFET nyolc különböző csatornaellenállású állapotával tárolnak három bitet. Mindezt úgy, hogy a töltés nagyon változatlan maradjon, közel van a szomszédos állapot. Értem, hogy hibajavító kódok, redundancia, kiolvasás és visszaírás néha, de ez nekem akkor is nagyon undorító.


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

Ha gpt-s tablad volt es nem barmoltal nagyon bele gdisk meg vissza tudja allitani a backup gpt tablabol.

MBR-t is, ha papírra fel voltak írva a szektor címek. :) Bár inkább az a baj, hogy már elérhetetlenek a szektorok.


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

ŐŐŐŐ hááát.... Nem vagyok felhőtlenül elégedett. Hivatalosan is kijött az 5.0.5 nagy változás nem történt és az idő csak telik :(
De, hogy még legyen egy kis adalék, Az USB eszközök felismerése súlyos 10 másodpercekbe kerül Pendrive és memóriakártya... stb Valami nem egyenes ezzel a kernellel.
Egyenlőre 4.18-ra downgrade az nem produkál ilyeneket.

--
Karesz
www.fotokaresz.hu

Van egy tippem, megint mesélek, figyej nagyon! :) Munkahelyen lévő saját gépemen Fedora 30-ra frissítettem. Működik, de nagyjából 1 perc 50 másodperc alatt boot-ol SSD-ről. Néztem logot, kiderült, hogy resume=UUID=blabla teljesen hibás - fogalmam sincs, honnan vette - uuid volt megadva kernel paraméterként a swap-em uuid-ja helyett. Kijavítottam Laura Abbott blogjában írottak szerint, azaz töröltem a kernel paramétert a grubby-val, majd megadtam a helyes uuid-dal, s lőn, 18.8 s alatt boot-olt be a gép.

Amúgy rescue image-et boot-oltam a „döglött” gépemen, chroot után feltelepítettem a grub-ot, azóta megy ez a gépem is. Nem soká lesz 5.0.6-os kernel, megy is fel a gépre hamarosan.


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

Fedora 28-ra is kijött az 5.0.5.
Ott nfs-re nem tudtam felmásolni 160-170 megabájtos fájlokból 10-20 megánál tőbbet, azt állítja, nem tudja lezárni.
4.20.17 az előző, azzal nincs ilyen gond.

Ez nagyon aggasztó, szerintem lett valami a kernelben, ami spontán helyeken felülírja a RAM-ot.


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

Gugliztam a problémámra, de csak korábbi találatom volt, a write errort nem is túlzottan részletezte.
A megoldási javaslata sem vált be (retrans=2,actimeo=1800), lehet, hogy csak azért, mert akkoriban még a systemd nem pofázott bele, és az x-systemd.device-timeout=4s-t is hozzá kellett volna igazítanom, de azt nagy pofára esésnek képzelem wifi-s kapcsolattal :)
Most várhatom az újabb kernelt..

5.0.6-ot a build szerverről már eléred:

https://koji.fedoraproject.org/koji/packageinfo?packageID=8


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

Május elején jelenik meg a hivatalosan a Fedora 30, remélem addigra kiszedik/javítják ezeket a problémákat.
Bétába csak belefut olyan hw, amelyiken sarkosan jelentkeznek ezek a problémák.

--
Karesz
www.fotokaresz.hu

Aprónak tűnő, ám nem elhanyagolható probléma, hogy Fedora 28-hoz és 29-hez is ez a hivatalos kernel. ;)


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

Előre vetítve (nálam) a következő Fedora kiadást... a 29-es verzióhoz kiadott 5.0.7-kernel továbbra sem működik valami jól. Bár elmúlt a percekig tartó inicializálás, de az USB eszközök csatlakoztatása továbbra is agybaj. Pendrive, memóriakártya "felismerése" gyakorlatilag nem működik. A korábbi 4.18, 4.20-as kernellel nincs ez a probléma.
Szóval Fedora 30....? Hááát nem tudom.

--
Karesz
www.fotokaresz.hu

Tudom, a works for me rajtad nem segít, de három gépemen, két teljesen eltérő hardware-en Fedora 30 remekül működik 5.0.8-cal, de amúgy 5.0.7-tel is. Tapasztalatom szerint 5.0.5-ben már konszolidálódott a helyzet.

Olvass logokat, nézd meg, mi történik, netán előfordulhatott, hogy a korábbi hibás kernel tönkrevágta a pendrive filerendszerét, a jó kernel pedig kínlódik az elfuserált filerendszer leírókkal. Lehet, érdemes lenne újraformázni a pendrive-ot.


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

netán előfordulhatott, hogy a korábbi hibás kernel tönkrevágta a pendrive filerendszerét

Meghajlok előtted :) Kipróbáltam egy régi pendrive-ot azzal simán ment.
A kritikus pendrivet-ot, memóriakártyát egy má$ik rendszeren (érdekes, ott működött) lementettem a tartalmat és újra formáztam, azóta patent. :)
Az 5.0.7-es kernel felkerültek a gépekre :)

Amúgy, hihetetlen:)
--
Karesz
www.fotokaresz.hu

Linuxon valahogy így (root joggal):

fdisk -l

Kiderítjük, melyik a pendrive, melyik partícióját szeretnénk formázni. Mondjuk, sdc1. Ha fel van csatolva, umount-oljuk. Ez nem az eject, csak umount!
Utána:

mkfs.vfat -F32 -n SzKareszFAT /dev/sdc1
sync

Bár szerintem a sync-et megcsinálja megától is, ha tippelnem kellene. A -n után legfeljebb 11 karakter állhat.

Az sdc1 tehát csak példa, azt ki kell deríteni, melyik eszköz. Nehogy leformázd FAT-re az operációs rendszert tartalmazó háttértárat!


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

Formáztam már így :) aztán, ha bedugtam a pendrive-ot egy MS gépbe jött a pánik, hogy "Houston baj van"
, Ez ugyan fa32 ,de nem én csináltam :)

El lehet szúrni a partícionálásnál is, ha rossz filerendszer típust ad az ember a partíciónak. Én mindig Linuxon formázom a pendrive-ot, windows-os gép is kajálja rendesen, ahogy kell.


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

Az updates-testing repoban is megvan, de miért akarja az install leszedni a 4.20.16-os kernelt?

Azért, mert emlékeim szerint úgy működik, hogy mindig az utolsó 3 verzió van fenn, beleértve azt is, amelyikre épp frissítesz, s a negyediket már törli. A többi csomagnál amúgy csak a legfrissebb van fenn. Teszem azt, Firefoxból nincs a gépen több különböző verzió, csak a legfrissebb. Kernelnél viszont akár boot-olhatatlanná is válhatna a gép egy hiba miatt, így megtartják a két korábbi változatot is.

Már, ha jól értettem a kérdésed.


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

Korábban kevésbé volt szigorú a régebbiekkel, inkább tartogatom még a maradék 4-eseket.
Firefoxot is többet használok, de azt könnyebb függetleníteni a repoktól(:

Most a változatosság kedvéért archon néztem 5.0.7-el, az is ugyanaz.
Legfeljebb kernelretrózok, amíg nem találok megoldást):

Közben megtaláltam, lehet 3-nál több kernelem:)
installonly_limit az /etc/dnf.conf-ban

Biztos, hogy ez kernel bug? Vagy azon az alapon az, hogy a régivel konzekvensen jó az nfs megosztás, az újjal meg nem? Én nem használok nfs-t, egyéb vonatkozásban viszont az 5.0.7-es stabilnak tűnik.


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

Próbálgattam, a noac opció volt a kulcs (:
Szóval a cachelésbe piszkáltak bele, és van, akit ez összezavar.

Amíg hiába keresgéltem a nyűgömre, aközben kiszúrtam, hogy centoshoz is van 5.0 kernel, még a végén release upgrade helyett belepróbálok..

"Ekkor már csak a grub promptja fogadott, nem indult el a gép."

Ebbe én is belefutottam upgrade után, azonban kézzel megadva a linux16 és initrd16 paramétereket bootolt a friss rendszer. Egy grub2-install megoldotta miután felraktam a rejtélyes módon hiányzó grub2-pc-modules csomagot.

Esetleg ezt javasolom, mert ha ez valóban kernel bug, lehet, hogy már kijavult.

Szerk.: hozzávaló. Amúgy meg javasolom a scriptemet. :)

upd kernel


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

Nem tudom miért, de mióta systemd van, azóta ez Fedoran rendszeresen előjön. Nem kernel függő.

Nem csak "mióta" és nem csak Fedora. systemd-analyzer blame, amivel el lehetne indulni.

pontosabban


systemd-analyze blame

Bocs, valóban.

Na de nem az indulás a baj, hanem a leállás. Mintha a wtmp-ben maradt volna valami (systemd nem biztos, hogy azt nézi, csak lusta vagyok utánanézni). Igaz, nem pont ez jön elő, mint a képen, hanem "Stop job is running for user blablabla".

Valami nem szeretné, hogy kinyírd a leállítással. Ha jól emlékszem, másfél perces time out-tal olykor nekem is csinálja, de nagyon ritkán.


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

A systemd-ben ezek jól vannak kezelve. Vannak time out-ok, függőségek, minden, ami kell.


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

Nálam Archon már 5.0.7 kernel van, és nincs ilyen hiba. Van ugyan nekem is egy néha előjövő stop job problémám, de az egy másik szolgáltatás, nem sikerült még elcsípnem, de más a szövegezése.

Ha nagyon zavar, a /etc/systemd/system.conf-ban a kommentjelet vett ki a DefaultTimeoutStopSec elől, és adj meg utána valami minimális értéket, pl. 5s. Ezzel ugyan a probléma nem oldódik meg, csak tüneti kezelés, de a semminél meg másfél perc várakozásnál jobb.


No keyboard detected... Press F1 to run the SETUP

Óvást nyújtok be! :D A timeout nem véletlenül elég nagy ahhoz, hogy legyen ideje leállni bárminek, aminek sokat kell mentenie.


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

Elvileg. Gyakorlatilag meg csak valami apró-cseprő szolgáltatás akadt be, ami nem nagyon mentett nálam adatot, csak az időt húzta. Úgyis csak ritkán jött elő. Az 5.0.10 környékén megoldódott, nem jött elő többet.

De hasonlót csinált régebben az Arch.iso is, várt bootkor a dhcpcd 1:45-ig, hátha kap a semmiből címet (mikor se Ethernet kábel nem volt bedugva, a Wi-Fi meg még nem volt bekonfigurálva SSDID+jelszó ügyében). Az ilyeneket nyugodtan ki lehet lőni a ’cibe, adatmentést nem végző, felesleges időhúzás az esetek 99%-ban.

Ez egyébként nagy hiányossága a Linuxnak. Egyrészt ki kéne normálisan írni, hogy mi várakozik, nem csak annyit, hogy „Stop job is running”, hanem konkrétan név szerint megnevezve, és be kéne tenniük egy feature-t, hogy mondjuk Ctrl+Alt+S-re vagy valami hasonló, véletlenül nem megnyomható billkombóra azonnal ki lehessen lőni. Tényleg legtöbbször csak felesleges szopást és értelmetlen várakozást okoz. Még azt az 5 mp. veszteséget is sajnálom ezekre, amit beállítottam. Csak azért nem vettem 0-1 mp.-re, mert akkor nem látom, ha újra előjön ez a hiba. Így meg észlelem, el tudom olvasni, de időben nem várakoztat még meg olyan durván, ha mégis előjönne.


No keyboard detected... Press F1 to run the SETUP

Jó, csak a systemd nem tudhatja, hogy valóban oka van-e a várakozásnak, vagy magába fordult a szolgáltatás és a köldökét nézegeti épp.


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

Ezért kéne a usernek beavatkozási lehetőséget adni, mert ő jobb eséllyel tudja, hogy mi gikszer. Nem is kell mindent a systemd-nek kitalálni, nem muszáj mindenható entitásnak lennie. Jelenleg viszont a felhasználónak, rendszergazdának semmilyen konrtollja nincs azon kívül, hogy a systemd.conf-ot szerkeszti, de erről a lehetőségről kevesen tudnak, és ez az említett beállítás is nem szelektív, minden várakozó folyamatot ki fog lőni. Sokkal jobb lenne a user kezébe adni az eseti kontrollt.


No keyboard detected... Press F1 to run the SETUP