-
Fototrend
Arch Linux topik
Új hozzászólás Aktív témák
-
vinibali
őstag
válasz eddie1978 #5150 üzenetére
nekem amikor néha frissen lehúzott disk-re vár, meg tud akadni pár másodpercre, de aztán minden megy tovább. érdemes lenne a kernel messages esetleg a journalctl-t nézegetni, amikor ez történik.
dmesg -wH
journalctl --follow
ha tényleg szögre befagy, esetleg másik gépről ssh-t próbálni. nekem mostanában a chrome szokott úgy befagyni, hogy visz magával mindent. legutóbb ssh-val tudtam belépni és megölni a process-t.
esetleg érdemes lehet még asysrq_always_enabled
paraméret beírni a boot-hoz, és ha minden kötél szakad így reboot-ot csinálni.BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/
-
májkimiki
őstag
Üdv. Mindenkinek!
Két kérdésem lenne.
1: Arch Linux esetén az SSD trimmelés a systemd időzítőjének a feladata default? ( Vagy lehet cron.weekley-ben intézni, mint Ubuntun).
2: Találtam egy számomra igen tetszetős Plasma5-t használó disztrót ( Bluestar). Az Octopi-t lecserélhetem-e Pamac-re, gond és galiba nélkűl? -
csixy
addikt
válasz májkimiki #5153 üzenetére
Maradhat mind a kettő . Az octopi úgy néz ki mint a synaptic , a pamac meg mint a szoftverközpont. A lényeg hogyha ajánlgatják, hogy frissíteni kell ,akkor mind a kettőt lődd ki és konzolba : sudo pacman -Syu és enter.
Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.
-
BoB
Topikgazda
válasz májkimiki #5153 üzenetére
Arch linux-on neked kell beállítani a trim-et, választhatsz a discard és az fstrim között de alapból egyik sincs beállítva.
Ha azt a származék disztrót teszed fel abbam viszont már lehet hogy az egyik engedélyezve van, meg kell nézni.
You may corrupt the souls of men, but I am steel. I am doom.
-
ubyegon2
nagyúr
-
Frawly
veterán
válasz májkimiki #5155 üzenetére
850-es Samuk a kernelben trim-tiltólistán vannak, így mountoláskor a discard paramétert NEM szabad használni. Helyette engedélyezd a fstrim systemd service-t:
sudo systemctl enable fstrim.timer
sudo systemctl enable fstrim.serviceEsetleg ha nem akarsz ezzel bajlódni, akkor az is elég, ha néha napján terminálban lefuttatod a sudo fstrim -a -v parancsot. Attól függ ennek az alkalmazási gyakorisága, hogy mennyire van tele a meghajtó, meg mennyire sűrűn törölgetsz róla. Végül is a systemd service is ezt a parancsot hívja meg előre beállított rendszerességgel.
Hosszú távú tapasztalatom alapján az fstrim-es megoldás amúgy is hatékonyabb TRIM, mint a discard-os. A discardot csak akkor erőltetném, ha nem Samu-ról lenne szó, és mondjuk FAT32-es fájlrendszeren akarsz TRIM-elni, mert azt pl. az fstrim még nem tudja. Nálam egymás mellett megy a kettő Crucial MX300 SSD-ken, azok nincsenek a kernelben tiltólistán sem.
-
ubyegon2
nagyúr
Volt valami gyanúm, mikor láttam, hogy Samuról van szó, ezek szerint benne lenne e 850-es a blacklist-ban?
Szerintem gyakorlatiasabb heti cron-ba tenni a fstrim-et, mert az ember úgyis elfelejti előbb-utóbb lefuttatni manuálisan.
Hosszú távú tapasztalatom alapján az fstrim-es megoldás amúgy is hatékonyabb TRIM, mint a discard-os.
Hogy mi van? Te látóasszony vagy esetleg más különleges képességed volna? Rögvest kieszem az SSD-t ebből a halott laptopból, ha ezt élő ember meg tudja állapítani, hatékonyabb a ló*szt, ha mégis, az csak véletlen és ezt gondolod, de ez a tapasztalat dolog még nekem is erős volt, pedig szoktam nagyokat mondani néha.
KDE plasma6-ost már fogod használni?
Mondjuk ki nyíltan, hogy az online trim, amit a vezérlő irányít az oprendszer utasításainak megfelelően, jóval hatékonyabb, mint egy adott időben végrehajtásra kerülő kényszerített trim.
[ Szerkesztve ]
-
BoB
Topikgazda
"850-es Samuk a kernelben trim-tiltólistán vannak, így mountoláskor a discard paramétert NEM szabad használni. "
A discard és az fstrim ugyanazt csinálja. Az a különbség hogy előbbi esetén a trim azonnal végrehajtódik, míg utóbbinál időnként van lefuttatva. Ez miért volt probléma? Azért mert a trim a SATA 3.1-es szabványig csak és kizárólag unqueued volt, ami azt jeletni hogy azonnal végre kellett hajtani és amíg az végbement minden más I/O blokkolva volt. Ezért sok fájl törlése esetén teljesítmény vesztés volt. Ez kiküszöbölhető volt a néha futtatott trim-el. Ez az fstrim.
Ez miatt bejött a queued trim (amit egyébként a samsung egyes SSD-ihez firmware frissítéssel juttatott el). Setjhető, itt a trim már úgy fut hogy közben nem blokkolj a meghajtót. Ez a Native Command Queueing (NCQ) ATA protokoll kiterjesztéssel működik. Arról van szó tömören, hogy az OS küldözgeti az ATA parancsokat, de a meghajtó dönti el azokat milyen sorrendben hajtja végre.
NCQ-t akkor használ a kernel, ha a meghajtó azt mondja neki hogy ismeri. A probléma az volt egyes samsung meghajtók esetén, hogy azt mondta tudja közben a valóságban meg nem tudta. Jött a discard/fstrim (tökmindegy), és azzal a hibák. A discard-nál azonnal mert azzal már nem is bootolt a gép, míg ugye fstrim nem folyamatosan megy így nem volt olyan feltűnő. Azonban ha kiadtad konzolban, jött a hiba ugyanúgy.
Ezért volt hirtelen megoldás ha ilyenkor kiszedték a discard-ot az fstab-ból.
https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005
Jelenleg a 4.16-os kernelben bizonyos SSD-k esetén a queued trim van tiltva. Ettől még "hagyományosan", azaz i/o blokkoló módon továbbra is működik a trim, tökmindegy hogy discard vagy fstrim-el:
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Micron_M5[15]0_*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M550*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 840*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 850*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "FCCT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },https://github.com/torvalds/linux/blob/v4.16/drivers/ata/libata-core.c#L4552
Egyetlen SSD van, aminél teljesen le van tiltva:
/* devices that don't properly handle TRIM commands */
{ "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, },Nem tudom ez mennyire volt érthető, de összefoglalva:
Sasmung akármilyen SSD-nél is lehet discard-ot használni, nincs tiltva. Más kérdés hogy ugyanúgy mint eddig, ez mennyire preferált.[ Szerkesztve ]
You may corrupt the souls of men, but I am steel. I am doom.
-
ubyegon2
nagyúr
válasz májkimiki #5161 üzenetére
Nézed végig a cron mappákat, ami benne van az lefut értelemszerűen a mappa nevének megfelelően. (nincs most Arch-om, de gondolom ugyanott vannak a cron mappák) sajna nekem csak ilyen nem túl szakszerű módszer jut eszembe
Példa
status lekérdezése
systemctl status fstrim.service[ Szerkesztve ]
-
Frawly
veterán
Valóban pontatlanul fejeztem ki magam. Samu 8XX sorozaton is megy a discard TRIM, de mivel a kernel nem alkalmaz queue-t, azért azonnal végrehajtódik, ami teljesítményproblémákhoz vezethet. Ezért nem érdemes használni. Viszont abban igazad lehet, hogy ettől még lehet használni, és érdemes is lehet olyankor, ha pl. FAT32-es partíciót akarsz TRIM-elni, azt jelenleg az fstrim még nem támogatja.
Az fstrim-ről meg azért gondolom, hogy hatékonyabb, mint a discard TRIM, mert hiába discardol a kernel, lefuttatva az fstrim-et hosszabban végigtrimeli a partíciókat, azaz talál még trimelni valót. Használom mindkettőt MX300-as SSD-n, az nincs a kernelben sem queued TRIM-es tiltólistán.
Júbájgön: a systemd-s fstrim-szolgáltatás használata könnyebb és felhasználó/kezdőbarátabb, mint cron-ba belebarmolni, ami vagy fog menni, vagy nem.
[ Szerkesztve ]
-
vargalex
félisten
Arról nem is beszélve, hogy alapból nincs is semmilyen cron implementáció telepítve.
Alex
-
ubyegon2
nagyúr
válasz vargalex #5165 üzenetére
A Bluestar-ban vagy a pure Arch-ban? A kérdező előbbit használja.
(#5164) Frawly
Szerintem egyformán nem kezdőbarát.
cron-ba belebarmolni, ami vagy fog menni, vagy nem.
Vagy fog menni.....öööö ezt nem értem, arra gondolsz, hogy ha ki van kapcsolva a gép, nem fut le a heti cron?
[ Szerkesztve ]
-
BoB
Topikgazda
Aki frissít:
https://www.archlinux.org/news/glibc-227-2-and-pam-130-2-may-require-manual-intervention/
You may corrupt the souls of men, but I am steel. I am doom.
-
májkimiki
őstag
válasz ubyegon2 #5166 üzenetére
Systemd státusz:
[kikcsillag@kikcsillag-pc ~]$ sudo systemctl status fstrim.service
● fstrim.service - Discard unused blocks
Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled)
Active: inactive (dead)
[kikcsillag@kikcsillag-pc ~]$A cron.weekley üres volt. Az fstab-ban a root partíció "noatime" és "discard" opcióval volt csatolva. Ezeket töröltem. A cron.weekley-be tettem a trimmelést.
#!/bin/sh
# Trimmelés naplózással
LOG=/home/kikcsillag/TrimmLog/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOGA systemd részben nem voltam biztos, azt viszont nem szerettem volna, hogy anélkül teszem a cron.weekley-be, hogy ne bizonyosodjak meg a trimmelés állapotáról.
Hálás köszönet a sok hasznos infóért mindenkinek.
[ Szerkesztve ]
-
Frawly
veterán
válasz ubyegon2 #5166 üzenetére
Azért mert a cron-ba a haladóbbak is néha beleszerkesztenek, aztán csak csodálkoznak, hogy valami jogosultsága vagy egyéb hiba miatt nem fut le a cucc, vagy nem normálisan, vagy nem akkor, mikor kéne neki. Az fstrim system service-t meg bekapcsolod, és megy, mindenféle kínlódás meg paraméterezés nélkül, egyszerűen nem lehet elrontani.
-
májkimiki
őstag
Volna még egy kis gondom. A grafikus felületű tűzfal beállítások nem mennek. A gufw bekéri a jelszót, de el sem indul. A KDE-s tűzfal app elindul, de csak várakozik ezzel az üzenettel: kapcsolódás a Firewall ID-hez. Csak kilépni tudok. A tűzfal megy és aktív.
[kikcsillag@kikcsillag-pc ~]$ sudo ufw enable
Firewall is active and enabled on system startup
[kikcsillag@kikcsillag-pc ~]$A Wireshark-hoz létezik-e magyar fordítás?
[ Szerkesztve ]
-
félisten
Sziasztok!
Van egy munkahelyi gep, amin egy SSD-n van a rendszer.
A kerdes, hogy mi a modja annak, hogy egy esetleges SSD hiba utan egy uj SSD-re a leheto legegyszerubben vissza tudjam rakni a rendszert?
Mondjuk hetente mentenek.Maga a rendszer meg nincs felinstallalva, csak ezutan tervezem feltenni.
A masik kerdes, hogy van-e arra lehetoseg, hogy EFI boot eseten ne kelljen kulon /efi particiot letrehozni, hanem ez is a root-on legyen?
Kossz!
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
Frawly
veterán
Lehet lemezképet klónozni, de akár tar-ral is át lehet vinni az új rendszert. Vagy rsynccel. Vagy CloneZillával. Sokféle módja van. Én legutóbb tar-ral csináltam:
cd /
tar -cvpzf --one-file-system /cel/backup.tar.gzKicsomagolni ezzel csomagoltam ki, ha jól emlékszek:
tar -xf backup.tar.gz -C /Ha Tar-ral vagy rsync-kel csinálod, akkor viszont partíció UUID-t módosítani kell a bootmanagerben, /etc/fstab-ban.
EUFI boot elvileg lehetséges EFI partíció nélkül is, de nem tudom hogyan. Kék luficet kolléga (colomb2) szokta propagálni, de nem értettem hogy működik, mert én elvi szinten sem tartom lehetségesnek. Valahogy ő mégis használ ilyen megoldást Gentoo alatt.
[ Szerkesztve ]
-
Frawly
veterán
Akkor lehet Gyurmafigura volt, aki használja EFI partíció nélkül az UEFI bootot. Lehet azzal keverem, hogy te meg egész lemezes szoftveres titkosítást használsz titkosítatlan bootpartíció nélkül, az is olyan eset, amit nem sikerült megértenem.
Az Archra most haragszok. Újrahúztam bugok miatt, ugyanolyan bugos maradt, mint volt. Problémázik az Intel Modesetting driver és a NetworkManagerben lehal a Wi-Fi. Ez utóbbi problémát meg tudom kerülni, letiltottam a NetworkManagert, és bootkor automatikusan netctl-lel aktiválom a wifi-menu-ben wpa_supplicant-tal aktivált kapcsolatot.
Lehet lesz megoldás a Modesetting driverre is, az SDDM-et is átállítom Waylandre, nem csak a KDE Plasma5-öt. Így talán megszűnik ez a bug is.
Viszont a KDE továbbra is bugos, bezárok egy-két futó programot, Rendszerbeállítások, Konsole, erre jelenti a bugjelentő, hogy az alkalmazás összeomlott segfaulttal. De hiszen én zártam be. Meg a kernel is írogat hibákat leállításnál.
-
-
csixy
addikt
Tudnék javaslatot adni az Antergos telepítő alkotóinak a saját és szülő mamijuk közös nemi életének célzott tevékenységére! Kb 5x toltam fel az Antergost windows után , hogy tolja be a bootját dualra a winnyózos Efi partícióba a kis 2011-ben gyártott Dell Wise UEFI-s 4 Giga RAM-osra bővített keskeny kliensemre , de nem tette , hogy b@.x. ... . ..... .n..t! Ezek után toltam egy manjaro kde telepítőt és problémamentesen beintegrálta magát a felügyeletem mellett a kis flexxel befaragatt SSD-mre. Nnaaa!
Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.
-
Siriusb
veterán
Elég egyszerű lett volna a megoldás: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#efibootmgr
-
csixy
addikt
válasz vinibali #5180 üzenetére
Kérdezném a hozzáértőket pl. colomb2 kollégát, hogy mond-e ez nekik valamit? Miért futottam 3x is bele a susnyásba az antergossal és miért sikerült egyből a manjaro telepítés?
[pista@pista-pc-386sx ~]$ find /boot/efi -iname \*.efi -exec ls -l {} \;
-rwxr-xr-x 1 root root 1237920 márc 13 10.31 /boot/efi/EFI/Microsoft/Boot/bootmgr.efi
-rwxr-xr-x 1 root root 1083808 ápr 16 03.01 /boot/efi/EFI/Microsoft/Boot/memtest.efi
-rwxr-xr-x 1 root root 1252768 márc 13 10.31 /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
-rwxr-xr-x 1 root root 123904 ápr 23 02.08 /boot/efi/EFI/Boot/bootx64.efi
-rwxr-xr-x 1 root root 122880 ápr 22 00.36 /boot/efi/EFI/antergos_grub/grubx64.efi
-rwxr-xr-x 1 root root 122880 ápr 22 22.27 /boot/efi/EFI/antergos_grub_p1fo/grubx64.efi
-rwxr-xr-x 1 root root 122880 ápr 22 23.30 /boot/efi/EFI/antergos_grub_h1x8/grubx64.efi
-rwxr-xr-x 1 root root 123904 ápr 23 02.08 /boot/efi/EFI/Manjaro/grubx64.efi
[pista@pista-pc-386sx ~]$(#5182) Siriusb :
[pista@pista-pc-386sx ~]$ efibootmgr
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0006,0009,0008,0007,0005,0003
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash
Boot0003* PXE LAN:
Boot0004* SATA 0:
Boot0005* SATA 1:
Boot0006* USB HDD:
Boot0007* USB FDC:
Boot0008* USB CD-ROM:
Boot0009* Windows Boot Manager
[pista@pista-pc-386sx ~]$??????????????
[ Szerkesztve ]
Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.
-
Frawly
veterán
Én tudok javaslatot. Fogod a kiírt Antergos-telepítőt, és laza mozdulatta a jobb vállad fölött hátra hajítod a Petőfi Csarnokba. Aztán kiírsz egy Arch-ot, megtanulod szépen scriptek nélkül telepíteni, és megoldod magadnak az EFI bootot. Csak egyszer kell megtanulni hogy működik, utána minden gépen hasznosítani tudod ezt a tudást, nem leszel többé GRUB-ra meg társaira szorulva.
-
JonssoN
csendes tag
Sziasztok!
ArchmergeD linuxal lenne egy kisebb gondom. Mikor görgetek illetve videót nézek akkor ilyen szellem képes lesz minden. A szövegeknek meg az emojiknak ilyen árnyéka van vagy, hogy is mondjam. Videóknál ugyan ez.A GPU egy i5 7400-ban lévő HD630. Xfce-t használok, compton telepítve,xf86-video-intel nincs fenn,mert vele is csinálta ezeket, 20.intel.conf így néz ki:
Section "Module"
Load "modesetting"
EndSectionSection "Device"
Identifier "Graphics"
Option "AccelMethod" "glamor"
Option "DRI" "3"
Option "TearFree" "true"
Driver "modesetting"
EndSectionElőre is köszönöm a segítséget.
Xiaomi Mi 9T 6/128 GB Flame Red
-
Frawly
veterán
Igen, úgy jobban látszana. Egyébként a videó alapján sejtem, lagzik neki a kirajzolás, az oka az lehet, hogy a rendszer szoftverrendesen fallback drivert használ (llvmpipe), és nincs hardveres gyorsítás.
Nem tudom, hogy archmerged-re fel tudná-e szögelni az inxi progit, hogy lássuk inxi -Gxxx kimenetéből, hogy milyen drivert használ a GPU.
Bár most nálam az inxi is bugzik, az inxi -Gxxx-re ír ugyan néhány adatot, de a többi adatnál jelzi, hogy glxinfo kéne hozzá, feltettem, de a felbontást ezzel sem jeleníti meg, gondolom a glxinfo nem kompatibilis a waylandes Gnome-mal.
Még egy dolog: ha el lett távolítva a Xorg Intel driver, akkor mindegy mi van a 20-intel.conf-ban, meg pl. a TearFree opció sem érvényes, mert azt csak a Xorg driver tudja.
[ Szerkesztve ]
-
JonssoN
csendes tag
BoB: Megpróbálom felvenni úgy is csak töltőn van a telóm.
Inxi -Gxxx ezt írja:
Graphics:
Card-1: Intel HD Graphics 630 driver: i915 v: kernel bus ID: 00:02.0
chip ID: 8086:5912
Display: x11 server: X.Org 1.19.6 driver: none unloaded: modesetting
compositor: compton resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2)
v: 4.5 Mesa 18.0.1 compat-v: 3.0 direct render: YesXiaomi Mi 9T 6/128 GB Flame Red
-
Frawly
veterán
válasz JonssoN #5192 üzenetére
Ezek az adatok rendben lennének, egy kivétellel:
driver: none unloaded: modesettingItt azt kéne írja, hogy driver: i915 vagy modesetting, semmi unloaded vagy ilyesmi. Beigazolódott az a gyanúm, hogy 2D-s módban visszaváltott valami software render fallback driverre, aminek a kirajzolása lagol. Az i915-ös drivernek támogatnia kéne a HD630-at, és kéne lennie 2D hardveres gyorsításnak is.
Nagyon zavaró, hogy a hardver résznél azt írja, hogy az i915 driver hajtja, majd a Xorg résznél ezt az unloadedet írja.
[ Szerkesztve ]
-
JonssoN
csendes tag
válasz JonssoN #5194 üzenetére
A mai nap addig-addig túrtam a netet míg sikerült átrakni modesetting driverre. Ami xf86-os csomag volt és a megjelenítéshez volt köze pl: xf86-video-intel, fbdev, vesa az elment világgá. Majd találtam egy githubos cikket ami alapján beconfigoltam. A hiba ugyanúgy fenn áll de legalább annyira előrébb lettem, hogy az inxi már drivernek modesettinget ír.
Graphics:
Card-1: Intel HD Graphics 630 driver: i915 v: kernel bus ID: 00:02.0
chip ID: 8086:5912
Display: x11 server: X.Org 1.19.6 driver: modesetting compositor: compton
resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2)
v: 4.5 Mesa 18.0.2 compat-v: 3.0 direct render: YesMi a franc lehet akkor ha így sincs hardveres 2d-s gyorsítás?
Xiaomi Mi 9T 6/128 GB Flame Red
-
Frawly
veterán
válasz JonssoN #5195 üzenetére
Ez már rendben lévőnek tűnik, kéne lennie hardveres gyorsításnak, nem véletlenül írja, hogy „Direct Rendering”, meg DRI.
Hamarabb inkább a Compton beállításai között nézz szét, hogy renderelésre a glx backendet használja. Bár ha a conf-fájlban a Glamour be van állítva, akkor enélkül is kéne lennie 2D-s hardveres gyorsításnak. Arra is figyelj, hogy Comptonban legyen bekapcsolva a vsync.
-
Frawly
veterán
válasz JonssoN #5197 üzenetére
Ha a leírás alapján csináltad, próbáld átnevezni a glamor.conf-ot, hogy anélkül mit csinál. Kezdek arra gyanakodni, hogy nálad mégis valami más dolog lesz. Ahogy nézem friss X-et, Mesa-t használsz, modesetting drivert, kompozitor beállításai is rendben, GPU-d is támogatott. Egyszerűen nem értem miért szellemképezne. Esetleg ha csak böngészőben csinálja, próbáld megnézni más böngészőkkel, progikkal, görgess fájlkezelőben, szövegszerkesztőben.
Böngésző about:support lapján is nézd meg a hardveres GPU gyorsítás állapotát.
-
JonssoN
csendes tag
-
Frawly
veterán
Blogolásom folytatom ide, nem offolom vele a kezdő témát. Most megint nem jó a NetworkManager. Hetekig jó volt, tegnap előtt frissített a 4.16.6-os kernelre, és elkezdett megint szórakozni. Tegnap a 4.16.7-re frissült, és ez sem segített. Lehal random pontokon a Wi-Fi, persze nem szakad meg a kapcsolat, csak elkezdenek nem betöltődni az oldalak. Ahogy beszögelem a /etc/resolv.conf-ba a 8.8.8.8-as Google-féle DNS-t, egy rövid időre megjavult, majd újra lehal, és semmi nem segít rajta. Ráadásul beállítási módozat sincs, amin változtathatnék.
Úgyhogy megint az van, hogy NetworkManagert letiltottam, és wpa_supplicant-os profilt betöltve netctl-lel használom a netet, így jó, bár ennek a módszernek van egy olyan hátránya, hogy bootkor beakad néhány másodpercre, míg a wpa_supplicant kapcsolódik, ami kicsit kellemetlen.
Kezdek közelebb lenni a probléma gyökeréhez, eddig azt hittem, hogy a 238-as systemd-vel van gond, közben meg a kernel lesz a ludas. Abból is tesztelni fogom más disztrókkal, mert lehet csak a csomagkészítő hányja el a dolgokat Arch alatt, kihagy a fordítás során valamit, ami kéne a kernelbe.
Abban is biztos vagyok, hogy nem a Wi-Fi kártya, meg a tré Wi-Fi jelerősség az oka, mert bizonyos szoftveres megoldásokkal jó, Win10 alatt megint jó. Archon majdnem egy évig jó volt. Ha a kártya haldokolni, mindenféle környezetben lenne vele problémám.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Micro Four Thirds
- Azonnali processzoros kérdések órája
- Azonnali alaplapos kérdések órája
- Mibe tegyem a megtakarításaimat?
- Xbox Series X|S
- Aliexpress tapasztalatok
- Szeged és környéke adok-veszek-beszélgetek
- Crypto Trade
- További aktív témák...
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- Canva Pro előfizetés - 1 éves
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!