Lassú boot

jövevény képe

Fórum: 

Szervusztok!

 

Kezdő linuxos felhasználóként itt 49 fórumon nem, de az askubuntun talán megtaláltam a megoldást. Miszerint van egy bug, ami sok disztrón fellelhető, szoftvereket és hardwereket is ide számítva.

https://askubuntu.com/questions/893817/boot-very-slow-because-of-drm-kms-helper-errors

 

Karakteres parancsot kellene adnom, ha jól látom, amit még nem tettem eddig.

Az első parancs után megadom a jelszót, el is fogadja, de aztán elakadok. A kernel számára sem tudom megadni hogy kezelje egyként a videót az svideoval.

És ugye három parancsot kellene adni.

Parancsolni tudni kell(ene).

 

 

A »Dell Inspiron 1520« 6:36 alatt bootol.

A rendszerről még:

Linux Mint 19 Tara 32-bit

Kernel: Linux 4.15.0-20-generic i686

MATE 1.20.1

 

Memória: 2,5 GiB

Processzor: Intel® Pentium(R) Dual CPU T2330 @ 1.60GHz × 2

Elérhető lemezterület: 59,0 GiB

 

POST után két gépelt oldallal vidít engem vagy két percig. A Mint indulása után újra sötétszürke a képernyő több percen át.

A jó hír, hogy a kezdő képernyő megjelenése után szépen muzsikál a gép. Böngészés, DVD-nézés, Youtube, szövegszerkesztés szépen és nekem elég gyorsan megy.

 

Ezen a Dell gépen van még egy XFCE változat is, ami 4p 40 mp alatt bootol.

POST után csak fél gépelt oldal a hibajelentés , de a lényege ugyanaz, mint az askubuntu posztjában látható.

Ettől függetlenül küldjek-e fotót a POST-ról?

 

Nem magamért teszem, egy 82 éves mamika készülékére tettem fel a Tarát, mert megtetszettek neki a »Mint« OS-ek. Nagyon is érthető, ha a félig sem működő Vista ultimate+ Opera volt eddig neki.

Lassú boot

Szia !
Nem vagyok róla meggyőződve hogy a boot időt lerövidíti az általad linkelt oldalon javasolt grub fájl szerkesztése.
De meg lehet próbálni.
Az első parancs (terminálban) admin. jogosultsággal (szerkeszthetően) megnyitja a grub fájt.
sudo nano /etc/default/grub
Ezután a navigáló billentyűkkel (le) odamész ehhez a sorhoz:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
A jobbra billentyűvel a splash szó végére mész, és ütsz egy szóközt.
Ezután bemásolod ezt: video=SVIDEO-1:d
Úgy hogy a szerkesztett sor így nézzen ki:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=SVIDEO-1:d"

Ezután mentés, és kilépés következik: (ebben e sorrendben !)

F3
enter
Ctrl+X

sudo update-grub
sudo reboot

Ha ez nem segít, akkor ugyanezeket a lépéseket használva törölni is lehet a beillesztett:
splash video=SVIDEO-1:d
paramétert. Hogy az eredetit kapd vissza:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

 

Értékelés: 

0
Még nincs értékelve

Lassú boot

#1 Bocs ! A végét elszúrtam ... így kellett volna:

Ha ez nem segít, akkor ugyanezeket a lépéseket használva törölni is lehet a beillesztett:
video=SVIDEO-1:d
paramétert. Hogy az eredetit kapd vissza:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Értékelés: 

0
Még nincs értékelve
kimarite képe

Itt elolvashatod a teendőket

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.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Kernel modulok

#3 Off kicsit. Például én észrevettem egy hibát ... (dmesg kimenet). Magyarázat: kíváncsiságból új kernelt használok, a WiFi eszköz firmware még nem „új”.

[   16.527552] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[   16.527557] cfg80211: failed to load regulatory.db

Van egy újabb firmware, újratelepítem tehát.

sudo apt-get -t buster-backports install firmware-iwlwifi

Majd betöltöttem a modult újra:

sudo rmmod iwldvm
sudo modprobe iwldvm

Úgy tűnik, eltűnt a hiba (de majd még ránézek):

[ 5870.636197] iwlwifi 0000:24:00.0: CONFIG_IWLWIFI_DEBUG disabled
[ 5870.636199] iwlwifi 0000:24:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[ 5870.636200] iwlwifi 0000:24:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[ 5870.636202] iwlwifi 0000:24:00.0: Detected Intel(R) Centrino(R) Advanced-N 6205 AGN, REV=0xB0
[ 5870.672024] ieee80211 phy1: Selected rate control algorithm 'iwl-agn-rs'
[ 5870.679406] iwlwifi 0000:24:00.0 wlo1: renamed from wlan0

Szándékosan nem részleteztem, amit csináltam, ez nem a te megoldásod, hanem egy példa csak. Csak annyi, hogy volt megoldás, mint a te rendszered problémájára is lehet. És a hibaüzenetből lehet kiindulni, mint én is tettem.

Javított a beállítás a betöltésen amúgy?

Értékelés: 

0
Még nincs értékelve
jövevény képe

Itt elolvashatod a teendőket

#3

Itt van a 6 perc 36mp alatt bootoló Dell Inspiron 1520 állapotáról a kért kimenetek(egy hónapig érvényes) linkje:

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

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

#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?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot

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

Értékelés: 

0
Még nincs értékelve

Itt szinte teljesen hasonló

Itt szinte teljesen hasonló problémáról van szó, ráadásul szintén DELL.

https://askubuntu.com/questions/1052002/extremely-slow-boot-with-kernel-...

Állitólag kernel kapcsolóval megoldódott:

"I have solved it, I just add the "video=SVIDEO-1:d" at the grub parameter, however for doing that i had to change to root since terminal, and being root i could add that, save, update and done."

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

#7 Reggel már mutatta a csillagokat a jelszó helyén. :)

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

Tartozom egy vallomással.

Ez a Dell inspiron 1520 átesett egy memóriacserén. Az egyikhez, az M jelű fedél alatt könnyedén hozzáfértem. Ezt cseréltem ki. A másikhoz, a billentyűzet alatt többszöri próbálkozással sem sikerült  hozzáférni. 

 A tudatlan és erőszakos próbálkozások is okozhatják ezt a problémát?

A javasolt három parancsot a terminálban kiadtam.

Nem javult a helyzet.

Vagy nem voltam elég pontos vagy ...

Értékelés: 

0
Még nincs értékelve

Lassú boot

#9 Mi a helyzet a gub fájl szerkesztésével - sikerült ? Nem sikerült ? Lett valami hatása ? :)

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

#11 Egyszerre 11:20-kor írtunk.

Nincs változás

Értékelés: 

0
Még nincs értékelve

Lassú boot

#12 Nézd ! Nem akarok erőszakoskodni, de eléggé szófukar vagy.
A grub fájl szerkesztése nem csak 3 parancs kiadásából áll !
Az első válaszomban ezt elég részletesen - lépésről-lépésre leírtam.
(Ettől függetlenül lehet hogy megcsináltad, de ez a válaszaidból nem derül ki egyértelműen.)

Értékelés: 

0
Még nincs értékelve

Lassú boot

#12 Kellene a kimenete ennek a parancsnak:

cat /etc/default/grub

Mert macskarajongó vagyok...

cat /etc/default/grub

 

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

#11 A szerkesztést is elvégeztem. Sietve. Holnap érekhaza, addig csak elmélkedni tudok.

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

#14

Mañana. Domani....Holnap érek haza.

Engem is érdekel. :)

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

Jó a csapat.

Csak én vagyok lassú.

De már edzek.

Értékelés: 

0
Még nincs értékelve

Lassú boot

#17 Edzésként ezeknek a parancsoknak a kimeneteit is gyűrd be a válaszodba:

sudo systemd-analyze blame

sudo systemd-analyze critical-chain

Talán mutatnak valamit ami ötletet ad.

Értékelés: 

0
Még nincs értékelve
jövevény képe

Van egy jó hírem meg rossz

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!

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Tara | Tricia (a számítógép ugyanaz)

#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 ... . :-)

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

#19

Edzésként ezeknek a parancsoknak a kimeneteit is gyűrd be a válaszodba:

sudo systemd-analyze blame

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

sudo systemd-analyze critical-chain

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

Íme.

Gondolom elmondod, mire lehet jó. :)

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

#19

Lala kérte ezt is. Korában rossz választ írtam.

sudo systemd-analyze critical-chain

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

Értékelés: 

0
Még nincs értékelve
jövevény képe

Laasú boot

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

 

Értékelés: 

0
Még nincs értékelve
jövevény képe

Laasú boot

#25 Mert nem férek hozzá. Holnap nekilátok.

Értékelés: 

0
Még nincs értékelve
jövevény képe

Laasú boot

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

Értékelés: 

0
Még nincs értékelve
kimarite képe

Laasú boot

#28 USB írás: Etcher

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

Értékelés: 

0
Még nincs értékelve

Átnéztem a dmesg-et...

Szóval.

-Utána kellene nézni, van-e BIOS frissítés a géphez, és esetleg frissíteni.

-Ellenőrizni kellene a lemez állapotát. Itt alálni a hozzávaló ellenőrző programot, és az angol leírást, hogy miként kell használni:

https://support-en.wd.com/app/products/product-detail/p/300#WD_downloads

(Data Lifeguard Diagnostic for DOS -t kell kiválasztani)

-A memória csere bővítés volt? A 2 GB maradt, vagy több lett?

Értékelés: 

0
Még nincs értékelve

Lassú boot

#10

Ez a Dell inspiron 1520 átesett egy memóriacserén. Az egyikhez, az M jelű fedél alatt könnyedén hozzáfértem. Ezt cseréltem ki. A másikhoz, a billentyűzet alatt többszöri próbálkozással sem sikerült  hozzáférni. 

 A tudatlan és erőszakos próbálkozások is okozhatják ezt a problémát?

Induláskor (POST után) nyomjad a Shift-et, mire feljön a GRUB menü, ott meg futtatni kell a Memtest-et, az megmondja.

Értékelés: 

0
Még nincs értékelve

Átnéztem a dmesg-et...

#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)

Értékelés: 

0
Még nincs értékelve
kimarite képe

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

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

Értékelés: 

0
Még nincs értékelve

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

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

Értékelés: 

0
Még nincs értékelve
kimarite képe

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

#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 :-) )

Értékelés: 

0
Még nincs értékelve

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

#35 Én is remélem, hogy nincs merevlemez gond, csak ahogy a dmesg riportot olvastam, nagyon olyan érzésem támadt, hogy benne lehet a pakliban.

Az ACPI másik gond, az nehéz ügy, de itt még bízni lehet abban, ha van frissebb BIOS, akkor az megoldhatja. A dmesg riportban is látható egy ilten üzenet, hogy, ha lehet, jó lenne a BIOS-t frissíteni. Akkor van gáz, ha nincs frissebb BIOS, vagy, ha az új sem orvosolja a hibát...

Értékelés: 

0
Még nincs értékelve

Átnéztem a dmesg-et...

#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)

Értékelés: 

0
Még nincs értékelve

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

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

Értékelés: 

0
Még nincs értékelve
kimarite képe

Átnéztem a dmesg-et...

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

Értékelés: 

0
Még nincs értékelve

Átnéztem a dmesg-et...

#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 :-)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Átnéztem a dmesg-et...

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

Értékelés: 

0
Még nincs értékelve
kimarite képe

boot.log

Érdemes a boot.log naplófájlt is nézegetni a lassú betöltés jelentkezésekor.

Nekem feltűnt (Debian), hogy a boot alkalmával a Plymouthról is szó esik, mármint hibaüzenetet látok. Először megnéztem a teljes naplófájlt (boot.log)..., most a grep paranccsal szűkítve a tartalmat (tudom, mit kerestem), mutatom, mi a hiba:

cat /var/log/boot.log | egrep -i Ply | egrep -i 'failed|see'
[FAILED] Failed to start Tell Plymouth To Write Out Runtime Data.
See 'systemctl status plymouth-read-write.service' for details.
[FAILED] Failed to start Show Plymouth Boot Screen.
See 'systemctl status plymouth-start.service' for details.

A Plymouthról ezt lehet tudni (Synaptic > csomag tulajdonságai:

Plymouth provides a boot-time I/O multiplexing framework - the most obvious
use for which is to provide an attractive graphical animation in place of
the text messages that normally get shown during boot. (The messages are
instead redirected to a logfile for later viewing.) However, in event-driven
boot systems Plymouth can also usefully handle user interaction such as
password prompts for encrypted file systems.

This package provides the basic framework, enabling a text-mode animation.

azaz (webes fordítás).

A Plymouth indulási I / O multiplexelési keretet biztosít - ez a legnyilvánvalóbb
amelynek felhasználása vonzó grafikus animációt biztosít a
azokat a szöveges üzeneteket, amelyek általában a rendszerindítás során jelennek meg. (Az üzenetek:
ehelyett egy naplófájlba irányították későbbi megtekintés céljából.) Ugyanakkor eseményvezérelt
rendszerindító rendszerek A Plymouth hatékonyan képes kezelni a felhasználói interakciókat is, például a
jelszókérdések a titkosított fájlrendszerekhez.

Ez a csomag biztosítja az alapvető keretet, lehetővé téve a szöveges módú animációt.

Na most, nekem ez a szolgáltatás biztosan nem kell, mondhatni, azt hittem, ez az „állatfaj” kihalt, azaz nem használja már rég semmilyen Linux. Nem kell csilivili. Tévedtem a használatban. Úgyhogy töröltem. Így is lehet (vagy Synaptic > Teljes eltávolítás):

sudo apt-get purge plymouth

A rendszer újbóli indításakot a szöveges boot üzenetek eltűntek („lehetővé téve a szöveges módú animációt”), ezért a quiet paramétert töröltem a grub fájl szerkesztésével,

sudo nano /etc/default/grub

ebből a sorból (az egyenlőségjel mögött nem üres a sor),

GRUB_CMDLINE_LINUX_DEFAULT=

merthogy a quiet paraméter elrejti a boot üzeneteket (a splash paraméter a képes hátteret biztosítja ... röviden), de azokat én látni szeretném, hiszen az előbbi problémára is itt figyeltem fel.

Összefoglalva: ha lassú a rendszer indulása, és még, ha nem is látod a boot üzeneteket, mert elrejti előled valamilyen „csilivili” betöltési animáció, érdemes belenézni a boot.log naplóba is.

cat /var/log/boot.log

Itt láttam I / O hibára utaló üzenetet is, amely következmény volt (vélhetően), hogy a belépés alkalmával az egér és a billenytűzet nem működött (nem tudtam belépni), de fontos megjegyezni, hogy mindez az unsigned (nem aláírt) rendszermag telepítés után történt ... a unsigned rendszermag egyféle, vagyis a (szinte) egyedüli megoldás, a Virtualbox moduljainak elfogadására a rendszer által (Debian 10 rendszernél). HIba:
https://www.virtualbox.org/ticket/18904#comment:10

dmesg | grep vboxdrv
[   21.932419] vboxdrv: loading out-of-tree module taints kernel.
[   21.934565] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[   21.950579] vboxdrv: Found 2 processor cores
[   21.967022] vboxdrv: TSC mode is Invariant, tentative frequency 2594109811 Hz
[   21.967757] vboxdrv: Successfully loaded version 6.1.2 (interface 0x002d0001)

Lehet, a korábban telepített Plymouth problémával is összefüggött mindez, erre (unsigned rendszermag) ránézek még egyszer. Hozzáteszem, hogy a mokutil alkalmazással kezelni nem lehet a helyzetet, ha a rendszer nem UEFI, csak a rendszermag van aláírva (Debian kulccsal). Íme:

mokutil --test-key MOK.der
EFI variables are not supported on this system

Nézegesd a boot.log naplót ... csak nyersz ezzel. :-)

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

Hű Gyerekek!

Jó sok tudomány jött itt össze.

Mindenek előtt közlöm, a 'Dell Inspiron 1520' 58 mp alatt eljut a kezdő képernyőig. Mifelénk ez jó.

Segített a grub fájl szerkesztése.

Köszönöm Nektek!

A gép stabilan működik.

Így már át merem adni az örökké fiatal 82 éves felhasználónak. 

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot

#43 Nagyon jó. Érdemes lenne ránézni a lemez állapotára is, biztos, ami tuti alapon:
https://linuxmint.hu/blog/2020/01/ha-dos-program-futtatasara-van-szukseg

Értékelés: 

0
Még nincs értékelve
jövevény képe

Lassú boot

#44 OK!

Hétfőig beleférhet. Az átadás első lehetséges időpontja ez.

Remélem, megértem hozzá az itt leírtakat. Nagyon jókat írtok. Pl. ha jól értem, a grub fájlt egyszerűsíteni is lehet, nem csak foltozni.

Megőrzöm az itt leírtakat. Közösségi oldalakon szokták írni: lopom.

Értékelés: 

0
Még nincs értékelve
jövevény képe

Átnéztem a dmesg-et...

#30 T. Istvánnak!

A 'Dell Inspiron 1520' 

eredetileg 2×512MB memóriával rendelkezett. A könnyen hozzáférhető 667MHz-es memóriát cseréltem ki egy 2GB-osra.  Az eredmény egy 2,5GB memória. Az OS figyelő programja szerint szépen ketyegnek. Frissítés közben dolgoztak 100%-on. A CPU szintén. Egyébként győzik a munkát kisebb teljesítményen. Illik egymáshoz a szoftver és a hardver.

Értékelés: 

0
Még nincs értékelve

Lassú boot

#45 A lemez állapotáról azért elég jól tájékoztatást adnak a SMART adatok is.

Kellékek -> Lemezek ->
https://ibb.co/W6f1yDx

https://ibb.co/2g1xYJj

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

Üdv mindenkinek!

Mióta frissítettem a rendszert 19.3-ról 20.1-re, (friss telepítés, nem upgrade) azóta szinte lépésről, lépésre boot-ol a gép, tele hibaüzenettel.

Minek a hibáját jelzik ezek az üzenetek, milyen megoldást igényel, vagy milyen következményekkel járhat, ha figyelmen kívül hagyom?

Előre is köszönök minden választ és megjegyzést.

Mellékelve küldöm a kimeneteket.

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

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

#49 Én ezt látom (aztán mondd te, mi más hibát látsz még!):

[    8.304410] ata1.00: SATA link down (SStatus 0 SControl 300)
[    8.304420] ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    8.327761] ata1.01: failed to IDENTIFY (I/O error, err_mask=0x2)
[    8.327763] ata1.01: revalidation failed (errno=-5)
[   14.192412] ata1.00: SATA link down (SStatus 0 SControl 300)
[   14.192422] ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   19.296366] ata1.01: qc timeout (cmd 0xa1)
[   19.296368] ata1.01: failed to IDENTIFY (I/O error, err_mask=0x4)
[   19.296370] ata1.01: revalidation failed (errno=-5)
[   19.296570] ata1.01: disabled
[   20.080399] ata1.00: SATA link down (SStatus 0 SControl 300)
[   20.080409] ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

Induljunk ki onnan, hogy lépj be a BIOS-ba.
Nézd meg, a chipkészlet beállításánál milyen választási lehetőségek vannak.
Sorold fel ezeket. Továbbá, mondd el, most melyik van beállítva.
Ilyesmiket kéne látnod: Native IDE, RAID, AHCI, Something.

Igen régi gép, itt lehet a csont elásva.
A jelenséget semmiképpen ne hagyd figyelmen kívül.
Az I/O hibák lassítják a rendszer működését.
Az írás, olvasás sebesség csökkenését, pontatlanságát okozhatják.
Igaz, itt azonosítani nem tudja a rendszer a merevlemezt, de ennek is lehet következnénye.

Hasonló probléma (jegyzet): https://forums.gentoo.org/viewtopic-p-5110819.html?sid=ebdc2d5afbebd2308...

Tehát BIOS.
A CPU fiirmware-e telepítve. Igaz, én még nem láttam 2010-es dátummal.
Mindez, a lassú rendszer betöltésnek is oka lehet. Tegyük helyre a hibát, aztán továbblépünk.

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#49 Messziről most két fő probléma látszik, egyik a lemezkezeléssel kapcsolatos, a másik egy USB vezérlővel. A merevlemezt érdemes lenne ellenőrizni, lehet, hogy csak kábel probléma, de az is lehet, hogy újra lesz szükség.

Továbbá ki kell húzni minden USB eszközt, amit lehet, és figyelni a hibákat, egyenként visszadugva.

Az első mindenképpen a merevlemez legyen. Illetve ellenőrizni a hűtést, port kifújni a gépből, stb.

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

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?

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

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

Értékelés: 

0
Még nincs értékelve

Lassú boot

A 20.1 telepítése után nem lett eltávolítva a gépből olyan eszköz amelyik automatikusan csatolódott ?
Bent maradt a bejegyzése az /etc/fstab-ban, és azért lassú a boot mert ezt az eszközt keresi ... keresi ?

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#51

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

Köszönöm a segítséget!

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#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/

 

 

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#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?

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

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

Mindkettőtől.

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?

Gépet lekapcsolni, USB hangkártyát kivenni, indítani: Van hibaüzenet?

-igen= valami gond van az alaplapi hangkártyával, ha a megadta magát jelenségben esetleg zárlatot jelent... BIOS-ban letilatni, indítani: Eltűnt a hibaüzenet?

-nincs= valami gond van az USB-s hangkártyával

Továbbá: Ebből az alaplapból az MSI több változatot is kiadott. Amikor szét volt szedve a kondik szem elé kerültek?
Mifélék? Kis csupasz alu töppedt hengerkék? Vagy magasabb fekete hengerek? Utóbbi esetben nem púpos valamelyik?

+ Kérdés: Konkrétabban mi az alaplap pontos neve? Gyanús hogy a BIOS nagyon elavult.

 

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

#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

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

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

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

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

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#60

A következő lépésben az USB csatlkozókkal próbálkozom.

Nekem is megfordult a fejemben egy párszor, hogy frissíteni kellene a BIOS-t. Viszont többektől hallottam, hogy az egy macerás procedúra, de ha tényleg van értelme, akkor miért ne... Csak valaki mondja meg, hogy hogy lehet kivitelezni és mi benne a macera, mire kell figyelni...

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet -BIOS frissítés

#62 valamikor az őskorban kockázatos volt, olyan tekintetben, hogy ha valami hiba miatt megszakadt a frissítés (elment az áram, hibás szektor a lemezen// jellemzően flopiról történt a frissítés// akkor egy halott alaplap lett a vége, amit nagyon bonyolultan lehetett helyre hozni (BIOS chip csere).

De azóta sokat fejlődött a technika, és gyakorlatilag nincs konkrét kockázat már az újabb alaplapokál (az LGA775 alapok bár bőven ebbe a körbe tartoznak). Ugyan az MSI-t nem ismerem közelebbről, nem nagyon volt dolgom ilyen alaplappal, de az összes amivel találkoztam, mind dual BIOS-osak, azaz van egy árnyékmásolata a BIOS-nak. Ha bármi gebasz van, az árnyék másolatból automatikusan visszaíródik az eredeti BIOS.

Ma már csak olyan macera lehet, hogy a BIOS frissítéhez esetleg windows kell, mert csak windowsos frissítőt biztosít a gyártó, volt dolgom olyan notival, amire fel kellett telepítenem egy Windowst, mert másképpen nem ment, frissíteni a BIOS-t, majd leszedni a windowst, és visszatenni a Linuxot.

Az alaplap pontos típusa kell, meg lehet nézni a kézikönyvében, hogy miként működik a BIOS frissítés (Pl lehet-e BIOS SETUP felületről frissíteni), van-e DUAL BIOS-a, stb....

 

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#61

Ez már kib@szás...

Csak a tápkábel van bedugva, mégis ugyanazt az üzenetet produkálja az usbhid-ra nézve...

Most tényleg ennyire hülye vagyok, vagy létezik ilyen?

Utána persze visszadugtam a perifériákat, hogy tudjak kommunikálni...

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

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

Remélem ezzel már tudok, illetve tudtok segíteni...

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet | Az alapértelmezett 5.4-es kernellel?

#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?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

#64 Csak a tápkábel van bedugva, mégis ugyanazt az üzenetet produkálja az usbhid-ra nézve...

Hm. Igazából nem biztos az ..., mert a régebbi dmesg üzenetét is látod, ha csak ki- és bejelentkezel:
A dmesg parancs kimenetének értelmezhető idő formátumban történő kijelzése

Adtam egy tippet (5.4-es kernel), nézz rá.
A xinput egy gyors ötlet volt, folytatása inkább holnap.

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#62 Csak valaki mondja meg, hogy hogy lehet kivitelezni és mi benne a macera, mire kell figyelni...

Alaplap pontos típusa....

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#59

Igaz, az egér lehet a probléma okozója, átdugtam másik csatlakozóra, újraindítás és ugyanaz a hibaüzenet, csak másik portra hivatkozva.

De nem is érdekel.

A HDD probléma megoldódott, ami tényleg fontos volt, a többi meg le van sajnálva.

Mindenkinek köszönöm a segítséget.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

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

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

#64 Csak a tápkábel van bedugva, mégis ugyanazt az üzenetet produkálja az usbhid-ra nézve...

Ez tényleg így van? Nézted az időbélyegeket?
Nézd meg az utolsót, és ha újabb van, akkor az tényleg új üzenet.

#68 Igaz, az egér lehet a probléma okozója, átdugtam másik csatlakozóra, újraindítás és ugyanaz a hibaüzenet, csak másik portra hivatkozva.

Vélhetően már a gyerekkora is rossz volt az egérnek... ;)
Lehet, egy újabb kernellel jól működik. Kipróbálnám a legújabb stabil kernelt. Vagy az 5.4-est, amit korában javasoltam. Vagy többet is.

#62 Nekem is megfordult a fejemben egy párszor, hogy frissíteni kellene a BIOS-t.

Érdemes frissíteni, ha elérhető újabb. A BIOS árnyékmásolatról nem hallottam, csak itt. Utána olvasok majd. Fene tudja, én olyan szervízbe, szakemberhez vinném, ahol garantálják a felelősséget. FreeDOS alól nekem egyszer majdnem sikerült a BIOS frissítés, szóval, én még nem próbáltam. Az igazság az, a frissítések sokszor semmi újat nem nyújtanak, és a gyártó nem örök életre adja. A BIOS eszközvezérlés kiváltását a Linux kernel a CPU firmare-ekkel próbálja kiváltani (microcode), ami a nagyon régi gépek csak önmagukkal kompatibilis BIOS-a miatt necces, de általában sikeres szokott lenni.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

#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)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

#71 A lassú boot is megjavult, ugye, jól érzem? :)
Jó hangulatú, felfedezésekben gazdag Linuxozást neked!

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#70 A BIOS árnyékmásolatról nem hallottam, csak itt.

Ezt anno a Gygabyte alaplap gyártó találta ki, már egyes PIII alaplapjainál is megjelent, de a PIV-nél lett általános.
itt egy korabeli cikk, amelyik fogalkozik vele, olyant most nem találtam, ami az első alkamaszás bejelentésről szól:

https://logout.hu/cikk/a_gigabyte_dualbios_rejtelmei/bevezeto.html

A cikk érdekes problémákat is felvet, bár jelesül nekem személyes tapasztalataim vannak a dologgal, és többször volt, hogy jól működött. Igaz, jóval később voltak ezek az esetek a cikk írásához képest. Mert később ezt mások is átvették, lassan alapértlemezett lett mindenkinél (Gondolom. Ebből a korból (LGA775, C2duo proci) Asus, Intel, stb. alaplapokkal volt főleg dolgom és ezeknél már általános volt a DUAL BIOS, de megvallom őszintén, az MSI valahogy elkerült.  Ha az alaplap pontos neve kiderülne végre, akkor a kézikönyvéből ezt meg lehetne tudni, hogy mi a helyzet. Sajnos azzal a típus számmal, ami a DMESG-ben látható az MSI kb. tucat alaplapot gyártott, eltérő chipkészletekkel, és körítéssel)

A PIII idejében volt egy hasonló kezdeményezése az Advance alaplap gyártónak (az ő termékeit nem forgalamazták soha Magyarországon), az afféle dual rendszert tudott kezelni BIOS-ból, ami konkréten a HDD megfelezését jelenti, az első partición van az éles rendszer, a másodikon ami rejtett, annak a másolata. Ezt sehol nem lehetett látni, annyira el volt zárva, de BIOS-ból vissza lehetett klónozni az első particióra az egészet. Mindig induláskor frissítette a második rendszert, ill, be lehetett állítani az időzítést, ha jól emlékszem. Akkoriban a tárhely drága volt, annak a magfelezése igen fájó is volt, meg a frissítés is időt igényelt, így ez nekem sem jött be, és úgy látom, ki is halt ez a találmány.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

#73 Érdekes. Konkrétan az EPROM jut az eszembe a BIOS frissítése kapcsán (taxameter gyártókkal, forgalmazókkal álltam kapcsolatban az első munkahelyemen). :)
https://hu.wikipedia.org/wiki/EPROM
Persze, ez is elmozdulhat, ami további hiba lehetőség. Viszont újraírható külső eszközzel is ... könnyedén.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Lassú boot + hibaüzenet

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

Értékelés: 

0
Még nincs értékelve

Lassú boot + hibaüzenet

#73 sudo dmidecode
Parancs kimenetének az elején kapunk információkat a BIOS-ról.

Értékelés: 

0
Még nincs értékelve