Itt elolvashatod a teendőket,
https://linuxmint.hu/blog/2019/09/a-drmdrmatomichelperwaitforflipdone-dr...
de szerintem már leírták.

Jó lenne valamit tudni a gépről, és az esetleges és tényleges hibákról. Az Ubuntu Pastebin (https://paste.ubuntu.com/ ) oldalra töltsd fel (mert a második igen terjedelmes) a két parancs(sor) kimenetet,

inxi -Fz

dmesg

(felülre a felhasználóneved írd, alulra a kimenetet másold be szövegesen) mentsd, és linkeld.
Bemásolsz egy parancsot a terminálba, az indítás az Enter. Tedd nagyra az ablakot a futtatás előtt.

Tájékozódunk, tesztelónk a kimeneteket megnézve,azaz nem javítanak, inkább az a kérdés, mit javítsunk, processzor, videó eszköz, stb. „miféle”.
Az első parancsor a géped, rendszered tulajdonságait mutatja.
A második parancs a megjelenítés és a firmware-ek, driverek helyes és olykor helytelen működését.

#6 A jelszó  az adminisztráció műveletekhez szükséges felhasználói jelszó. Amikor begépeled, nem látszik (aki a  monitort látja, ne olvashassa le), de ettől még ott van (a terminálban). Nyomj Enter, ha begépelted.

#1 Nem engedi beírni a superuser jelszavát. Tegnap ugyanezen a gépen  az xfce os felszólított root jelszó megadására. Nem reagáltam. Lehet a két dolognak köze egymáshoz?

#20 A javasolt grubszerkesztés vagy ötödik próbálkozása végén észrevettem, hogy a frissítés a Tara helyett szintén ezen a Dell gépen lévő Tríciát találta meg. Gondolom, mert bootolás előtt a választható első OS a Trícia.

Mindig azon rendszer grub fájlját szerkeszted (a javasolt módszerrel), amellyel be vagy lépve. A Tricia kiadáshoz is, és a Tara kiadáshoz is tartozik egy-egy grub. Semmi gond tehát, belépsz a Tara kiadással és itt is megcsinálod ugyanazt. Majd megnézed, javult-e a helyzet a Tara alatt. Merthogy a módszer bevált, annak mondható:

A Trícia az eddigi 4:40 helyett 1:10 alatt bootol. Mifelénk ez  jó.

És akkor ez a része boldogság ... https://www.youtube.com/watch?v=QGQIbWYgj9c

-----

Gondolkodjunk azon, hogy ebben vagy másik fórumban folytassuk-e a rendszer nyesegetését.

Ez azért is meggondolandó, mert az estleges további gyorsítás mellett volna még egy-két óhaj a beüzemeléshez. Pl. off-line program telepítése, amihez JAVA szükséges.

A másféle téma, más topik. Nem folytatás, kezdés. :-)

A kért tesztek, amikre nem adtam választ, lehet holnap délutánig várni kell.

Megvárjuk.

-----

Ha dolgozol este, nem tudsz koncertre menni, Akik tudnának, egy koncert vasárnapra ... . (off :-) ) Vélhetően vasárnap este nekem sem jó, mert ... . :-)

Van egy jó hírem meg rossz hírem.

 

A jó hír:

Sikerült a grub szerkesztése a javasolt módon.

A rossz hír:

A javasolt grubszerkesztés vagy ötödik próbálkozása végén észrevettem, hogy a frissítés a Tara helyett szintén ezen a Dell gépen lévő Tríciát találta meg. Gondolom, mert bootolás előtt a választható első OS a Trícia.

Hurrá! Hallelujah! Éljen!

A Trícia az eddigi 4:40 helyett 1:10 alatt bootol. Mifelénk ez  jó.

 

Most alszom, mert reggel értem haza, este újra műszak.

Gondolkodjunk azon, hogy ebben vagy másik fórumban folytassuk-e a rendszer nyesegetését.

Ez azért is meggondolandó, mert az estleges további gyorsítás mellett volna még egy-két óhaj a beüzemeléshez. Pl. off-line program telepítése, amihez JAVA szükséges.

A kért tesztek, amikre nem adtam választ, lehet holnap délutánig várni kell.

Bona serata! Sleep well! Jóccakát!

 

#25 Vélhetöen a Tarât is megjavítja a kernel paraméter. :-)

Még nem javítottam ki Tarát.

 

#28 USB írás: Etcher

https://linuxmint.hu/comment/26483#comment-26483

#27

"Vélhetöen a Tarât is megjavítja a kernel paraméter. :-)"

Szerintem is.

Asszem csináltam magamnak felesleges munkát.

Nem jegyzeteltem, de ugyanazt a jelszót és felhasználót adhattam Tarának és Triciának.

Ezt gyanítva újra akarom telepíteni legalább Tarát.

Az optikai meghajtó bizonytalan működésű. Hiába bootoltatnám lemezről. Filmet, hanglemezt is nehezen indít.

Most meg fogom kérdezni a tulajt, szokott-e lemezeket hallgatni, nézni, alkalmazni.

Ha nem, akkor usb-ről telepítek. Tricia így települt fel.

#32 Köszönjük. Ezt esetleg meg lehet írni blogbejegyzésben is. Maradandó, sokkal könnyebben visszakereshető, legközelebb elég linkelned.

Fő oldal > Tartalom hozzáadása > Blogbejegyzés

A LiveUSB, LiveCD nem jó erre a célra?

A Western Digital merevlemezekhez való, ami kérdezőnek is van:

WDC_WD1200BEVS

(Western Digital Data LifeGuard Diagnostic: https://www.lifewire.com/western-digital-data-lifeguard-diagnostic-revie... )

#30 Data Lifeguard Diagnostic for DOS használathoz (Linux alatt):

1. fenti linkelt oldalról letölteni a dlgdiag_5_27.zip-et.

2. erről az oldalról: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc2/ letölteni a FD13-Floppy.zip -et. Ez utóbbiban van egy FD13FLOP.IMG fájl, ezt pl. a Mint Lemezkép írójával fel kell írni egy pendrive-ra. (Vigyázat, a pendrájvon levő adatok eltűnnek, tehát olyant kell használni, amin nincsenek fontos adatok!)

3. pendrájvról törölni a gyökérből ezt: SETUP.BAT (nincs szükésg rá, amúgy automatikusan elindulna)

4. Hogy legyen elég szabad hely, lehet törölni a FREEDOS\SETUP mappából a DE, EO, ES, FR, NL, RU, TR mappákat.

5. A dlgdiag_5_27.zip -ből a fájlokat a pendrive gyökerébe másolni.

6. Gépet a pendrájvról indítani. A promt jelentkezik, beírni: DOSDLG, enter. (Arra figyelni, hogy az Y és Z gombok fel lesznek cserélve, amikor Y-t kell nyomni, akkor valójában a Z gombot kell lenyomni)

#34 Remélem, hogy a kérdezőnek nincs merevlemez problémája, és a javasolt kernel paraméter
https://linuxmint.hu/blog/2019/09/a-drmdrmatomichelperwaitforflipdone-dr...
ahogy az egyik rendszeren, úgy a másik rendszeren is megoldotta a gondját, vagyis a lassú rendszer betöltést, csak még nem volt ideje ezt visszajelezni.

Én is készítek egy Linux Mint Live USB-t tartalékba, nem is tudom, miért töröltem. Ha valami gond lenne általában (chroot módszer), mert tegnap este volt egy pici  ... és csak telepítőm volt USB-n, nem Live. Valahogy megjavult (a rendszer indítása után,a belépéskor is szükséges egér, billentyűzet kezelés, kernel modulok betöltése ment el [GRUB mutatta], vélhetően a acpi_enforce_resources=lax paraméter miatt | más, azaz ACPI gond megoldása lenne), de ezen a témán dolgoznom kell még: https://forums.gentoo.org/viewtopic-p-8387942.html#8387942 (a homeopátia nem jött be :-) )

#33 Nem tudom, majd menézem otthonról. Az tuti, hogy generáció váltások vannak, újabb programok csak újabb lemezeket kezelnek, a régebbi programok meg az újabbakat nem támogatják. Jelen esetben a WD oldalán kerestem rá a típus számra, ehhez a programhoz irányított.

Majd írok erről blogot, bővebben kifejtve, mert a módszer jó még más esetekre is, pl BIOS frissítés régebbi gépeken.

Vannak egyébként kész ISO-k is, amikben ezek összegyűjtve megtalálhatók, pl. UBCD, csak ezekhez gyakorlat kell a bőség zavarában eligazodni, az alkalmas progit elindítani...

#37 Ezt kéne esetleg leírni. Egy két képpel, ha megy. Ha nem fotózható a kinézet, a működés, akkor nem „kötelező”. Mondjuk, olyan képmegosztó oldalra töltsd fel a képet (ha lesz), ahol regisztráltál és be vagy lépve a feltöltéskor. Imgur, ImgBB ... . A módszer (a frissített leírás):
https://linuxmint.hu/comment/25562#comment-25562

#38 Nem néztem az alkalmazást, mert ezt beállítva (ezzel foglalatoskodtam és még pár más dologgal),

mitigations=auto,nosmt kvm-intel.vmentry_l1d_flush=always l1tf=flush,nosmt mds=full,nosmt spec_store_bypass_disable=on vsyscall=none init_on_alloc=1 init_on_free=1

úgy tűnik, a sebezhetőség hiba megoldódott. Intel CPU.
És készítettem az Etcherrel (frissített tartalom) egy Live USB-t is. :-)
Még egy-két dolog nem oldódott meg, érdekes, hogy most így hirtelen ennyi minden jött.

#33

A LiveUSB, LiveCD nem jó erre a célra?

A Western Digital merevlemezekhez való, ami kérdezőnek is van:

WDC_WD1200BEVS

(Western Digital Data LifeGuard Diagnostic: https://www.lifewire.com/western-digital-data-lifeguard-diagnostic-revie... )

Nos, megnéztem. Amiről itt írnak, az egy Windowsos telepítő, amivel Win alatt lehet tesztelni a lemezt,  továbbá amivel létre lehet hozni egy indítólemezt, ami ugyanezt a fenti DOS programot tartalmazza, amit írtam fentebb. Az oldalon található DOS verzióra muatató linkek meg ugyanoda visznek a WD oldalán, ahol csak magát a DOS programot lehet letölteni, nem live csomagot.

#32 Upsz! Kipróbáltam amit írtam, de sajnos a flopi image túl kicsi, hogy ráférjen a WD tesztprogramja, így ahelyett ezt kell letölteni: FD13-LiteUSB.zip

Ezen lesz elég hely a fájlokat rámásolni, és működik is, kipróbáltam.

(A SETUP.BAT-ot erről is törölni kell)

#40   Éppen elkövettem, jó lesz így? https://linuxmint.hu/blog/2020/01/ha-dos-program-futtatasara-van-szukseg

Jónak tűnik. :-)

Szándékomban állt képeket készíteni, de aztán elvetettem, mert nem konkrétan a WD cuccáról akartam írni, hanem egy általánosat, Freedos képek vannak fent a saját oldalukon, a programok, amiket futtatni lehet Freedos alatt, az meg sok...

Rendben. Egyszer frissítettem volna a BIOS-t egy másik gépen, de nem ment a FreeDOS alól valamiért. A nevet nem fogadta el a FreeDOS, pedig le volt egyszerűsitve eléggé.

De egyébként is szándékomban állt folytatni, néhény Live ISO megoldással, ha kell, akkor kitérek a programokra is, képekkel...

Szuper. :-)

-----

úgy tűnik, a sebezhetőség hiba megoldódott. Intel CPU.

Akartam is kérdezni, ez miért fontos? Fakultatíve? (Csak mert én azért nem érzem égetőnek, mivel ezek kihasználásához hozzá kell férni a helyi géphez, nem?) Persze, azért jó, ha valaki ezzel is foglakozik :-)

Nem feltétlen kell tán fizikailag hozzáférni a géphez, hogy megtörjék a rendszert. :-)

https://linuxmint.hu/hir/2018/01/igy-javitsd-meg-a-spectre-meltdown-es-a...
https://linuxmint.hu/forum/a-spectre-variant-2-sikeres-befoltozasa-a-415...

Nálam most ez a helyzet (az első két parancs nem tartozik a vizsgálathoz)

git clone https://github.com/speed47/spectre-meltdown-checker.git

cd spectre-meltdown-checker/

sudo ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.43-3-ga1a35c9

Checking for vulnerabilities on current system
Kernel is Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64
CPU is Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES  (But not in all CPUs)
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES  (But not in all CPUs)
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  YES  (Intel SSBD)
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  YES  (But not in all CPUs)
    * CPU indicates L1D flush capability:  YES  (L1D flush feature bit)
  * Microarchitectural Data Sampling
    * VERW instruction is available:  YES  (MD_CLEAR feature bit)
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
  * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO):  NO
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO
  * CPU/Hypervisor indicates L1D flushing is not necessary on this system:  NO
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):  NO
  * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDS_NO):  NO
  * CPU explicitly indicates not being vulnerable to TSX Asynchronous Abort (TAA_NO):  NO
  * CPU explicitly indicates not being vulnerable to iTLB Multihit (PSCHANGE_MSC_NO):  NO
  * CPU explicitly indicates having MSR for TSX control (TSX_CTRL_MSR):  NO
  * CPU supports Transactional Synchronization Extensions (TSX):  NO
  * CPU supports Software Guard Extensions (SGX):  NO
  * CPU microcode is known to cause stability problems:  NO  (model 0x3a family 0x6 stepping 0x9 ucode 0x21 cpuid 0x306a9)
  * CPU microcode is the latest known available version:  YES  (latest version is 0x21 dated 2019/02/13 according to builtin firmwares DB v130.20191104+i20191027)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass):  YES
  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection):  YES
  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load):  YES
  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read):  YES
  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass):  YES
  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault):  NO
  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  YES
  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  YES
  * Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)):  YES
  * Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)):  YES
  * Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)):  YES
  * Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)):  YES
  * Vulnerable to CVE-2019-11135 (ZombieLoad V2, TSX Asynchronous Abort (TAA)):  NO
  * Vulnerable to CVE-2018-12207 (No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)):  YES

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: usercopy/swapgs barriers and __user pointer sanitization)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO
* Kernel has mask_nospec64 (arm64):  NO
> STATUS:  NOT VULNERABLE  (Mitigation: usercopy/swapgs barriers and __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  YES  (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES
    * IBRS enabled and active:  YES  (for firmware code only)
  * Kernel is compiled with IBPB support:  YES
    * IBPB enabled and active:  YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  YES
    * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
> STATUS:  NOT VULNERABLE  (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES
  * PTI enabled and active:  YES
  * Reduced performance impact of PTI:  YES  (CPU supports PCID, performance impact of PTI will be reduced)
* Running as a Xen PV DomU:  NO
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability:  YES
> STATUS:  NOT VULNERABLE  (your CPU microcode mitigates the vulnerability)

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface:  YES  (Mitigation: Speculative Store Bypass disabled)
* Kernel supports disabling speculative store bypass (SSB):  YES  (found in /proc/self/status)
* SSB mitigation is enabled and active:  YES  (global)
> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled)

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  N/A
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled)
* Kernel supports PTE inversion:  YES  (found in kernel image)
* PTE inversion enabled and active:  YES
> STATUS:  NOT VULNERABLE  (Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled
* This system is a host running a hypervisor:  NO
* Mitigation 1 (KVM)
  * EPT is disabled:  NO
* Mitigation 2
  * L1D flush is supported by kernel:  YES  (found flush_l1d in /proc/cpuinfo)
  * L1D flush enabled:  YES  (unconditional flushes)
  * Hardware-backed L1D flush supported:  YES  (performance impact of the mitigation will be greatly reduced)
  * Hyper-Threading (SMT) is enabled:  NO
> STATUS:  NOT VULNERABLE  (this system is not running a hypervisor)

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface:  YES  (Mitigation: Clear CPU buffers; SMT disabled)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  YES
* SMT is either mitigated or disabled:  YES
> STATUS:  NOT VULNERABLE  (Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface:  YES  (Mitigation: Clear CPU buffers; SMT disabled)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  YES
* SMT is either mitigated or disabled:  YES
> STATUS:  NOT VULNERABLE  (Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface:  YES  (Mitigation: Clear CPU buffers; SMT disabled)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  YES
* SMT is either mitigated or disabled:  YES
> STATUS:  NOT VULNERABLE  (Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  YES  (Mitigation: Clear CPU buffers; SMT disabled)
* Kernel supports using MD_CLEAR mitigation:  YES  (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active:  YES
* SMT is either mitigated or disabled:  YES
> STATUS:  NOT VULNERABLE  (Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled)

CVE-2019-11135 aka 'ZombieLoad V2, TSX Asynchronous Abort (TAA)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* TAA mitigation is supported by kernel:  YES  (found tsx_async_abort in kernel image)
* TAA mitigation enabled and active:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-12207 aka 'No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)'
* Mitigated according to the /sys interface:  YES  (KVM: Mitigation: Split huge pages)
* This system is a host running a hypervisor:  NO
* iTLB Multihit mitigation is supported by kernel:  YES  (found itlb_multihit in kernel image)
* iTLB Multihit mitigation enabled and active:  YES  (KVM: Mitigation: Split huge pages)
> STATUS:  NOT VULNERABLE  (this system is not running a hypervisor)

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer

Visszakapcsoltam a Turbo-t (bekapcsoltam: echo 0), de a Hyper Threading amúgy ... ki van kapcsolva a védekezés miatt:

echo 0 | sudo tee -a /sys/devices/system/cpu/intel_pstate/no_turbo

De inkább ez a kimenet mutatja az igazságot:

grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: Split huge pages
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected

Az Intelnek kéne lépnie: újabb intel-microcode csomaggal.

#39 Ezt kéne esetleg leírni. Egy két képpel, ha megy. Ha nem fotózható a kinézet, a működés, akkor nem „kötelező”. Mondjuk, olyan képmegosztó oldalra töltsd fel a képet (ha lesz), ahol regisztráltál és be vagy lépve a feltöltéskor. Imgur, ImgBB ... . A módszer (a frissített leírás):

Éppen elkövettem, jó lesz így? https://linuxmint.hu/blog/2020/01/ha-dos-program-futtatasara-van-szukseg

Szándékomban állt képeket készíteni, de aztán elvetettem, mert nem konkrétan a WD cuccáról akartam írni, hanem egy általánosat, Freedos képek vannak fent a saját oldalukon, a programok, amiket futtatni lehet Freedos alatt, az meg sok...

De egyébként is szándékomban állt folytatni, néhény Live ISO megoldással, ha kell, akkor kitérek a programokra is, képekkel...

úgy tűnik, a sebezhetőség hiba megoldódott. Intel CPU.

Akartam is kérdezni, ez miért fontos? Fakultatíve? (Csak mert én azért nem érzem égetőnek, mivel ezek kihasználásához hozzá kell férni a helyi géphez, nem?) Persze, azért jó, ha valaki ezzel is foglakozik :-)

#52 megnéztem a BIOS chipkészlet beállításait. IDE és AHCI közül lehet választani, jelenleg az IDE az aktív.

Állítsd be az AHCI-t a BIOS-ban az IDE helyett és így nézzünk egy másik dmesg kimenetet.
Egyszerre csak egy hibával érdemes foglalkozni.
A mutatott képen is ugyanaz a hiba. Plusz a Pulseaudio-é. Az más téma.

Mit jelent az, hogy a rendszer nem tudja azonosítani a merevlemezt, akkor hogy tud mégis boot-olni?

Sok ember vígan él, mindeközben nem beszélgetnek és nem köszönnek egymásnak. Ilyesmi.

Valóban régi gép, nem is játékra használom. Csak látom, hogy a hibaüzenetekben szerepel ata, SATA, gondoltam köze van a merevlemezhez, amit nem szeretnék, ha egy pillanat alatt menne róla a levesbe a sok hasznos és értékes adat.

Látok-e más hibát? A napló "Fontos" fülének a tartalma, lásd: csatolmány.

https://paste.ubuntu.com/p/gxxGhBXpmD/

Továbbá megnéztem a BIOS chipkészlet beállításait. IDE és AHCI közül lehet választani, jelenleg az IDE az aktív.

Mit jelent az, hogy a rendszer nem tudja azonosítani a merevlemezt, akkor hogy tud mégis boot-olni?

 

#56 Vélhetően mindkettő segített:
-- a hibaüzenetek eltűntek (a mai modern Linuxok AHCI beállítást használnak).
-- és a fizikai hiba is elég nagy hiba.
Nem mondtuk, hogy lehelgetni kell! :)

17:09:22 kernel: usbhid 4-1:1.1: couldn't find an input interrupt endpoint

A probléma az 4-es USB csatin lép fel, ami egy HUB.

[    0.721925] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.08
[    0.721927] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.721929] usb usb4: Product: UHCI Host Controller
[    0.721930] usb usb4: Manufacturer: Linux 5.8.0-41-generic uhci_hcd
[    0.721931] usb usb4: SerialNumber: 0000:00:1a.1
[    0.722018] hub 4-0:1.0: USB hub found
[    0.722025] hub 4-0:1.0: 2 ports detected
[    0.722220] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[    0.722225] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[    0.722230] uhci_hcd 0000:00:1a.2: detected 2 ports
[    0.722253] uhci_hcd 0000:00:1a.2: irq 19, io base 0x0000b800

És mi van ott? Egy egér, vagyis úgy tűnik, az van ott:

[    1.441913] usb 4-1: New USB device found, idVendor=0458, idProduct=0186, bcdDevice=24.58
[    1.441916] usb 4-1: New USB device strings: Mfr=4, Product=40, SerialNumber=0
[    1.441918] usb 4-1: Product: Wired Mouse
[    1.441920] usb 4-1: Manufacturer: KYE SYSTEMS CORP.
[    1.452455] hid: raw HID events driver (C) Jiri Kosina
[    1.469191] usbhid 4-1:1.1: couldn't find an input interrupt endpoint
[    1.469494] usbcore: registered new interface driver usbhid
[    1.469496] usbhid: USB HID core driver
[    1.494605] input: KYE SYSTEMS CORP. Wired Mouse as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/0003:0458:0186.0001/input/input3
[    1.495065] hid-generic 0003:0458:0186.0001: input,hidraw0: USB HID v1.11 Mouse [KYE SYSTEMS CORP. Wired Mouse] on usb-0000:00:1a.1-1/input0

Azt nem tudom, mire képes az egér, de ha másik USB aljzatba dugod?
Arra gondolok, USB 1 helyett USB 2-esbe?
A meghajtó alapján is jelenleg szerintem USB 1-esben van.

A jelenlegi tesztje, tulajdonságok:

sudo lshw -c input

Az OHCI, és a UHCI az USB 1 csatikat vezérlik,
míg az EHCI az USB 2-es csatikat,
és az xHCI az USB 3-as csatikat is.
https://en.wikipedia.org/wiki/UHCI
https://www.kernel.org/doc/html/latest/usb/index.html
http://www.linux-usb.org/FAQ.html

#53

AHCI beállítva.

T.István javaslatára vizsgálódtam egy picit fizikálisan is, aminek meglett az eredménye. "A HDD-vel kapcsolatban, ha nem is a kábel, de az alaplapi SATA foglalat volt a ludas, mivel az egy leheletnyi mozdításra a kezemben maradt. Nem baj, van még négy szabad."

Nem tudom, hogy az AHCI-nek, vagy a SATA foglalatnak köszönhetően, de gyorsabb a boot.

És az új dmesg kimenet: https://paste.ubuntu.com/p/d9zkXWBSVt/

Azért két hibaüzenet csak maradt: https://paste.ubuntu.com/p/WKycMgQcgh/

 

 

#60 Ezen az alaplapon nincs USB1 port (LGA775 alaplap),

Nem néztem. Az én gépemen visznot van egy USB 1 csatlakozó.

a vezérlők viszont visszafele kompatibiltás miatt tudnak ebben a módban is működni.

Jaja.

Esetleg meg lehet nézni a

xinput list

parancs kimenetet (aztán ránézni, engedélyezve van-e az egér - ez egy későbbi dolog lesz), és az egér beállításokat a grafikus felületen, továbbá a DConf szerkesztőben is. Szerintem az sem elvetemült gondolat, ha rájönnénk, milyen IRQ beállítást kéne változtatni a BIOS-ban, ami segíthet a HID működésének javításában (ezt olvastam).

#59 Ezen az alaplapon nincs USB1 port (LGA775 alaplap), a vezérlők viszont visszafele kompatibiltás miatt tudnak ebben a módban is működni. Azért vált vissza, mert nem működik stabilan USB2 módban. Az alaplapi vezérlő, vagy a bedugott eszköz hibája is okozzhatja ezt. Másik egérrel kellene próbálkozni, a Genius egerek már régóta csapnivalók, és Linux is érzékeny erre. Javalolt Logitech egeret használni. De mindenek előtt érdmes lenne felmérni, hogy mivel állunk szemben (Pl. BIOS), ill. alaplap állapota....

#59 Itt ugyanazzal a márkával szintén gond:
https://unix.stackexchange.com/questions/546828/anabel-mouse-couldnt-fin...
https://www.spinics.net/lists/linux-usb/msg153996.html
https://marc.info/?l=linux-usb&m=148786778921138&w=2

  idVendor           0x0458 KYE Systems Corp. (Mouse Systems)
  idProduct          0x0186 

Azt írja Alan Stern, ne foglalkozz a hibaüzenettel, ha működik, akkor rendben!

In any case, does the mouse work okay?  If it does, you don't have to 
worry about the error message.

A LED ki- és bekapcsolható, vagy hogyan működik az egéren?

Az alapértelmezett 5.4-es kernellel belépve fellép a hiba?

#56 Vélhetően mindkettő segített:
-- a hibaüzenetek eltűntek (a mai modern Linuxok AHCI beállítást használnak).
-- és a fizikai hiba is elég nagy hiba.
Nem mondtuk, hogy lehelgetni kell! :)

17:09:22 kernel: usbhid 4-1:1.1: couldn't find an input interrupt endpoint

A probléma az 4-es USB csatin lép fel, ami egy HUB.

[    0.721925] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.08
[    0.721927] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.721929] usb usb4: Product: UHCI Host Controller
[    0.721930] usb usb4: Manufacturer: Linux 5.8.0-41-generic uhci_hcd
[    0.721931] usb usb4: SerialNumber: 0000:00:1a.1
[    0.722018] hub 4-0:1.0: USB hub found
[    0.722025] hub 4-0:1.0: 2 ports detected
[    0.722220] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[    0.722225] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[    0.722230] uhci_hcd 0000:00:1a.2: detected 2 ports
[    0.722253] uhci_hcd 0000:00:1a.2: irq 19, io base 0x0000b800

És mi van ott? Egy egér, vagyis úgy tűnik, az van ott:

[    1.441913] usb 4-1: New USB device found, idVendor=0458, idProduct=0186, bcdDevice=24.58
[    1.441916] usb 4-1: New USB device strings: Mfr=4, Product=40, SerialNumber=0
[    1.441918] usb 4-1: Product: Wired Mouse
[    1.441920] usb 4-1: Manufacturer: KYE SYSTEMS CORP.
[    1.452455] hid: raw HID events driver (C) Jiri Kosina
[    1.469191] usbhid 4-1:1.1: couldn't find an input interrupt endpoint
[    1.469494] usbcore: registered new interface driver usbhid
[    1.469496] usbhid: USB HID core driver
[    1.494605] input: KYE SYSTEMS CORP. Wired Mouse as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/0003:0458:0186.0001/input/input3
[    1.495065] hid-generic 0003:0458:0186.0001: input,hidraw0: USB HID v1.11 Mouse [KYE SYSTEMS CORP. Wired Mouse] on usb-0000:00:1a.1-1/input0

Azt nem tudom, mire képes az egér, de ha másik USB aljzatba dugod?
Arra gondolok, USB 1 helyett USB 2-esbe?
A meghajtó alapján is jelenleg szerintem USB 1-esben van.

A jelenlegi tesztje, tulajdonságok:

sudo lshw -c input

Az OHCI, és a UHCI az USB 1 csatikat vezérlik,
míg az EHCI az USB 2-es csatikat,
és az xHCI az USB 3-as csatikat is.
https://en.wikipedia.org/wiki/UHCI
https://www.kernel.org/doc/html/latest/usb/index.html
http://www.linux-usb.org/FAQ.html

#56 Önmagában a jelzés nem közlékeny, mi okozza pontosan a problémát.

17:10:22 pulseaudio: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Arról van szó, hogy egy alkalmazás használata közben a Pulseaudio alkalmazás és a DBus kapcsolatában valamilyen probléma keletkezett. És felsorolásra kerülnek a lehetséges problémák, és magyarázatuk:
-- a hangot használó alkalmazás (the remote application)
    -- nem válaszol (did not send a reply),
    -- a biztonsági szabályok az válasz üzenetet blokkolják  (the message bus security policy blocked the reply),
    -- a válasz üzenetre álló időtartam lejárt (the reply timeout expired),
-- vagy a hálózati kapcsolat megszakadt vagy más probléma van vele (or the network connection was broken).

Amikor ilyesmi történik, általában megszakad egy alkalmazásban lejátszott hang. Ezt észre kéne venned. Ha nem veszed észre, akkor a probléma átmeneti, és javítva lett.

Ha használlsz Bluetooth kapcsolatot, például fejlhallgatót, vagy okostelefont, stb., akkor a kapcsolat néha nem stabil, ezért a hang átvitelt is szakadásnak érzékeli a rendszer.

Példák:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873641
(https://hard-digital-trash.blogspot.com/2021/01/bug-1873641-re-pulseaudi...)
https://ask.fedoraproject.org/t/pulse-audio-issue/9740
https://forums.gentoo.org/viewtopic-t-1054838.html
https://github.com/linuxmint/Cinnamon/issues/5568
https://bugs.centos.org/view.php?id=17796

De például a Bluez alkalmazásnál, ha nem használod, viszont nem kapcsolod ki, hogy fusson, akkor is lehet ilyen jelenség. Sorolhatnám a példákat, de mélyebb információkat nem látunk.

A Pulseaudio magában is csinálhat ilyet néha, valamilyen körülmény hatására.
Ha azt tapasztalod, elmegy a hang, nézz rá a parancssor kimenetére:

systemctl status --user pulseaudio.service --no-pager

Megjelenhet itt az alkalmazás, ami a gondot okozza.
Ugyanígy benne lehet a naplókban.
Mi a napló neve, amiben láttad az üzenetet?
Mert a teljes napló utalhat a fenti üzenet előtt, után a hiba pontos okára.

A Pulseaudio egy általánosan használt hang szerver, leginkább más hangrendszereket vezérel. Mint például az ALSA hangrendszert, ami kevesebb grafikus beállítást nyújtott, a Pulseaudio-val viszont könnyen vezérelhető. De például JACK is hangszerver, ténylegesen valós idejű hangátvitelhez (pl. az Ardour használja). A Pulseaudio-n folyamatosan dolgoznak, lehet, kiváltják valami mással, de tulajdonképpen nem jellemző, hogy rosszul működik.

A DBus végzi az alkalmazások közötti hírvivő, üzenetküldő szerepet. Megjelenése a szabványos, Freedesktop-féle megoldás. Vannak szabályok is az üzenetekre, ez is rögzítve van, itt és más alkalmazásban is. Ha nem felel meg a biztonsági szabályoknak egy üzenet, nem fog megérkezni.

#53

AHCI beállítva.

T.István javaslatára vizsgálódtam egy picit fizikálisan is, aminek meglett az eredménye. "A HDD-vel kapcsolatban, ha nem is a kábel, de az alaplapi SATA foglalat volt a ludas, mivel az egy leheletnyi mozdításra a kezemben maradt. Nem baj, van még négy szabad."

Nem tudom, hogy az AHCI-nek, vagy a SATA foglalatnak köszönhetően, de gyorsabb a boot.

És az új dmesg kimenet: https://paste.ubuntu.com/p/d9zkXWBSVt/

Azért két hibaüzenet csak maradt: https://paste.ubuntu.com/p/WKycMgQcgh/

 

 

#69 Nem Linux Mint hiba, hanem általános, minden Linux terjesztésen előfordulhat: Pulseaudio-t használ szinte mindegyik. (korábban, véletlenül a másik válaszba írtam, ott még törölhető volt, de a Pulseaudio-s válaszba már nem fért bele)

#56 Önmagában a jelzés nem közlékeny, mi okozza pontosan a problémát.

17:10:22 pulseaudio: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Arról van szó, hogy egy alkalmazás használata közben a Pulseaudio alkalmazás és a DBus kapcsolatában valamilyen probléma keletkezett. És felsorolásra kerülnek a lehetséges problémák, és magyarázatuk:
-- a hangot használó alkalmazás (the remote application)
    -- nem válaszol (did not send a reply),
    -- a biztonsági szabályok az válasz üzenetet blokkolják  (the message bus security policy blocked the reply),
    -- a válasz üzenetre álló időtartam lejárt (the reply timeout expired),
-- vagy a hálózati kapcsolat megszakadt vagy más probléma van vele (or the network connection was broken).

Amikor ilyesmi történik, általában megszakad egy alkalmazásban lejátszott hang. Ezt észre kéne venned. Ha nem veszed észre, akkor a probléma átmeneti, és javítva lett.

Ha használlsz Bluetooth kapcsolatot, például fejlhallgatót, vagy okostelefont, stb., akkor a kapcsolat néha nem stabil, ezért a hang átvitelt is szakadásnak érzékeli a rendszer.

Példák:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873641
(https://hard-digital-trash.blogspot.com/2021/01/bug-1873641-re-pulseaudi...)
https://ask.fedoraproject.org/t/pulse-audio-issue/9740
https://forums.gentoo.org/viewtopic-t-1054838.html
https://github.com/linuxmint/Cinnamon/issues/5568
https://bugs.centos.org/view.php?id=17796

De például a Bluez alkalmazásnál, ha nem használod, viszont nem kapcsolod ki, hogy fusson, akkor is lehet ilyen jelenség. Sorolhatnám a példákat, de mélyebb információkat nem látunk.

A Pulseaudio magában is csinálhat ilyet néha, valamilyen körülmény hatására.
Ha azt tapasztalod, elmegy a hang, nézz rá a parancssor kimenetére:

systemctl status --user pulseaudio.service --no-pager

Megjelenhet itt az alkalmazás, ami a gondot okozza.
Ugyanígy benne lehet a naplókban.
Mi a napló neve, amiben láttad az üzenetet?
Mert a teljes napló utalhat a fenti üzenet előtt, után a hiba pontos okára.

A Pulseaudio egy általánosan használt hang szerver, leginkább más hangrendszereket vezérel. Mint például az ALSA hangrendszert, ami kevesebb grafikus beállítást nyújtott, a Pulseaudio-val viszont könnyen vezérelhető. De például JACK is hangszerver, ténylegesen valós idejű hangátvitelhez (pl. az Ardour használja). A Pulseaudio-n folyamatosan dolgoznak, lehet, kiváltják valami mással, de tulajdonképpen nem jellemző, hogy rosszul működik.

A DBus végzi az alkalmazások közötti hírvivő, üzenetküldő szerepet. Megjelenése a szabványos, Freedesktop-féle megoldás. Vannak szabályok is az üzenetekre, ez is rögzítve van, itt és más alkalmazásban is. Ha nem felel meg a biztonsági szabályoknak egy üzenet, nem fog megérkezni.

#57 #71 Felfigyeltem rá, hogy a maradék hibaüzenet usb-ről, illetve hangról szól.
Pár hónappal ezelőtt megadta magát a 3.25"-ös front panelnek az audio része, de a két usb port működik.
Így hát vettem is egy usb-hangkártyát, amivel működtetem a fejhallgatót.
Esetleg ez beleszólhat az akadálymentes működésbe?

Hát, lehet, a Pulseaudio pont ezzel az eszközzel nincs tökéletes barátságban (olykor). A tesztelés módját leírtam. MIndez nem tűnik hatalmas problémának, ha soha nincs gond a hang lejátszással. AZt is meg lehet nézni, melyik az alapértelmezett hangkártya. A grafikus beállításokban látszik (panel > hangerőikon), hogy a rendszer indítása után melyik van használva. Ha az USB-s, akkor a rendszer a kiválasztást jól lekezelte.

#69 Nem Linux Mint hiba, hanem általános, minden Linux terjesztésen előfordulhat: Pulseaudio-t használ szinte mindegyik. (korábban, véletlenül a másik válaszba írtam, ott még törölhető volt, de a Pulseaudio-s válaszba már nem fért bele)

#56

Még egy érdekesség...

Felfigyeltem rá, hogy a maradék hibaüzenet usb-ről, illetve hangról szól.

Pár hónappal ezelőtt megadta magát a 3.25"-ös front panelnek az audio része, de a két usb port működik.

Így hát vettem is egy usb-hangkártyát, amivel működtetem a fejhallgatót.

Esetleg ez beleszólhat az akadálymentes működésbe?