-
Fototrend
Ubuntu Linux Összefoglaló
Hivatalos Ubuntu dokumentáció
Amennyiben kérdésed lenne, kérünk, add meg a szükséges adatokat a hiba minél pontosabb leírása mellett:
-számítógép típusa, hardverek pontos megnevezése (különösképp videókártya, vagy hálózati egységek)
-a használt rendszer pontos neve, verziója, a grafikus felület
-mikor és hogyan jelentkezett hiba, mi váltotta ki (program telepítés, frissítés, ...)
-eddigi próbálkozások a megoldásra (ha voltak ilyenek)
A hardverinformációkat legegyszerűbben úgy gyűjtheted össze, ha megnyitod a Terminál nevű programot a menüben. Ide írd be a következő parancsokat (mindkettő után nyomj Enter-t):
lspci
lsusb
Új hozzászólás Aktív témák
-
Mtbsrác
senior tag
Üdv!
Mint-es csopiban is feltettem a kérdést de az a topic eléggé kihalt így ide is másolnám:- Mit jelenthetez a hiba? Van többször hogy ezt kiírja majd lefagy, utána meg elindul ha olyanja van. Kernelt is cserélek ha elindul akkor általában elsőre okés elindul ahogy kell, majd kövi indításnál ismét lefagy itt. Hw-k ki/be a gépbe kábelcserék megvoltak a hibajelenség továbbra is fenntáll.
SSD: Kingston A400 4 éves, 11Tb össz írással! 100/79 állással.
Megj.:
Azóta "talán" annyival lettem okosabb hogy lehet az ssd-m kezd el meghalni és az okozhatja a gondot talán. Külföldi topicban láttam pár utalást rá. Ill vettem egy új vincsit is felraktam rá biztonság kedvéért.Újraindítottam ment is míg vissza nem dugtam az SSD-t. Onnantól fogva az is kifagyott indulásnál igaz ott hibát nem mutatja.Amúgy a smartcontrol egy vödör ilyen hibát dobott ki rá:
[ Szerkesztve ]
-
#40853
UberMutant
őstag
Mtbsrác
#40851
UberMutant
őstag
válasz
Mtbsrác
#40851
üzenetére
az SSD topikban meglátják ezt a típust (a400) és rögtön irányítanak a pénztárhoz, hogy vegyél másikat. a vezérlője annyira vacak, hogy bármikor felmondja a szolgálatot. vszeg te is így jártál.
https://prohardver.hu/tema/flash_ssd_osszefoglalo_az_1_hsz-ben/hsz_1-50.html
Kifejezetten nem ajánlott típusok, melyek nem megbízhatóak, vagy nem hozzák a specifikációk szerinti értéket:
Kingston: V100,V200, V300, A400
Ha meg vásárláshoz kérsz majd tanácsot itt a másik topik
https://prohardver.hu/tema/milyen_ssd-t_vegyek_2/hsz_1-50.html -
-
válasz
Mtbsrác
#40851
üzenetére
Sajna ahogy páran említették, az a A400 a legelvetemültebb SSD modell, ehhez nem is kell külföldi fórumokat olvasni, elég a linkelt itteni SSD szaktopikok keresőjébe beírni az A400 varázsszót!
Ennek a modellnek alapból gáz a vezérlője, amiben ez a tipus van, mind megbízhatatlan! Ami nálad van, kb bármely pillanatban megadhatja magát. 4 évet ment eddig, szóval kb szerencsés vagy/voltál vele.mennyé' be az ólajtón és ne gyere ki
-
Mtbsrác
senior tag
Köszönöm a válaszotokat!
Ma veszek egy másikat, ha véletlen nincs akkor még egy pár napig menjen még el. Kábel csere ilyesmin már rég túlvagyok. Viszont én úgy olvastam hogy az A400-on már módosítottak a vezérlőjén, direkt emiatt, s vmi UV sorozat volt a rossz belőle. Mellesleg van egy King Dian nevü kínai (Aliex) csodám benne, az is kb ugyanennyit futott vmivel kevesebb írással egy másik gépben annak semmi baja
. -
válasz
Mtbsrác
#40856
üzenetére
UV400 meg az A400 nem ugyanaz, itt a comparison, ha érdekel. Pár napot/hetet még talán ki fog bírni, annyira nem durva a smart hibajegyzéke, de sajna a vezérlőt ez annyira nem is érdekli, egyszer csak putty és vége.
Ezek a kínai SSD-k is sok esetben egész jól elvannak, gyakorlatilag a piacról összevásárolják a legolcsóbb komponenseket és összerakják, aztán működnek.
[ Szerkesztve ]
mennyé' be az ólajtón és ne gyere ki
-
-
válasz
gregory91
#40860
üzenetére
GRUB-on simán túljut, mivel az SSD elkülönített boot része mondjuk hibátlan...nem meghalt még a vezérlő, max haldoklik, szóval....
Ezek a
driver probe devicemeg? device driver attachsorok a képen simán utalhatnak meghajtóhibára is, legalábbis tippre. Szóval a kernel próbálkozna, mint malac a jégen, de valami eszköz illesztése nem valósul meg. Laikus szemmel legalábbis ezt látom.
Te mit látsz a kernel logban?mennyé' be az ólajtón és ne gyere ki
-
afi0903
aktív tag
Sziasztok!
Egy samba megosztást szeretnék elérni minden rendszer indításkor.
Az fstabba így írtam be://<ip>/<megosztás név> <felcsatolás mappa> cifs username=<felhasználónév>,password=<jelszó>,uid=1000,gid=1000,iocharset=utf8 0 0
Amikor bekapcsolom a gépet nem csatlakozik hozzá. A megadott mappa jobb felső sarkában egy lakat van és a mappa üres.sudo mount -aparanccsal felcsatlakozik.
Ezt hogyan tudnám megoldani? -
válasz
afi0903
#40862
üzenetére
Én parasztabbul oldottam meg
, simán az rc.local-ban van a virtuálhoston egy ilyen :
root@a8host:~# cat /etc/rc.local
#!/bin/bash
ping -i2 -c2 192.168.1.238 && mount -t cifs -o username=user,password=jelszo //192.168.1.238/cuccokz/ISO /remoteisoTehát ha pingelhető az az IP, akkor felmountolja.
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
#40864
lionhearted
őstag
afi0903
#40862
-
#40868
RoryBreaker
aktív tag
RoryBreaker
aktív tag
Sziasztok!
Egy kis segítség kellene:
Van egy VMware virtuális gépen egy 20.04 LTS ubi, ami fut, most lett telepítve.
Putty-olni szeretnénk SSH-val rá, ami a szerver újraindítása után kb. 15-20 percig működik is, utána viszont néha igen, néha nem, de inkább nem.
Én a VMware -ből közvetlenül belépek gond nélkül.
Viszont a Putty nál, ha visszanézem a log-ot, akkor ez van:
"Password authentication failed"
"Remote side unexpectedly closed network connection"
Tudjátok, mi lehet a probléma?
Köszi előre is!Rog Strix B-760i Gaming Wifi, 32 GB DDR5@6000, i5-13500, Asus RTX 4060 OC Dual, 1TB Samsung 980 Pro, Be Quiet Pure Power 1000W Gold 80+, Noctua NH-12UA + Noctua házventik, Asus AP201 Mesh ház
-
#40869
hcl
félisten
RoryBreaker
#40868
válasz
RoryBreaker
#40868
üzenetére
A Vmware-ből persze, hogy be tudsz menni, mert az olyan konzol, mintha a gép előtt ülnél.
A Vmware -ra magára (ha engedélyezed az ESXi shellt) is be tudsz SSH-zni. As is leszakad?
""Password authentication failed"
"Remote side unexpectedly closed network connection""
Ez melyik oldalon van?
Vmware tools fent van az Ubin?Mutogatni való hater díszpinty
-
#40870
afi0903
aktív tag
lionhearted
#40864
afi0903
aktív tag
válasz
lionhearted
#40864
üzenetére
Jelenleg időnként működik, időnként nem. Ha nem, akkor "mount.cifs: permission denied"-ot ír, amikor a könyvjelzők közül meg akarom nyitni.
Mi lehet erre a megoldás? -
#40871
RoryBreaker
aktív tag
hcl
#40869
RoryBreaker
aktív tag
Szia!
Csak egy Virtual machine manager van fent, semmi más.
Most frissítettem 22.04.1 LTS-re, mert nem tudtam mit tenni.
A helyzet változatlan.ESXi shellt engedélyezem, már ha tudom, utánanézek.
(Az a baj nem nagyon értek linuxhoz, de más sem jelenleg, aki itt van. Ezt a szervert el kell érnie pár embernek. Más dolgom nekem nem lenne vele.)
Köszi a segítséget!
Rog Strix B-760i Gaming Wifi, 32 GB DDR5@6000, i5-13500, Asus RTX 4060 OC Dual, 1TB Samsung 980 Pro, Be Quiet Pure Power 1000W Gold 80+, Noctua NH-12UA + Noctua házventik, Asus AP201 Mesh ház
-
PociAti
őstag
Sziasztok!
Pár hónapja a PHP 7-ről 8-ra frissítés közben valami az Apache környékén összekuszálódott.
Volt ami idővel (frissítéseket követően) magától rendbe jött, van a mit piszkálni kellett, de egy dologgal nem sikerült zöld ágra vergődni. Hátha tud rá valaki megoldást, vagy hol kéne keresni a hiba okát.Amikor a localhoston belül (var/www/html) létrehozok egy html vagy php állományt, és azon belül adom meg a css-t, akkor nem tölti be, nem dolgozza fel a mellette lévő CSS fájlt.
<link rel="stylesheet" type="text/css" href="style.css">De ha ugyanezt a html/php + hozzá tartozó css-t kimásolom más könyvtárba (pl. Dokumentumok közé), és onnan nyitom meg, akkor minden rendben van.
Hogy még érthetőbb legyen:
ha a CSS csak annyit tartalmaz, hogy a body háttere legyen sárga,
akkor a /var/www/html/ belül nem lesz sárga, de ha átmásolom máshová a html+css állományt (pl. a home könyvtáramba), akkor sárga lesz a háttér.64 bit Xubuntu, kernel: 5.15.0-56-generic,
ii libapache2-mod-php 2:8.1+92+ubuntu22.04.1+deb.sury.org+1
ii libapache2-mod-php7.4 1:7.4.33-1+ubuntu22.04.1+deb.sury.org+1
ii libapache2-mod-php8.1 8.1.13-1+ubuntu22.04.1+deb.sury.org+1[ Szerkesztve ]
-
PociAti
őstag
Leellenőriztem és rendben vannak a jogok, 777-vel se tölti be a css-t. (Az is mindegy, hogy a felhasználó vagy www-data a tulajdonosa az állománynak, ugyanaz az eredmény).
Sőt, a php 8-ra váltás előtt rendben működött. (Akkor sok minden lecserélődött.)
Bár arra se mernék biztosan megesküdni, hogy pont a php 8-ra váltás okozta a problémát, mert az az időszak nagyon zsúfolt volt, másik SSD-ken több rendszert is kipróbáltam, nem mindegyik ment zökkenőmentesen, bőven volt mivel küzdeni. -
PociAti
őstag
Néztem, nem találtam semmi különöset.
Ami érdekes volt, hogy phpinfo() ezt adta:
Configuration File (php.ini) Path /etc/php/8.1/fpm
Loaded Configuration File /etc/php/8.1/fpm/php.ini
Scan this dir for additional .ini files /etc/php/8.1/fpm/conf.dMiközben a php -v
PHP 7.4.33 (cli) (built: Nov 8 2022 11:33:53) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.33, Copyright (c), by Zend TechnologiesAzt most rendbe tettem, sudo update-alternatives --config php
Kiválasztottam a 8.1-et, a gépet is újraindítottam, már a php -v-re is 8.1-et ír, de a hiba továbbra is fennáll.(Holnap folytatom a nyomozást.)
-
bugizozi
őstag
Sziasztok!
KeePassXC browser integrációt szeretném beállítani Firefox-szal KDE Neon22:04 alatt, de nem sikerül
Ezt írja:
Cannot connect to KeePassXC. Check that browser integration is enabled in KeePassXC settings.
Key exchange was not successful.Minden friss, mai telepítés (KeePassXC 2.7.4, Firefox 108.0) ugyanez működött Linux Mint (20.04) alatt. Úgy láttam más is belefutott már: [link] [link] Akármit próbáltam, egyelőre nem sikerült működésre bírni
Köszönöm a segítséget!
VCP7-DCV, CCNA ||| Ami működik, ahhoz nem szabad hozzányúlni!
-
PociAti
őstag
Megint végig bogarásztam a logot, semmi arra utaló dolgot nem találtam.
Aztán egyenként elkezdtem kitörölni a header részből a sorokat, minimálisra csökkenteni a hiba okát, de az sem vezetett végeredményre.
Nem ragozom tovább, a kiindulási HTML így szokott kezdődni nálam:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
...
Ha a legelső sort, a dokumentum típusának deklarálását kitörlöm, akkor tökéletes. Visszarakom, akkor elromlik (nem tölti be a css-t). Biztos valamelyik konfig fájl csesződött el valamikor, majd ha lesz kedvem megkeresem, de mostantól nincs jelentősége.Köszi a segítséget!
-
-
Formaster
addikt
Csináltam egy 3 lemezes softRAID5 tömböt. A neten fellelhető kalkulátorokkal úgy számoltam, hogy 3 lemez esetén kb 50%, de akár 2x olvasási sebesség is elérhető. Legnagyobb meglepetésemre még a lemez specifikus értékeket is csak alulról karcolja (nagy fájllal tesztelve)
Végig vittem ezt a tutort a sebesség növelésére. Van más, amit érdemes lehet?
Alternatívaként megfontolandó venni még egy lemezt és inkább RAID10-ben gondolkodni?
[ Szerkesztve ]
-
Formaster
addikt
-
inf3rno
nagyúr
válasz
Formaster
#40883
üzenetére
Nekem eddig, ami sebességben a legtöbbet számította az a buffer méret, olyan tizedére húzta le a sebességet a túl alacsony buffer méret. Igaz az nem RAID volt. ECC memória nélkül nem nagyon állnék neki szoftveres RAID-nek, ha meg nekiállnék, akkor BTRFS vagy ZFS lenne.
Buliban hasznos! =]
-
válasz
Formaster
#40887
üzenetére
Nem tudom, szerintem nem egészen korrekt az oldal. Write speed-re azt írja, hogy nincs változás.
Ez vmi elméleti matekolós oldal.
Mostanában már nem szerverezek, de ha a raid5 data-nak volt használva (tehát az OS nem arról futott) akkor sem értük el a 2x sebesség növekedést. Viszont írásban is volt rendesen sebesség növekedés.És ahogy előttem is írták a cache amivel lehetett durván növelni a sebességet. (raid kártyán a Read Ahead feature-rel tudtam még látványos növekedést elérni, de csak olvasásban és nagy file-oknál)
A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
válasz
Formaster
#40884
üzenetére
Engem is érdekelne. A virtuálhostomban tükrözve van két lemez, és az írás elég ergya.
(@Inferno, nincs benne ECC RAM, maradhat ? )
Ezeket találtam, de csak a resync-re hat elvileg.[ Szerkesztve ]
Mutogatni való hater díszpinty
-
inf3rno
nagyúr
-
válasz
inf3rno
#40893
üzenetére
Persze, van ilyen, de általában az van, hogy ha hibás a RAM-od, akkor vagy csontra fagy a gép, vagy kernelpánikol. Ez még azoknál a szemét hibáknál is kijön, amikor Memtest-tel több körön át is jó a memória, csak mondjuk fél nap után dob egy-egy hibát
De az átlag az, hogy ha meghal egy bitnyi kondi valahol a DRAM-ban, akkor indítasz egy Memtest-et, és az első körben f0ssa a piros sorokat.Mutogatni való hater díszpinty
-
inf3rno
nagyúr
válasz
Formaster
#40896
üzenetére
A ZFS és BTRFS azért jobbak egy sima EXT4-nél, mert block checksum van rajtuk, amit ellenőriznek olvasásnál, és ha RAID-be teszed őket, akkor automatikusan javítják a sérült adatot, ha van redundancia. Volt régebben ilyen városi legenda, hogy a hibás memória miatt ez az ellenőrző mechanizmus felülírhatja a jó adatot is hibással, mert a checksumja nem jön ki. [link] Úgy tűnik nem volt igaz. Viszont az ECC így is erősen ajánlott, ha fontos az adatod integritása. A többi RAID megoldásnál úgy tudom nincs ilyen checksum, és ott vagy vége a világnak, ha az egyik példány sérült az adatból és felhasználói beavatkozás kell, vagy simán felülírhatja a hibással a jót. Legalábbis olvastam erről is régebben. Van még azt hiszem olyan funkció ezekben, hogy tömöríteni lehet az adatot, aztán ott még jobban be tud kavarni a hibás memória. De már olyan 5 éve olvastam ezekről, amikor összeraktam itthonra a szerverem. Azóta sem használtam. Kiderült, hogy nincs időm erre, meg egyelőre megúsztam a hibás SSD-ket. El is adom a cuccot nem sokára, aztán maradok egy sima EXT4-nél meg sűrű backupnál.
[ Szerkesztve ]
Buliban hasznos! =]
-
-
inf3rno
nagyúr
Elvileg régen nem volt gyakori, manapság egyre gyakoribb, mert nagyobbak a modulok és érzékenyebbek. Fogalmam sincs a statisztikáról, talán napi 1-2 bit lehet. Azt hiszem annak idején a row hammer volt, ami végleg meggyőzött, hogy nekem ECC kell. [link]
Buliban hasznos! =]
-
Formaster
addikt
Ennek a modellnek alapból gáz a vezérlője, amiben ez a tipus van, mind megbízhatatlan! Ami nálad van, kb bármely pillanatban megadhatja magát. 4 évet ment eddig, szóval kb szerencsés vagy/voltál vele.
.
Te mit látsz a kernel logban?
, simán az rc.local-ban van a virtuálhoston egy ilyen : 
Pedig tegnap is többször újraindítottam.![;]](http://cdn.rios.hu/dl/s/v1.gif)
(@Inferno, nincs benne ECC RAM, maradhat ? 
Új hozzászólás Aktív témák
A topik célja: Segítségnyújtás az Ubuntut és variánsait használók és az ezekkel még csak ismerkedők számára
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Bemutató Linux a mindennapokban
- Bemutató Ubuntu 16.04 LTS kezdőknek, gyakorlatiasan, objektíven
- Hír Megjelent az Ubuntu 16.04 LTS
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: HC Pointer Kft.
Város: Pécs