Fedora 29 5.0.3 kernel

Red Hat, Fedora, CentOS

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

  • 2150 megtekintés

( locsemege v | 2019. 03. 30., szo – 14:54 )

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

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

ŐŐŐŐ 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

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..

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

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

"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.

( Zsugabubus | 2019. 04. 01., h – 09:49 )

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

( Raynes v | 2019. 04. 11., cs – 07:35 )

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

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

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