-
Fototrend
Arch Linux topik
Új hozzászólás Aktív témák
-
válasz
Archttila
#7559
üzenetére
qbit-et ne sajnáld hogy nem megy pi-n, rettentő erőforrás zabló beágyazott eszközökön, pi-re/routerre jobb/stabilabb a transmission/rtorrent.
Próbálkoztam 1200GU-n qbit-tel de hosszabb rövidebb idő után mindig kilőtte a kernel memória hiányra hivatkoza, amíg ment rettentő magas volt a load, pedig az mt7621 egy 2c/4t proci ha jól tudom. -
Microsoft Edge dev AUR csomag
akit érdekel, ms fiókkal bejelentkezés/szinkronizálás sajnos még nem működik
-
Jó hír, végre megy a TBS6221 tuneremmel a V4L tree újrafordítást nem igénylő(pillanatok alatt lefordul) AlexanderS féle tbsecp3 driver
a tuneres topikban írtam róla, azt a hsz-t linkeltem be. -
Most frissítettem és ezek az üzenetek jöttek szembe:
Not setting net/ipv4/conf/all/rp_filter (explicit setting exists).
Not setting net/ipv4/conf/default/rp_filter (explicit setting exists).
Not setting net/ipv4/conf/all/accept_source_route (explicit setting exists).
Not setting net/ipv4/conf/default/accept_source_route (explicit setting exists).
Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists).
Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists).
Ezek mit jelentenek? -
Kellemes meglepetést okozott az Arch Linux!
A HUP fórumon olvastam ha be van kapcsolva a kernel módú PPPOE akkor a gyengébb gépeken is megy a gigabit PPPOE kapcsolattal. Na akkor gondoltam kipróbálom. Kde-t használok network managerrel. No akkor beállítjuk network manageren keresztül a közvetlen PPPOE kapcsolatot, írta a wiki hogy kell a rp-pppoe csomag, amikor felraktam akkor figyelmeztetett hogy új helyre került a kernel módú plugin és módosítsam a konfigot.
A leírásnak megfelelően módosítottam az /etc/ppp/pppoe.conf LINUX_PLUGIN sorát. Majd a Kde felületén keresztül beállítottam a network managerrel a PPPOE kapcsolatot. Gyorsan felkapcsolódott, majd mértem egyet a szelessav.net-en, valamivel 900mbit feletti sebességet mért
Ezt windows alatt nemigen tudtam összehozni, ha jól emlékszem ~300mbit jött ki router nélkül. -
válasz
attilav2
#6780
üzenetére
A pikaur man oldala meg is említi a notable features résznél amit szeretek benne:
interactively handle common build problems (like untrusted GPG key or checksum mismatch, wrong architecture)Míg a trizen-nél csak a --skipinteg kapcsoló áll rendelkezésre, nem kezeli interaktívan a leggyakoribb build problémákat.
BoB: Javaslom a yay-t próbáld meg, valószínű kiváltja mind2-t.
Ránézek -
Érdekes dolgot figyeltem meg. Ha pikaur-ral próbálom frissíteni a google-chrome aur csomagot akkor a frissítés megkezdése helyett "fagyott" állapotba kerül a pikaur, ctrl+c vel azért kilőhető. Minden más aur csomagot tud frissíteni a pikaur csak a google-chrome -on akad fenn. Kedvelem a pikaur-t mert ha valamelyik aur csomag aláírása nem stimmel (pl spotify) akkor erre az esetre egy rakat opciót felkínál és befejezhető a telepítés/frissítés. Kísérletképp felraktam a trizen-t, ez simán tudja frissíteni a google-chrome-t, viszont a spotify frissítésén elhasal az aláírás miatt, azt már a pikaur-ral kellett frissítenem.
Érdekes még az is hogy chromium-mal nem működik a chromecast, viszont a google-chrome-mal igen! Ezért raktam fel aur-ból a google-chrome-t. Vettem pár hónapja egy Xiaomi MiBox S-t, ez tudja a chromecast-ot, hivatalos androidtv van rajta.
-
A legutóbbi frissítések óta szebb lett a Kde felülete, és a háttérkép is változott (az alap hátteret használom) ez verzió váltásnál szokott változni. Nekem tetszik az új Kde kinézet
A discover ha kész a frissítés már nem azt írja hogy up to date hanem hogy naprakész, tehát a fordításon is reszeltek itt ott -
A 3 féle Vulkán illesztőprogram összehasonlítása, tesztelése a phoronixon
Mesa-Radv, Amdvlk-Open, és az amdgpu-pro vulkan drivere kerül tesztelésre különböző játékokkal.
Archon mind 3 vulkan implementáció elérhető: Link -
Igazad van, tényleg nem kell az AMDGPU PRO driver a Dirt4-hez, betölt a nyílt vulkan driverrel is, csak sokkal lassabban, utána már a játék sebességgel nincs gond. Nyílt vulkan driverrel legalább 3-5 perc amíg betölt a játék, míg amdgpu-pro és hozzá tartozó vulkan csomaggal szinte azonnal indul. Az amdgpu-pro-t és a hozzá tartozó vulkan drivert leszedtem, és felraktam az amdvlk opensource vulkan drivert, és valóban ezzel is megy a Dirt4. Sőt Debian buster alatt is tettem egy próbát a Dirt4-el, ott csak a mesa féle radeon vulkan driver érhető el, az amdvlk nem, a mesa vulkan-t felraktam és azzal is betöltődött a játék, persze itt is lassan töltött be, de utána játszható volt.
Az amdgpu-pro-nak van egy hátránya hogy a telepítése aur-ból nem valami gyors, ugyan nem forrásból teszi fel, hanem ubuntu 18.04-re való deb csomagokat szed le lassan valahonnan és ezt alakítja át arch kompatibilissé. Gondolom a frissítése se lehet túl gyors az amdgpu-pro aur csomagoknak.
Ki kellene deríteni miért tölt be lassabban a nyílt vulkan driverrel a dirt4, a googleban egyelőre nem találtam megoldást. -
Nem nagy ördöngősség az amdgpu pro, a wiki szerint ez egy userspace driver ami a nyílt amdgpu kerneldriver felett fut, a lényeg hogy ne fusson az X amikor telepítjük, mert akkor problémás a telepítés utáni első reboot mert szétesik a kép.
Egyébként linuxon Vulkan alatt jobb teljesítményt nyújt a Dirt4, high részletességgel tudom futtatni, míg windowson csak mediumon mert high-en már picit szaggat.
-
Egy érdekes jelenségre figyeltem fel, frissült a clementine és hiányolt egy protobuf libet nem indult, észrevettem hogy a protobuf csomag viszont nem frissült amiben van a kérdéses lib. Az arch oldalán a packages részen viszont látom hogy a protobuf frissült csak a mirrorok nem követték le. Letöltöttem a frissebb protobufot az arch oldaláról és pacman -U val helyi csomagként felraktam. Így már indult a clementine. Ezek szerint zavar van az arch mirror rendszerében. Hm... lehet hogy a clementine fork strawberry tartotta vissza a protobuf frissülését, mert most meg az nem indul, az eggyel régebbi libet hiányolja. Most ledúrtam a clementine-t majd a strawberry-t is, mindkettőt újraraktam, most mindkettő elindul, sőt a mirrorról már ezek frissebb verziói jöttek le. Néha zavar van az erőben
-
Hát az opensource driverrel nem fut a dirt4 csak töltikézik de nem történik semmi. Mindkét opensource vulkan implementációt kipróbáltam, egyikkel sem tölt be, visszaraktam az amdgpu-pro-t és a hozzá tartozó vulkan csomagot, ezzel már betöltődik és fut seperc alatt.
Úgyhogy komolyabb játékokhoz kell az amdgpu-pro meg a hozzá tartozó vulkan. -
Na túl vagyok egy Vulkan-os játékteszten. Karácsonyra kértem és kaptam egy AMD RX550 vga-t. Kipróbáltam a Dirt4-et linux alatt natívan. Jól fut eddig nem volt vele gond. Csak furcsa a játékmenet meg túlkormányzottak az autók, szinte mindig kisodródom. Felraktam az AMDgpu-pro-t meg a hozzá tartozó vulkan csomagot. Mikor újra akartam indítani a gépet akkor szétesett a kép, gondolom így újraindítás előtt a display manager(sddm) nem tudta még betölteni az új drivert, de egy reset után rendben elindult a rendszer és futott a Dirt4.
-
Én most nem a virtuális gépben történő wayland környezet tesztelésére gondoltam. Csak megemlítettem hogy éles rendszeren Arch plasma wayland session alatt nem fut a virtualbox, clementine, míg Debian éles renszeren plasma wayland session alatt fut a virtualbox és a clementine is.
-
A clementine-nak van egy forkja a strawberry, ez fut Arch plasma-wayland session alatt, viszont a virtualbox nem fut Archon plasma wayland alatt, míg debianon plasma wayland alatt fut, ahogy a clementine is. Aztán ott van a Kmplayer ez sem debianon se archon nem fut plasma wayland alatt.
Hogy van a strawberry arra úgy jöttem rá hogy kipróbáltam a solus linuxot virtualbox alatt és a clementine-t kerestem a tárolóban, de nem találta, helyette listázta a strawberry-t. -
Debianban jól működik a plasma wayland, megy a qt5 platform plugin, fut a clementine is. Arch alatt plasma wayland sessionben valamiért nem tőltődik be a qt5 platform plugin, és sok q5-ös app elcrashel. Megoldást nem találtam akárhogy túrom a google-t.
Most vettem egy crucial mx500 500gb-t hogy az Arch mellé felrakjam a debiant is állandóra, eddig egy 64gb os ssdn volt a debian. Az Arch meg egy 480g-s radeon r3 ssdn foglal helyet. A debianban kellemesen csalódtam, meglepően kevés utómunkát igényel telepítés után, és van egy kész desktopom. Csak a firmware-amd-graphics csomagot kellett felraknom hogy elunduljon az X, meg raktam backportsból 5.x-es kernelt. Non free firmware netinst iso-t használtam. Telepítés közben még a mount opciókat is ki lehetett választani többek közt a discardot és a noatime-t. Viszont a csomagok régebbiek egy Arch-hoz képest, de valamit valamiért. Nem érzem bloatnak a debiant, villámgyorsan bootol a rendszer a plasma desktoppal, kb az Arch-al egyszinten van bootidőben. A debian wiki sajnos a fasorban sincs az Arch-hoz képest. Párhuzamosan fogom használni a két rendszert. Így első blikkre az Arch tűnik egyszerűbbnek logikusabbnak. -
válasz
#63718632
#6290
üzenetére
Pamac-aur-ral jártam már úgy hogy egy csomagtelepítést vagy eltávolítást nem tudott megcsinálni, nem tartom megbízhatónak. Inkább a pacman, az a hivatalos megoldás, a grafikus csomagkezelők inkább arra jók hogy jelezzék ha van frissítés, vagy rákeresni egy csomagra kategóriák szerint. Telepíteni, frissíteni csak konzolból, pacmannal és valamelyik aur wrapperrel. A legszükségesebb kapcsolókat meg lehet jegyezni. A téma összefoglaló is írja a pacman alapvető kapcsolóit.
-
Valamelyik oldalon egy leírásban láttam és azóta buzgón használom csomagok föggőségekkel való eltávolítására a pacman -Rscn parancsot. Hát most ráfáztam egy kicsit.
Felraktam a gnome gnome-extra csomagokat egy próba erejéig, majd eltávolítottam őket a szokásos pacman -Rscn gnome gnome-extra paranccsal. Hát csak néztem hogy utána nem volt net! Hát eltávolításra került a Networkmanager is! Telefonon megnéztem hogyan kell bekonfigolni a systemd-networkd-t, ezzel gyorsan megvoltam lett megint net. Aztán megnéztem pacman man oldalát és a -c --cascade kapcsoló volt a bűnös
-c, --cascade
Remove all target packages, as well as all packages that depend on one or more target packages. This operation is recursive and must be used with care, since it can remove many
potentially needed packages.
Mostmár csak az -Rs kapcsolót fogom használni föggőségekkel együtt történő eltávolításra, ha csak ki nem megy a fejemből -
A Sway-t felraktam, ha elindítom csak egy üres asztalt kapok és a jobb egérgombra sem jön elő menü. Mit kell beállítsak, hol, hogy valamit el tudjak benne indítani?
qt5-wayland csomag telepítve van és a libek is megvannak a /usr/lib/qt/plugins/platforms
alatt de csak az xcb plugint tudja betölteni a plasma wayland session. Ez tuti valami Arch specifikus hiba. -
Kipróbáltam a fedora 31-est, borzalom
A telepítője, partícionálója is viszont a gnome alapból waylandes rajta.
Szerintem a SuSe-nak van a legnormálisabb telepítője, partícionálója, és a majdnem fullosan működő Plasma wayland session is jó pont(a firefox kifagy alatta de minden más pl clementine is, megy). Archon azért nem fut a clementine és egy sor másik QT5 app Plasma waylanden mert a rendszer nem tudja betölteni a qt wayland platform plugint, sokat googleztam a hibaüzenetre, meg is próbáltam a talált megoldásokat de semmi nem segített.
Egyedül úgy működik majd' minden QT-s app waylanden ha a QT_QPA_PLATFORM=xcb változó be van töltve az /etc/environments-ben. De ezzel agyon is van vágva a wayland, mert így ugyan futnak az eddig nem futó Qt alkalmazások waylanden, de fagyogatnak egy idő után.
Amúgy a wiki QT5 alkalmazásokhoz a QT_QPA_PLATFORM=wayland-egl változót ajánlja vagy lehet még jó a QT_QPA_PLATFORM=wayland is, de ezeket a plugineket nem tudja betölteni Arch-on a plasma. Ha a QT_QPA_PLATFORM=xcb változó be van kapcsolva akkor a szokásos méretű az egérkurzor, de ha ez a változó nincs bekapcsolva(ez az alapértelmezés) akkor az egérkurzor nagy méretű, ez jelzi ha tiszta plasma wayland sessionben vagyunk X emuláció nélkül. Tumbleweed-en nagyméretű volt az egérkurzor a Plasma wayland sessionban, tehát nem volt bekacsolva az X emuláció a QT5 appoknak, a clementine így is szépen futott. -
Rájöttem hogy a a grafikus gyorsításért, megjelenítésért, a mesa driverek (mesa mesa-vdpau libva-mesa-driver) felelnek. Az én kártyámnál konkrétan a r600-as driver, ez az Xorg.0.log-ból derült ki. Ha nincs feltelepítve az xf86-video-ati (radeon driver) illetve nincs /etc/X11/xorg.conf.d/20-radeon.conf akkor is vígan indul az X van vdpau meg vaapi, sőt 3d is. Akkor ez azt jelenti hogy az xf86-video-ati csomag teljesen felesleges? De adak ki az új kártyáthoz xf86-video-amdgpu Xorg drivert, akkor az is felesleges akinek újabb radeonja van mert a mesa úgyis megoldja? Waylandnál ha jól gondolom akkor mindent a mesa intéz.
-
válasz
Shyciii
#6250
üzenetére
Igen az Arch elég gyorsan megvan a frissítéssel, ha dkms kernelmoduljaid vannak (pl vmware hez kell) akkor kicsit tovább tart a frissítés, feltéve hogy a kernel is frissül. Tumbleweed-en hosszabb a frissítési idő, csak néhány naponta érkeznek frissítések és sok csomag frissül egyszerre, nomeg a zypper lassabb mint a pacman.
-
Úgy telepítettem a Kde-t ahogy kellett.
pacman -S plasma, pacman -S plasma-wayland-session + a mesa csomagok, az xwaylandet is behúzta azthiszem.
A plasma metacsomag egyébként koránt sem tesz fel mindent, pl a konsole-t sem. A plasma meta csomag teszi fel a legtöbb összetevőt azthiszem, de egy tumbleweed kde alaptelepítéshez képest azért még mindig elég szegényes. -
-
Most próbaképp telepítettem az Arch-ot a kisebbik 64GB-os ssdm-re a 480G-oson a Tumbleweed egyelőre marad. Sokkal rövidebb idő alatt végeztem az Arch telepítésével mint a Tumbleweed ével. Waylandos Kde-t terveztem kipróbálni Arch-on, így xorg ot fel sem raktam csak a plasmát a plasma wayland session-t meg a szükséges mesa csomagokat. A wikiben leírtak szerint indult a Kde waylanddal! A Tumbleweed tényleg bloat az Arch-hoz képest, de össze akarom hasonlítani a két rolling disztrót. Vaapi gyorsítás wayland alatt vainfo szerint működik, vdpau viszont nem, ez ugyanígy van tumbleweed-en is.
-
Nem vagyok expert linuxos, ezért a fájlrendszer jogokhoz nem nagyon értek, csak a chown paramétereit tudom ha valamit saját tulajdonba szeretnék venni akkor: chown -R felhasznalo:users, vagy ha root nak akarom adni akkor root:root ot írok, chmod paramétereit nem ismerem, shell scriptekhez sem értek, így nem is tudnám a chromium ubuntu dev ppa branch csomagjait makepkg scriptbe bedolgozni :)) 3 deb ből kellene arch csomagot gyártani maga a chromium, az ffmpeg-extra, és a lokalizációs csomag, ja és a legújabb 19.10 es ubuntus chromium dev csomagokat kellene átültetni, valaki a fórumról csinálhatna makepkg scriptet :)) Az arch-ot azért tudom egyébként feltelepíteni mert nagyon jó wikije van, és megvan a logikai érzékem hozzá. A tumbleweedben az tetszik hogy csak pár naponta kap frissítéseket, nem olyan nagy a tempo mint az Arch nál, kevesebbet változtatnak szerintem. Kulcsrakész desktop rendszert ad telepítés után, nem kell találgatnom mik az éppen hiányzó kde/egyéb csomagok, meghát az is közrejátszott a váltásban hogy lusta vagyok, az Arch al mindig van egy kis utómunka, meg hajt a kíváncsiság. Gentoo nekem magas, nem szeretek sok időt szánni a fordítgatásokra. Épp elég hogy a tv kártyám (tbs márkájú) opensource drivere vagy fél óráig fordul mert saját v4l tree-t fordít, minden kernel váltásnál újra kellene fordítani, ezért nem is üzemelem be sokszor linux alatt a tv kártyámat.
-
Az ubuntu dev chromiumot manuálisan bemásoltam arch alá, csak utána volt egy kis szívás a rendszerkönyvtárak jogaival, ami miatt az ufw leállt, helyrehoztam. De macerás minden chromium frissítésnál másolgatni meg jogokat állítgatni. Majd ha kijavítják arch-on a chromium vaapi -t akkkor lehet visszatérek.
-
Hoppoltam tumbleweed-re, majd meglátom mennyire válik be. Az tetszik benne hogy kevés reszeléssel kapok egy kulcsrakész rendszert, és a chromiumban van működő vaapi támogatás!
-
-
válasz
Siriusb
#6175
üzenetére
Én pl azért raktam Grub-ot systemd-boot helyett, mikor egy Kubuntus próbálkozás után újraraktam az Arch-ot, mert a Grub képes egy másik lemezen lévő OS-t(gyk Windows) is indítani. Míg a systemd-boot csak akkor képes erre ha a windows efi partíciójáról a microsoft könyvtárat átmásolom az Arch efi partíciójára. Nem túl elegáns megoldás de így érzékeli a systemd-boot a windowst és megjelenik a menüben és el is indítja a másik lemezről. Hátránya ennek a megoldásnak hogy a Bios(uefi) menüben így kétszer jelenik meg a windows boot manager bejegyzés, ezt el akartam kerülni, ezért raktam Grub-ot. A windowsos indítómenü hozzáadása a grub hoz úgy nézett ki hogy felcsatoltam a windowsos lemez efi partícióját a /mnt alá, futtattam az os-prober-t, kiírta hogy felismerte a windows efi betöltőjét, aztán a szokásos grub-mkconfig -o /boot/grub/grub.cfg ami szépen hozzáadta a windows indítómenüt. Nem olyan rossz a Grub, custom menük hozzáadására is van lehetőség, az Arch wiki grub pontja ír néhány példát, pl Efi(Bios) menübe lépés, én ezt hozzáadtam, és prímán működik, ha rányomok akkor az EFI-be dob a gép újraindulás után. Bár tény hogy a systemd-boot-ban alapból van efi-be lépés menü.
-
Egyelőre biztos nem váltok, pl a Gufw nem elérhető tumbleweed-re, csak instabil tárolóból lehetne feltenni, ez nem tetszik. Kénytelen voltam parancssorból konfigolni az Ufw-t, de nem volt nehéz a google adott leírásokat. Meg az sem tetszik hogy a videólejátszáshoz külső tárolókat kell hozzáadni, pl packman, vlc, amik esetleg összeakadhatnak a gyári csomagokkal egy frissítéskor. Egyelőre nem is raktam be külső tárolókat. Az viszont tetszik hogy a chromium alapból vaapi támogatással van forgatva és működik is a hw videó gyorsítás. Igazából a kíváncsiság hajtott a SuSe kipróbálására, utoljára a linux hőskorában a 2000-es évek legelején használtam SuSe-t és érdekelt azóta mennyit változott.
-
válasz
attilav2
#6159
üzenetére
OpenSuse Tumbleweed tapasztalataim a Suse topikban:
Hosszászólás linkje, Suse topik -
Próbálgatom az OpenSuse Tumbleweed-et virtualboxban mert kiváncsi vagyok
Messze nincs ennyire jó wikije mint az Arch-nak. Frissíteni sem akar pedig már kijött belőle egy a telepítésemhez képest két nappal frissebb iso, ennek ellenére a zypper nem talál frisebb csomagokat. Szerintem Az Arch a világ legjobb linuxa! 
Legáttekinhetőbb rendszer, legjobb wiki. Megérdemelné a distrowatch-on a tartós első helyezést. Most az első ötben vannak az Arch és származékai:
https://distrowatch.com/dwres.php?resource=ranking
https://distrowatch.com/dwres.php?resource=popularity -
válasz
attilav2
#6106
üzenetére
Felraktam a haveged csomagot és elindítottam a service-jét, ez úgytűnik megoldotta a gss.proxy-ra várást grafikus belejentkezés esetén, valamilyen random number generator kell az nfs egyik függőségének, ha nincs TPM akkor a haveged-et ajánlja a wiki. kwallet beállításra meg a kwalletmanagert ajánlja a wiki.
-
Ma reggel jól felbosszantott az arch! Már azthittem mindent jól beállítottam, nfs, tűzfal, torrent. Beállítottam az sddm display managert mert kde-t használok. Hát újraindításnál azzal örvendeztet meg a rendszer hogy a gss proxy-ra vár ami az nfs-utils függősége így leszedni sem tudom mert akkor le kell szedjem az nfs-t is. Kb 10-15mp-et vár a gss proxy-ra indításkor ha a display manager be van kapcsolva, kikapcsoltam most gyorsan bebootol csak nincs grafikus bejelentkezés. Hogy tudom ezt a gssproxy-t debugolni hogy miért tartja fel a boot-ot bekapcsolt sddm esetén? Másik problémám a kwallet ami a chrome indulásakor jelszót kér, pedig nem is adtam meg semmilyet, és kijelentkezteti a chrome-ot a google accountból. Hogyan szabadulhatok meg a kwallet-tól?
-
Sajnos nemcsak ntfs-ről ext4-re másolásnál nyaldossa a 100%-ot a proci, hanem egy izmosabb gigabites torrent letöltésnél is, két 26 gb-os filmet töltöttem le, jöttek lefele úgy 60-80megabájt/s-el és legalább egy procimag a 4ből szinte mindig 100%-on volt a Ksysguard szerint. Kde-t használok. A proci X4 860K, 8GB ram, a rendszer egy Radeon R3 480GB ssd-n van. A kliens qbittorrent. Bár talán nem volt annyira drámai a rendszerlassulás a letöltés ideje alatt Arch alatt, mint Kubuntu alatt.
-
Kipróbáltam a Kubuntut a hardveresen gyorsított chromium-beta chromium-dev miatt, de végülis nem tetszett a rendszer filozófiája, vissza tértem az Arch-ra, amit megint uefi telepítéssel raktam fel. Ezúttal viszont grub-ot raktam fel systemd-boot helyett és a másik lemezen levő szintén uefi módú windowst az os-prober segítségével adtam hozzá a grub menüjéhez ezen leírás szerint, működik. Nem kellett átmásolni a Microsoft mappát a windows efi partíciójáról /boot/EFI alá mint systemd-boot-nál, így nem jelenik meg kétszer a windows boot manager az alaplap menüjében. A grub és az os-prober ezt kultúráltabban megoldja.
Viszont egy negatív jelenséget felfedeztem ami sajnos érinti az Arch-ot és a (K)ubuntu-t is, hogy mikor átmásoltam a zenéimet (több tíz giga) az ntfs-es adattáróló lemezről a linuxos lemezre akkor közel 100% körül volt a prociterhelés(Pedig mindkét lemez ssd). Keresgéltem a google-ban de megoldást nem igazán találtam erre. -
Le is zavartam gyorsan egy Arch telepítést virtuális gépben hogy kipróbáljam működik e a megváltozott feltételekkel az install. Működik.
A base rendszer felrakása pacstrap '/mnt base' helyett így néz ki: 'pacstrap /mnt base linux'
a nano szövegszerkesztő már nem része a telepítőnek, az alaprendszer felrakása és chroot olás után lehet felrakni. Az mkinitcpio parancs paraméterezése is kicsit változott: 'mkinitcpio -p linux' (asszem ez volt régen) helyett csak simán 'mkinitcpio -P' -
válasz
wwenigma
#6004
üzenetére
Grubnál elég egyszerű hozzáadni az Lts kernelt, az lts kernel telepítése után:
grub-mkconfig -o /boot/grub/grub.cfg
Ezzel alapból az lts kernellel fog indulni azthiszem. De kiválasztható marad a sima kernel is ha jól emlékszem. Már systemd-boot-ot használok ott picit macerásabb hozzáadni új kernelt, de nem bonyolult az sem. -
Itt van egy kép a felgányolt ubuntus dev-chromiumról, így néz ki ha elérhető a hardveres video gyorsítás chromium alatt:
"Hardware-accelerated video decode" beállítás elérhető és be van kapcsolva.A sima chromium és a chromium-vaapi-bin csomagoknál a "Hardware-accelerated video decode" beállítás a chrome://flags fülön az unavailable részen tanyázik és be sem lehet kapcsolni
-
válasz
Shyciii
#5979
üzenetére
_Nem működik_ sima chromium alatt a hardveres videógyorsítás, akármit is írjon a chrome://gpu alatt. A chrome://flags alatt az unavailable résznél van a hardware video decode, be se lehet kapcsolni. 1080P 60fps youtube videó 30-50% proci terhelés, szóval sima chromium alatt semmilyen videógyorsítás nincs. A chromium-vaapi-bin aur-os chromiumnál sincs vga gyorsítás. Aki gyorsítást akar az felgányolja az ubuntus dev-chromiumot ahogy fentebb írtam. Vagy lefordítja az aur-os chromium-dev csomagot csak győzze kivárni.
-
Most húztam fel magam a Mate-n, totál bugos
Ezt Link a videót követve próbáltam a mate-t testreszabni, az aur-os mate-menu-t(Advanced mate menu) hozzá sem adta a tálcához hiába nyomkodtam a hozzáadást, sebaj felraktam a brisk menu-t is, hozzáadtam azt, de egy ki és bejelentkezés után totál üres tálca fogadott. Le is dúrtam a mate-t. Kde-vel komolyabb gondom még nem volt, marad az. -
válasz
Shyciii
#5977
üzenetére
Pontosan milyen vga-d van?
Ez lényeges, mertlinkeltem egy hivatalos Arch fórumos threadet valamelyik fentebbi hsz-ban ahol panaszkodnak hogy nem megy náluk a hw video gyorsítás sima chromiummal egyes intel, nvidia és amd vga-kkal. Ha megnézed a chrome://flags -ot akkor a hw accelerated video decode vagy vmi ilyesmi, enabled -en van? -
Néztem htop-al a különbséget, firefoxnál ahol nincs hw videó gyorsítás 40-50% között terhelődtek a processzor magok youtube 1080P 60FPS videó lejátszásakor, chromium-dev -nél ugyanez a videó 15% prociterheléssel ment. Nálam fenn van mind firefoxban mind chromiumban a h264ify plugin, ez kényszeríti a youtubeot hogy h264-ben renderelje a videókat vp9 helyett. A vga-m csak h264 dekódolást támogat, de szoftveres dekódolásnál is jól jön a h264 ify, mert a legtöbb procinak jobban fekszik a h264 mint a vp9. Szerintem te is rakd fel a h264ify-t ha még nincs fenn.
-
Igazából a kíváncsiság vezérelt hogyha felrakom az ubuntu alá forgatott chromium-dev verziót akkor működni fog e a hardveres videó gyorsítás, mert kubuntun a chromium-dev -el simán megy, és ahogy sejtettem arch-on is simán megy a videógyorsítás chromium-dev verzióval. Nomeg az ubuntus chromium-dev felrakásával fordítási időt is akartam spórolni, mert van ugyan az aur-ban chromium-dev de csak forrásból lehet feltenni, chromium fordításra meg horror időket írnak a neten ilyen alap procikkal ami egy átlagembernek van.
Egyébként meg az X4 860K, de gondolom a legtöbb mai alap proci is csak kihajtja rendesen vga nélkül is az 1080P-t, a 860K kihajtja, szóval nekem felesleges lett volna dev-chromium felrakásával bíbelődnöm de hajtott a kíváncsiság. A linuxos firefoxban sincs hw videó gyorsítás, elvileg mostanában rakják majd bele. Ha neked is elmegy az 1080p youtube cpu-ból akkor felesleges dev chromiummal bíbelődnöd szerintem. De ha kíváncsi vagy hogy nálad is működik e a hw videó gyorsítás akkor hajrá!Arch-on ezzel a patchelt aur-os chromium-vaapi-bin -el van a gond, hogy a patchet nem megfelelően alkalmazzák nem aktualizálják az aktuális mesa-nak megfelelően, és az arch fórum topikban amit linkeltem ezt szóvá is tették. Az kellene itt is mint ubuntun, kellene egy build szerver amin mindig lefordulnak a legújabb chromium-dev buildek, ezt az arch közösség szerintem meg tudná finanszírozni.
-
Ezt a két csomagot
chromium-browser_78.0.3902.4-0ubuntu1~ppa3~19.10.1_amd64.deb
chromium-codecs-ffmpeg-extra_78.0.3902.4-0ubuntu1~ppa3~19.10.1_amd64.deb
kell letölteni innen: https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-dev/+packagesAmikor megnyitjuk a deb csomagokat az Ark-al akkor fogunk találni bennük egy data.tar.xz -t, ha megnyitjuk akkor akkor egy etc és egy usr mappát találunk benne, csomagoljuk ki az etc tartalmát az /etc -be az usr tartalmát az /usr -be
A dev chromium máris indítható a chromium-browser paranccsal. De érdmes paraméterekkel indítani különben youtube-on nézhetetlen lesz a kép hardveres gyorsítással(ez alapból be van kapcsolva ebben a buildben).
Így indítsuk: allow_rgb10_configs=false chromium-browser --enable-gpu-rasterization --ignore-gpu-blacklist --disable-gpu-driver-workaroundsAz allow_rgb_10_configs=false változó nagyon fontos mert enélkül szar lesz a kép youtube-on.
-
Talán chromium-dev csomaggal megoldódna a videó és egyéb gyorsítás, viszont ott meg nem működik a google fiókkal szinkronizálás, de ez legyen a legkisebb gond.
Csak kellene csinálni egy bináris csomagot valakinek rendszeresen, kellene egy build szerver amin automatikusan fordulnak a chromium-dev csomagok arch-ra. -
Nem működik nálam a hardveres gyorsítás a chromium-vaapi-bin aur csomagos chromiummal, Radeon 6670-nel. Valami gond van a csomaggal mert az Arch fórumban vitatkoznak róla:
Link
Régen még működött a hardveres videógyorsítás nálam ezzel a csomaggal, mostmár nem
Akármit csinálok.
Vaapi működik rendesen:
[attilav@Attilav-PC ~]$ vainfo
vainfo: VA-API version: 1.5 (libva 2.5.0)
vainfo: Driver version: Mesa Gallium driver 19.1.7 for AMD TURKS (DRM 2.50.0 / 5.3.1-arch1-1-ARCH, LLVM 8.0.1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProcAmit az Arch fórumban írnak aszerint a gallium platformot is érinti a probléma. Szomorú vagyok
Kubuntu alatt bezzeg működik a vga gyorsítás, ha felrakom a chromium dev branch ppa-ról a dev chromiumot. Kicsit csalódtam az Arch-ban. Az arch fórumos threadben liewkj javasolt egy patchet amivel a hiba javítható lenne, de vagy nem akarja alkalmazni a fejlesztő vagy nem reagál.Próbáltam aur-ból chromium-dev verziót forgatni, abban a reményben ha Kubuntu alatt megy vele a gyorsítás akkor Arch-on is működni fog, el is kezdtem, de a rákerestem a google-ba a fordítási időre és ilyen 7-13 órákat írnak, úgyhogy meg is szakítottam a fordítást. Kubuntu-ra van bináris chromium-dev csomag, Arch-ra nincs
Nincs valami izmos procim ilyen nagy fordításhoz, csak egy X4 860k-m -
Na túlestem rajta megvolt a windows újratelepítése EFI módban (természetesen leválasztottam minden linuxos efi-s meghajtót a windows telepítése idejére, ahogy a fentebb linkelt leírás is említi:
"You can copy the "/EFI/Microsoft" folder from the EFI partition on the Windows drive into the EFI partition of your Arch drive. The systemd-boot loader will then automatically add an entry for Windows to its menu.
That new menu entry will start Microsoft's boot loader. Inside that "Microsoft" folder you copied, that loader will have all files it needs to be able to boot the Windows that's on the other drive.
This idea requires that you have two EFI partitions, one on each drive. To make this happen, you have to disconnect the Arch drive while you install Windows. The Windows installer will then create a new EFI partition on that drive."
Az UEFI módú windows telepítés létrehoz egy rakat partíciót, de linux alatt az fdisk -l megmondja melyik a windows efi partíció. Ennek felcsatolása és a /EFI/Microsoft könyvtár átmásolása az Arch-os lemezre a /boot/EFI/Microsoft helyre, egy újraindítás és már ott is van a systemd bootloader menüjében a windows, és szépen el is indítja a windowst a másik lemezről. Nem kell a windowsos lemezen a windowsos bootloaderrel szenvedni hogy az töltse be a linuxot, ez a megoldás sokkal elegánsabb.
Az windows driver aláírásellenőrzését is sikerült kikapcsolni a "bcdedit /set nointegritychecks on" paranccsal, így a tunerkártya drivere sem problémázik uefi módban, a leírást itt láttam:
Link
Persze linux alatt simán működik a tunerkártya uefi módban mindenféle driver aláírásellenőrzés nélkül, ez a linux egyik előnye. Csak minden kernelfrissítéskor újra kell forgatnom a driverét, ami elég sokáig tart, mert teljes v4l tree-t is forgat.(https://github.com/tbsdtv/linux_media/wiki) működő dkms megoldás még nincs a TBS6221-hez. a Tbs-ecp-dkms driver az aur-ból amit ajánlanak nem támogatja ezt a kártyát sajnos. -
Összeszedtem minden angol tudásom és találtam egy reddit szálat ami már azt boncolgatja amit én akarok:
Dual-boot Arch and Windows on separate drives with systemd-boot?
Elovastam, amit itt írnak az tűnik működőképes megoldásnak. -
Na találtam is valamit Windows systemd-boot ügyben.
Link
itt thomasamadeusking hozzászólását kell nézni.
Kreálni kell egy új entry fájlt a /boot/loader/entries alá, pl /boot/loader/entries/windows.conf
Ennek a tartalma meg:
title Windows
efi /EFI/Microsoft/Boot/bootmgfw.efiEhhez meg nyilván létre kell hozni a /EFI/Microsoft/Boot könyvtárakat a linuxos lemez efi partícióján, aztán a windowsos lemez efi partíciójáról be kell másolni a bootmgfw.efi-t a linuxos lemez efi partíciójának /EFI/Microsoft/Boot könyvtárába.
Elméletileg így már indítható is a windows a linuxos lemezről, de csak elméletileg. Mert ugyan biztos lefut a windows efi alkalmazás de mivel másik diszkről indul, nem fogja megtalálni a windows rendszerpartícióját. Persze aztán lehet hogy megtalálja és betölt a windows, de murphy törvénye alapján inkább nem
Update: Illetve nem is kell ennyi marcera, a bootmgfw.efi fájlt egyszerűen bele kell rakni egy tetszőleges könyvtárba a linuxos lemez efi partícióján és aztán meghivatkozni a (boot)/loader/entries/windows.conf fájlban.Arch systemd-boot wikiben is van utalás erre a megoldásra, még ha nem is szó szerint:
Még meg kell ezt gondolnom, mert már telepítettem efi módban a windows10-et, és a tunerkártya drivere nem szerette, aláíratlannak(érvénytelen aláírás) mutatta magát és letiltotta a windows, az aláírásellenőrzést ugyan macerásan de ki lehet kapcsolni(nekem nem sikerült állandóra csak egy egy alkalomra, ennek is utána kell nézni), de még kékhalálozott is asszem. Ugyanez a driver mbr módú windowson persze megy normálisan.
További probléma még ezzel a boot megoldással hogy a linuxos lemezen a bootmgfw.efi -t manuálisan kell frissítgetni, egy egy nagyobb windows frissítés után bizonyára nem árt megtenni. Kérdés ha nem frissítgetem akkor sok sok update múlva is indul e így a windows.
-
Gondolkodom rajta hogy a windowst is újrarakjam e uefi módba, de csak akkor ha a systemd-boot -ba könnyen bekonfigurálható hogy elindítsa a windowst is, azaz legyen egy boot entry a windowsnak is. A nehézséget az jelenti hogy a windows másik lemezen van, de ha uefi-s lenne az a lemez is, akkor valahogy csak meg lehetne hivatkozni a systemd-boot konfigban. Csak kellene valami leírás.
-
Na rászántam magam, újra raktam uefi/gpt módban az "éles" Arch telepítésemet a 480Gb-os ssd-men, systemd-boot -al. Kevesebb ideig tartott mint gondoltam. Sokat gyakoroltam virtuális gépben ezért mehetett gyorsabban. Eddig MBR-es volt, de szokni kell az UEFI-t mert ez a jövő
-
Igen, sajnos a radeon 6670-el nem fér össze valamiért az arch konzol, google kidobott pár arch-os találatot erre de megoldás nincs
Sajnos a mikrokód betöltése sem szünteti meg a hibát, néhány alkalommal fekete ahogy kell a konzol, de kikapcs és másnapi bekapcs után szürke konzollal indít megint. Különösen telepítéskor kellemetlen, nem jó a szemnek Feltelepített rendszeren nem annyira zavaró már. Ez a hiba azthiszem a display managerre is hat, ha feltelepítek valamilyet, sddm-et próbáltam régebben, mert kde hez ezt ajánlják, akkor elég sűrűn elhasalt a DM, le kellett szedjem mert nem tudtam vele bejelentkezni, el sem indult vagy összeomlott. De ugyanaz a DM kubuntunál rendesen működik ezen a vason.... -
Találkoztatok már olyannal hogy amikor bebootoljátok az Arch telepítőt akkor a konzol háttere szürke színű? Ez a telepített rendszernél is így van, szürke hátterű konzollal tölt be az esetek 99%-ában. A grafikus felület rendben indul startx-re (Display managert nem használok). Miután kilépek az X-ből akkor normális fekete hátterű konzolt kapok. Most feltettem és betöltöttem az amd-ucode -ot, ez úgytűnik megoldani látszik a hibát(de nem akarom elkiabálni), legalábbis egyelőre, de csak a telepített rendszernél. Azt hogy tudom elérni hogy a telepítő _ne_szürke_ konzollal bootoljon? Vga és a proci is amd, ott van az aláírásomban.
-
válasz
vargalex
#5947
üzenetére
Írhatnál egy systemd-boot konfiguráló shell szkriptet Arch-hoz, ami bekéri a partíciót
és már nyomja is bele a konfigba az uuid-jét. Illetve telepíti a systemd boot-ot a megfelelő(bekért) paraméterekkel. Amit most írtál azt shell szkriptként elmentem, hogy ne kelljen beírni, mert úgyis elrontom
-
Uefi Systemd-boot beállítására van olyan megoldás ahol nem kell disk UUID-eket körmölgetni?
Most kísérletezgetek a uefi módú arch telepítéssel, a grub uefi módja egyelőre szimpatikus, különösen hogy nem kell lemezazonosítókat körmölgetni telepítés közben, amikor se egér se vágólap nincsen.
Ezt a leírást követtem: https://averagelinuxuser.com/a-step-by-step-arch-linux-installation-guide/# a startup.nsh készítés kivételével, mert az csak virtualboxhoz kell. Az itt leírt grub uefi telepítési paramétereket ha megtoldom még egy --removable kapcsolóval akkor bios reset vagy lemez eltávolítás visszadugás után is indítható az UEFI Grub-os Arch. Csak ha --removable kapcsolóval telepítem akkor nem veszi figyelembe a bootloader-id paraméterben megadott nevet, egyszerűen UEFI-OS néven jelenik meg az alaplap boot menüjében. -
válasz
attilav2
#5927
üzenetére
Keresgéltem a "Kde stuck on splash screen"-re és egy találat azt javasolta hogy a kompozitor beállítások körül nézzek szét. Kikapcsoltam a kompozitort, és újraindítottam a kde-t, megszűnt a probléma, majd visszakapcsoltam a kompozitort és próbáltam indítani így is, ekkor is késlekedés nélkül betöltött. X akta
-
Beleütköztem egy Kde plasma indítási problémába.
Szokatlanul hosszan kinn marad a Kde splash screen, utána betölt megjelenik az asztal, de a tálca csak később jelenik meg.
Mit tudok tenni hogy tudom ezt debugolni? Teljes újratelepítés a megoldás? Nem szivesen raknám újra mert ez egy belakott jól bekonfigurált rendszer. -
Biztonságilag milyen ez a megosztás, lehet ezen még finomítani?
A wiki ezt javasolja biztonság szempontjából:
Configuration
ServerGlobal configuration options are set in /etc/nfs.conf. Users of simple configurations should not need to edit this file.
The NFS server needs a list of exports (see exports(5) for details) which are defined in /etc/exports or /etc/exports.d/*.exports. These shares are relative to the so-called NFS root. A good security practice is to define a NFS root in a discrete directory tree which will keep users limited to that mount point. Bind mounts are used to link the share mount point to the actual directory elsewhere on the filesystem.
Consider this following example wherein:
The NFS root is /srv/nfs.
The export is /srv/nfs/music via a bind mount to the actual target /mnt/music.# mkdir -p /srv/nfs/music /mnt/music
# mount --bind /mnt/music /srv/nfs/music
To make the bind mount persistent across reboots, add it to fstab:
/etc/fstab
/mnt/music /srv/nfs/music none bind 0 0Van értelme így csinálni?
Egyetlen aggályom van ezzel, hogy mivel sima felhasználóként csak a /home könyvtáramra van írási jogom, és az alkalmazások is csak oda írhatnak tudtommal, ha a torrentkliens letölt valamit annak az én felhasználóm lesz a tulajdonosa, a torrent kliens alapból nem is tud írni a /srv/nfs könyvtárba. Megoldható ez valahogy? Hogy kell beállítani a felhasználó/csoport jogokat hogy az én nevemben futtatott alkalmazások írhassák a /srv/nfs-t? -
Na most kikommenteltem ezt a beállítást:
Add the following line to the [Unit] section of /usr/lib/systemd/system/nfs-client.target
DefaultDependencies=False -> #DefaultDependencies=Falseés így is működik a szolgáltatás. Lehet csak az nfs telepítés után egy újraindítás kellett volna, ahogy az egyik arch-os fórum javasolta.
Ha a nfs-client.target szolgáltatás automatikus indítása is be van kapcsolva(ahogy ez a leírás javasolja) akkor vár 1perc 30mp-t az nfs szerver indítása előtt, inkább kivettem ezt az automatikus indításból, maradt csak a nfs-server.service és most nem volt várakozás és elindult rendben az nfs. Érdekes anomáliák vannak az arch linuxbanEgyébként a /home/attilav/nfs <lejátszó ip>(ro,sync,crossmnt)
paraméterekkel a megosztás működik és az alkönyvtárakba is beenged.
A paramétereket az /etc/exports fájlban levő példák és a wiki alapján próbáltam belőni.
Az NFS-t egyszerűbb beállítani mint a Samba-t -
válasz
attilav2
#5724
üzenetére
Kigugliztam, megcsináltam ezt: [link] Egyelőre nem dobott hibát.
Most újraindítom a gépet, meglátom működni fog e.Hát ez nem jött össze, szarakodott az indításnál, valami szolgáltatásra várva számolta a másodperceket, átléptem.
Belépés után elindítottam az nfs szervert, megtalálta a megosztást a médialejátszó. Az automatikus indítással lesz egy kis bibi.
-
Nem indul az NFS, erre panaszkodik (ezt a journalctl -xe paranccssal írattam ki):
The unit var-lib-nfs-rpc_pipefs.mount has entered the 'failed' state with result 'exit-code'.
máj 13 17:12:43 attilav-pc systemd[1]: Failed to mount RPC Pipe File System.
-- Subject: A start job for unit var-lib-nfs-rpc_pipefs.mount has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- A start job for unit var-lib-nfs-rpc_pipefs.mount has finished with a failure.
--
-- The job identifier is 1350 and the job result is failed.
máj 13 17:12:43 attilav-pc systemd[1]: Dependency failed for rpc_pipefs.target.
-- Subject: A start job for unit rpc_pipefs.target has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- A start job for unit rpc_pipefs.target has finished with a failure.
--
-- The job identifier is 1349 and the job result is dependency.
máj 13 17:12:43 attilav-pc systemd[1]: Dependency failed for RPC security service for NFS client and server.
-- Subject: A start job for unit rpc-gssd.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- A start job for unit rpc-gssd.service has finished with a failure.
--
-- The job identifier is 1353 and the job result is dependency.
máj 13 17:12:43 attilav-pc systemd[1]: rpc-gssd.service: Job rpc-gssd.service/start failed with result 'dependency'.
máj 13 17:12:43 attilav-pc systemd[1]: rpc_pipefs.target: Job rpc_pipefs.target/start failed with result 'dependency'. -
Sziasztok! Média lejátszó számára szeretném megosztani a filmjeimet NFS-en keresztül, csak olvasható módban, a megosztás elérését a médialejátszó ip címére korlátozva. Milyen paramétereket javasoltok az /etc/exports fájlba? A megosztás a /home/usernev/nfs és az ez alatt levő könyvtárak lennének. Tehát a felhasználóm könyvtára alatt lenne a megosztás.
A wikiben ez a példa konfig van:/etc/exports
/srv/nfs 192.168.1.0/24(rw,sync,crossmnt,fsid=0)
/srv/nfs/music 192.168.1.0/24(rw,sync)
/srv/nfs/home 192.168.1.0/24(rw,sync,nohide)
/srv/nfs/public 192.168.1.0/24(ro,all_squash,insecure) desktop(rw,sync,all_squash,anonuid=99,anongid=99) # map to user/group - in this case nobodyMilyen paraméterek kellenek ebből? A /home/usernev/nfs <lejátszó ip>(ro,all_squash,crossmnt) elég? Azt silabizáltam ki a wikiből hogy nekem ezek a paraméterek kellenek.
-
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.
-
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. -
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.
-
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. -
[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 -
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?
-
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.
-
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 -
-
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.
-
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.
Ezt windows alatt nemigen tudtam összehozni, ha jól emlékszem ~300mbit jött ki router nélkül.
A discover ha kész a frissítés már nem azt írja hogy up to date hanem hogy naprakész, tehát a fordításon is reszeltek itt ott 
Javaslom próbáld ki.
A telepítője, partícionálója is 
Így kényelmesebb csak beállítom alapértelemezettnek a biosban az Arch lemezét, így bekapcsoláskor indul a grub amiből rögtön választható a windows, vagy az uefi(bios)ba lépés. Alapértelmezetten természetesen az Arch indul.
Legáttekinhetőbb rendszer, legjobb wiki. Megérdemelné a distrowatch-on a tartós első helyezést. Most az első ötben vannak az Arch és származékai:
Akármit csinálok.
Új hozzászólás Aktív témák
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Torrent meghívó kunyeráló
- CASIO órák kedvelők topicja!
- Megérkeztek a Xiaomi 15T sorozatának telefonjai Magyarországra
- Bambu Lab 3D nyomtatók
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Autós topik
- sziku69: Fűzzük össze a szavakat :)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- További aktív témák...
- BESZÁMÍTÁS! MSI Z490 i5 10400F 32GB DDR4 1TB SSD RTX 3060Ti 8GB Zalman Z1 PLUS Enermax 650W
- 138 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4080 (ELKELT)
- GYÖNYÖRŰ iPhone 15 Pro Max 256GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3496, 90% Akkumulátor
- Gamer PC-Számítógép! Csere-Beszámítás! R5 5600X / RX 7600 / 32GB DDR4 / 1TB M.2 SSD
- BESZÁMÍTÁS! Logitech G920 Driving Force Racing kormányszett
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest