- Argos: Szeretem az ecetfát
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- sziku69: Szólánc.
- Flashback: Építsünk PC-t akciós alkatrészekből, lassan. upd: 05.28
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bambano: Bambanő háza tája
- Parci: Milyen mosógépet vegyek?
- Luck Dragon: Asszociációs játék. :)
- vrob: Az IBM PC és a játékok a 80-as években
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
BoB
Topikgazda
Ehez szerintem a google a legjobb megoldás.
Hivatalos oldalon van lista ilyen 3rd repókról (ez nem jelenti azt hogy az összes szerepel is): [link]
Ha el akarod kerülni a repó felvételt a bennük való kereséshez, javaslom a böngésződből csináld, vagy írj rá scriptet ami megteszi.
-
Siriusb
veterán
Szia!
Ezt tedd fel: https://archlinux.org/packages/community/x86_64/virtualbox-host-modules-arch/
Szerk.:
Egy félördöggyorsabb volt.
De csak azért, mert megkísértett az ebéddel!
-
vargalex
félisten
Ha Manjaro-t használsz, akkor nem lenne célszerű a Manjaro wiki-t követni?
Egyébként:
1. Ahogy a wiki is írja, CONFIG_MODULE_SIG_FORCE beállítással fordított custom kernel esetén van rá szükség
2. De, be kell töltődnie. Ha az Arch leírást követted, akkor a virtualbox-host-modules-arch neked nem megfelelő a Manjaro miatt.
3. Lásd 2. -
#63718632
törölt tag
Várjál úgy látom a LightDM-nél van valami gyíkja a rendszerednek.
Ma éjszaka néztem az említett gépet. A cimbim panaszolja, hogy egy ideje a bootolás után a LightDM betöltése megakad. Minimális háttér világítással áll a kijelző és csak hosszú power gomb nyomással lehet kilőni. A vicc, hogy ezt random csinálja, valamikor elindul rendesen, lehet normálisan loginolni.
Aztán ma gyorsan ránéztem, vannak-e friss bug jelentések LightDM ügyben. Vannak bizony, csak mélyebben nem merültem bele.
Szerintem nálad is az van.
Próbáld meg esetleg másik login managerrel felhúzni a rendszert.
Nálam Xfce van, de ha lesz időm feleteszek rá egy GDM-et. -
Frawly
veterán
Ez szerintem csak uninstallállással lehetséges. De nyugodtan uninstallálhatod, a beállításokat az nem törli alapesetben. Tehát csak egy yay -R csomagnév alapján leszeded, majd pacman -Sy csomagnév alapján felteszed. Nem fog elveszni semmilyen beállítás, rendszert sem kell újraindítani.
-
Frawly
veterán
Szerintem az összes ilyen Intéző-szerű fájlkezelő fapad. Ha rendes grafikus fájlkezelő kell, akkor Double Commander-t tedd fel, abból is a gtk-s verzió való Xfce-hez és Cinnamonhoz. Szerintem ez a grafikus fájlkezelők non plus ultrája, az egyetlen, ami pariban van a windowsos Total Commanderrel.
Egyébként a KDE5 belőhető, hogy minden ugyanúgy nézzen ki, mint Xfce alatt. Akármilyen UI elem idegesít, le lehet cserélni, ki lehet iktatni. Lassan már erőforrásigényre is ugyanott vannak, a legújabb Xfce hízott, az egyre újabb verziói a KDE5-nek meg soványodnak (igaz butítják is), így egy szintre ér a kettő.
Persze ha elérsz majd egy még haladóbb szintet, akkor majd saját DE-t alakítasz ki WM-ből, meg valami minimalista panelből.
Ha a legcsilivilibb kell, akkor szerintem csakis KDE vagy esetleg Compiz egy jó témával. Ez a maximum, amit grafikai szépségre ki lehet hozni a Linuxból. De én már fapados WM-ekből is láttam elég szépeket, igazából nem is annyira a WM-en vagy DE-n múlik, mint inkább a háttérkép, színösszeállítás, téma és kompozitor együttesén.
Ha XFCE-t akarsz, akkor nem kell Manjaro-t telepíteni, hanem a meglévő Arch Cinnamonra egyszerűen felteszed az XFCE fullos metacsomagját és login managerben kiválasztod az XFCE-t a Cinnamon helyett, ezt is csak egyszer kell, utána megjegyzi. Az XFCE és a Cinnamon jól megfér egymás mellett, nem vesznek össze, mert mindkettő Gtk3-as.
-
Shyciii
veterán
Én ezért nem vettem AMD-s laptopot magán használatra (sem). Régebben, de az elmúlt időkben is a sok linuxos topicba olvasgatva továbbra is sokkal több probléma van az AMD-s GPU-kkal, mint az Intel-ekkel. Amúgy én hogy írtad megnéztem a Fedorát, illetve terveztem, aztán elkedztem olvasgatni mit, merre, hogyan, és rögtön le is tettem róla, hogy ugyanazt kialakítsam rajta, mint Arch-on, mert Fedora-n is jó sok korlátba ütköznék, mint Debian esetében.
Egyébként csak hogy Arch mennyire nem való munkára. Ugye ez otthoni magánhasználatra van ez az Arch + Openbox. Ehhez képest most ezen home office-olok probléma nélkül: OpenVPN, VNC, Telegram, Teamviewer, Zoom. Közben avi-t dekódolok mkv-be AC3-as kódolással, de volt hogy közben konvertáltam szintén parancsosors progival SACD-t nagyfelbontású FLAC-re. Semmi bajom nincs. Egyszer összeállítottam, és működik rendben. -
Frawly
veterán
Jó, te tudod. Nyilván azt használsz, amit akarsz, nem mi szabjuk meg. De ha már egyszer Archon megfejtetted a hiba okát, akkor nem sok értelmét látom fedorázni. Egyébként az Arch ilyen, egyszer kell szívni vele, kiismered rajta a dolgokat, utána viszont kézreáll, kezesbárány, gondod nem lesz vele többet, legalábbis nem lényegi, meg semmi olyan, amit ne tanulnál meg egyszerűen megoldani. Emiatt bőven megéri bele időt feccölni, hosszú távon bőven meghálálja magát.
Ezzel szemben kiadás alapú és félrolling disztróknál minden kiadásban mást csesznek el, és mindig teljesen új felállással szívhatsz, sose tudod mire számíts.
Fedorán egyébként azért nem volt gondod ezzel, mert ott beletesznek mindenféle csomagot, meg kernelparamétert, és ugyan ez az esetek nagyobb részében kényelmesnek tűnhet, viszont sokkal bloatabbá is teszi a rendszert. Archon ezzel szemben minimalista vonalon építkezés a cél.
-
Frawly
veterán
Szerintem meg nem az Arch/Manjaro hibája, vagyis olyan értelemben az, hogy ők nem adják hozzá automatice ezeket a kapcsolókat, vagy úgy fordítják le a kernelt, hogy szükséges a kapcsoló. De ez nem azért van, hogy téged szopassanak, hanem hogy vanilla állapotban tartsák a csomagokat, neked ettől még megvan ez a lehetőséged, hogy kernelparaméterekkel meg egyebekkel szórakozz. Ez az Archnak a „hekkeld magad” filozófiájából ered, ők nem foltozgatnak semmi disztróspecifikus dolgot a csomagokba.
Ehhez képest a Debian, Ubuntu és Fedora vonalán a disztrókészítők tengernyi patcht meg disztróspecifikus beállítást eleve odahekkelnek default, azért megy. Ez hihetetlenül kényelmesnek is tűnik, de ennek is megvan legalább annyi hátránya, csak máshogy jön ki, pl. ha egy vanilla csomagot forráskódból forgatsz (mert nincs meg semmilyen tárolóban, nem hivatalos külső tárolóban sem), akkor néha meg az a szopás, hogy nem fut normálisan a kód valami disztróspecifikus patch-csel összeveszve, ami épp ott csücsül a futó binárisokban. Vagy pl. ilyen külön patcheléssel nem tudják olyan gyorsan kihozni az új verziókat, mindig csak fáziskéséssel tudják kiadni.
Ami az Arch/Manjaro hibája, az az, hogy ezeket az esetlegesen szükséges kernelparamétereket, nem kommunikálják le, de ez részben a kernelkészítők igénytelensége is, hogy nem tartják rendesen karban a dokumentációt. A kerneldoksinak tartalmaznia kéne ezeket a GPU specifikus dolgokat, hogy melyik generációs kártyára milyen kapcsolók kellenek, meg az Arch Wikinek is ki kéne térnie erre, külön felhívva a figyelmet, hogy ilyen meg olyan AMD GPU generációknál erre szükség lehet, fokozottan kell rá figyelni.
De én még az AMD-től is elvárnám, hogy a linuxos driveroldalukon összehozzanak egy általános linuxos Wiki cikket, ahol sorra veszik, hogy milyen GPU generációknál milyen beállítások, driverek, stb. kellenek a főbb disztróvonalakon, hogy használható legyen a ×4rjuk.
És itt most nem az Arch-osokat akarom védeni, hanem azt kell érteni, hogy nem vagy nem csak miattuk szenvedsz, hanem több ember és cég érdektelensége miatt kell szívni, meg küzdeni, mire rájössz ilyen hekkelős megoldásokra.
-
Frawly
veterán
Gondolom a frissebb kernelben megváltozott az amdgpu driver, az tette szükségessé, bár nem tudom mit csinál ez a két kapcsoló, magamtól erre rá nem jöttem volna. Egyébként nem is az a gond, hogy ilyen kernelparaméterekre szükség lesz, hanem nincs lekommunikálva rendesen, és sokszor a kerneldokumentáció sem egyértelmű. Ez utóbbit elég sokan kritizálják is, hogy a kernel doksija nincs rendesen karbantartva, a kernelt fejlesztik ezerrel, a dokumentáció meg le van maradva jócskán.
-
Sziasztok!
A korábbi hibára meglett a megoldás, amit egy fórumban találtam.
A kernel paraméterek közé be kellett tenni ezt:amd_iommu=on iommu=pt
A kérdés, hogy egy frissítéstől miért lett erre szükség?
Nagyon kiváncsi lennék a válaszra.Előre is köszi!
-
Frawly
veterán
Az, hogy te telepíted fel esetleg a szükséges csomagokat, firmware-t, vagy valami, pl. AMD GPU-s gépről váltasz NV GPU-sra (utóbbinál lényegében muszáj zárt drivert használni). Vagy Inteles gépről AMD-sre, és másik microcode csomag kell. Esetleg a Wi-Fi kártya változik meg teljesen, AUR-ból kell forgatott drivert, kernelmodult feltenned, és emiatt nem működnek a korábbi hálózati konfigok. Nem azt mondom, hogy biztosan így lesz, de még ezen a téren is pozitívabb lehet újratelepíteni. Ha telepítettél már Archot, nem nagy munka újratelepíteni, ha már érted mit csinálsz. Bootpartícióhoz pl. nem is kell nyúlni, bootmanager, bootolási mód is maradhat. A korábbi konfigokat is elmentheted a ~/ mappádból, /etc-ből, stb.. Persze, valamennyi munka újratelepíteni, de nem rosszabb, mint egy problémás rendszer frissítésével küzdeni.
Nem kötelező persze hardverváltozáskor újratelepíteni, azok az esetek, amiket példának említettem, megoldhatók újratelepítés nélkül is, de mégis csak jobb új lappal kezdeni.
-
Frawly
veterán
Én nem frissítgetnék egy olyan rendszert, amit nem használok. Szerintem jobban jársz, ha egy év múlva újratelepíted. Legalább:
1) gyakorlod a telepítést
2) friss lappal kezdesz
3) eladtad a géped alóla, az új gépen lehet már másik hardverkiépítés lesz, és egy frissen telepített rendszer jobban tud ahhoz igazodni. -
BoB
Topikgazda
Megoldható, de kérdés hogy mi tartana több ideig neked, egy friss telepítés vagy egy update.
Ha update akkor természetesen minden manual cuccot meg kell majd csinálnod, de lehet hogy automatikusan nem fog menni már akkor (a dolog jellegétől függően), olyankor extra munka lesz vele.
-
vinibali
őstag
a laptopok esetén azért teljesen más a felállás, mert van egy muxed/muxless switch.
én egy ideje már - nagy szerencsémre - Asus lapokat használok, és idáig (FM1->FM2->FM2+->AM4) mindegyiken volt egy IGFX Multi-monitor support opció a BIOS-ban. talán azzal lenne még érdemes játszani, mindamellett ez teljesen másképpen műküdik végeredményben Linux és Windows alatt.
viszont az igényed nagyon egyedi, talán az AMDGPU display core-ral lenne érdemes valamit nézelődni. -
Frawly
veterán
BIOS-t próbálj meg frissíteni, lehet úgy az új BIOS ténylegesen is le tudja kapcsolni a kívánt GPU-t. Nagyon más ötletem már nincs.
Az acpi-call-dkms-nél konkrétan arra gondoltam, hogy a hozzá való kernelmodullal együtt. Arch alapú disztrókon elvileg AUR-ban van, és kernelmodullal együtt települ.
-
Frawly
veterán
Hú, ez tényleg húzósabb, mint gondoltam. Minden oldal ezt az acpi-call-t írja, amit az Arch Wiki is. Esetleg acpi call dkms?
Akkor könnyebb lenne, ha két különböző gyártójú GPU lenne. De így, hogy mindkettő AMD és mindkettőt az amdgpu kerneldriver hajtja, így kiesik a kernelparaméteres letiltogatás, hiszen ha letiltod, akkor egyikkel sem lesz kép.
-
Frawly
veterán
Ezt kernelparaméterrel lehet elérni, a bootloaderben megadod a kernel mögött a vonatkozó paramétert, hogy az IGP-t használja. De ehhez tudni kéne, hogy pontosan milyen IGP-ről van szó.
Szintén kernelparamétereknél le lehet tiltani a dGPU-t is. Ehhez megint tudni kéne, hogy pontosan milyen GPU-ról van szó.
-
Frawly
veterán
Nálam i7-es notin az egész Atom volt kompletten lassú, indulás, szöveg beírása, menük reakcióideje. Pedig még plugin is alig volt fent, azért is volt fapados.
A vim valóban érthetetlennek tűnik elsőre, mert gépíráshoz tervezték, meg módok között kell váltani, és ezt nehéz megszokni. Egyébként a vim nem is szövegszerkesztő, hanem szövegfeldolgozó, olyasmi, mint a sed, awk, csak valós időben viszed be szövegmanipuláló parancsokat billentyűkkel. Eleve, mikor manipulálja valaki vele a szöveget, akkor nem úgy kell gondolkodni, mint egy normál szövegszerkeszőnél.
A Geany teljesen jó. Régen a Kate volt még jó, igaz az nem nagyobb projektekhez volt akkor sem való, de az 5-ős verziótól kezdve agyon van butítva, ahogy a Gedit is. Ezért a vim előtt SciTe-t használtam. Jó még a Sublime, de az fizetős. A Kommodo Edit sem lenne rossz, de az elviselhetetlenül bloat. Projektekhez állítólag a Visual Studio Code jó, az ingyenes.
Aki vim-mel próbálkozik: mindenképp a gvim-et tegye fel, akkor is, ha nem GUI-n használja (javasolt nem GUI-sat használni), hanem terminálból. Azért gvim-et, mert az abban lévő vim tudja a vágólapkezelést a X.org felé. A sima vim csomagban lévő vim-ből ki van szedve egy csomó funkció, eleve úgy van forgatva a forráskód. Illetve a neovim-mel lehet próbálkozni, de az nem sztenderd még, nem próbáltam.
Amire még sokan esküsznek, de nekem mindig is átláthatatlan volt, meg nehezen lenyomható billkombói vannak: Emacs.
-
Frawly
veterán
Nem ugyanaz a mikrokód minden AMD procinál. De azonos csomagban vannak, linux-firmware, alapból telepítve van, induláskor a kernel ebből betölti a gépben lévő procira vonatkozót.
A GPU driver attól függ milyen GPU-d van. Ha AMD, ahhoz nem szokott megint semmi extra kelleni, a linux-firmware csomagban ott vannak a szükséges firmware-ek hozzá, a kernelben meg az opensource driver, ehhez már csak a mesa csomag kell, de ez is fel szokott kerülni függőségnek.
Szerintem a váltásnál nem lesz problémád, főleg, hogy AMD-ről AMD-re váltasz. Simán mennie kéne mindennek.
-
Siriusb
veterán
Ami így hirtelen eszembe jut e késői órán:
Letörlöd a régi VGA és proci specifikus csomagokat és konfigokat. Grub kipofozása. Fallback módban elindít, mkinitcpio -p linux futtat. Ja, és az új hardver specifikus cuccok telepítése.Szerk.: Biztos kihagytam valamit, de majd a többiek megmondják.
(#5805) BoB
Kösz -
vargalex
félisten
Én először rTorrent-et használtam, majd sokáig Transmission-t. Aztán visszatértem az rTorrent-re, majd váltottam qBittorrent-re. Utóbbi jóval gyorsabban elkezd maximális sebességen tölteni. Az rTorrent sajnos feleslegesen jobban terheli a háttértárat seed alatt (nagyságrendekkel több adatot olvas, mint kellene). Én egyelőre maradok a qBittorrent-nél, ami nálam egy AsRock J3455-ITX lapon fut (az otthoni mini szerverem/NAS-om, természetesen Arch-al), gond nélkül kihajtja az 500 Mbps-es netet. 60 MB/s letöltésnél a magok még csak fel sem kapcsolnak maximális órajelre...
-
Frawly
veterán
Erről nem kell neked gondoskodni. Ha a proci lesz a szűk keresztmetszet, akkor a kernel ütemezője úgyis úgy fogja pakolgatni a szálakat, hogy jól kihasználja a procit. Ennek ellenére a gigabites netet azzal a procival nem fogod tudni kihajtani, túl gyenge (rossz IPC, kicsi freki, kevés L2 cache, amin az összes mag osztozik), több szálon futó torrentprogival sem. Egy normálisabb i5/i7-es szintet szoktak ajánlani gigabithez.
Fogadd el, hogy csak egy részét leszel képes kihajtani a gigabitnek, vagy cseréld le azt a gépet / procit.
Egyébként meg a gigabites netnek ezért nincs lakossági szinten értelme. A legtöbb embernek se a kábelei, se a routere, se a Wi-Fi-je, se a hálókártyái, gépei, akármilyei nem tudják kihajtani a felét sem.
Ha nagyon minimalista torrentprogi kell, akkor rtorrent.
-
Shyciii
veterán
Igen, a Deluge volt a másik amit a Transmission mellett érdemesnek találtam a qbitorrent helyett. Egyelőre most hagyom a Transmission-t. Ha pár nap alatt nem válik be, vagy nem tetszik, akkor kipróbálom a Deluge-t is. Flacon helyett split2flc -t találtam, de persze külsőre ég és föld, hisz parancssoros ahogy néztem, de még nem próbáltam ki, mert most épp nincs olyan flac-em amit darabolni kellene. A gáz az XnView lesz és a VLC. Ezekhez nagyon hozzászoktam hosszú évek alatt. Ebben az esetben meg kell erőszakolnom magam
No meg a notepadqq miatt is...
-
Shyciii
veterán
Mikor Openbox-ra áttértem én is így tettem, de van pár berögződés még Win-es korszakból (meg KDE-s Manjaro-ból is), ami miatt pár QT-s cuccom van.
Win-es korszakból:
- Xnview képnézőnek
- VLC média lejátszónak
- Qbittorrent -> mondjuk tegnap átváltottam Transmission-ra. Kevesebbet tud, de jó ez is nekem ahogy most próbáltam.
Manjaro KDE-ből:
- Flacon -> 1 darabos FLAC fileok szétválasztása
- FF Multi Converter -> képek, videók konvertálása más formátumra
- Notepadqq szövegszerkesztőDe muszáj lesz keresnem alternatívákat amik megfelelnek nekem a hülye berögződéseim ellenére is, mert ha nem is fog bejönni a sötét téma (bár most nagyon tetszik épp), akkor se jó, hogy ennyire meg van kötve a kezem. És az már tuti, hogy soha többet nem fogok KDE-re visszamenni.
-
Frawly
veterán
A password timeout-ot nem ajánlom 0-ra venni. Sőt, azt sem, hogy csak egyszer kérjen jelszót tty_tickets-szel , és onnantól az egész sessionben ne kelljen újra sudo-t megadni, másik ablakban sem. Hihetetlen kényelmes, de biztonságilag megkérdőjelezhető. Egyszer futtatsz valamit sudo-ként onnan minden szutyok egyszerű sudo-val rendszergazdai joghoz jut, elég veszélyes.
A kényelem és a biztonság egymást kizáró fogalmak.
Az AUR-ból forgatás úgyis csak a legelején és a legvégén kér jelszót. Először mikor a build függőségeket teszi fel, másodszor mikor a kész csomagot. Nem kell ott ülni mellette. Ha végzett és time outolna, akkor a cache-ben megmarad a kész csomag, azt felteszed pacman -U segítségével.
(#5689) Siriusb: wow, ezt a nobody useres trükköt nem ismertem. Ez a jó a Linuxban, minden nap tanul az ember valamit.
-
Frawly
veterán
A sima userként lefordítod és betömöríted csomagot yay-jel, majd root-ként pacman - U ~/.cache/yay/új-csomag-neve.tar.xz módon.
De szerintem minden AUR helpernek fog kelleni sudo jog, mert a végén, amikor a csomagokat telepítenék, ahhoz nélkülözhetetlen. Vagy csinálod úgy, ahogy fent írtam, cache-ből telepíted rootként a kész csomagot.
Azt sem értem, hogy miért ne akarnád a felhasználód felvenni a sudoers-be, vagy ha nem akarod, akkor gondolom biztonsági célzattal, de akkor meg miért szeretnéd, hogy tudjon mégis a rendszerre csomagokat feltelepíteni? Valahogy az egész problémád nem áll össze nekem.
-
Shyciii
veterán
Elhiszem, hogy az a kénylemesebb, ha su-zol, aztán kész, de ugye a biztonság, és a kényelem nem fér meg egymás mellett. Pont ez a módszer nem biztonságos. Egy olyan cég, aki figyel a biztonságra, ott a rendszerüzemeltetők nem su-zhatnak, csak kivételes esetekben.
Amúgy engem is zavar valamennyire, főleg Windows után, de mivel elég gyorsan gépelek, így a masszív hosszú jelszóval se gond már nekem a sudo-zás -
Siriusb
veterán
Amint vargalex is mondta, tudod szabályozni, milyen parancsok futhassanak emelt joggal a te felhasználóddal, ez mennyi ideig tartson, stb.
Persze még mindig megteheted, hogy leforgatod a csomagokat és manuálisan telepíted, de ez macera.
Amúgy engem is idegesít ez a sudo-zás, Ubuntunál nagyon megutáltam annak idején. Kb. csak a pikaur-nál használom. Nyitok egy root terminált, megcsinálom, amiket kell és bezárom, nekem így áll kézre, hiszen a napi teendőkhöz kevés root jog kell.
-
Siriusb
veterán
makepg nem futhat root-ként.
Running makepkg itself as root is disallowed.[2] Besides how a PKGBUILD may contain arbitrary commands, building as root is generally considered unsafe.[3] Users who have no access to a regular user account should run makepkg as the nobody user -
Sonja
nagyúr
A második kérdésre válaszolva szerintem nincs elindítva a dhcpcd service.
A
systemctl enable dhcpcd.service
parancsot kiadva boot után már lennie kell.Szerk.: Én végül befejeztem az Archot. Igaz, az Openboxot dobtam, mert semmi kedvem nem volt ennyit szórakozni.
Ment fel egy XFCE, és öröm, boldogság van.
Minden működik, ahogy az kell.
-
Frawly
veterán
Üdv az igazi archerek táborában.
AUR-hoz és yaourt-ot használok. Ha nem akarsz AUR-ozni, akkor azt is lehet csinálni, hogy a nevezett progikhoz letöltesz az oldalukról .deb csomagot, vagy tar.gz binárist, kibontod és használod úgy, ami függésük van, azt pacman-nal felteszed.
Flatpak, Snap használata csak a legvégső esetben ajánlott.
-
Siriusb
veterán
Úgy emlékszem Cinnamon-ék nem támogatják még a Wayland-et.
Részemről az aurman-t használom, bár igyekszem kerülni a hivatalos tárolókon kívüli csomagok használatát.
Szerintem a Linux egyik fő erőssége, hogy egy cucc csak egy verzióban van fent a rendszerben, s nem százféle változatban, mint a tudjukkinél. Szóval ebben az irányban elmenni (hacsak tényleg nem muszáj), nem éppen a jó út.
-
Frawly
veterán
Az Archnál a csomagfenntartó (tipikusan egy heftig nevű user) kénye-kedve dönti el, hogy melyik verziókat ugorja át. Most biztos több ideje volt, így azonnal ráment a 4.19-es kernel tesztelésére (staging vagy testing tárolóban), és mivel az sikeres volt, gyorsan kiadta 4.19.1-et a stable tárolóba, és nem pöcsölt a 4.18-as ág frissítésével, mert hát minek, ha van újabb és azzal sincs probléma. A régi ágat akkor szokta frissítgetni, ha az új még instabil szerinte, nem alkalmas éles bevetésre.
Vagy olyan is van, hogy az új tesztelésére nem ér rá magánéletbeli gondok miatt, ezért a régi ágat frissítgeti helyette.
-
Siriusb
veterán
Azért nem mindent nyomnak ki ész nélkül.
Persze volt már problémám nekem is frissítéssel, pláne amikor a függőségek is frissültek és bonyolult lett volna a downgrade... Azonban nagyon ritkán ütköztem komolyabb problémába. 10 évvel ezelőtt szvsz az Ubuntuval sokkal többet kínlódott az ember.
Gondolom a kernelre azért jobban odafigyelnek, mint pl. a gThumb-ra. -
Siriusb
veterán
Szia!
Ugye először csak a testing-be kerül be, s ha valami miatt problémás, vagy közben jön a javítás hozzá, szerintem akkor az adott verziót kihagyják, nem teszik ki mindenáron a népnek. Biztos láttad már csomagoknál, hogy az Arch alverzió 2-es vagy 3-as, amikor frissül, szóval csak a működő változat lesz publikus. -
Frawly
veterán
efibootmgr-rel milyen paramétereket vittél be a bootoló Archnak?
Gondolok itt erre a sorra, hogy milyen formában oldottad meg:
efibootmgr --disk /dev/sdX --part Y --create --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw initrd=\initramfs-linux.img' --verboseEbből főleg a PARTUUID nagyon fontos, hogy egyezzen, a blkid paranccsal tudod ellenőrizni. De a /dev/sd-akármi is fontos, meg a partíció száma.
Az EFI engedélyezettségét úgy tudod ellenőrizni, ha kiadod az
ls /sys/firmware/efi/efivars
parancsot, ha van, amiket kilistáz, akkor biztosan EFI módban vagy. -
-
Frawly
veterán
Ha már fent van a Windows, akkor még könnyebb is az UEFI boot, mivel a Windows telepítője már megcsinálta az EFI partíciót, meg létrehozta a /boot/loader/loader.conf-ot, így annyival is kevesebb munka van vele, neked a bootctl install után csak a kész loader.conf-ot kell szerkeszteni, meg egy arch.conf-ot a entries mappába és így csak bővíted a már meglévő UEFI bootos opciókat egy újabbal. Teljesen veszélytelen művelet, mivel a Windows bootolhatóságát nem érinti, még ha el is rontasz valamit, attól legfeljebb csak az Arch nem fog bootolni.
Van egy másik módszer az EFI systemd-booton kívül. Ez pedig a EFI stub boot, ezzel már egy másik Arch Wiki cikk foglalkozik. Itt nem az EFI partíción lévő .conf fájlokkal zsonglőrködünk, hanem efibootmgr futtatásával közvetlenül az UEFI-ben matatunk, adjuk hozzá kézzel a bootopciókat. Na, ez veszélyes, mert ha valamit rosszul viszünk fel, bootképtelenné vállhat a gép, és ha nincs defaultra állítás az UEFI-ben opcióként, akkor az egész UEFI-t haza lehet vele vágni. Ezt tényleg csak annak ajánlott, aki tudja mit csinál.
-
Frawly
veterán
Nincs hátránya, de Arch-nál felesleges, mivel ott eleve live iso-t töltesz be, és igaz nincs grafikus felület, de pl. a cfdisk text user interface-t tud nyújtani, ami legalább olyan használható, mint egy grafikus tool. Annyi, hogy utána a csatolásokat is neked kell csinálni, mivel az Archban nincs telepítő, de pont ez a poén benne, hogy mindent te csinálsz kézzel, látod mi futott le, mit tettél fel, így nincs az, hogy nem tudod miért nem megy. Különösen áll ez az UEFI bootra, amit a telepítők 90+%-a el szokott qrni, pedig a világ legegyszerűbb dolga, ha egyszer kézzel telepítve Wiki alapján megérted hogyan működik.
-
Frawly
veterán
Lehet lemezképet klónozni, de akár tar-ral is át lehet vinni az új rendszert. Vagy rsynccel. Vagy CloneZillával. Sokféle módja van. Én legutóbb tar-ral csináltam:
cd /
tar -cvpzf --one-file-system /cel/backup.tar.gzKicsomagolni ezzel csomagoltam ki, ha jól emlékszek:
tar -xf backup.tar.gz -C /Ha Tar-ral vagy rsync-kel csinálod, akkor viszont partíció UUID-t módosítani kell a bootmanagerben, /etc/fstab-ban.
EUFI boot elvileg lehetséges EFI partíció nélkül is, de nem tudom hogyan. Kék luficet kolléga (colomb2) szokta propagálni, de nem értettem hogy működik, mert én elvi szinten sem tartom lehetségesnek. Valahogy ő mégis használ ilyen megoldást Gentoo alatt.
-
Frawly
veterán
Nem. A 3. pont független a gnome themestől. Ha normálisan működik a lightdm, akkor ne nyúlj hozzá. Érdekességnek összevetheted mi van az új .conf.pacnew fájlban, miben más, mint a te konfigod. Csak figyelmeztet, hogy az új csomagverzióban lévő .conf nem lép életbe automatikusan (nem akarja a te konfigolásodat automatán tönkretenni, felülírni), így ha mégis életbe szeretnéd léptetni, akkor a mostani .conf-ot nevezet át .conf.old-ra, az újat meg .conf.pacnew-ről .conf-ra.
A 2. pont viszont tényleg amiatt volt, hogy nem egyeztél bele a cserébe.
-
Siriusb
veterán
Az ilyen konfigurációs fájlok nem íródnak felül, hogy az általad végzett módosítások ne vesszenek el. Amennyiben pl. verzióváltás miatt nem váltak idejétmúlttá a beállítások, sok teendőd nincs. Én mindig összehasonlítom és összefésülöm a két fájlt, hogy könnyebben nyomonkövethető legyen a fejlesztőtől érkező változ(tat)ás. Erre használhatod a vimdiff-et vagy a meld-et is akár.
-
-
Frawly
veterán
Rosszul tetted. A Yes-re kell nyomni. Nálam is előjött, a Y-t megadva neki sikerrel lement a frissítés, mindenféle hiba nélkül. Nem rontottál el semmit, futtasd újra a frissítést, meg fogja kérdezni újra, és most ezúttal egyezz bele a cserébe.
Ezzel a possibly missing firmware for module aic94xx és wd719x figyelmeztetéssel nem kell foglalkozni, ezt mindenkinél kiírja. Még a kezdeti időkben benne hagyták ezt a f4sságot az initramfs-generáló mkinitcpio szkriptben, ezért mióta Arch az Arch, ezt írogatja ki mindenkinek. Majd megszokod, mikor már 1000×-re látod minden kernel/systemd-frissítés után. Nem te vagy az első, akinek szúrja a szemét. Annyira alaptalan és annyira régi dolog, hogy lassan inkább mém lesz már belőle
-
vinibali
őstag
meg kellene nézni, hogy milyen hangkártyák vannak a gépben és az ALSA melyiket használja.
már ha te is ALSA-t használsz[balazs@archBalazsPC ramdisk]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Generic [HD-Audio Generic], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Generic [HD-Audio Generic], device 1: ALC892 Digital [ALC892 Digital]
Subdevices: 0/1
Subdevice #0: subdevice #0
a kívánt hangkártyát kell beállítani az/usr/share/alsa/alsa.conf
-ban.
kicsit több olvasnivaló: Set the default sound card
nálam ezek az értékek az integrált hangkártyát szólaltatják meg.defaults.ctl.card 1
defaults.pcm.card 1
defaults.pcm.device 1
defaults.pcm.subdevice -1
ha mindezek rendben vannak akkor azalsamixer
binárissal lehet szabályozni a ki- és bemeneteket.
egyébként nekem úgy tűnik, hogy kernel kiadásonként is gyakran kell ehhez a fájlhoz nyúkálni.
ha pulseaudio-t használ az Arch-od, akkor meg a GUI-val van "csak" dolgod. -
Rimuru
veterán
UEFI csatolás volt szívás, mert 2-3 újabb linkelt doksiból kellett kibogarásznom - szerintem grub wikiben ott van minden
Létezik, hogy ez nekem kimaradt? - letezik, amikor pacman felrakja a kernelt akkor egy hook megcsinalja magatol (csak ha pl valtoztatsz a configon akkor kell manualisan futtatni -ha szeretned ervenybe lepteti-) -
Frawly
veterán
A Cinnamon nem támogatja a Waylandet, a GDM igen. Elég kevés DE, WM, DM támogatja, tényleg csak egy maréknyi, de alkalmazás sincs túl sok, amit támogatná (a többieknek az XWayland emulál Xorgot). Távolítsd el pacman -Rs segítségével, majd telepítsd újra a Xorg-ot és a Cinnamont. Kéne mennie. GDM-et fenthagyhatod, nem muszáj Gnome-mal használni, más DE-ket, WM-eket is indíthat, támogatja a Xorgot is.
A Wayland egyébként nem jobb, csak modernebb, és mivel saját maga is egyben kompozitor, ezért nem kell hozzá külön kompozitort feltenni, mint X-nél. Ha annyira Waylandet akarsz, akkor Gnome3-at vagy KDE5-öt telepíts, azokkal rendesen működik, azok behúzzák függőségnek, és rendesen konfigurálja is a rendszer, nem kell vele semmit kínlódnod.
Az Arch telepítése nem nehéz, ha csak alap telepítést csinálsz. Bonyodalom onnan lehet, ha valami extra dologgal telepíted, systemd UEFI boot, LVM, LUKS, ezek kombinációja, hasonlók. Egyébként rém könnyű feltenni, kialakítod neki a partíciókat, felcsatolod őket, genfstab futtatása, pacstrap-pal alaprendszert telepítesz a felcsatolt root partícióra, átváltasz rá arch-chroot-tal, ott még feltelepíted amit kell pacman -S segítségével, hostname, lokalizáció beállítása, bootmanager telepítése, mkinitcpio-val initramfs készítése, passwd futtatásával root jelszó beállítása, reboot. A bootmanagerrel lehet esetleg nagyokat szívni, de ez nagyban függ, hogy melyiket választod, meg használsz-e UEFI bootot, meg hogy más OS-t használsz-e dual/multibootban.
Ha megvan az alaprendszer, onnan a telepítés további nehézsége attól függ, hogy komplett, fullos DE-t telepítesz-e fel, mert az leszedi magának az összes függőséget, és kulcsrakész rendszert kapsz. Ha viszont kisebb WM-et akarsz feltenni, ahhoz még elég sokmindent kell konfigolni, meg tudni hozzá, hogy melyik csomagokat szedjed le és konfigoljad, hogy az igényeid szerint tudjad használni, ha tapasztalatlan vagy, ez tud nehézségek elég állítani, meg nyálazni kell a Wiki-t sasszemekkel, de ez is csak első telepítésnél nehéz, amíg nem tapasztaltad ki.
Esetleg néhány driver feltétele lehet még szívás, főleg, ha GPU drivernél ragaszkodsz a zárt driverhez vagy valami speciális megoldáshoz, vagy virtualizációhoz kell kernelhackhez, forgatni kell Wi-Fi drivert, stb..
Már el is felejtettem sok mindent, mivel az Arch olyan, hogy ha egyszer feltelepíted, akkor többet arra a gépre a büdös életben nem kell újratelepíteni, hacsak ki nem rohad alóla a gép, vagy a disk, vagy az user szét nem cseszi valami bénasággal a telepítést, és nem tudja megjavítani. Egyébként magától frissül a végtelenségig, mivel rolling, nincs disztrófrissítés. Legutóbb 9 hónapja tettem fel egy használtan vásárolt laptopra, amibe mindjárt egy SSD is került.
-
Siriusb
veterán
Épp ilyenkor fontos a megfelelő lépések megismerése.
Egyébként ez a könyvtár csupán arra szolgál, hogy rendszerszinten meghatározd, mely alkalmazások induljanak el automatikusan a bejelentkezés után (minden felhasználónál). Felhasználói szinten ez a ~/.config/autostart/. Persze pl. az ablakkezelőknél (openbox), van saját fájl, ahol mindezt megadhatod. -
Siriusb
veterán
Gondolom kezd tönkremenni a merevlemez. Soha nem volt rá szükségem, szóval a mikéntjét nem tudom megmondani, de át kell olvasni az fsck leírását, szerintem megjelöli a hibás szektorokat és nem fog oda dolgozni az írás során. Ha rövid időn belül újabb hibás szektorok keletkeznek, akkor fejvesztve kellene új merevlemez után nézni, s már most elkezdeni a fontos adatok lementését.
Valószínűleg be kellene állítani, hogy induláskor teljes ellenőrzést hajtson végre (ha elfogadható az időveszteség számodra) vagy rendszeresen kézi vezérléssel ellenőrizni.
Új hozzászólás Aktív témák
Hirdetés
- Autós topik
- Argos: Szeretem az ecetfát
- Samsung Galaxy S25 - végre van kicsi!
- Hardcore café
- Milyen okostelefont vegyek?
- Épített vízhűtés (nem kompakt) topic
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Honda topik
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Gyermek PC játékok
- Assassin's Creed Shadows Collector's Edition PC
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Alkatrészt cserélnél vagy bővítenél? Nálunk van, ami kell! Enterprise alkatrészek ITT
- AZONNALI SZÁLLÍTÁSSAL Eladó Windows 8 / 8.1 Pro
- Telefon felvásárlás!! Huawei P20 Lite/Huawei P20/Huawei P30 Lite/Huawei P30/Huawei P30 Pro
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 XT GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest