- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- sh4d0w: Tele a hócipőm
- GoodSpeed: Megint 3 hónap Disney+ akciósan :)
- btz: Internet fejlesztés országosan!
- sellerbuyer: Te tudod, mi mennyit fogyaszt az otthonodban?
- Barthezz2: Cím: Ismeretlen - Chapter 4
- Magga: PLEX: multimédia az egész lakásban
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
Szerintem a leggyorsabb, legegyszerűbb(KISS filozófia) linux. "Olyan is volt, hogy használat közben eltörtek a csomagok." Nekem ez többnyire akkor fordult elő amikor normál arch és aur-os csomag ütközött, eltávolítottam a kérdéses aur csomagot és rendben lement a frissítés/csomagtelepítés. Persze volt olyan is hogy normál csomagot kellett eltávolítani hogy lemenjen a frissítés(megváltozott csomagnév, más kategóriába került, stb), az arch honlapját érdemes időnként nézni, vannak manuális beavatkozást igénylő események. Nekem nagyon bevált az Arch, jó, stabil, gyors, nincs bloatware.
-
-
A legjobb megoldás szerintem az lenne ha léterhoznának az arch-on is egy hivatalos non-free tárolót, ahogy a debianon van, ebben lenne a hivatalos-google-chrome csomag, meg a többi non-free utility, pl viber, telegram, stb.
Átmeneti megoldásként a .deb csomag letöltése a google-től és megbízható makepkg(PKGBUILD) script futtatása helyben az arch csomaggá alakításhoz. Ilyen google-chrome .deb-et arch csomaggá alakító scriptet akár te vagy BoB is publikálhatnátok itt a topicban. -
Ezt találtam az opal-al megtámogatott LUKS-ról:
https://www.phoronix.com/news/Cryptsetup-Lands-OPAL-EncryptEzek alapján sima liba elvileg, sokkal kevesebb szívással jár mint a sima sed hw titkosítás.
-
Írd le a lépéseket hogy kapcsoltad be a hardveres titkosítást az ssd-n. Próbáltam google fordítóval értelmezni az arch wiki vonatkozó részeit de nekem elég bonyolultnak tűnik, meg lehet a fordítás sem az igazi. Kell valami pre boot authorization image-t generálni vagy letölteni valahonnan, lehet hogy az alaplap biosának is támogatnia kell a dolgot mert különben nem tudok bootolni a hw titkosított drive-ról, ennyit silabizáltam ki. A sedutil-cli --scan azt mondja az sn580 támogatja az opal-t. A LUKS elméletileg tudja használni a hardveres titkosítást(vagy legalábbis részben arra támaszkodni), ha a LUKS konténert a cryptsetup --hw-opal-only kapcsolóval hozom létre, ez nekem egyszerűbb lenne mint a meghajtó sima lejelszavazása. A kérdés az ha a LUKS-on keresztül opal-al használom a hw titkosítást akkor ugyanúgy lejelszavazódik a meghajtó mintha simán sed-et használnék, és támogatnia kell a biosnak a feloldást, meg pba image kell, vagy hogy van ez ? Mert a wiki azt írja hogy a LUKS fejléc fogja feloldani a hardveres titkosítást, tehát elvileg a LUKS ugyanúgy bekéri a jelszót mint eddig. Azt is írja a wiki hogyha opal-al megtámogatott LUKS titkosítást használok akkor a trim engedélyezve lesz alapból, és elméletileg így nem érintett az adatszivárgásban. A wiki szerint komolyabb adatszivárgás szoftveres titkosításnál trim mellett akkor lehet ha a cryptsetup 1.6.0 vagy alacsonyabb verzióval lett létrehozva a konténer, ez esetemben nem áll fenn, bőven magasabb verzióval hoztam létre.
-
Igazad van, amíg a systemd-boot konfigban nem engedélyeztem hogy a LUKS engedje át a discard-ot, addig az fstrim -v / parancsra azt írta nem támogatott. Amint engedélyeztem reboot után működött az fstrim, kb 300gb-ot trimmelt. sd-encrypt -et használok a rendszerpartíció felcsatolásához, ilyenkor a /boot/loader/entries/arch.conf a következőképp néz ki:
title Arch Linux NVME
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options rd.luks.name=UUID=sn580_cryptroot root=/dev/mapper/sn580_cryptroot rw
options rd.luks.options=UUID=discardAz UUID helyére a rendszerpartíció UUID-je kell. Az utolsó sor engedélyezi a trim-et.
Az sn580_cryptroot helyére lehet tetszőleges nevet írni, praktikusan a meghajtónk típusát.Kísérletképp az fstab-ba beraktam a discard-ot, kíváncsi vagyok néhány hét múlva belassul e a rendszer, ha igen akkor marad a periodic trim mint lehetőség. A crucial mx500-on és a samsung QVO 860-on gyakorlatilag nem nagyon működött a continous trim, az fstrim-el indőnként be kellett segíteni. Van egy másik gépbe adata sp600-on(sata ez is) Arch Luks-al, az még nem lassult be, pedig kb egy éve használom, lehet az a meghajtó jobban komálja a linux alatti folyamatos trim-et.
-
Nvme-re kellett cseréljem az Arch-ot futtató ssd-t mert a sata-s ssd nem szerette a luks titkosítást és a trim-et egyszerre, nagyon laggolt. Átklónoztam a rendszert nvme-re, pöccre indul nem laggol. A régi ssd egy mx500 egy terás, az új egy wd sn580 1 terás. Más márkájú sata ssd-nél is előjött luks és folyamatos trim beállítás mellett a laggolás, magas IO használat. Egyelőre úgy tűnik az nvme beváltotta a hozzá fűzött reményeimet, nem kell a trim-el törődni, ha minden igaz firmware-ból végzi automatikusan, semmilyen rendszer beállítást nem igényel.
-
válasz
vargalex
#8819
üzenetére
Lehetséges.
Egyébként a viszonylag gyakori link up/down az a mediatek switch hülyesége miatt is lehet, ezt már az AC57U-nál is megfigyeltem(normál üzemben mindig 1gb/s-re áll vissza a link), mert amikor az archer c7v5(atheros SoC, atheros switch) volt itthon egy rövid ideig használva(a gyenge wifi és gyenge SoC miatt nem vált be), akkor nem volt tele vezetékes háló fel/le csatlakozással az openwrt log.
Ezért is érdekelne a qualcomm-os dynalink, jó lenne ha 2 hétig tesztelhetném
Persze csak úgy add kölcsön hogy már openwrt-sítve van. Ha kölcsön akarod adni, akkor ne futárral küldd le, nehogy elvesszen(ahhoz drága), ha pesten járunk valamikor lehet át tudom venni, vagy öcsém lehozza nekem(ha gyál-ig el tudod vinni). -
válasz
vargalex
#8815
üzenetére
Érdekes, a dhpcd.conf volt statikusra(192.168.0.66-ra azthiszem) állítva mert az archer c7v5-öt flasheltem át openwrt-re tftp-n. Most működik az ipv4 h visszaálítottam dhcp-re. Próbálkoztam networkmanagerrel, leállítottam és kikapcsoltam a dhcpcd-t, de továbbra is fennált az ipv4 probléma mialatt a networkmanager ment. Érdekes hogy a dhcpcd-ben beállított statikus ip okozhat linksebesség anomáliát, meg check cabling üzenetet a dmesg-ben.
Ez a zárt r8168 driver stabilabbnak tűnik ami a linksebességet, link stabilitást illeti. A r8169-el gyakran volt link up/down, a gyári r8168 stabilan tartja a link-et.
-
válasz
vargalex
#8815
üzenetére
Merre vagy helyileg? Szívesen kipróbálnám azt az USB-s NIC-et...
Ha már a felajánlásoknál tartunk szívesen kipróbálnám a Dynalink-DLWRX36-ot, mivel autista vagyok, nem merek külföldről rendelni(pláne ilyen nagy értékben), angolul alig tudok, a vámeljárástól is félek. A Dynalinkre viszont kíváncsi vagyok abból a szempontból hogy anyám Unisoc Tiger T618-as Galaxy Tab A8-asával szakadozna e a wifi, mert az AC57U-val szakadozott, és AX3200-al is szakadozik(mindkettő mediatek-es). Hátha qualcomm-os ap-val nem kapcsolódna le a wifiről. Megmutattam neki hogy kapcsolódhat újra, de akkoris macera. Meg arra is kíváncsi vagyok hogy a torrentet hány megabájt/s-al töltené a dynalink, az AC57U(amit ap módban seedelni használok hogy ne kelljen járatni egy pc-t) 5-10megabájt/s-al tölt le. -
válasz
vargalex
#8815
üzenetére
Akkor nem marad más mint az arch újratelepítése 0-ról, vagy debian. Szegedi vagyok, te meg a fővárosi vagy ha jól tudom.
Valamelyik csomag elk*rta a hálózati beállításokat, fogalamam nincs merre keressem a hibát. Valószínűleg valami a nic firmware-t fekteti meg arch alatt(mert ha újraindítással megyek más rendszerre akkor hasonló hibák jönnek, kikapcs/bekapcs-os reboot-kor teljesen jó más rendszerek alatt a nic), tippem sincs mi lehet. -
válasz
vargalex
#8813
üzenetére
Azthiszem feladom, próbálkoztam a hivatalos (realtek) oldalról letölthető driverrel(r8168-8.052.01.tar.bz2, az arch féle r8169-et blacklistre tettem), ipv4 továbbra sem megy, pl prohardvert az ip begépelésével sem érem el, megpingetni sem tudom(hálózat elérhetetlen). Az 1Gbit-es linksebességet viszont úgy tűnik stabilan tartja. Csak ipv6-os oldalak jönnek be. MacOS, Windows alatt normálisan megy az integrált nic. Van axagon ade-src usb-s nic-em, de azzal is hasonló tapasztalatom van arch alatt, mivel az is realtek chipes... Lehet rendelni kéne valahonnan egy asix chipes usb-s nic-et, de magyarországon ilyet nem forgalmaznak tudomásom szerint, max aliról lehetne rendelni, de külföldről nem merek, macera a vámeljárás, angolul sem tudok annyira jól, ha valami gond lenne a rendeléssel/szállítással h reklamáljak. Rakok debiant arch helyett.
-
-
Firmware problémám támadt a másodlagos gépem, Giga B85M-HD3-R4 integrált realtek gigabit lanjával Arch alatt a legutóbbi frissítés óta. IPV4 nem működik, dmesg kábelhibákra panaszkodik(linksebesség visszavétele). Más rendszerekbe bootolva(MacOS Windows) megy rendesen a net, linksebesség marad 1Gbit-en. Illetve, ha újraindítással bootolok más rendszerbe akkor a nem működő IPV4 és a linksebesség csökkentése ugyanúgy előjön. De ha az Arch-on leállítom a gépet, és újra bekapcsolva más rendszerbe bootolok akkor normálisan működik az integrált lan. Ebből gondolom hogy firmware probléma lesz. Próbálkoztam lts és zen kernelekkel, a hiba megmarad sajnos. Valamit nagy elkúrtak a realtek firmware-ban Arch alatt. Hogyan tudnám megoldani a problémát ? Esetleg elérhető valahonnan, megbízható forrásból, gyári realtek firmware, illetve annak különböző verziói ? Firmware cserélgetéssel próbáélkoznék, hátha.
-
-
válasz
Blasius
#8794
üzenetére
Nekem régen HD6670-em volt, állandóan szürke színben jött be a konzol, utána kerestem és kiderült hogy ez egy általános régi radeonokat (ati meghajtót) érintő linux kernel hiba. Még 2018-ban lecseréltem a kártyát egy RX550-re,(úgy döntöttem nem kínlódok tovább a nagyon régi HD6670-el), az RX550 amdgpu meghajtóval megy, azóta nincs gondom linux alatt.
-
Rájöttem a megoldásra, némi gondolkodás után, a -noconsolein opcíót kellett törölnöm innen:
Külső link a képhez
nincs kicsillagozva a bitlocker jelszómező, és engedi beírni a jelszót.
Tehát aki bitlockerrel használja ezt a megoldást, annak ez egy hasznos info. -
Arch - Windows 11 dual bootot akarok, a 2 rendszer 2 külön lemezen van, mindegyiknek saját efi partíciója van a saját lemezén. A windows bitlockerrel titkosított. Lehet ez kavar be, ugyanis amikor a systemd-boot menüből elindítom az arch systemd-boot wiki alapján lérehozott Windows bejegyzést, szépen el is indítja, de a bitlocker jelszóbekérő képernyőjén a jelszómező csillagokkal végig kivan töltve, a billentyűzetre nem reagál, tehát törölni és a helyes jelszót beírni nem tudom. Itt elakadtam. A windows.nsh efi script a linux efi partíciójára került, oda ahol a bootx64.efi és a shellx64.efi is van, a windows.conf indítóbejegyzést megfelelően felparamétereztem az arch systemd-boot wiki alapján, ötletem nincs miért produkálja ezt a viselkedést. Ha a systemd-boot menüből nyitok egy efi shellt(direkt benne hagytam a menüben a lehetőséget, hogy tudjam indítani a windowst, linuxot, az f11 bootoláskori szorgos nyomogatása helyett), és beírom windows.nsh akkor jól működik a bitlocker jelszóbekérő, üres jelszómezővel indul, bill. működik, be tudom írni a jelszót a windows elindul.
Van valami ötletetek hogy rendesen működjön a windows indító bejegyzés ?
Az arch wiki mellett még ez a leírás volt segítségemre: Link
Most cseréltem gépet, ahogy az aláírásomban is látszik, eddig a dual(trial) bootot OpenCore-val oldottam meg mert macOS is ment a gépen. Haswell-re viszonylag könnyű volt felrakni, 12.gen -re állítólag nehezebb, egyelőre nem akarok nekiállni új OC EFI-t készíteni, így a dual boot-ot systemd-boot al akarom megoldani. -
válasz
baloo79
#8779
üzenetére
Kár, mindig ez alatt csináltam az arch parancssoros telepítését titkosítással, jól jött hogy böngészőben tudom olvasni az arch wikit és egyéb leírásokat. Fejből még nem megy a telepítés, mobilról meg kényelmetlen olvasni a leírásokat. Meghát a vágólap használata egyszerűbb grafikus live rendszer alatt, a titkosítás miatt másolgatni kell a disk uuid-t partuuid-t. Keresnem kell más arch alapú live rendszert amit még frissítenek. Szerencsére csak nagyon ritkán kell újraraknom az arch-ot, alapvetően jól működik.
-
Az openboxot szeretném a --debug kapcsolóval indítani display managerből (sddm-et használok). A probléma az hogy amikor ki akarok lépni az openboxból akkor első probákozásra csak villan egyet a kép és nem lép ki, második próbálkozásra lép csak ki és kapom vissza a display managert. Ha az sddm-et leállítom és startx-el indítom az openboxot akkor simán elsőre működik a kilépés. Van egy másik gépem ott is sddm-et és openboxot használok, ott első alkalomra probléma nélkül kilép és visszatér az sddm-hez. Melyik fájlt kell szerkesszem hogy a display managerből --debug kapcsolóval tudjam elindítani az openbox-ot ? Azt olvastam a google-ban hogyha --debug-gal indítom akkor a /var/log-ba teszi a logjait az openbox, vagy esetleg máshova ?
-
Én már régóta openbox+tint2+sakura+xscreensaver+thunar+pcmanfm-t használok a nagysúlyú desktopok helyett,(rimuru leírása alapján, azóta változott pár dolog, de utána lehet googlezni+arch wiki) sokkal gyorsabb, és jóval kevesebb gond van vele, igaz macerásabb a beállítása, de csak egyszer kell megcsinálni, a konfigok lementhetők és újratelepítéskor visszamásolhatók.
-
Megoldottam! Módosítottam az fstabot egy új opcióval.(x-systemd.mount-timeout=1m) Olvasgattam a wiki vonatkozó részeit, és találtam egy workaroundot, lehet hogy nem szép, de működik
Természetesen nem kell egy percet várni, mikor beírom a második lemez jelszavát azonnal megy tovább a boot folyamat. A crypttab-ból a discard opciót kivettem mert nem oda való valószínűleg. A boot folyamat során még a jelszó megadása előtt fel akarja oldani a /dev/mapper/CT1000MX500-at, és mivel még nem létezik elhasalt a felcsatolás, ezután kéri a jelszót, így létrejön az eszköz, de az fstab már nem fog újra lefutni. Megnöveltem a mountolás várakozási idejét 1 percre az fstab-ban, így szépen megvárja míg beírom a jelszót és létrejön a /dev/mapper/CT1000MX500 eszköz, és sikeres az automata mountolás.
Most így néz ki a konfig:
/etc/crypttab:CT1000MX500 PARTUUID=[partíció kód] none timeout=180/etc/fstab:
/dev/mapper/CT1000MX500 /media/CT1000MX500 ext4 rw,noatime,discard,nofail,x-systemd.mount-timeout=1m 0 2 -
-
Artix-on vagyok már egy jóideje, de kíváncsiságból egy másik drive-ra feldobtam az Arch-ot. Hogy tudom azt megoldani hogy a másik lemezen levő Artix titkosított(luks) root partíciója egy boot-kori jelszóbekérés után automatikusan felcsatolódjon ? Az /etc/crypttab -ba ezt írtam:
CT1000MX500 PARTUUID=[partíció kód] none discard timeout=60
Induláskor kb a vga driver éledésekor bekéri a meghajtó jelszavát, ezzel létrejön a /dev/mapper/CT1000MX500 amit bejelentkezés után manuálisan akár udisksctl-lel tudok csatolni. Viszont automatikusan szeretném. Ezt írtam az /etc/fstab-ba:/dev/mapper/CT1000MX500 /media/CT1000MX500 ext4 rw,noatime,discard,nofail,x-systemd.device-timeout=20ms 0 2
Nem tudja a systemd felcsatolni. hibaüzenet jön bootkor. Lehet az a gond hogy a lemez titkosítása túl későn oldódik fel, a vga driver inicializálódásakor, és a systemd előtte akarja csatolni, amikor még a /dev/mapper alatt nem jött létre az eszköz. Próbálom értelmezni az Arch wiki vonatkozó részét, de gyenge az angolom. Szóval hogyan oldható meg hogy a meghajó időben feloldódjon és az automatikus csatolás megtörténjen ? -
Sokaknak hasznos lehet: Enable periodic TRIM - including on a LUKS partition
ez alapján finomítottam a LUKS alatti trim beállításokat.
A hivatalos veracrypt generikus telepítővel vigyázzatok, üres /usr/sbin mappát hoz létre (amibe belerakja a mount.veracrypt binárist), ami a rendszer hibás működését eredményezi a későbbiekben. A mount.veracrypt-et másoljuk a /usr/bin -be, a /usr/sbin mappát töröljük, hozzunk létre symlinket a /usr/bin -ről /usr/sbin-re. Vagy használhatjuk a tárolóban levő, jelen pillanatban eggyel régebbi verziót. -
válasz
attilav2
#8261
üzenetére
Lehet hogy a veracrypt telepítő szúrta el a rendszert, a veracrypt mount.veracrypt állománya volt az egyetlen a /usr/sbin-ben levő bináris. Lehet a veracrypt telepítő szkriptje csinált a /usr/sbin-ből valódi mappát, de az is lehet hogy már korábban valami elcsezte a rendszert és csak utána telepítettem a vercryptet. A veracryptre vagy egy aur-os app-ra gyanakszok. Vigyázni kell a külső forrásokkal. Magyarch live alatt töröltem a /usr/sbin-t és symlinkeltem a /usr/bin-t /usr/sbin néven, a műtét úgy tűnik sikerült, bootkor nem jelzett az init hibát. Spotify szokott még rendetlenkedni, sokszor akadozik nem játszik le, de ez betudható annak hogy alapvetően debianra fejlesztették és archon nem tökéletes. Debian 11-en jól megy. Különbség még a debian és arch között hogy a debian még a LUKS jelszó bekérése előtt betölti a vga drivert, az arch csak a LUKS prompt után tölti be. Debian telepítőben ki tudtam választani a titkosított partícióra a noatime discard flageket, és működik az fstrim
Samsung840-nél a continous(folyamatos trim blacklistelve van a kernelben a ha jól tudom), ezért időnként futtatnom kell az fstrim-et, vagy van rá systemd service de abban nem bízom. -
Akkor valami nagyon elmászott, nálam egy valós mappa a /usr/sbin, valami történt hogy ennyire elkefélődött, csak nem tudom mi. Lehet hogy valamelyik aur csomag kavart be. Egy live arch rendszer alól, pl magyarch megpróbálom javítani, törlöm a /usr/sbin-t és symlinkelem a /usr/bin-t /usr/sbin néven.
ztsoft: a csomagok újratelepítése jó ötlet, ezt is meglépem live rendszer alól.
Futó rendszer alól nem tudom merjek e ezekbe belepiszkálni, nehogy több kárt okozzak. -
Most van az első komolyabb szívásom Arch-al. Eltűnt a /usr/sbin könyvtár tartalma, a frissítés le sem futott emiatt, mégegyszer elindítottam, ekkor már lefutott de a /usr/sbin tartalma nem állt helyre. Pár program és az nfs service hiányolt dolgokat onnan ezeket symlinkeltem a /usr/bin ből a /usr/sbin-be, de gondolom ez nem jó megoldás. Googleban nem találtam semmit hogyan állítható helyre e könyvtár tartalma, attól tartok újratelepítés lesz a vége, nagyon jól összelőttem a rendszert az évek során, úgyhogy nagy meló lesz az újrarakás. Visszatettem a gépbe egy régi 84%-os samsung 840 120-as ssd-t, feldobtam a debian 11-et tesztelni, hülyét kaptam a telepítőtől, volt pár kör mire átverekedtem rajta amit akarok, egyéni partícionálás, titkosított root. Meglepett de a telepítőt leszámítva kellemes csalódás a debian, sokkal összecsiszoltabbnak tűnik a 11 mint a korábbi változatok, debian desktop environment-el raktam fel, ez gnome-ot jelent, az ubuntu alaptelepítéshez hasonló cuccokkal.
Van ötletetek a /usr/sbin mappa tartalmának helyreállítására ? Szeretném megúszni az arch újratelepítést.
Van artix is telepítve, azzal eddig nem volt komolyabb szívásom. -
De miután kijavítottam a dhcpcd service beállításait az ntp kliens nem működik, azt írja DNS hiba miatt nem éri el a time servert, pedig net megy normálisan. Most lecseréltem openntpd-re, de ez lehet hogy csak time server és nem működik kliens módban, ezt nem tudom, majd jobban utána nézek.
-
OpenRC-s Artix-on enp5s0-ról eth0-ra változott a hálókártya "neve", azt vettem észre hogy a dhcpcd service bootoláskor hibára fut, aztán rájöttem hogy eth0-ra változott az interface, átkonfiguráltam a service-t, most jó. Valamelyik frissítés csinálhatta. Más is tapasztalta ezt?
-
-
Openbox + tint2 tálca egy ideális kezdő pálcika wm, Rimuru arch telepítési blogjában van róla leírás, illetve jó még az Arch openbox wiki, Debian openbox wiki
-
Én is átlőttem egyszer pipewire-ra, de az előlapi fejhallgató kimeneten nem adott hangot, próbáltam debugolni, valamelyik audio sink nem működött, legalábbis a systemd-s debug eszközök szerint. Vissza állítottam a pulse-t egyből működött a fejhallgató. Az arch pipewire wiki szerint a bluetooth-al is lehetnek gondok. Leírhatnád hogy a pipewire-t hogyan konfiguráltad be, milyen csomagokat tettél fel, szedtél le.
-
A Runitban az nem tetszik így első blikkre hogy elég szűkszavú, pl mikor az OpenRC elindítja a dhcpcd-t akkor szépen látszik ahogy végbe megy a dhcp folyamat, ugyanígy az nfs szervernél is látom hogy miket írkál ki. Runitnál semmi visszajelzés, csak annyi hogy a szolgáltatás elindult... ez így nagyon systemd-s. Meg ha el akarok indítani bootoláskor egy szolgáltatást akkor symlink készítésével tudom megtenni, ez sem jön be, itt megvan az elégépelés esélye, szerintem macerásabb mint az rc-update. Persze OpenRC-nél is van szolgáltatás aminél symlinkelni kell, pl dhcpcd, de ezek kivételek, a nagy többség az rc-update-val felvehető az indítási listára. Talán azt lehet modani hogy az OpenRC konzervatív megodásokat használ, a Runit meg inkább systemd szerű.
-
Egyre jobban kezdem belakni az Artixot, tetszik az openrc, érthető logikája van. Viszont a disztró dokumentáltsága hagy kívánnivalót maga után, hol a gentoo wikiben hol az arch wikiben hol az artix saját oldalán van a megoldás. Arra nem találtam leírást sehol hogy melyik csomagot kell telepíteni az openrc-s bluetooth szolgáltatáshoz, illetve ami volt leírás az abban levő csomag már nem létezett, végül a google egy artixos github tárolóhoz vezetett amiben ott volt a csomagnév: bluez-openrc, ezt kellett felrakni és elindítani, és a megfelelő pulse bluetooth modulok betöltése után már ugrásra készen állt a bluetooth fejes. Bliuetoothctl-lel a párosítás simán ment, de kapcsolódni stabilan az istennek nem akart, végül a pulseaudio többszöri újraindítása oldotta meg a dolgot és ment a fejes. Openboxot kezdem belakni, beállítottam időzített képernyővédőt és lezárást(xscreensaver) a debian openbox wiki alapján, billkombóra bekapcsoló képernyőzárat(xlockmore) egy linuxos fórum alapján. Sokkal gyorsabb ez a sovány openbox wm+tint2 mint a KDE, csak minden kényelmi funkcióért meg kell küzdeni
Az is tetszik még az openrc-ben hogy amikor elindítok egy szolgáltatást akkor általában kapok valami visszajelzést, mikor az nfs servert indítottam akkor is kaptam egy egész korrekt visszajelzést hogy milyen paraméterekkel indult, systemd-nél nincs visszajelzés. Szerintem az Artix az Arch és a Gentoo keveréke, a gentoo szállítja az init rendszert és nagyrészben a rendszer konfigurációs struktúrát, az arch pedig a csomagkezelőt és a rendszer konfigurációs struktúra kisebb részét. OpenRC-s szolgáltatásokat/gentoo specifikus részeket a gentoo wiki alapján állítom be. Arch specifikus részeket meg arch wiki alapján, ha valami ezekben nincs meg általában segít a google 
-
A LUKS titkosítási paramétereibe nem mélyedtem bele, alap beállításokkal titkosítottam, a linkelt leírásnak és videónak megfelelően, remélem így is jól véd
TRIM jó kérdés megy e, ha nagyon belassul egy idő után a rendszer akkor nyilván nem, de majd akkor keresek rá valami megoldást, sajnos az angolom elég sekélyes, arch fórumon / redditen, stb, nem tudok kérdezni LUKS vs TRIM témában, majd lehet valakit megkérek. A bitlockerrel titkosított meghajtót úgy tűnik csak olvashatóra lehet felcsatolni linux alatt dislockerrel, pedig írható megoldásnak hirdeti magát a dislocker, még tovább kell keresgélnem leírásokat. A ruby függőség nélküli dislocker-t érdemes telepíteni aur-ból(dislocker-noruby) az alap dislocker egy frissítés után elhasalt a ruby frissülése miatt.
Az viszont feltűnő hogy a bitlocker legalább 1-1.5 órát molyolt egy ssd titkosításával(256 AES XTS-re állítottam a gpedit-ben), míg a LUKS töredék idő alatt megvolt. Lehet hogy azért van ez a nagy időkülönbség mert a bitlocker a meghajtón levő adatokat titkosítja mikor átkonvertálok egy lemezt, a LUKS meg valószínűleg nem foglalkozik a meghajtón már rajta levő adatok titkosításával hiszen a LUKS kötetet létrehozása után formázni kell, és ha adatok kerülnek rá akkor röptében titkosítja. Az Arch mellett az Artix-ot is újratelepítettem titkosítva.
Nagy dilemma hogy mi legyen a külső hdd-kkel, hiszen a bitlocker írhatóságával gondok lehetnek linux alatt, lehet azt csinálom hogy a kritikus adatokat titkosított konténerbe rakom, nem egész lemezeket titkosítok. -
Asztali gépek/alaplapok BIOS-ai/UEFI-ei általában nem ismerik a SATA jelszó funkciót, az én lapom is ilyen sajnos
Másrészt ha elgépelem a jelszót első megadáskor akkor a meghajtót dobhatom a kukába(utána már nem lehet használhatóvá tenni, ha nem ismert a jelszó, míg szoftveres titkosításnál újra partícionálás formázás után használatba vehető), ezért félek a hardveres titkosítástól. -
válasz
attilav2
#8029
üzenetére
Letitkosítottam a windowsos lemezeket is, windowsos rendszer ssd + exfat adattároló ssd, bitlockerrel. Az aur ban levő dislocker meg tudja nyitni a bitlockerrel titkosított lemezeket, itt van egy leírás a használatáról: https://www.ceos3c.com/open-source/open-bitlocker-drive-linux/
Frawly:
További beállításokat eszközöltem hogy a LUKS átengedje a TRIM-et, létrehoztam a /etc/crypttab.initramfs -t és beleírtam ezt: rd.luks.options=2e1434a6-a4ac-49bf-91a0-d4f7dd5d3619=discard (a titkosított lemez uuid-je szerepel benne) ahogy a wikiből kihalásztam így kell csinálni, bár lehet elég lett volna a rd.luks.options=discard, inkább biztosra mentem, utána újra generáltam az initramfs-t. fstab-ba bekerültek a discard,noatime opciók.
Nem reklamált a rendszer bootoláskor, persze tudom ez nem azt jelenti hogy működik trim, de akár működhet is A wiki szerint, ha jól értelmezem. az /etc/crypttab -os bejegyzéseket az initramfs miatt nem veszi figyelembe bootoláskor a rendszer bootlemez esetén, illetve ez a fájl arra való hogyha a bootlemezen kívül van más titkosított lemez akkor azoknak az automatikus felcsatolását lehet benne defdiniálni a megfelelő opciókkal. -
Így jó a LUKS discard vagy máshol is állítani kell valamit? Fstabba mehet a discard a opció?
a /boot/loader/entries/arch.conf -ban adtam meg az allow-discards paramétert ami a wikiben van, bebootolt a rendszer tehát nagy bajt nem csináltam. Jól adtam meg ezt az opciót?
A többi beállítással is foglalkozni kell, vagy ez így elég?
-
-
Találtam egy jó leírást, egyszerű LUKS telepítés, systemd-boot -al:
https://jherrlin.github.io/posts/arch-install/
VirtualBoxban kipróbáltam, nekem működött!
Itt meg egy magyarázó videó, szintén alap LUKS telepítés, Grub boot -al:
https://www.youtube.com/watch?v=XNJ4oKla8B0
Ezt is megcsináltam vboxban, ez is működött.
Vim vágólapkezelés:
https://vim.fandom.com/wiki/Copy,_cut_and_paste
konzolban hasznos -
válasz
Shyciii
#8005
üzenetére
Nekem még nem volt olyan hogy frissítés után ne bootolt volna be, igaz nem is nvidiát használok aminek csak zárt drivere van, az egy kernelfrissüléskor lehet megfagy bootkor, szerencsére amd vga-m van. Olyan már párszor volt hogy a KDE-t úgy hazavágta egy update hogy nem indult, de akkor használtam másik desktopot. Tv tuneremhez dkms-es drivert használok, volt hogy kernelfrissüléskor nem fordult le, de attól még bebootolt a rendszer, csak a tuner nem működött, néhány hét múlva javították a driverét, nem létfontosságú mert tv-m is van.
-
El tudnátok e képzelni az Arch-ot produktív munkában ? Pl Termelésirányításban egy gyárban az üzemvezetők ilyen rendszeren dolgoznának win10 helyett? Szerintem kijelenthető hogy a Win10 frissítési folyamata ma már több leállási kockázattal jár mint az Arch-é. Én jópár éve használom az Arch-ot, pár évet használtam újra telepítés nélkül is, folyamatos frissítéssel, bátran ki merem jelenteni hogy a w10 frissítési folyamata megbízhatatlanabb és jóval lassabb is. Csak a KDE-vel volt gondom az évek során, magával a rendszerrel nem, de produktív környezetbe lehet nyilván más akár pehelysúlyú megbízhatóbb desktopot választani. Ami aggasztóbb és akadálya a váltásnak hogy sok vállalatirányítási szoftver nem érhető el linux alá. Meg egyáltalán kérdéses hogy a válallatirányítási rendszerek szállítói mernének e garanciát vállalni a hosszútávú működésre egy rolling disztribúció alatt?
Egy jelentős érv a váltás mellett lehetne a vírusokkal szembeni immunitás, hiszen a vírusok jelentős többsége windows platformra készül.
Az Arch abszolút párhuzamba állítható a Win10-el, hiszen mindkettő rolling.
Nektek mi a véleményetek az Arch produktív környezetben való munkaállomáskénti használatáról? -
válasz
Shyciii
#8000
üzenetére
Ebben a leírásban külön van az efi és a boot partíció, én jobban szeretem ha egybe van. A youtubeon vannak LUKS Arch telepítési videók, de többnyire Grub-osak, nem tudom miért ragaszkodnak annyira a Grub-hoz, mikor a systemd-boot sokkal egyszerűbb, mondjuk systemd mentes rendszeren érthető, de itt Arch LUKS telepítési videókról van szó, nem az Arch egy systemd mentes forkjáról ahol érthető ha Grub-ot használnak. Artixon én is Grub-ot használok, efistub meg hasonló csak uefi nvram-ba író megoldások jöhetnének még szóba Grub helyett, de ha átrakom a lemezt egy másik gépbe akkor már nem bootolna mert a másik gép uefi-jében értelemszerűen nincs ott a bejegyzés.
Egyelőre a jövő zenéje lesz a titkosított ökoszisztéma, mert csak akkor van értelme ha minden adatomat letitkosítom, a külső lemezeken levőket is, a külső lemezeket valószínűleg bitlockerrel oldom majd meg, hogy win alatt is használhatóak legyenek. Linux alá van bitlocker megnyitó tool, csak nem tudom mennyire stabil. -
válasz
Shyciii
#7998
üzenetére
Egy leírást te vagy Frawly vagy más hozzáértő csinálhatna a titkosított(LUKS) kézi telepítésről, mondjuk kezdetnek egy egyszerű 2 partíciós telepítéssel ( / /boot), swap nélkül
Csak a / lenne titkosítva, systemd-boot-al. Virtuális gépben meg lehet csinálni és akkor képekkel is tudjátok illusztrálni -
Vboxban próbálgatom ezt a hivatalos installert, háát, azt kell mondjam nem örülök neki túlzottan, alapból titkosított partíciót csinál, de hogy milyen megoldással azt nem választhatom meg.... Az Arch filozófiájával, egyáltalán a KISS-el ellentétes bármilyen installer szerintem... Aki nem érti hogy működik a titkosítás az szívhat vele, én sem értettem még meg hogyan kell titkosított (pl LUKS) telepítést csinálni, és amíg nem értem a folyamatot, de egy installer megcsinálja és valami gond lesz a későbbiekben akkor szívhatok vele mert nem fogom tudni megoldani, pláne hogy nem is tudom az installer milyen megoldással csinálta.
Időt viszont spórolt az installer rengeteget, töredék idő alatt megvolt a telepítés, viszont nem tudom milyen boot megoldást használ a rendszer, hogy lett megvalósítva a LUKS titkosítás, stb. -
Lehet hogy utoléri az Arch-ot is a bloatosodás?
Installer scriptet kapott a telepítő média: https://github.com/archlinux/archinstall -
Most az i3-gaps WM -et raktam fel natív Arch-ra, ez X-es és legalább minden app fut, Sway -en sokminden nem indul el, ha bekapcsolom az xwaylandet és olyan appot indítok ami igényli akkor kidob koznolra a Sway, nincs kedvem debugolni, meg nem is értek ennyire mélyen a rendszerhez. Át chromecastoltam chrome-val tv-re az i3 képét, míg KDE-n ez a művelet 100%-on pörgette a procit, itt beérte a chrome 50%-al, és a chromecastolás befelyezése után a terhelés visszaesett a normál terhelésre 5-10%-ra, ez KDE esetén marad 100%-on és csak a restart segít. A tiling wm mintha tv képernyőre termett volna sokkal kezelhetőbbnek tűnik tv-s böngészésre, online webes videózásra. A memória foglaltság a chromecastolás alatt ~1gb körül volt, ez a KDE alatti chromecastoláshoz képest nagyon jó! Gondolkodok pl egy Rock Pi X x86-os sbc beszerzésén, ebben csak 4gb memória van, de pálcika wm-ek mellett ez bőven elég lenne, kifejezetten tv-s böngészéshez venném. Openbox-al is próbálkozni fogok(virtuális gépen nagyon jók a memória foglaltsági tapasztalataim), már fel is tettem a natív rendszerre, csak ezt bonyolultabb testre szabni mint a sway/i3-at, jól jönne ha megdobnál néhány példa konfiggal, leírással. Felfedeztem ha rendszerindítás után egyből KDE-t indítok és kilépek belőle konzolra akkor a szutykai a memóriában maradnak, sokszor igen magas proci terhelést okozva, amin csak a restart segít. Ha indítás után közvetlenül sway/i3-at indítok akkor sokkal pattógósabb a gép töredék a proci terhelés és a memória foglaltság, és még a chromecastolás is 50%-al kevesebb procit fogyaszt, még akkor is ha webes videót nézek közben, tehát a pálcika wm-ek használhatóvá tették a chromecastot de az 50%-terhelés még mindig sok, ezen lehetne még kicsit faragni ha linux szakértő lennék, de sokat faragni nem lehetne belőle valószínűleg, talán egy -10%-ot. Windows alatt a KDE-hez hasonlóan szintén közel 100% terhelés van chromecastolás közben.
-
Sway ~150mb-ot eszik ezen a vboxos artixon, blackbox 75mb-ot eszik.
Mikor feltettem a firefoxot magával húzott vagy 600 megát, és ha elindítom akkor ~300 megára felugrik a memória foglaltság. Artix-on egy csomag több tárolóból is elérhető community, galaxy, stb ez újdonság az Arch-hoz képest. -
Artix-openrc, blackbox memóriafoglalás, friss virtualboxos telepítés:
~70mb
Első benyomások alapján komplikáltnak tűnik ez a systemd nélküli lét, a konfigfájlok több helyre vannak szétszórva a vanilla Arch-hoz képest. Szolgáltatások engedélyezése, letiltása is komplikáltabb. Office-olós/youtube-ozós átlag desktop usernek bőven jó a systemd, sőt neki az az optimális. Aki meg szereti a rendszerét állandóan faragni annak jó az initscriptes rendszer.
Ja és nem kapcsolja ki a gépet shutdownkor, legalábbis virtualboxban nem, szinte minden disztró amit eddig vboxban próbáltam ki tudta kapcsolni a virtuális gépet, ez megakad itt:
-
válasz
Shyciii
#7967
üzenetére
Akkor minimalista rendszert használsz. Nálam legalább 2-3 giga minimum, gondolom a KDE miatt. Szoktatom magam a Sway-hoz, de még ott is 1.5-2giga a foglalás egy idő után gondolom a sok háttérszolgáltatás amit a KDE felrakott. Szerencsére legalább 4 ssd-m van a gépbe így tudok különböző rendszerekkel kísérletezni, ki kell próbáljam a minimalista Arch telepítést, vagy egy systemd mentes Arch klónt, ez utóbbiból tudtok ajánlani párat?
-
Kíváncsiságból kipróbáltam a dhcpcd-t, előtte systemd-networkd és systemd-resolved volt(a régi telepítésemen pedig networkmanager, de bloatnak találtam így az újrahúzáskor már mellőztem), gondoltam kiváltom egy szolgáltatással, kikapcsoltam mindkét szolgáltatást(systemd-networkd systemd-resolved), rebootoltam majd systemctl enable dhcpcd@enp5s0 az már gyanús volt hogy az indulása eltartott kb 5mp-ig, de utána működött a net bármiféle külön resolver indítása nélkül, ez elsőre tetszett, de rebootkor jött a fekete leves a systemd rendszerindításkor vár a dhcpcd szolgáltatás elindítására kb 5-10mp-et
Próbáltam konfigurálni a systemd-t már amennyire értek hozzá, egyszerűbb beállításokat változtattam az /etc/systemd/system.conf-ban:
DefaultTimeoutStartSec=3 -al próbálkoztam, de így a dhcpcd nem tudott elindulni, felemeltem 5-re, úgy sem, majd 10-re és így már indul bootkor a dhcpcd. A systemd-networkd systemd-resolved párossal semmilyen problémám nem volt.
Lehet valahogy diagonosztizálni mi akasztja meg ennyi időre a dhcpcd indulását?
Vagy váltsak valami systemd mentes Arch klónra?Na az arch wikiben meglett a megoldás:
https://wiki.archlinux.org/index.php/Dhcpcd#dhcpcd@.service_causes_slow_startup
Működik, nem gondoltam volna hogy egy ilyen szögegyszerű szolgáltatással mint a dhcpcd gond lehet, egyszer kipróbálok egy systemd mentes arch klónt -
Végül némi kínlódás után sikerült rsync-el átklónozni a fájlrendszert, nem az általad ajánlott kapcsolókat használtam, hanem az Arch rsync wiki File system copy pontjában ajánlott kapcsolókkal oldottam meg. Futó rendszerről a céllemezre nem tudtam átklónozni a rendszert mert a rsync hibára futott. Bebootoltam a MagyArch telepítővel(ami live rendszer is), majd terminálban sudo passwd root, majd su, felcsatoltam csak olvasható módban a forrásmeghajtót(ext4 root filerendszer) a home könyvtárban létrehozott MX500 mappába, a célmeghajtót partícionáltam formáztam, majd a root partíciót felcsatoltam az /mnt alá. Majd következett a fájlrendszer másolás:
rsync -qaHAXS --progress=2 MX500/ /mnt
Azt googlezás után megállapítottam hogy a forrás csatolási pont után / jel szükséges, különben a forrás csatolási pont tartalma nem a célmeghajtó gyökerébe hanem az MX500 könyvtárba kerül
A --progress=2 vel állítólag gyorsul a másolás, ami igaz lehet mert elég gyorsan végzett Ezután kijavítottam a uuid-ket az fstab-ban, majd csatoltam a boot partíciót
a /mnt/boot alá, utána arch-chroot /mnt, majd pacman -S linux amd-ucode, bootctl install, szerkesztettem amit kell, és máris bootolt az átklónozott rendszerMint az látható a MagyArch iso, de akár a CalamArch iso is(kipróbáltam), alkalmas az Arch hagyományos kézi telepítésére/klónozására, közben gui-s böngészőben -firefox- tudjuk nézni az Arch wiki-t, rágooglezni valamire. Mondjuk a CalamArch nál kicsit trükkös magyar kiosztást beállítani
-
A dd ről azt mondják hogy egyszerű és jó eszköz, viszont az üres blokkokat is átmásolja ezért általában lassú.
Arch wikiben ajánlják az e2image-t ext fájlrendszerek másolására:
File system cloning
Using e2image
e2image is a tool included in e2fsprogs for debugging purposes. It can be used to copy ext2, ext3, and ext4 partitions efficiently by only copying the used blocks. Note that this only works for ext2, ext3, and ext4 filesystems, and the unused blocks are not copied so this may not be a useful tool if one is hoping to recover deleted files.
To clone a partition from physical disk/dev/sda, partition 1, to physical disk/dev/sdb, partition 1 with e2image, run
# e2image -ra -p /dev/sda1 /dev/sdb1Ez akkor most úgy működik hogy a céllemezen létrehozom az üres ext4 partíciót és a forráslemez ext4 partíciójáról átmásolom az adatokat e2image-vel a céllemez ext4 partíciójára(a wiki-ben megadott paraméterekkel)? Használtál már e2image-t klónozáshoz? Az e2image talán gyorsabb lenne mint a dd mert csak a használatban levő blokkokat másolja, az üreseket nem.
Szerintem a nem használt blokkok átmásolása egyébként sem tenne jót az ssd-nek, ezért ssd-hez ideálisabb olyan tool ami kihagyja az üres blokkokat. -
válasz
baloo79
#7952
üzenetére
A partclone-val valóban át tudom másolni a partíciókat, viszont utána átméretezni sehogy sem lehetett az így átmásolt partíciókat, és más gondok is voltak, pl újraindítás után elvesztek az átmásolt partícióra írt fájlok, stb, ez azért lehet mert a clonezilla a gpt-uefi vel hadilábon áll. Inkább megoldanám közvetlenül partclone-val ha lehetséges.
-
A partclone tud fizikai lemezről fizikai lemezre partíciót másolni? Ha igen milyen paraméterek kellenek ehhez? Tudna valaki egy példa parancsot írni, ahol ext4 partíciót másol egyik lemezről a másikra partclone-val? Erről nem találtam leírást, csak arról hogy lehet vele partíciót image fájlba menteni. Gondoltam hogy a frissen belakott friss arch telepítésemet átmozgatnám az 500-as crucial-ról az 1tb-os 860QVO-ra. Ha sikerült átmozgatni a partíciót akkor milyen parancsokkal kell átméretezni a partíciót és az ext4 fájlrendszert ? Mert ugye a céllemez nagyobb mint a forrás.
-
válasz
Shyciii
#7941
üzenetére
Nos, nekem a chromium engedett bejelentkezni/syncelni FreeBSD alatt. Verzió: 88.0.4324.182 (Hivatalos verzió) (64 bites) ez van a chromium névjegye alatt. Lehetséges hogy csak az újabb verziókból vették ki a google sync lehetőséget a google kérésére, lehet hogy nem az api támogatást vonták meg? Gyanús hogy így lehet. FreeBSD alatt meg egy ideje nem frissül valamiért a chromium. Nem portsból van, nem forrásból pörgettem, pkg install -al felrakott csomag. Mondjuk beleőszülnék mire ezen a gépen lefordulna a chromium
AMD X4-860K 8GB, kb 5 évvel ezelőtti vas, de még akkor sem a legerősebbek közé tartozott. -
Próbálgatom a Weston-t, hát ezen tisztán wayland módban(xwayland kikapcsolva) még annyi alkalmazás sem fut mint a sway-en, pl deadbeef el sem indul(sway-en fut natív wayland módban). Meg jóval butábbnak tűnik mint a sway, már ami a beállítási lehetőségeket illeti.
Bellőttem egy minimál weston.ini-t, xwaylenddel fut minden, az xwaylandet használó appoknak más a fejléce(így meg lehet különböztetni a natív waylanden futó appoktól), egyéni bill kombókat nem tudom hogy lehet definiálni, ha egyáltalán lehet... -
válasz
Shyciii
#7941
üzenetére
A brave-t ajánlani tudom! Elég stabil. Tedd fel a google-chrome ot AUR-ból és szinkronizáld le amit kell, majd tedd fel a brave-bin-t AUR-ból és az első indításnál felajánlja a beállítások/könyvjelzők átvételét másik böngészőkből, kiválasztod a chrome-t és szépen beimportálja magának amit kell. A brave beállításaiban bekapcsolod a szinkronizálást, generálni fog egy jelmondatot ez lesz a jelszó, mentsd el,(újra telepítéskor jól jöhet).
brave-dev-bin AUR csomag is van, ha az új featureok hamarabb kellenek, bár ez nyilván a stabilitás rovására megy. -
Egyedül a Konsole-t nem párosítanám hozzá, mert bár nem rossz terminál, de elég bloat
Azért használok egyelőre(csak akkor ha vágólap kell terminálban) konsole-t mert nem tudom hogy az alacritty kezeli e a vágólapot, kijelölés másolás beillesztés, ha kezeli a vágólapot akkor ehhez milyen billkombók kellenek. Tudsz olyan wayland képes terminált aminek van a konsole-hoz hasonló menüje és nem bloat ? -
Waybar. Innen húztam le a konfigot:
git clone https://git.sr.ht/~begs/dotfiles/
a dotfiles nevű könyvtárba jön le, sok más sway kiegészítőhöz is van benne konfig.
A waybar konfig a dotfiles/config/waybar könyvtárban található.
Innen nézek példa konfigokat:
https://github.com/Alexays/Waybar/wiki/Examples -
Az arch sway wiki alapján(Keymap rész) konfiguráltam a billzetet magyarra, kicsit módosítottam a wikiben látható példán, működik a magyar kiosztás ezzel:
input * {
xkb_layout "hu"
# xkb_variant "colemak,,typewriter"
# xkb_options "grp:win_space_toggle"
}input Keyboard0 xkb_model "pc105"
Az Fn+F11-re a hangerő le, az Fn+F12-re a hangerő fel, az Fn+F10-re a mute funkciót bindeltem(Custom keybindings rész a wikiben).
bindsym XF86AudioRaiseVolume exec pactl set-sink-volume @DEFAULT_SINK@ +5% bindsym XF86AudioLowerVolume exec pactl set-sink-volume @DEFAULT_SINK@ -5% bindsym XF86AudioMute exec pactl set-sink-mute @DEFAULT_SINK@ toggleEz egy logitech rádiós billzet+egér szett, mk220 azthiszem.
-
Nem irta ki sima terminalos inditassal, csak a cvlc -v kapcsoloval jelenitette meg milyen libek hianyoznak neki es rakerestem melyik lib melyik csomagban van es felrakosgattam ami valoszinu kell a dvb-hez. Ekezetek most nincsenek mert probalgatom a sway-t egy uj telepitesen es meg nem lottem be a magyar bill-t sway alatt. Xwayland-et le kellett tiltsam mert ha inditottam valamit aminek X kellett akkor elcrashelt a sway, kitett konzolra. Ha most inditok valamit aminek X kell, hibauzenetet dob a terminalra es legalabb nem crashel a sway
Chrome, chromium sehogy sem indul wayland modban, a sati altal javasolt kapcsolokkal sem. Ellenben a brave -chromium szarmazek- igen
Jo kis alkalmazasmenu-t allitottam be magamnak sway ala, arch wiki alapjan, .desktop fajlokat is listazza:
bemenu is a native Wayland dmenu replacement which can optionally be combined with j4-dmenu-desktopAUR to provide a Wayland-native combination for launching desktop files (as i3-dmenu-desktop does):
j4-dmenu-desktop --dmenu='bemenu -i --nb "#3f3f3f" --nf "#dcdccc" --fn "pango:DejaVu Sans Mono 12"' --term='termite'A sway/config-ba a kovetkezokepp irtam be, es mukodik:
set $menu j4-dmenu-desktop --dmenu='bemenu -i --nb "#3f3f3f" --nf "#dcdccc" --fn "pango:DejaVu Sans Mono 12"' --term='termite'Elotte termeszetesen felraktam a dmenu-t ugy hogy a wlroots-t hasznalja, meg a j4-dmenu-desktop AUR csomagot. A firefoxnak es a brave-nak csinaltam az /usr/share/applications ala uj desktop fajlokat - firefox-wayland, brave-wayland - amik wayland modba inditjak megfelelo parameterekkel ezeket a bongeszoket, a regi parancsikonokat meghagytam, hiszen nemcsak sway-t hasznalok hanem KDE-t is.
-
válasz
attilav2
#7925
üzenetére
aribb24 - ez a csomag lesz a hunyó szerintem, most letöröltem és egyből nem tudta megnyitni a vlc a dvb-t streamet, miután visszaraktam ezt a csomagot a vlc meg tudta nyitni a dvb-t streamet.
A csomag leírása:
Library for ARIB STD-B24, decoding JIS 8 bit characters and parsing MPEG-TS stream -
Meglett a megoldás, de csak úgy hogy találomra kísérleteztem. a cvlc -v MINDIGTV.channels.conf.test.hu.fta.xspf(lejátszási lista fájl) paranccsal néztem a hibaüzeneteket, hogy milyen .so-kat hiányol, rákerestem a google-n hogy az Archban melyik csomag tartalmazza a kérdéses libet, és egyenként elkezdtem felrakosgatni amelyikről valószínűsítettem hogy kell a dvb-hez, egyszercsak megjavult
Tehát szétcseszték a vlc default függőségeit K*jó 
Jó az Arch meg minden, de ezt az állandó variálást nem szeretem, miért kell szétcseszni egy eddig jól működő csomag default függőségeit ??! -
Próbálok a végére járni hogy a VLC friss Arch telepítésen miért nem képes DVB-T/C streamet/csatornákat megnyitni. Készítettem vlc log-ot ahogy próbálja megnyitni a dvb-t csatornákat, de nem sikerül: [Link] A csatornalista(xml .xspf formátum) amit próbálok megnyitni az új rendszeren(a régi pár éves Arch telepítésemen működik vlc-vel): [Link] az újszegedi adótorony fta csatornái. Segítsetek hol lehet a hiba.
-
válasz
Archttila
#7918
üzenetére
De te ARM-on vagy én meg X86-on, ami egyik platformon működik az lehet h a másikon nem, és fordítva
Letiltottam kísérletképp a sway configjában az xwaylandot sok progi ezután már nem indult el, de a fontosabb alkalmazások ezután is futottak, libreoffice, vlc, clementine(de instabil volt wayland only módban) firefox(a wayland használatát engedélyező mozilla környezeti változó beállítása után futott), chrome és változatai ellenben nem mentek wayland alatt, hiába adtam meg a megfelelő paranccsori kapcsolókat. Ha esetleg még egy környezeti változó is kell a waylandes chrome hoz kérlek írd le melyik az. -
Kipróbáltam, és most is tesztelem a Frawly által istenített Sway-t, a kezdésben sokat segített ez a videó.
Hát elég macerás a kezelése, de a memória fogyasztás tény hogy kisebb mint a KDE-nél. A memória fogyasztást nem mondanám soványnak ~2-2.5gb a 8-ból. Xwayland letiltva, firefox fut 10 tabbal + clementine. A natív waylandes környezetben (dierkt azért tiltottam az xwaylandet hogy tesztelhessem) van jópár program ami nem indul, Pl a chrome alapú böngészők, hiába paramétereztem fel az archwikiben is írt módon(--enable-features=UseOzonePlatform --ozone-platform=wayland), sem a google-chrome-stable, sem a chromium, sem a brave-dev-bin nem indult. Ellenben a firefox egy környezeti változó beállítása után simán fut(amit a fent linkelt videóban írtak le). Libreoffice is fut, vlc is, strawberry nem megy, clementine fut, deadbeef nem fut. Még szoknom kell billentyűkkel való irányítást, de az egérrel részben be lehet segíteni
Gondolkodok egy passzív hűtésű SBC-n/miniszámítógépen(Pl Rock PI X) ami csak böngészésre és alap dolgokra lenne, és oda jól jön egy minimalista wm, mert a proci jóval gyengébb mint egy desktop / laptop-ban. Csak a böngészés végett nem akarom járatni a nagy PC-t, de laptopot sem akarok, így jöttek képbe az SBC-k. Még gondolkodok hogy Arm sbc vagy X86 sbc legyen. -
#7873 jimmy399
Én is szívok, új arch telepítésnél - akár a hivatalos módon kézzel, akár calamarch-al telepítem - a vlc nem képes megnyitni a dvb streamet(se T-t se C-t) a tbs tuner driver(tbsecp3-driver-git-dkms) jól van feltéve mert az mpv megnyitja a streamet. A régi telepítésemen minden további nélkül a vlc is meg tudja nyitni a dvb streamet. Valamit megint variáltak... -
válasz
Laszlo733
#7613
üzenetére
Kipróbáltam a calamarch-ot, bár fel tudom telepíteni az arch-ot a hivatalos módon, nem vagyok annyira láma
, kíváncsi voltam mennyire használható ez a telepítő. Nos azt kell mondjam használható, szinte kulcsra kész rendszert ad. Azt leszámítva hogy nálam a telepítő nem tudta létrehozni a partíciókat, mbr kiosztás volt a céllemezen, én meg uefi módban telepítettem, talán ez lehetett a gond, ebbe még a win10 telepítőnek is beletörhet a bicskája. cfdisk -z /dev/céleszköz módon megoldottam a partícionálást gpt-re, ezután a grafikus telepítő partícionáló részében már csak fájl rendszereket és csatolási pontokat választottam ki a cfdiskben létrehozott partíciókhoz, majd szépen felkúszott a rendszer. Alaprendszert, amd drivereket és xfce4-et telepítettem. Probléma mentesen indult az új rendszer, csak az amdgpu drivert finomhangoltam az arch Wiki alapján hogy ne legyen tearing. -
A brave a chrome alapúak közül egész jónak tűnik, egy ideje használom, eléggé stabilnak tűnik, tán ez most a legjobb chrome alapú böngésző. Aztán ott van az edge ami egy ideje linuxra elérhető lett, ez nem annyira stabil de tetszetős a kinézete(olyan w10 utánérzés
) sajnos az aur csomagját nem frissítik rendszeresen így szerkeszteni kell a PKGBUILD-ot hogy a legfrissebb binárist telepítse, a kommentekbe általában postolja valaki a frissített PKGBUILD-ot. -
Azt ki tudnád listázni hogy nálad milyen font csomagok vannak fenn? Milyen parancssal lehet kilistázni a fenn lévő font csomagokat?
Gondolkodok egy minimalista újratelepítésen, kde helyett mate vagy cinnamon alapokon, mert már eléggé meghízott a rendszer, viszont a fontokkal mindig gondban voltam újratelepítés után, mindig el kellett telnie pár hónapnak mire úgy ahogy helyre rázódott a dolog(weboldalak, rendszer párbeszédpanelek, menük helyesen nézzenek ki). -
válasz
growler
#7798
üzenetére
Szerintem nem éri meg debian csomagokat feltaknyolni, ha elérhető az aur-ban azt kell választani, ha nem elég friss az aur által buildelt csomag át lehet írni a PKGBUILD-ban a deb csomag elérési útját verziószámát stb, és akkor a frissebbet is lebuildeli és felrakja.
Én a chromium vaapi ubuntus ppa változatát taknyoltam fel hasonló módon kézzel ahogy frawly írta, a youtube vga gyorsítás ment vele, de a felrakás módja szétcseszte a jogokat a rendszerkönyvtárakban így más programok hibásan kezdtek működni végül rendszer reinstallal sikerült rendbehozni, szóval aki nem ért nagyon az unix jogokhoz az ne nagyon taknyoljon fel manuálisan más disztróhoz való csomagokat, akár nagy szívás is lehet belőle. -
válasz
jimmy399
#7791
üzenetére
7m-res hdmi kábel szerintem már nagyon hosszú, különösen 4K-hoz, a képpel nincs gond csak a hanggal? Ajánlom az anydesk-et(android/android tv app) a desktop tv-re küldésére hálózaton keresztül. Ha AMD vga-d van akkor windows alatt szóbajöhet az AMD Link amit az adrenalin driver tartalmaz, van hozzá alkalmazás android/android tv-re, vga-s gyorsítást használ a desktop átküldésekor, így jobb mint az anydesk, de sajnos csak windows alatt elérhető mert kell hozzá az adrenalin driver ami linux alatt nincs
-
Egy esetleges jövőbeli szívás ami a chromium használókat fogja érinteni
Hacsak addig el nem áll a szándékától a google.
Use Chromium? Sync Features Will Stop Working on March 15
Egy ideje már a google chrome-ot használom az aur-ból, rendszeresen frissítik.
Az edge-t is használom, bár vannak hibáid de tetszik(a renderelés minősége szerintem elég jó), nem működik az ms account sync egyelőre linux alatt, a legördülő menükben levő linkeket nem nyitja meg a linuxos verzió egyelőre(pl digi.hu), az aur csomagot nem frissítik rendszeresen de a kommentekben általában posztolnak az aktuális verziót letöltő/buildelő PKGBUILD fájlt
Persze csak úgy add kölcsön hogy már openwrt-sítve van. Ha kölcsön akarod adni, akkor ne futárral küldd le, nehogy elvesszen(ahhoz drága), ha pesten járunk valamikor lehet át tudom venni, vagy öcsém lehozza nekem(ha gyál-ig el tudod vinni).
Jó az Arch meg minden, de ezt az állandó variálást nem szeretem, miért kell szétcseszni egy eddig jól működő csomag default függőségeit ??!
Új hozzászólás Aktív témák
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Vírusirtó, Antivirus, VPN kulcsok
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- HIBÁTLAN iPhone SE 2020 64GB White -1 ÉV GARANCIA - Kártyafüggetlen, MS2025, 100% akkumulátor
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 32/64GB RAM RTX 5060 Ti 8GB GAMER PC termékbeszámítással
- Részletre elviheted akár 365 napra Bankmentes , azonnal elérhető Dell GAMER laptop G15 5530 360Hz
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 14 Pro Max 256GB Deep Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3419
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest