- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- TCL LCD és LED TV-k
- Milyen TV-t vegyek?
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Epson nyomtatók
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Everest / AIDA64 topik
- Milyen billentyűzetet vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
-
PROHARDVER!
Arch Linux topik
Új hozzászólás Aktív témák
-
vinibali
őstag
bocsánat az offért, de nekem nagyon tetszik
biztos ti is hallottatok arról, hogy a Gentoot kisebb attrocitás érte a GitHubon.
a pénteki nap Phoronix kommentje [link] :
What did the hackers do? downgrade the CFLAGS in the ebuilds? -
anorche1
őstag
Sziasztok!
ide irok, mert talan ez aktivabb topic mint a manjaros
dell e6440 -en hasznalok manjarot. A problemam, hogy windows 10 -hez kepest sokkal rosszabb a hangminoseg, sokkal dobozosabb a hangja, meg halkabb is.
A gyarto honlapjan talaltam linux drivereket, de debianhoz, .deb csomagokkal.
Hogyan tudnam pl. a "oem-audio-hda-daily-lts-quantal-dkms_0.201305151525~precise1_all.deb" drivert telepiteni manjarora?
A csomagon beluli data.tar.gz -bol atmasoltam a fajlokat a megfelelo mappakba, volt restart is, de nem erzem, hogy tortent volna barmi is. -
attilav2
őstag
Néztem egy traceroute -6 www.youtube.com -ot és a vége felé az összes címet kicsillagozza, lefuttattam NetworkManager, systemd-networkd és netctl alatt is, ugyanaz az eredmény. Ha ipv4-el nézem akkor nincs kicsillagozott cím. A youtube egyébként bejön működik, ipv6-os módban töltődik be a firefox kiegészítők szerint.
-
attilav2
őstag
Kíváncsiságból visszatértem a networkmanagerre, ki/bekapcsoltam egyes beállításokat a nmtui-ban, restartolgattam a service-t, végül bejött a youtube, működik ez csak rugdosni kell
Ezeket kapcsolgattam ki/be:
Require IPv6 addressing for this connectionIPv6 CONFIGURATION: Automatic/Automatic(dhcp only)
Végül mindent visszatéve alapra is ment a youtube.
Egyelőre marad a networkmanager, kíváncsi vagyok meddig működik yt. -
vargalex
félisten
válasz
attilav2 #5287 üzenetére
Nálam NetworkManager van, LAN oldalon IPv6 és IPv4 osztva OpenWrt alapú routerről. Igaz, WAN oldalon csak IPv4 van az UPC-nek köszönhetően. Systemd-networkd-vel is kapsz IPv6 címet? Én valami olyanra gondolok, hogy a youtube a Digi hálózatáról valamiért nem megy rendesen IPv6 alatt, ellenben IPv4-el igen.
Frawly: Nálam a wifivel sincs semmi gond. Ma is egész nap wifi-n lógok, itthonról dolgozom, így a céges VPN-re is folyamatosan csatlakozva vagyok (OpenVPN) délelőtt 10 óta.
-
Frawly
veterán
válasz
attilav2 #5289 üzenetére
Ez ilyen. Minden DE NetworkManagert használ már.
Én is alternatív megoldást használok, igaz systemd-networkd-t, hanem netctl-t, ami épp úgy systemd-s megoldás. A NetworkManagert kidobtam, mert régóta van egy olyan bugja, hogy lehal vele a Wi-Fi, alig van net, pár perc után teljesen elakadnak az oldalletöltések, még újrakapcsolódni sem lehet normálisan.
Nálam is IPv6+IPv4 dualstack van, sose volt vele gondom.
-
attilav2
őstag
A systemd-networkd -t átállítottam dual stackre, és így is bejön a youtube. Akkor a networkmanagerben kefélhettek el valamit valószínűleg.
Mondjuk kisebb hátrány hogy a systemd-networkd-nek nincs grafikus konfigoló sőt semmilyen konfigoló programja, nincs net ikon a kde-ben a tálcán forgalmi statisztikával. Nade ezzel együtt lehet élni.
-
-
attilav2
őstag
Nem fogjátok elhinni mi volt a probléma.
A networkmanager! Openwrt routerem van és ipv4-ipv6 dualstackre van beállítva ez alapján: [link]
A networkmanager látszólag jól lekezeli mert ipv6 címet is oszt a gépnek, de lehet hogy a youtube esetén ez okozta a galibát, hogy esetleg a networkmanager rosszul kezelte a dual stacket, ez csak tipp. Most átváltottam a systemd-networkd.service -re a NetworkManager.service -t kilőttem, és láss csodát egyből bejött a youtube. -
attilav2
őstag
[attilav@attilav ~]$ drill TXT youtube.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 10847
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; youtube.com. IN TXT
;; ANSWER SECTION:
youtube.com. 3600 IN TXT "v=spf1 include:google.com mx -all"
youtube.com. 3600 IN TXT "facebook-domain-verification=64jdes7le4h7e7lfpi22rijygx58j1"
youtube.com. 3600 IN TXT "google-site-verification=OQz60vR-YapmaVrafWCALpPyA8eKJKssRhfIrzM-DJI"
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 31 msec
;; SERVER: 192.168.1.1
;; WHEN: Wed Jun 20 18:19:07 2018
;; MSG SIZE rcvd: 228[attilav@attilav ~]$ drill @8.8.8.8 TXT youtube.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 28594
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; youtube.com. IN TXT
;; ANSWER SECTION:
youtube.com. 3599 IN TXT "google-site-verification=OQz60vR-YapmaVrafWCALpPyA8eKJKssRhfIrzM-DJI"
youtube.com. 3599 IN TXT "v=spf1 include:google.com mx -all"
youtube.com. 3599 IN TXT "facebook-domain-verification=64jdes7le4h7e7lfpi22rijygx58j1"
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 34 msec
;; SERVER: 8.8.8.8
;; WHEN: Wed Jun 20 18:20:20 2018
;; MSG SIZE rcvd: 228 -
attilav2
őstag
Lehet hogy a nyílt ati driver okozza a galibát? A catalyst felrakása nekem bonyolult, még az X-et is downgradelni kell. Ha lesz új vga-m talán megoldódik a gond, majd egyszer ha lesz rá pénzem akkor nvidia-t választok. Lehetséges hogy a radeon 6670 túl régi? És romlik a támogatás színvonala?
-
vargalex
félisten
De, szerintem is ettől zengene. De a kolléga valamiért nem akarja elhinni nekünk (pedig már mindannyian írtuk), hogy nem az Arch-ban kell keresni a hibát, akárhogy bizonygatjuk... Itt konkrétan kérte is (illetve kijelentette, hogy új telepítésnél tuti gond lesz), így gondoltam jó fej leszek. A telepítés pedig néhány percet vett el az életemből, aztán töröltem is a virtuális gépet.
-
Frawly
veterán
válasz
attilav2 #5268 üzenetére
Akkor nem hálózati hiba, ha ugyanazon a gépen Win10-zel bejön, meg Kubuntuval is.
Tedd fel az inxi-t és terminálból másold ki az inxi -inxxx és az ip ad kimenetét.
Proxyval nem baj, ha nem jutottál el a videók megnézéséig, tesztként hibát zártunk ki vele azzal, hogy a YT oldala bejött.
-
attilav2
őstag
Felraktam a tor browsert a honlapjáról: https://www.torproject.org/projects/torbrowser.html
Megy a youtube:
[link]Két dolog lehetséges, vagy a tor proxy miatt töltődik be a yt, és akkor az arch hálózatkezelésében van valami baki, vagy pedig a tor browser statikusan lett fordítva és mivel nem használja a rendszer libjeit emiatt küszöbölődik ki a hiba.
-
attilav2
őstag
válasz
vargalex #5272 üzenetére
/etc/hosts és /etc/resolv.conf tartalma
[attilav@attilav ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
search lan
nameserver 192.168.1.1 (ez a routerem címe, ez így rendben van sztem)
[attilav@attilav ~]$ cat /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1 localhost
::1 localhost
127.0.1.1 attilav.localdomain attilav -
-
vargalex
félisten
válasz
attilav2 #5270 üzenetére
Szerintem, ha proxyn keresztül (valamennyire) megjelenik az oldal, akkor nem az Arch-ban kell keresni a hibát. Én is inkább DNS szerverre gondolnék. Nézd meg, hogy Arch alatt mi a DNS szervered és nézd meg azokon a rendszereken is, ahol megjelenik az oldal.
Ha holnap lesz időm, feltolok egy Arch-ot virtuális gépre és megnézem.
-
eddie1978
senior tag
Tegnap volt egy olyanom, hogy eltűnt a Bluetooth. Nem látta a Blueman manager. Újraindítás sem segített. Archwiki alapján megnéztem rfkill szerint nem fogta semmi. Ma megjelent és működik. Remélem nem hardver probléma lesz. Nem volt frissítés szerintem ami befolyásolta volna.
-
attilav2
őstag
Win10 et használok elsődlegesen, mind a chrome a firefox az edge böngészőkben bejön a youtube. Arch linux alatt viszont akármivel próbálkozok opera chromium firefox, csak az oldal fejléce és egy nagy fehérség jön be. Már kétszer újraraktam az Arch-ot, és ugyanez a hiba. Kubuntu 18.04 alatt szintén bejön a youtube minden böngésző alatt, még úgy is hogy rendszert frissítettem telepítés után és akkor sem jött elő a hiba, tehát az Arch valamelyik összetevőjében van a hiba.
-
vargalex
félisten
-
Frawly
veterán
válasz
attilav2 #5265 üzenetére
Probáld egy web proxyn keresztül meglátogatni a YouTube oldalát. Bár azt írod, hogy nem hálózati hiba, mert a többi gépeden jó, csak azon az egyen nem.
Próbaképp feltennél egy Win10-et? Ingyenesen letölthető, nem muszáj aktiválnod, drivereket sem kell feltenni a hálózati csatolón kívül, csak told fel az alaprendszert, indítasz benne egy Edge-t, és megnézed ott bejön-e.
-
attilav2
őstag
válasz
attilav2 #5258 üzenetére
Most kísérletképpen felraktam virtualboxban az Arch-ot. Az eredmény ugyanaz, nem megy a youtube firefox és chromium alatt, a fejléc bejön de az oldal üres fehérség.
Képernyőkép:
[link]
Ezt már nem lehet a 2d gyorsítás hibájára fogni, valódi és virtuális gépen is jelentkezik a hiba, újonnan telepített Arch-nál legalábbis egészen biztosan. Valamit nagyon elkeféltek, valami közös libraryt-t amit a komolyabb böngészők használnak, mint az opera firefox chromium.
Szeretem az Arch-ot, jó lenne ezt a hibát megoldani, jelentenem kellene a hibát, csak az angolom hiányos.
Régi telepítéseknél nem jelentkezik a hiba azért nem tapasztaljátok szerintem, próbáljatok új telepítést legalább virtuális gépbe és tuti hogy ti is belefuttok ebbe hibába. -
Frawly
veterán
válasz
#63718632 #5260 üzenetére
Nekem nincs vele konkrét tapasztalatom, de a GPU-t alapból kéne vigye kernelbe épített radeon DRI modesetting driverrel, neked csak a Mesa csomagot kell feltenni a 3D-s gyorsításhoz. Más gondnak nem kéne legyen vele, de ezt csak akkor tudod meg ténylegesen, ha feltelepíted. Kezdd el telepíteni az Arch Wiki alapján, ha elakadtál, valami nem megy, jelezz, segítünk. Szerintem semmi olyan nem merül majd fel, amit egy kis utánaolvasással ne tudnál megoldani, általában minden beüzemelhető.
-
válasz
#63718632 #5262 üzenetére
Egyaltalan nem, en is hasznalom utazasra, de a GCN elotti radeon-ok a friss kernelekkel nem minden esetben stabilak, emiatt hasznalok debian-t.
GCN eseten pont az Arch lenne a jobb, mert ahhoz mindig jonnek ki ujitasok, gyorsitasok, es figyelnek is arra, hogy stabil maradjon. -
válasz
#63718632 #5260 üzenetére
V5 121?
Nekem ilyenem van debiannal. Hasznalhato a gep, de lassu, pedig SSD-t raktam bele.
Akkor erezni a lassulast, amikor az alkalmazasok (pl. bongeszo) elindulnak, vagy tobb tab meg van nyitva, animalt reklamok szaggatnak, pl. a mobilarena mostani fooldalan levo vodaf*ne reklam elegge akad.Azert nem olyan gaz, hasznalhato. Lenyeg, hogy egyszerre egy dolgot csinalj es neha igy is turd a varakozasokat.
Az arch nalam nem volt nyero ezen a gepen, mert az uj kernelekben a regi radeon driver neha el tud romolni, de azert nem veszes az sem.
A debian 4.9-es kernele mindent tud, amit ez a GPU tud.
Kulon munkat igenyel mindket disztron a 3D gyorsitas bekapcsolasa pl. bongeszokben. Erre oda kell figyelni, mert sokat segit.Ezen kivul az IGP kepes regi jatekokat (pl. Quake 3) tokelesen elvinni, de ujabbakkal is elbir.
Itt a proci a szuk keresztmetszet, a GPU sokkal jobb, mint gondolna az ember.Amire oda kell figyelni ennel a gepnel linux eseten:
- tapipad indulasnak ki van kapcsolva
- tapipadra koppintas nem muxik alapbol
- wifi/BT alapbol nem megyDebian alatt ezekre mind van megoldas, Arch eseten nem tudom.
-
#63718632
törölt tag
Sziasztok!
Mire lehet számítani egy AMD C-70 procival szerelt kis Acer netbook és Arch Linux találkozásakor?
[link]
A gépben 4 GB memória van, nem volt még alkalmam kipróbálni. Van-e tapasztalat a grafikus vezérlő működéséről és úgy általában a Linuxos élményről erről a procival.
Általános használatra lenne a gép, a gyári belassúlt, használhatalan Windowst cserélnénk Linuxra. -
attilav2
őstag
Próbaképp felraktam a Kubuntu 18.04-et, természetesen ebben megy firefox és chromium alatt a youtube. Most újrainstalláltam az Arch-ot, és persze se a firefox se a chromium se a falkon nem viszi a youtubeot, helyette csak az oldal fejléce jön be és egy üres fehér lap.
Screenshot:
[link]Sejtésem szerint egy olyan libraryvel lehet gond amit a legtöbb böngésző használ, kivéve a midori-t mert abban megy a youtube. Lehet hogy ezt hibaként jelenteni kellene az Arch-nak? Sajnos az angol tudásom nem valami jó... Milyen infókat kell összegyűjteni egy hibajegyhez?
Akinek megy a youtube firefox és chromium alatt, milyen vga-t használ, és nyílt vagy zárt driverrel?
-
Frawly
veterán
Jó, de Live Archon nincs grafikus felület. Elvileg valóban lehet X nélkül is beröffenteni grafikus alkalmazást, így Gparted-et, de kérdés van-e értelme. Én mindig is egy rakás, lassú bughalmaznak tartottam a Gpartedet, a sima parted meg CLI-s, de nem felhasználóbarátabb, mint az fdisk. A cfdisk viszont felhasználóbarát, menüs, meg villámgyors is vele dolgozni, és alapból részét képezi az Arch iso-s rendszernek.
Annyi, hogy az fdisk, cfdisk nem formázza meg a létrehozott partíciót, de senki nem halt még bele egy plusz mkfs.akármifs parancsba.
Ilyen külön live rendszernek, rajta Gparteddel akkor van értelme csak, ha mondjuk partíciókat kell átméretezni a rajtuk lévő adatok törlése nélkül. Egyébként csak sima Arch telepítéshez nem éri meg.
-
Frawly
veterán
Ha már fent van a Windows, akkor még könnyebb is az UEFI boot, mivel a Windows telepítője már megcsinálta az EFI partíciót, meg létrehozta a /boot/loader/loader.conf-ot, így annyival is kevesebb munka van vele, neked a bootctl install után csak a kész loader.conf-ot kell szerkeszteni, meg egy arch.conf-ot a entries mappába és így csak bővíted a már meglévő UEFI bootos opciókat egy újabbal. Teljesen veszélytelen művelet, mivel a Windows bootolhatóságát nem érinti, még ha el is rontasz valamit, attól legfeljebb csak az Arch nem fog bootolni.
Van egy másik módszer az EFI systemd-booton kívül. Ez pedig a EFI stub boot, ezzel már egy másik Arch Wiki cikk foglalkozik. Itt nem az EFI partíción lévő .conf fájlokkal zsonglőrködünk, hanem efibootmgr futtatásával közvetlenül az UEFI-ben matatunk, adjuk hozzá kézzel a bootopciókat. Na, ez veszélyes, mert ha valamit rosszul viszünk fel, bootképtelenné vállhat a gép, és ha nincs defaultra állítás az UEFI-ben opcióként, akkor az egész UEFI-t haza lehet vele vágni. Ezt tényleg csak annak ajánlott, aki tudja mit csinál.
-
Telepitettem mar (egyszer) Arch-ot, de mivel nem sajat gep volt, es windows particio is volt mellette, es nem volt meg tapasztalatom az Arch particionalojaval, igy bolcsebbnek lattam hipszterkedes helyett az altalam ismert modszerrel menni, es nem elcseszni mas rendszeret.
Legkozelebbi telepitesnel mar magabiztosabb leszek.
-
Frawly
veterán
Nincs hátránya, de Arch-nál felesleges, mivel ott eleve live iso-t töltesz be, és igaz nincs grafikus felület, de pl. a cfdisk text user interface-t tud nyújtani, ami legalább olyan használható, mint egy grafikus tool. Annyi, hogy utána a csatolásokat is neked kell csinálni, mivel az Archban nincs telepítő, de pont ez a poén benne, hogy mindent te csinálsz kézzel, látod mi futott le, mit tettél fel, így nincs az, hogy nem tudod miért nem megy. Különösen áll ez az UEFI bootra, amit a telepítők 90+%-a el szokott qrni, pedig a világ legegyszerűbb dolga, ha egyszer kézzel telepítve Wiki alapján megérted hogyan működik.
-
-
Frawly
veterán
válasz
Silεncε #5249 üzenetére
Az Arch Wikinek ezt a cikkét nézd.
A lényeg, hogy fel kell lennie csatolva a EFI partíciónak, tipikusan /boot-ként. Ekkor arch-chrootban kiadod a bootctl --path=/boot install parancsot, és felteszi az EFI partícióra az Arch indítófájlait. Ezzel nincs vége, mert szerkeszteni kell egy konfigfájlt is, a /boot/loader/loader.conf néven, sőt, kell egy conf fájl a /boot/loader/entries/-be is, ennek a neve szabadon választott, de össze kell egyeztetni a loader.conf-ban írtakkal. Én is így csináltam meg az Arch EFI bootját, csak X220-on. Működik. Úgy is, hogy ha Win10 van mellette.
Ha elakadnál, akkor nyugodtan kérdezz még, lehetőleg a hibaüzenettel együtt, amit kiírt.
-
Silεncε
őstag
Sziasztok! Szeretnék kicsit ismerkedni az Arch-al, sok jót hallottam már róla. Jelenleg a laptopomra szeretném telepíteni (ThinkPad X230), most van rajta dualbootban egy Windows10 és egy Ubi 18.04. Viszont a partícionálással totál elakadtam. Szeretném róla az uborkát letakarítani és a helyére rakni az Archot, viszont fogalmam sincs, hogy kéne. UEFI-t használok a laptopon, a Windows már megcsinálta az EFI partíciót, innen viszont nem tudom merre tovább. A wikin valószínűleg a bénaságom miatt nem tudok eligazodni, tudna valaki segíteni, pontosan merre induljak el?
Előre is köszi!
-
Frawly
veterán
válasz
attilav2 #5244 üzenetére
Az inxi kimenetéből az látszik, hogy rendben van a videódriver, van hardveres gyorsítás. Ha kikapcsoltad és úgy sem megy, akkor azt jelenti, hogy FF-ban szintén be volt kapcsolva. Az is biztos, hogy nem a böngésző beállítása, addonja, mert több böngészővel sem megy. A Chrome, Opera azonos böngészőmotort használ (Blink), de nem is lehet az, mert mind a FF, mind a Falkon más motorral fut.
Próbából az Xfce-ben kapcsold ki a kompozitort. Tényleg csak tesztképpen, kicsi az esélye, hogy segít. Ha az lenne a baj, akkor más oldalak sem jelennének meg.
-
eddie1978
senior tag
Szerintem igazad van mert ezt olvastam is valahol. Ezzel akkor nincs teendő ha jól sejtem. Marad az Adwaita-dark.
Van GTK3-as is. Majd kipróbálom. pl Xfce-dusk-gtk3 Minőségét nem tudom milyen.
-
eddie1978
senior tag
Xfce-Dusk témát használok. Az utóbbi időben ahogyan jönnek a frissítések, egyre több helyen nem használja a beállított témát. Ez mivel van összefüggésben? GTK? Most átraktam Adwaita-dark témára, ezzel most jó. Annyi a különbség, hogy ez nem fekete hanem szürke. Picit zavar. Van valami jó fekete téma ami használható?
-
attilav2
őstag
Ha kikapcsolom a hardveres gyorsítást a chromiumban akkor sem jelenik meg a youtube.
Opera alatt is fehérséget ad a youtube-ra, sőt a falkon browser is ugyanezt a tünetet produkálja.
Tehát a firefox chromium opera falkon browserek alatt csak a yt fejléce jelenik meg egy üres fehér oldallal. Csak a midori hozza be a yt-ot.
dailymotion rendesen megy firefox és chrome alatt, sőt a vimeo is.
Inxi kimenete:[xfce@attilav aur]$ inxi -Fxxx
System:
Host: attilav Kernel: 4.14.48-1-lts x86_64 bits: 64 compiler: gcc v: 8.1.1
Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 info: xfce4-panel dm: startx
Distro: Arch Linux
Machine:
Type: Desktop Mobo: ASUSTeK model: A88X-PLUS v: Rev X.0x
serial: <root required> UEFI [Legacy]: American Megatrends v: 3003
date: 03/10/2016
CPU:
Topology: Quad Core model: AMD Athlon X4 860K bits: 64 type: MCP
arch: Steamroller rev: 1 L2 cache: 2048 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
bogomips: 29525
Speed: 1695 MHz min/max: 1700/3700 MHz Core speeds (MHz): 1: 1695 2: 1690
3: 1695 4: 1694
Graphics:
Card-1: AMD Turks XT [Radeon HD 6670/7670] driver: radeon v: kernel
bus ID: 01:00.0 chip ID: 1002:6758
Display: server: X.Org 1.20.0 driver: radeon resolution: 1920x1080~60Hz
OpenGL: renderer: AMD TURKS (DRM 2.50.0 / 4.14.48-1-lts LLVM 6.0.0)
v: 3.3 Mesa 18.1.1 compat-v: 3.1 direct render: Yes
Audio:
Card-1: AMD FCH Azalia driver: snd_hda_intel v: kernel bus ID: 00:14.2
chip ID: 1022:780d
Card-2: AMD Turks HDMI Audio [Radeon HD 6500/6600 / 6700M Series]
driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 1002:aa90
Sound Server: ALSA v: k4.14.48-1-lts
Network:
Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
driver: r8169 v: 2.3LK-NAPI port: d000 bus ID: 05:00.0 chip ID: 10ec:8168
IF: enp5s0 state: up speed: 100 Mbps duplex: full mac: f0:79:59:6c:c6:58
Drives:
HDD Total Size: 618.55 GiB used: 10.32 GiB (1.7%)
ID-1: /dev/sda vendor: Samsung model: SSD 840 Series size: 111.79 GiB
speed: 6.0 Gb/s serial: S19HNEBD353510Y rev: AB0Q scheme: MBR
ID-2: /dev/sdb vendor: AMD Radeon model: R3SL480G size: 447.13 GiB
speed: 6.0 Gb/s serial: E201607070040523 rev: 2C scheme: GPT
ID-3: /dev/sdc vendor: A-Data model: SP600 size: 59.63 GiB speed: 6.0 Gb/s
serial: 2E4620012337 rev: 5.2 scheme: MBR
Partition:
ID-1: / size: 58.44 GiB used: 10.32 GiB (17.7%) fs: ext4 dev: /dev/sdc1
Sensors:
System Temperatures: cpu: 14.5 C mobo: N/A gpu: radeon temp: 48 C
Fan Speeds (RPM): cpu: 0
Info:
Processes: 147 Uptime: 4h 04m Memory: 7.74 GiB used: 1.67 GiB (21.6%)
Init: systemd v: 238 Compilers: gcc: 8.1.1 Shell: bash v: 4.4.23
running in: xfce4-terminal inxi: 3.0.10 -
attilav2
őstag
Ilyet még nem tapasztaltam!
Arch alatt Firefox és a Chromium egy üres fehér képernyőt jelenít meg a youtube helyett, csak a fejléc látszik az oldalból, a midori simán behozza a youtube-ot. Windows alatt is megy a youtube firefox és chrome alatt. Ilyet még nem pipáltam! Milyen hiba ez?
Képernyőkép:
[link] -
#63718632
törölt tag
Lehet, hogy lényegtelen dolog. De lehet fontos is. Leírom.
Szóval többször neki kezdtem a pamac-el feltenni ezt a js52 csomagot. Aztán az itt kapott link segítségével feltudtam frissíteni.
Viszont én root mc-vel kerestem a fájlt és töröltem is. Volt még egy ugyanilyen nevű fájl is csak az @ karakterrel kezdődött és a szine is eltért mc szerint az előtte lévőtől. Töröltem azt is. Majd sudo pacman -Syu paranccsal frissítettem a rendszert.
Szóval ez a @ elejű fájl nem olyankor keletkezik, ha szöveges fájlt kezdünk módosítani? Lehet törölni akarta a szkript, de nem ment végbe. Vagy a szkriptben felülírás van, nem törlés? -
Frawly
veterán
válasz
#63718632 #5234 üzenetére
Nem baj, hogy kérdeztél, megvan legalább itt is. Én is belefutottam, de magamtól rájöttem, ha ez a fájl létezik, akkor szimplán csak törölni kell rm paranccsal. Utána szépen megy a frissítés. Majdnem beírtam én is ide figyelemfelhívásnak, de aztán megjelent az Arch oldalán is a hírekben, aztán úgy voltam vele, hogy az elég figyelmeztetés mindenkinek.
Egyébként nem értem, hogy a csomagkészítő milyen nem vettem fel scriptbe, ha létezik a fájl, akkor telepítés során automatikusan törlődjön.
-
BoB
Topikgazda
Bekerült a core tárolóba a pacman 5.1-es verziója.
A felhasználókat érintő legfontosabb változás, hogy megszűntetésre került a
--force
kapcsoló, helyette--overwrite
van.További változások listája itt található: [link]
-
Siriusb
veterán
válasz
#63718632 #5232 üzenetére
https://www.archlinux.org/news/js52-5273-2-upgrade-requires-intervention/
Célszerű ilyenkor a híreket vagy a hivatalos fórumot megnézni. Ha van valami hiba, valószínűleg mások már megoldást is találtak a problémádra.
-
#63718632
törölt tag
Sziasztok!
A következő csomagfrissítési hibába futottam, a js52 csomag frissítésekor.
js52 (JavaScript interpreter and libraries-Version 52)ütköző fájlok:
js52 /usr/lib/libmozjs-52.so.0 már létezik a fájlrendszerbenAz 52.7.3-1 csomag frissűlne 52.7.3-2 verzióra.
Firefoxot használok, annak szükséges. Előjött már másnál is ez a hiba? -
Jó az, minek stoppereljem, érezhetően kb annyi az így is.
Nincs GPT, mint említettem, felment a teszt Mint C és első dolgom volt gpartedben csinálni 4 elsődleges partíciót próbaképpen. A negyediknél jött az ismerős ablak, hogy csak 4 elsődleges ......
Szóval bootol ez rendesen, csak nincs választási lehetőség, mert desktopon van, amikor pendrive-ról bootolok.
Annyira látszik, hogy semmi nem akarja ezt az UEFI-t!Mondhatnám azt is, hogy fák jú GPT/UEFI !
-
Frawly
veterán
válasz
ubyegon2 #5229 üzenetére
A systemd-analyze outputját felejtsd el, bullshiteket írogat. Stopperral mérd. A bootmenüben ahogy indítod a rendszerd, onnan indítsd a mérést, és ott állítsd le, ahogy minden ikon az asztalon, tálcán, stb. megjelent.
Az a HP Elitebook, ami neked van, elviekben UEFI-s és támogatja a GPT-t. Az UEFI-ben állítsd át a Boot type-ot vagy Legacy + EUFI-re, vagy UEFI-re. Tessék csak szépen próbálkozni vele.
A telepített rendszer csak akkor fog az UEFI-ben látszódni, ha az OS megtette a szükséges bejegyzést magában az UEFI-ben. Valószínű jó az a GPT-s átállás, csak az OS telepítésekor az UEFI boot részletei nem megfelelően lettek beállítva, ezért nem bootol.
-
Hasznosak ezek az optibay-ek valóban. Mint Cinnamon amúgy most sem túl gyors bootban:
ubyegon@HP-EliteBook-8470p ~ $ systemd-analyze
Startup finished in 5.315s (kernel) + 1.534s (userspace) = 6.849sKipróbálom valamelyik Arch klónnal, de nem pure Arch lesz, mert már megszoktam, hogy 5-10 perc egy full install.
A GPT-re átállás nem sikerült, pedig live alól inicializáltam, el is tűnt minden, de egyrészt a HP biosában nem lehetett választani, majd körül kell benne néznem, másrészt MBR maradt. Lehet, hogy bios is régi ebben a Elitbookban.
Most jött ki friss Antergos, érdemes bepróbálkozni vele? Anno elég gyatra volt a Inchi nevű telepítősegéd benne.
Meglepő, de Mint Cinnamonnal 500 mega alatt maradt a memória (boot után 423MB), FF 3 lapjával lépte át az 1gigát. Meglátjuk, mit ad ehhez az Arch alap.
A Cin 3.8 a Mint 19 alatt simán kiröhögi a KDE-t, ha most ennyit zabál csak.
-
Frawly
veterán
válasz
ubyegon2 #5227 üzenetére
Márpedig szerencsénk van, mert a DVD meghajtót a laptopból úgy kivágjuk, hogy csak nyekken. Konkrétan a bal vállunk felett hajítjuk hátrafelé. Persze nem mindenhol opció, mert az X220-ban mivel szubnotesz, eleve nincs ODD, így nincs az, hogy a HDD-t átrakod a helyére. Meg a 2. SSD sem azért kéne nekem, mert annyira szűkében vagyok a tárhelynek, csak inkább szeretném külön lemezen tudni a két OS-t.
Az 2,7 másodperces antergosos Cinnamon-boot az nagyon szép. Lehet ahhoz jobb gép kéne. NVMe-vel is max csak ilyen 0,1-0,5 mp-eket lehet lefaragni, inkább a procin, buszsebességen múlik, nem az SSD-n. Esetleg ha a kernelben a hardverdetektálást fel lehetne gyorsítani nem használt komponensek detektálásának a letiltásával.
-
Ha minimalista WM-mel használod, akkor a bootidő leszorítható 4 mp. környékére egy sima SATA3 SSD-vel. Ez Minten elérhetetlen.
Szép is lenne, ha WM-et kéne használni, hogy megfelelő bootidő legyen. Amúgy igazad van, Mint Cinnamonnal 5 sec alá nem ment a bootidő, Debian Cinnamonnal viszon 3 sec volt, pár éve kipróbáltam Antergossal, az 2,7 sec bootidőt hozott. Mindenütt a leglomhább DE volt fenn, szóval nem kell ide WM.
Jó dolog az SSD, én is sokáig küzdöttem ellene, mert minek az, ha WD Black-et használok rendszer alatt, de szerencsére már megvannak, így viszont a leggyorsabb, legstabilabb HDD-t tárolásra használom, ha ezt előbb tudom, dupla tárhelyet vehettem volna az áráért.
Desktopnál lehet a legjobban megoldani, mert ott valóban elég egy 10 rugós 12GB-os SSD és xTB HDD tárolásra. Laptopnál kicsit nehezebb ezt megoldani, ha csak ki nem dobod a DVD írót.
-
Frawly
veterán
válasz
ubyegon2 #5225 üzenetére
Óó, ne aggódj, ha Archot teszel rá, azt azért SSD-n is érezni. Ha minimalista WM-mel használod, akkor a bootidő leszorítható 4 mp. környékére egy sima SATA3 SSD-vel. Ez Minten elérhetetlen.
Ennek az SSD-korszaknak már nagyon ideje volt, a HDD-k nagyon visszafogták már a mai gépeket. Főleg a Win10-nél fontos az SSD, mert mocskosul tekeri a lemezt, részben az NTFS fossága miatt, másrészt a registry írása, olvasása is elég lassú. Linux fronton el lehet lenni HDD-vel, de az SSD ott is sokat gyorsít. Ma már nem éri meg spórolni rajta, ha más nem egy olcsó 120 gigás Kingston A400-at be kell szerezni, vannak boltok, ahol 10 ezer alatt megkapod, alig drágább, mint egy nagyobb pendrive. Lesz ez még olcsóbb, ha lemennek reálisabb szintre az memória/SSD árak.
-
A manóba, tényleg kevesebb nullát írtam, szokni kell még ezt a 14" -os ketyerét vagy túl gyorsan írtam.
Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón
Az Intel 520 esetén ez különösen jó üzlet volt, mert pár évvel ezelőtt magasan a legjobb consumer SSD volt megbízhatóság terén és gyakorlatilag feleződött az új eszköz ára az új modell miatt. A Furyra meg használtan elég nehéz volt lecsapni, nagyon ajánlott még a legtöbb új modellel szemben is, a milyen SSD-t....topikból infóztam vétel előtt.
Annyira jók ezek az SSD-k, hogy ha nem Arch-ot rakok rá, akkor is repül a rendszerem!
-
Frawly
veterán
válasz
ubyegon2 #5223 üzenetére
Jó neked, hogy ilyen 10-12 gigás SSD-kkel beéred, én 480-525 gigás kategóriában nézelődök
Tudom, hogy elgépelted, gondolom a 12-es az 120 gigás akart lenni, az Intelnél meg a 10 az lehet 120 vagy 180 giga?
Abban igazad van, hogy átlag felhasználó, amilyen én is vagyok, elvan planár TLC-vel is, mivel nem ír annyit rá, hogy számítson a TLC, 3D TLC, MLC írásterhelhetőségi különbsége. Amúgy is a vezérlő fárad el, nem a cellák. Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón, nem baj az se, ha planár TLC, csak sokat nem szabad érte adni.
A 16K-s align onnan jön, hogy 3D TLC-nél 16K-s lapokba vannak a cellák szervezve, nem 4K-ba. Ez az átlag usert nem érinti, mivel a modern particionálóprogik és telepítők továbbra is úgy alignálnak, hogy mindenfajta eszköznek megfeleljen tekintet nélkül a fizikai szektorméretre, az OS felé meg tudják a 0,5K-s módot emulálni (egy szektor 512 bájt sémát). A lényeg, hogy ilyen DOS-os meg meg Win9x-es progikkal nem szabad particionálni, meg XP és annál régebbi Windows telepítőjével sem, azok a partíciókat 63-mal osztható szektoron kezdik, mivel a HDD-ken egy sávban 63 szektor volt. Ez az SSD-nek nem jó, jelentősen belassul tőle.
-
Az msata SSD tényleg drágább, 15 alatt nem is nagyon van jó minőségű 12GB-os. Amúgy jelennek meg még újak ezzel a csatolóval is, van még időd válogatni.
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez
Ez ki is ment a fejemből, ebből is látszik, milyen elavult a Win fájlrendszere......
3D TLC-s SSD-kről épp nemrég olvastam, nem olcsók, átlagfelhasználó elvan egy mezei SSD-vel is, én az elsőt pont akkor vettem, mikor kifutó lett az Intel 520 10GB, a laptopba meg vettem egy használt Fury 120-ast. Ezek elketyegnek még jó darabig. 16K-s meg a többi align-ról még nem is hallottam, ezért jó, hogy legalább valaki követi az SSD totyikot!
-
Frawly
veterán
válasz
ubyegon2 #5221 üzenetére
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez, ami ha rájön az overprovisioningre, akkor az már magában elegendő lehet. Ezt a szabad hely hagyása igazából windowsos usereknél fontos.
Második OS futtatására venném, jelenleg egy külső SSD-t használok erre, de az kicsi (64 GB), és idegesít, hogy lóg ki a gépből USB-SATA átalakítós kanócon. A ThinkPad X220-amba már benne van egy SATA SSD, így már csak mSATA-nak marad hely. Viszont ez egy elavult, kifutott csatolófelület, egyre inkább nem kapni, ami van, az is drága.
A 3D TLC-s SSD-k még a 4K AF-es HDD-knél is jobbak, mert 16K-s alignálást igényelnek. A több pedig jobb
Persze nem kell aggódni, mert a modern particionálóprogramok, OS telepítők 1024K-n alignálnak (2048-cal osztható szektoron kezdődnek a partíciók, azaz egész MB-os határon), ami megfelel az 1K, 2K, 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K, 1024K-s alignálásnak is, mivel ezekkel is osztható maradék nélkül.
-
OP-re 8-27 százalékot célszerű tartalékolni, de ez bőven megvan a gyári lefoglalással is, mert nem valószínű, hogy 100 százalékig teletömöd a többi részt a meghajtón. De ha mégis, a 120GB-os még így is jól lesz.
Sokan totál értelmetlenül hagynak még pluszban ki helyet, mert nem tudják, hogy az ő SSD-jük is 128-as a valóságban.HDD-ből az AF-es a jó, az már 4k-s, WD1003FZEX például.
Ha valaki akkora idióta, hogy csurig pakolja a meghajtóját, akár HDD-n is.......
Amúgy msata-s SSD-t tárolásra akarsz venni a laptopodba? (az árát említetted, ezért gondoltam)
ATA jelszavas titkosítás ez jó móka, ha elfelejted a jelszót.
-
Frawly
veterán
válasz
ubyegon2 #5219 üzenetére
Na, látod, azt nem tudtam, hogy a tartalék területet overprovisioningnek hívják. Az viszont vitatott, hogy egy 120 gigás meghajtónál 8 giga elég-e. Valamennyit biztosan segít, de hogy milyen mértékben, az vitatható.
Azt én sem szoktam javasolni, hogy particionálatlan helyet hagyjunk. Csak abban a speciális esetben jó, ha nagyon laikus felhasználóhoz kerül az SSD, akinek nem lesz adattárolási fegyelme, és állandóan csurig pakolva használja az SSD-t. Aki viszont nem ilyen, ne hagyjon particionálatlan helyet az SSD-n, csak arra figyeljen, hogy ne legyen állandóan csurig, legyen rajta tartósan legalább kb. 10% hely (néha be lehet menni ezalá, de ne legyen tartós állapot). Jobb, ha ez a szabad terület a partíción van meg, mintha partíción kívül. A hatása a wear levelingre mindkettő megoldásnak azonos.
Már a HDD-k sem örültek, ha csurig voltak töltve. Pedig azoknál nincs se TRIM, se wear leveling. Még a 4K alignálás sem csak a SSD-k specialitása. Igazából az SSD úgy kell használni, mintha HDD lenne. Egy plusz dologra kell figyelni, a TRIM menjen, meg pár havonta ránézni a SMART adatokra, nehogy valami bugos program írási kergekórt kapva szétírja. Meg ugye defragolni nem kell, de ez sem gond, mert Win7 és attól felfelé már alapból nem defragolja, Linuxon meg sose volt erőltetve a felhasználó tudtán kívül a defrag, ott neked kell futtatni, nincs az, hogy véletlenül lefutott, mert nem akadályoztad meg, elfelejtetted letiltani.
Így ha lehet is az SSD-vel bonyodalom, az csak a TRIM körül lehet, esetleg az ATA jelszavas titkosítás terén (de az meg megint lehet HDD-nél is).
-
Nincs nekem ezzel gondom, inkább örülök, ha valaki képben van az SSD dolgaival kapcsolatban, mert bár már nem annyira féltjük, mert tudjuk, hogy mindent kibír, a vezérlő adja meg magát úgyis. Ettől még jó, ha tudja a felhasználó, mi micsoda. Hányan tudják szerinted, mi a különbség a 120 és 128 gigás meghajtók között? Mi az overprovisioning?
Te és sokan tudjátok ezeket, de legtöbben nem. Ez viszont helytelen, de legalábbis értelmetlen felhasználói szokásokat alakíthat ki! Feleslegesen hagynak particionálatlan területeket például előbbiek, de akár a trim miatt is.
Szóval csak legyél képben!Én már nagyon nem vagyok, nem mint ha.....
(szerintem, mivel én sem értek hozzá)
-
Frawly
veterán
Pedig ugyanazt mondjuk, azért nem volt vita. Azt is elismertem, hogy pontatlanul használtam a fogalmakat, ebben sem volt vita. A lényeg lényegén meg amúgy sem változtat, Samu 850-en nem jó ötlet a discard TRIM-et erőltetni, és az is tény, hogy nem veszteni semmit a hiányával, de ha ez utóbbiakkal nem értesz egyet, cáfolhatsz nyugodtan. Érdemi cáfolatra gondoltam, nem elnevezéseken lovaglásra, azon túlvagyunk.
De ha már Gyurmafigura paprikás kedvében van, akkor mégis húznám még azzal az idegeit, hogy a security erase is trimmelés lényegében, és annak is van kétféle változata, egy rövidebb, és a meghajtó teljes felületén végrehajtott. A rövidebb azoknál a meghajtóknál lehetséges, amelyek támogatnak öntitkosítást. De a security erase-t nem a kernel intézi, hanem az SSD vezérlője, ha erre kap parancsot.
Júbájgön: az EFI partíció FAT32-es, bár az elméletileg nem igényel trimmelést, mert egyszer ráírod, ami rákerül, utána nem nagyon történik róla törlés, csak néha felülírás kernelfrissítéskor (initramfs, fallback). Egyébként másra nem használnék FAT-ot, NTFS partícióm sincs (jó, vagy egy nyomorult darab egy külső meghajtón). Viszont nem kerülne semmibe lefejleszteni, hogy az fstrim vigye a FAT-ot is, soha nem tudni mikor jön jól, elfér, ha tudja. Nem lenne bonyolult implementálni, lényegében a FAT a legegyszerűbb létező fájlrendszer a swap után, már ha utóbbit lehet fájlrendszernek tekinteni.
Az fstrim-nél meg nem értem, hogy miért lenne nekem kötelességem rájönni a futási sebesség rejtélyeire. Tippem persze van. Első futáskor végignézi a fájlrendszer foglalási tábláit, megnézi, hogy mely szektorokhoz nem tartozik fájl, és ezekre mindegyikre kiküldi a TRIM parancsot, akkor is, ha ezek közül van olyan, ami már TRIM-elve van (tehát az adott partíció egész üres területét trimmeli). Második futásnál viszont a fájlfoglalási táblában az újonnan kiürült szektorokat keresi meg, és csak azokat trimmeli. Pedig még a forráskódjából is puskázhatnék, ha nem lennék lusta.
SSD topikot meg jó nyomon követni, melyik szériával mik a tapasztalatok, hogy alakulnak az árak. Egyszerűen tanulságos, még akkor is, ha nem akarsz SSD-t venni. Már pedig akarok (mSATA-s menne bele a fő gépembe 2. SSD-ként, már csak annak van hely), de nem találtam még jó áron. Nagyon fent vannak az árak, de nézelődök.
Persze emlékszem a fénykorodra, mikor te is aktívan részt vettél SSD-s flame-ekben, hogy pl. kell-e kímélni, le kell-e tiltani az atime-ot. Akkor azzal csesztettelek, hogy ki kell venni az SSD-t a gépből, betenni üvegvitrinbe, akkor nem kap sok írást. Csak ezzel azóta nem poénkodok, hogy pár helyről kiderült, hogy üvegvitrinben is bedöglenek ezek, épp úgy a vezérlő adja be a kulcsot.
-
Te amúgy érzel kényszert SSD-n FAT akármiről futtatni a rendszert?
Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára
Ezt pedig jó lenne, ha megfejtenéd!
Amennyit lebzselsz az SSD topikban, simán kideríthetnéd. Nagyon anno olvastam erről a témáról, de már nem emlékszem, mi volt a lényeg.
-
Frawly
veterán
Ilyen értelemben nem ugyanaz. Igazából ugyanazt mondjuk, csak a kifejezéseket használtam pontatlanul.
Ha nagyon a mélyére nézünk, TRIM-ből csak egy van. Ezt lehet kétféleképpen is kettébontani, attól függően, hogy milyen időbeli beosztásban van végrehajtva.
Az egyik a folyamatos TRIM (discard) a másik az időszakos (fstrim). Ez a felbontás Windows alatt is él, a Windows kernel (Win7 és attól felfelé) folyamatos TRIM-et alkalmaz (menet közben TRIM-el, mikor valami törlésre kerül, azzal együtt a TRIM parancsot is kiküldi), míg egy-két SSD-gyártónak és defrag progit fejlesztő szoftvercégnek van időszakos TRIM-es megoldása (ami viszont megy XP-n, Vistán is, ha a meghajtó és a driver tudja a TRIM-et).
Egy másik bontásban meg van a queued TRIM (a kiküldött TRIM parancsok későbbre ütemezve, kötegelve futnak) és a sima TRIM, aminek egyrészt ilyen terminológia miatt a felülete nem göcsörtös, és a TRIM parancsok valós időben hajtódnak végre, nem ütemeződnek kötegelt végrehajtásra.
Ezeket párokat keresztben is lehet párosítani, négyféle kombinációban. Kivéve, ha nem megy a queued TRIM, mert a kernelben tiltva van. Igazából még mindig áll, amit mondtam. A discard TRIM-et nem tanácsos használni feketelistás meghajtókon, mert nem kötegelve futnak, hanem azonnal hajtódnak végre valós időben egyenként, és ettől belassulhat a meghajtó. fstrim-nél ez mindegy, ahogy írtátok, „kevésbé zavaró”.
Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára, akkor is, ha trimmelt meghajtón fut. A 2-3., stb. futásnál már 0 mp. alatt végez. Majd egy reboot, és újra az első futtatásra mintha újra végigtrimmelné az SSD üres szektoraihoz tartozó cellákat.
Pont a queued TRIM miatt vettem anno Crucial MX300-at. Két fontos szempont volt, tudjon ATA-jelszavazható hardveres AES öntitkosítást a meghajtó, és ne legyen feketelistán a meghajtó queued TRIM ügyében. A Samsung 840, 850 emiatt esett ki, öntitkosítást tud, de a queued TRIM tiltva van. Kiderült, hogy felesleges volt aggódni, mert csak fstrim-et használva is normálisan trimelődik a meghajtó, és nem baj, ha nem használjuk a discard paramétert.
Igazából pedig a feketelistás meghajtók is tudnák, de firmwarehiba miatt okozna a használata anomáliát, ezért van a kernelben szoftveres úton letiltva. Ami duplán meglepő, hogy az illető SSD-k gyártói nem akarják ez ellen a firmware-t patchelni. Tudom, a Linux marginális platform, 0%-os részesedés, a kutya nem használja, mert csak a Windows a tuti. Az néha kísérletezik vele, akinek nincs pénze Mac-re vagy Windows licencre, de előbb-utóbb ők is letörlik, és ChromeOS-t vagy Androidot tesznek fel.
A másik, amit nem értek, hogy az fstrim miért nem támogat minden fájlrendszert. Olyan egyszerűt pl. mint a különböző altípusú FAT fájlrendszerek. A discard támogatja, az fstrim nem. Így ha valaki ilyen fájlrendszert akar trimmelni, feketelistás meghajtón is használni kell a discard TRIM-et.
-
BoB
Topikgazda
Nem megy a queued trim mert a kernelben le van tiltva, ahogy a legutóbbi hosszabb írásomban írtam, de látom hasztalan volt
Mégegyszer: a discard nem a queued trim-et állítja be, hanem alapvetően a trim-et, ha a meghajtó tudja azt akkor azt. Ugyanaz mint az fstrim csak folyamatosan megy.
Szerk. Vargalex éppen megelőzött
-
vargalex
félisten
Szia!
A queued trim <> continuous trim. Előbbi akár ütemezett, akár folyamatos trim esetén működik, ha tudja a drive és nincs blacklist-en. Sajnos a 850 esetében blacklist-en van, azaz a hagyományos blokkoló trim működik. Ekkor is használható mindkét módszer (continuous trim - discard, illetve periodic trim - fstrim.service, vagy kézi futtatás), csak a blokkolás miatt talán a periodic kevésbé zavaró.
-
Frawly
veterán
válasz
vargalex #5208 üzenetére
De, 8xx-es Samsungon is megy a queued TRIM, de teljesítményvesztés léphet fel, ezért nem érdemes használni. Ez csak azzal jár, hogy a mount opciók között nem szerepelteted a discard-ot.
A hiánya egyáltalán nem fájó. Bőven elég, ha az fstrim-et használod helyette, vagy fstrim systemd service engedélyezésével, vagy néha napján kézzel lefuttatva a sudo fstrim -a -v parancsot. Ezek a megoldások is rendesen TRIM-elik a meghajtót, semmi hátrány nem ér.
Fájlrendszernek XFS semmiképp. Vagy ext4, vagy f2fs. Mindkettővel van tapasztalatom. Mindkettő egyformán gyors. Az ext4 szerintem jobb, mivel az f2fs bootkor néha lassan ellenőrzi a fájlrendszert (fsck), az ext4-nél ez is villámgyors.
-
vargalex
félisten
Sziasztok!
Cégnél kaptam egy 500 GB-os SSD-t, így arra fogok a notebookon átköltözni. Kérdésem, hogy ki milyen filerendszert javasol? Nálam az XFS, illetve EXT4 merült fel. Persze más is lehetséges. Az szinte biztos, hogy LVM-en lesz.
Sajnos az SSD az egy Samsun 850 EVO, így a queued trim nem fog menni. Jobban járok a discard mount opció helyett az fstrim.service futtatásával? -
b3Ro
senior tag
Baratnomnek a laptopjan Ubuntu Mate figyel. Ukku-val szoktam frissitgetni neki a kernelt, es 4.16.3 megy neki tokeletesen, de a 4-5-6-7 mind hibat jelez bootkor, es itt meg is all. Szoval 3-as verzio szam folott azon a laposon azzal a rendszerrel nem megy. Ha ez jelentene valamit....
-
Slownz
senior tag
Megpróbálom itt is: katt
-
Frawly
veterán
Kösz a válaszokat. Jó tudni, hogy nem csak én szívok ilyennel akkor. Pedig tényleg teljesen támogatott Intel Wi-Fi kártyával tolom, ami megint csak a Linux kernel által teljesen támogatott üzleti szubnoteszben működik.
Korábbi kernelre nem váltok vissza, mert amúgy más baj nincs vele, és ezzel a netctl-es trükkel használható a rendszer, de kezd már frusztrálni, hogy az utóbbi időben túl sok baj van ezzel, ha így megy tovább, akkor át kell állnom Gentoora.
Egyébként ezt sem értem, mert ha a kernel lenne hibás, vagy a csomagkarbantartó hibázna, akkor nem lenne az, hogy a 4.16.x-es kernelek közül egyikkel jó lenne, a másikkal nem, hanem akkor mindig konzisztensen rossznak kéne lennie egy bizonyos verziószám fölött. De nincs így, egyszer megjavult, jó egy ideig, aztán megint előjön. Nagyon komolytalan ez így, mint egy hullámvasút.
-
b3Ro
senior tag
Par napja jott frissites Solus-ra, es jott vele a 4.16.7-es kernel. Aznap este felraktam, de masnap reggel mar jott is egy masik frissites, ami kernelt cserelt, a 4.15.18-67.current x86_64-ra. Lehet, h erdemes lenne megprobalnod, neked is vissza menni. Talan valami nem stimmel meg a 16-os vonalal
Új hozzászólás Aktív témák
Hirdetés
- Bowers/Wilkins PX8 fejhallgatók (dupla Bluetooth eszköz csatlakoztatása!) - ELKELTEK
- KATONAI ÜTÉSÁLLÓ!!! Getac S410 i5-6300u, G3: i5-8365u, G4: i5-1145G7
- BESZÁMÍTÁS! ASROCK H310CM i5 8400 16GB DDR4 256GB SSD 1TB HDD GTX 1060 3GB Rampage SHIVA TT 500W
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- LG 32GS95UE - 32" OLED / UHD 4K / 240Hz - 480Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest