- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy S23 Ultra - non plus ultra
- One mobilszolgáltatások
- Milyen okostelefont vegyek?
- Nem növel telepméretet a Galaxy S26 Ultra
- CMF Buds Pro 2 - feltekerheted a hangerőt
- Xiaomi 15 Ultra - kamera, telefon
- OnePlus 8 Pro - a túlgondolt
- Okosóra és okoskiegészítő topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
-
Mobilarena
Arch Linux topik
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
Shyciii
#5627
üzenetére
Ehhez telepítened kell az adott DE-hez vagy WM-hez való clipboard managert. Ez nem a Linux, hanem a X.org korlátozása, az alkalmazás bezárásával eltűnik az is, amit vágólapra rakott. A clipboard manager ezt kivédi, mert ő mindvégig fut, menedzseli a vágólapot, nem hagyja elveszni, de extrákat is nyújt, vissza is lehet több lépésben is állítani a régi tartalmát a vágólapnak, meg alkalmazásonként, MIME típusonként is lehet szűrni, stb., szóval érdemes ilyet használni.
Esetleg Wayland használata, de ott ugyanez áll fenn, waylandes progik között működőképes marad a vágólap, akkor is, ha az eredeti alkalmazást bezártad, de Waylanden is gond, hogy az X-es progi X.org-os vágólapot keres nagy xorgalommal, és abban nem talál semmit, így esetleg nem működik a beillesztés akkor sem, ha az eredeti program fut.
-
Frawly
veterán
Közben már utánaolvastam, hogy a nano támogatja, hogy színeket lehessen beállítani, ehhez a nanorc-t kell szerkeszteni, van külön man-ja. Persze alapból nincs olyan kapcsoló, hogy legyen színes (csak a kódot tudja színezni), hanem a színeket külön kell belőni egyenként a felső sorban és a billentyűknél. Nem is használok nano-t, vim-mel szerkesztek mindent (azelőtt meg terminálban inkább mcedit-et használtam), csak megakadt rajta a szemem. Nem is tudtam, hogy ubuntuék a terminálos programokat is csinosítják.
Ezen a slax-osított Minten mit értesz pontosan? Nem értem, valami vagy Slax vagy Mint.
-
Frawly
veterán
válasz
Shyciii
#5614
üzenetére
Az, hogy AUR-ból leszedték, nem jelent semmit. Max. csak azt, hogy a csomagfenntartónak nem volt elég ideje rendszeresen gondozni a kódot, és a közösség megelégelte, hogy csak régi verzió van fent, ami már nem fordul.
Nyugodtan húzzad git-ről. Csak a git csomagnak kell hozzá fent lennie, aztán nyomatod neki terminálban:
git clone https://git-címe-a-projektnek
cd git-cím-mappa-ami-most-jött-létre
./configure
./make (vagy make install, tőled függ).Előtte git-en érdemes elolvasni a projekt lapján az README.md-t, hogy milyen más függőségei vannak.
-
Frawly
veterán
válasz
Shyciii
#5611
üzenetére
Nincs kifejezetten fájlkezelőhöz kötve, de szerintem 1-2 fájlkezelő tudja, hogy nézi a kuka méretét. Én nagyon használni sem szoktam kukát, mindent egyenesbe törlök le, ha valami mégis félrenyomás miatt a kukában landolt volna (nem vette be a Shift-et, amit törléshez nyomtam), azt hébe-hóba takarítom, nekem még sose telt be lemez semmilyen okból, sem kuka, sem elszabadult naplók miatt.
Meg azt is látnám, ha valami mappa elhízna, kézileg le szoktam futtatni egy SSD-karbantartó scriptet, ami kijelzi az SSD SMART adataiból a kondíciót, írást, ebből írási statisztikát csinál (összmennyiségből mennyi GB/nap, mennyi GB/év, mennyi idő van hátra a TBW limit elérésig), megjeleníti a szabad helyet az SSD-s partíciókon meg fstrim-et hajt végre rajtuk, és ez mindkét SSD-n végigmegy. Ezekből az infókból azonnal látnám, ha valami gyanúsan enné a tárhelyet, onnantól kezdve fájlkezelőben leméretem a mappákat, amelyik nagy, abba belelépve tovább méretem őket, amíg meg nincs mi eszi a helyet. De ilyenre még sose volt szükségem.
-
Frawly
veterán
válasz
Shyciii
#5607
üzenetére
Ezekben a filekezelőkben nincs kvóta a kukára. Akkor csak azt tudod csinálni, hogy felteszed az autotrash csomagot, ebben az autotrash utility tudja üríteni a kukából a x. napnál régebbi fájlokat, meg mérethatárra minimalizálja, lásd a man-ját. Automatizálásra cron-t írnak, de a systemd-nél ez felesleges, most a Linux haladóban volt egy leírása cigamnak, hogy systemd-nél hogy kell scriptet futtatni service-ként.
Esetleg az openbox autostart-jába is beteheted az autotrash-t, de akkor a bootot vagy az Openbox indulását lassítani fogja.
-
Frawly
veterán
Az nem jó, ha flageket kell állítani, az azt jelenti, hogy MBR partíciós táblával próbálkozol, nem GPT-vel. GPT-n nincsenek flagek, emiatt is reklamál szerintem a bootctl-es hibaüzenetben. Meg nem elég létrehozni az EFI partíciót GPT táblán EFI Systems típussal, meg is kell formázni FAT32-re, hogy kialakuljon rajta FAT32 fájlrendszer, FAT fájlfoglalási táblákkal.
Nem véletlenül írtam cfdisk -z parancsot, amiben nagyon fontos az a -z paraméter. Az üres partíciós táblával indít, és van esélyed MBR(dos), GPT, SUN, stb. partíciós tábla közül választani. Ha csak -z nélkül használod a cfdisk-et, akkor nem engedi módosítani a partíciós tábla fajtáját, ha a lemezen MBR van, akkor ahhoz vagy kötve.
Bár egyes UEFI-k támogatják MBR-ről is a EFI bootot, de ez nem szabványos megoldás. Egyébként ez is jó a GPT-ben, nem kell flag-ekkel vergődni. Igazából a legtöbb UEFI-nak az sem fontos, hogy EFI Systems partíció legyen, elvesz bármilyen partíciótípust, MBR-est, GPT-st is, FAT32-es típust is, a lényeg, hogy FAT32-es fájlrendszert találjon rajta. De probléma esetén a szabványos GPT+EFI Systems beállításokra kell rámenni, az tuti szabványos, tuti megy.
-
Frawly
veterán
Nálam nem hagy előtte ennyi helyett, 2048 szektornyit hagy, ami 1024K, ami 1M, azaz egész megabájtos határon kezdődnek a partíciók, de ez jobb is így, mert az SSD-nek kell a jó eltolás.
4K eltolásra (8 szektornyi) nem érdemes rámenni, mert sok 3D TLC SSD-nek már nem 4K kell (mint a planár SLC, MLC, TLC meghajtóknak), hanem 16K, és a jövőben ilyen újabb 3D TLC és 3D QLC-s SSD-knek kellhet 32K is. Az 1024K viszont osztható 4K, 16K, 32K, stb.-vel is, egészen 512, 1024K-ig, szóval minden SSD-nek megfelelő.
Az a 32 mega eltolás az nagyon sok, próbáld cfdisk -z formában futtatni, és elölről kreálni a GPT partíciós táblát. Nálam csak létrehoz új partíciót a kívánt méretben (200M-et adtam neki próbából), a 2048, szektortól, utána a Type-ot átnyomtam EFI Systemre.
Csinálhatod sima fdisk-kel is, csak az kevésbé felhasználóbarát program, kevésbé látod mit csinálsz. Bár annak is ugyanezek a default beállításai, 1024K eltolással particionál, igaz annál bármit meg lehet adni kezdetnek.
Húzom le kipróbálni ezt a Nitruxot, de már az vicc, hogy 300 KB/sec-kel jön le, mikor a netem képes lenne 4 MB/sec-kel húzni. Egyelőre még nem ért le, jó régóta szüttyög vele, még nem tudtam kipróbálni nektek.
-
Frawly
veterán
Ezeket futtasd rendszergazdaként:
cfdisk /dev/sdc (ezzel létrehozol rajta GPT partíciós táblát, particionálod, létrehozva rajta egy EFI partíciót abban a méretben, amit szeretnél)
mkfs.fat -F32 /dev/sdc1
mount /dev/sdc1 /csatolas/helye
bootctl --path=/csatalas/helye installA /csatolas/helye-ként azt adsz meg, amit akarsz. A szükséges EFI fájlokat a bootctl install másolja rá. Ahhoz hogy Arch alatt működjön, initramfs-t is kell generálnod:
mkinitcpio -p linuxBár azt nem egészen értem, hogy milyen rendszert akarsz majd bootolni erről a meghajtóról.
-
Frawly
veterán
válasz
Shyciii
#5579
üzenetére
Pure Archon, meg akármilyen disztrón nem is megy a multikijelzőzés, azt az aktuális WM-nek vagy DE-nek kell tudnia. Az xrandr is opció, ha Xorg-alapú felületről van szó, Waylanden nem működik, ott megint csak a WM/DE-nek kell tudnia. A multikijelzőt úgy is értve, hogy nem feltétlenül több kijelző párhuzamosan, hanem kimeneteket váltogatva.
(#5580) Lenry: honnan tudod, hogy nincs munkája vagy nem jár suliba? Lehet csak szabin van vagy tanulmányi szünet van, esetleg vizsgaidőszak, de már megvan az összes tárgy. Teljesen jó idő az linuxozást tanulni, Archot alaposan megismerni. Meg a munkakeresést sem lehet adott esetben egész nap csinálni.
-
-
Frawly
veterán
válasz
Shyciii
#5573
üzenetére
Ilyen néha nálam is előfordul Archon, de tényleg csak héba-hóba, nem állandó jelleggel. Néha így áll le, hogy egy sorba zsúfolja a kiírásokat, srégen látszanak. Nem utal semmire, megszüntetni sem lehet, nincs ellene semmilyen praktika. De lehet csak nem néztem elég alaposan utána.
-
Frawly
veterán
Ez nem bug, hanem feature. Így van, ahogy írod. Elvileg az egyik disztrón meg lehetne változtatni az initramfs meg a kernel nevét, és aszerint módosítani a .conf fájlokat (initrd) az EFI partíción. Vagy az van, amit már írtam, hogy ha két külön lemezen vannak, akkor mindkét háttértárnak saját EFI partíciót dedikálni.
Manjaróék védelmére legyen mondva, ők nem látták előre, hogy valaki az ő disztrójukból mindjárt kettőt is feltelepít, egy gépre, egy lemezre és ütközés lesz. Őszintén szólva nem sok értelme van, ha ugyanabból a disztróból kettő is van a gépen. Meg igazából annak sem, ha két különböző disztró. Egyet érdemes használni, kizárólagosan. A disztróhopperkedés kezdőként inkább zavar a fejlődésben, haladóként meg még feleslegesebb, mert akkor eljutsz arra a szintre, hogy a disztró mindegy, mert testre tudod szabni 100%-ban, így mindegy milyen disztró van fent, csak legyen meg az a frissessége, ami neked kell, meg olyan frissítési metódust alkalmazzon, ami a te felhasználásodnak a legjobb (pl. kiadás alapú vagy rolling).
-
Frawly
veterán
válasz
Siriusb
#5560
üzenetére
Igen, ismerem a filozófiát, de szerintem az AUR nem csak a nyomiknak való. Elég hasznos. Még hasznosabb lenne, ha bináris csomagok is fent lennének rajta, mármint úgy értve, hogy minden csomagból a bináris verzió is, hogy ne kelljen annyit fordítgatni.
Az AUR-ral a legnagyobb bajom, hogy sok ottani csomag törött, mivel nem tartja őket senki karban, a script nem tud letölteni valami szükséges állományt, vagy csak egyszerűen a kód nem fordul. Ezért manapság egyre sűrűbben csinálom, hogy inkább az adott szoftvert a fejlesztője git oldaláról szerzem be, és kézzel forgatom le.
Az Archnak még ebben kéne fejlődnie, hogy több bináris csomag legyen az alap tárolókban, meg kéne most már közelítse az Ubuntu/Debian-vonal sok tízezer csomagját. Hiába népszerű disztró, kevés csomagkészítő van sajnos, egy marék ember mindössze, legalább tízszer ennyire lenne szükség. Jelenleg 10823 csomag van a rendes tárolókban. Ubuntun, Debianon valami 40-50 ezer.
Nem szeretek forráskódból forgatni, nem szeretem az időt rászánni. Ha erre vágynék, gentooznék. Főleg akkor utálom nagyon, mikor valami szoftvert keresek, hogy kipróbáljam milyen, leforgatom forráskódból, erre utána derül ki, hogy még be sem jön, nem tetszik. Nettó időpocsékolás, hogy tutujgattam valamit, amit még csak nem is fogok használni.
-
Frawly
veterán
válasz
vargalex
#5557
üzenetére
Jó, most nem tudom miért kötekedtek, de tényleg. Nem a Blikkből szopom, még én is sokáig csak a yaourtot ismertem. Annyira nem vagyok fogyatékos, hogy ha oda lett volna írva rendesen a többi is, hogy azt nem próbálom ki. Meg az Arch Wiki-n kívül is egy csomó cikk a neten a yaourtot mutatja be, meg egy csomó git-es oldal, ahol említik az Arch AUR-os elérhetőséget, ott példának csak a yaourt -S csomagnév van megadva telepítési metódusként.
A népszerűségét ennek köszönheti a yaourt, nem annak, hogy kiemelkedne a többi AUR helper / pacman wrapper közül akármivel is. A többi nem volt eléggé reklámozva.
-
Frawly
veterán
válasz
Siriusb
#5555
üzenetére
Jó, lehet ezzel a KELL-lel erősen fogalmaztam. Akkor mondom úgy, hogy régebben sok Arch-os doksi mikor mutatta a példákat az AUR-ból telepítésre, csak a yaourt volt bemutatva, említve, erről meg sok mindenki azt hitte, hogy ezzel KELL feltenni. Tehát a doksi semmi olyat nem mondott, hogy kell, de az egyszeri usernek mégis ez jött le.
-
Frawly
veterán
válasz
Amazonas
#5553
üzenetére
Igen, releváns. Pont ezen az oldalon tárgyaltuk ki, az (#5495)-es hsz-től kezdődik a szál, ahol erről volt, és mindenki leírta, hogy mit használ helyette. De tényleg nem baj, hogy betetted, sokan nem olvasnak vissza, és legalább nem kérdezik meg még tízszer ugyanazt. Sőt, ezt az összefoglalóba is bele lehetne venni. Igazából a yaourt nem most halt ki, 1-2 éve az archlinux.org fórumán folyamatosan írogatják, hogy nincs karbantartva, nem ajánlott használni. Most csak annyit változott, hogy hivatalos, a fejlesztő is megerősítette.
Egyébként meg a yay eddig bejött, nem nagy a különbség közte meg a yaourt között. Igazából eddig sem azért volt népszerű a yaourt, mert a legjobb lett volna, hanem régen ezt írta az Arch Wiki, hogy ezzel kell AUR-os csomagokat feltenni, és mindenki rászokott, sok ember csak ezt ismerte, így népszerű maradt. Emiatt a fejlesztőnek törölnie kéne a tárolóból, hogy a régi leírásokból telepítő emberek ne használják.
-
Frawly
veterán
De GRUB-ot azt még tegyél fel. A falra, kinyomtatva, bekeretezve. Mert az kell, nem maradhat ki. Az úgy nem éri, hogy csak nélküle bootolsz, Uby be fog rágni rád, és te is le leszel Arch-gyógyegerezve, meg UEFI-lemániás-ozva
Egyébként szerintem az általam vázoltnál is lehet egyszerűbben bootolni, ha nincs systemd, nincs initramfs, hanem csak valami egyszerű init/rc rendszer, amit egy szimpla vmlinuz kernel indít, azt meg egyetlen darab .EFI bináris fájl bootolja, az UEFI bootbejegyzésből (amiben az initrd root benne van opcióként), és akkor nem kell .conf fájl sem, de ez a módszer meg illékony, ha valami Windows vagy más OS belebarmol az UEFI bejegyzések közé, elveszhetnek a beállítások, eltörhet a boot. De ha valaki nagyon haladó haxxxor, annak kevesebb lépésből tető alá hozható.
-
Frawly
veterán
Akkor az szopó lesz, nem fog indulni. De nem kell sdakármit megadni, ha ott van a kernelopciók (options) között a root=PARTUUID=stb rész, az önmagában is elég.
De külső vinyónál azt is csinálhatod, hogy annak saját EFI partíciója legyen, azon csak a saját loader.conf-ja, és ahhoz csak egyetlen további conf kapcsolódjon, így függetlenül bootoló meghajtó lesz. Ennek csak az az egy kényelmetlensége van, hogy ilyenkor bootoláskor neked kell rátaposni az UEFI bootmenüt előhozó billentyűre (nálam az ThinkPad-en az F12), és onnan kell kiválasztani a külső HDD-n lévő rendszert bootolásra, mert enélkül a default (belső lemezeken) lévő OS fog indulni.
-
Frawly
veterán
Ez editor 3 sort törölheted, az csak azt jelenti, hogy 3 másodpercig a menüben ha megnyomod a kiírt billentyűkombinációt, akkor egy bootolás erejéig ideiglenesen szerkesztheted mondjuk a kernelparamétereket, vagy ilyesmit, amit GRUB-ban is lehet.
Az utolsó két sort viszont nem törölheted, mert azok alapján találja meg a plasma.conf és cinnamon.conf fájlokat.
-
Frawly
veterán
A # jeles megjegyzéseket törölheted, meg options sem kell, ha semmilyen kernelopciót nem alkalmazol, elég egy initrd, ha nem alkalmazol Intel CPU mikrokódot.
Ez a legminimálisabb .conf, amit egy Arch alapú disztró bevesz:
title Név
efi /vmlinuz-linux
ititrd /initramfs-linux.img
root=PARTUUID=b643254b-b015-4577-a698-58d140b29469 rwDe ahogy nézem a te .conf fájlaidat, azok is teljesen jónak tűnnek. Az UUID-kre kell figyelni csak lényegében, meg hogy nevek és .conf fájlnevek egyezzenek.
-
Frawly
veterán
Az attól függ, hogy a systemd bootot hogyan hívod meg. Van rá háromféle mód is:
1) efibootmgr-rel felvenni bootbejegyzést az UEFI memóriaterületére, vonatkozó olvasnivaló, ezt hívják efistub bootolásnak is
2) az UEFI-ben előhívni az EFI shellt, amibe ideiglenes vagy állandó jelleggel be lehet gépelni bejegyzést, ehhez szintén olvasnivaló az, amit már linkeltem, ezt is efistubnak nevezik
3) az EFI partíción lévő ./loader/loader.conf-ban felvenni egy új sort, ami egy a ./loader/entries/regi_telepites.conf-ra mutat, amibe beilleszted a régi telepítés vonatkozó .conf fájljának a tartalmát. Ez a klasszikus systemd boot, ez a legbiztosabban működő lehetőség. Ez utóbbit ajánlom.Pl. az Arch nálam így indul a 3. módszerrel. Az EFI partíción a /boot/loader/loader.conf-ban ez van:
#timeout 3 ez_ki_van_kommentelve_hogy_ne_mutasson_valaszto_menut
default arch #ez az arch.conf-ra mutat, lásd alább, a névnek egyeznie kell a fájlnévvelA /boot/entries/arch.conf-ban:
title Arch Linux Loader, de a név szabadon választható
root /dev/sda2 #ez nem feltétlenül kell bele
efi /vmlinuz-linux
initrd /intel-ucode.img #ez sem kötelező, Intel CPU mikrokód
ititrd /initramfs-linux.img
options initrd=intel-ucode.img initrd=initramfs-linux.img
#options résznél még zsúfolhatod mögé a kernelparamétereket
root=PARTUUID=b643254b-b015-4577-a698-58d140b29469 rw
#nálad az UUID más leszEnnyi. Két nyamvadt .conf textfile az egész, ez az a marha bonyolult dolog, amit rengeteg disztró telepítője a mai napig nem tud megcsinálni normálisan, mintha rakétatudomány lenne. Pedig rendkívül egyszerű, minden gépen bootol, a legkókányabb ócskavason is, a Windows sem zavar be neki. Annyi, hogy pl. egyes Acer gépeken nem szabványos az UEFI boot, de ott is csak annyi módosítást kell eszközölni, hogy az EFI partíción a ./EFI mappában lévő 1-2 .EFI fájlt át kell nevezni más (Windows EFI kompatibilis) névre, ahogy rájuk találjon az UEFI, de ez sem egy nagy szám, hogy valaki szellemileg belerokkanjon.
Annyi, hogy te bekapcsolhatod a bootmenüt, kiveszed a kommentet, pl. timeout 5, ez azt jelenti, hogy 5 másodpercig a képernyőn hagyja a bootmenüt, ha addig nem választottál, akkor elindul a default rendszer. Ha kikommenteled vagy 0-át írsz elő, akkor nem jeleníti meg a menüt.
Meg mivel nálad két Manjaro rendszer is van, ezért a loader.conf-ban két sort is feltüntetsz, manjaro1 és manjaro2, amelyiket default-tá akarod tenni, azelé beillesztesz egy default szócskát, meg nálad a ./loader/entries/ mappában két .conf fájl kell, az egyik az újabb, a másik a régebbi Manjaro indítási paramétereit tartalmazza.
Egyszerű, mint a szög, semmilyen más bootloader (GRUB, syslinux, stb.) nem kell. Még újratelepítés esetén sem kell újracsinálni, csak a PARTUUID-ket átírni és kész.
A működési mechanizmus is rettenet egyszerű. Indul a gép, indul az UEFI BIOS. Nálam nem talál default bejegyzést, így elkezdi keresni az EFI partíciókat, meg is találja. Az EFI partícióról betölti ./EFI/BOOT/BOOTX64.EFI bináris fáljt (ez nem is feltétlen szükséges, de a kompatibilitás miatt kellhet), ami meg betölti a ./EFI/systemd/systemd-bootx64.efi fájlt, ami meg megvizsgálja a loader.conf-ot, ami alapján menüt hozhat létre, és annak alapján rátalál a többi .conf fájlra, és bebootolja az azoknak megfelelő rendszert, azokból kiolvasva az opciókat tudja, hogy hol kell a vmlinuz nevű kernelt tölteni meg a initramfs-t. Az egész egyszerű, mint a szög, semmi feketemágia nincs benne.
-
Frawly
veterán
válasz
Siriusb
#5533
üzenetére
SFTP-t nem használtam még, de mivel az SSH-ra vonatkozik a hibaüzenet, azért bepróbálkozok azzal a kérdéssel, hogy biztosan jó jelszót adsz meg? Ezt úgy értve, hogy nem elgépelés, hanem az elérni kívánt gépen lévő felhasználóhoz tartozik valóban az a jelszó, amit próbálsz neki megadni? Gondolom evidens, hogy nem, de azért rákérdezek, biztos, ami biztos.
Tűzfal nem lehet, mert akkor nem a jelszóval lenne baja, hanem a kapcsolódás sem lenne meg.
-
-
Frawly
veterán
Az Xfce teszi ki, nem a Thunar. Ott nézd meg, ahol írtam: Settings Manager (magyarul nem tudom mi a neve, talán beállítóközpont), ott Desktop (Asztal) ikon, az előjövő ablakban Icons (Ikonok) fül, és ott lesz az alja felé, hogy az eltávolítható meghajtókat ne tegye ki asztalra:
-
Frawly
veterán
Nálam nem mutat ilyet a Thunar. Abban biztos vagy, hogy a Thunar teszi ki az ikonokat az asztalra? Az asztal beállításai között nézelődj:
In Settings Manager>Desktop, click the "Icons" tab. Clear the checkbox for "Removable Devices". I think this will remove all of the extra drive icons from your desktop. -
Frawly
veterán
Üdv az Archer táborban. Júbájgön el lesz keseredve, hogy már senki nem fahéjas mentázik. Amúgy te véletlenül nem az a hwsw-s csokis vagy?
Az eltávolító meghajtóra nincs sok ötletem. Az biztos, hogy az Arch nem mutat róla semmit. Legfeljebb a fájlkezelő, amivel nézitek. Pontosan melyik fájlkezelőt használjátok? PCmanFM, Nautilus, Dolphin?
Lehet a BIOS-ban a SATA vezérlő van RAID módban AHCI helyett, vagy a kernel egyes újabb SATA vezérlőkön lógó meghajtókat így kezel le.
Az Arch egyébként olyan, hogy ha megtanulod feltenni, meg mindent beröffenteni alatta, belőni a dolgokat, ahogy neked kell, akkor később már az életben nem lesz vele gond. Nincs külön disztrófrissítés, nem kell újratelepíteni.
-
Frawly
veterán
Nem értem mit csinálsz. Attól nem lesz neted, hogy a Wi-Fi-kártyát down állapotba küldöd.
Ami nálad hiányzik, az az, hogy hiába hoztál létre wifi-menu/wpa_supplicant profilt (benne SSID, jelszó), és mentődött is el, bootnál nincs olyan systemd service, ami automatikusan beizzítja. Ez lehet NetworkManager, lehet netctl, lehet wicd, és hasonlók. Az Arch Wiki alapján válassz egyet.
Az Openbox meg a többi kisebb WM ilyen minimalista. Nem kezelik helyetted a netkapcsolatokat, ahogy egy KDE, Gnome Shell, Cinnamon, stb..
-
Frawly
veterán
válasz
vargalex
#5503
üzenetére
Akkor lehet én csináltam rosszul, de egy időben az Arch Wiki, meg Kékluficet Arch-cikke is úgy írta, hogy tárolónak fel kell venni az archlinux.fr-t. Lehet ez egy elavult ajánlás, nem vettem észre, hogy módosították. Pedig én mindig kicsit máshogy telepítek, minden telepítésnél másmilyen rendszert építek fel, más fs, más WM/DE, más Wi-Fi-kezelő, stb..
De ez a yaourt mindig is ilyen vitatott volt, sokan már 2 éve is temették, aztán még mindig használható. De azért váltottam most már, ha ennyien óvva intenek tőle, akkor nem kockáztatok vele. Már sok helyről olvastam, hogy ajánlott lecserélni.
-
Frawly
veterán
Én is yaourt-ot használtam kizárólag. De tényleg valami francia tákolmány, régóta nem fejlesztik, meg idegesítő, hogy az .fr-es tárolót fel kell venni egyetlen progiért.
Egyelőre ezt a yay-t tettem fel, szemre nem rosszabb a yaourt-nál. Majd meglátjuk mennyire válik be.
Egy ideje a testing, testing multilib, stb. tárolókat is engedélyeztem. Mindenkinek ajánlom, még frissebbek a verziók és semmi hátránnyal nem jár. Egy tárolót nem érdemes használni általános jelleggel a staginget, mivel az csak arra van, hogy a csomagkarbantartóknak legyen mivel kielégítsék a csomagfüggőségeket csomagkészítés közben. De persze staging-ből is fel lehet tenni ezt-azt, pl. a kernelt onnan szoktam feltenni, ha ott a legfrissebb.
-
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.
-
Frawly
veterán
Pedig a hivatalos iso-nak dd-vel kiírva bootolnia kéne Legacy-n is.
Az UEFI boottól miért zárkózol el? Azt értem, hogy fujj, meg nem kell, de ha véletlenül mégis kipróbálod, még be is jöhet. Pl. megvan az az előnye, hogy pl. systemd UEFI boottal tudod indítani a gépet, és nem kell GRUB, syslinux, stb.-vel szenvedni, meg külön frissítgetni őket állandóan. Én a helyedben adnék egy esélyt az UEFI bootnak. 2018-ban, pár nap múlva már 2019-ben nem elhamarkodott átállni. 2007-ben még joggal morogtak ellene, hogy a Windows sem támogatja normálisan, meg még túl új, kísérleti, de azóta eltelt néhány év.
-
Frawly
veterán
Nem csináltál semmit, ez így működik alapból. Elvileg a másik Arch-os gépen is ugyanennek kéne lennie. Lehet egy olyan meghajtót csatoltatok alá, amin már el volt végezve ez a művelet, és többet nem okoz gondot.
Ha egy másik pendrive-nál is szükséged van erre, annál is végig kell ezt csinálnod, csak ott csatolási helynek mást írsz. De ezt minden meghajtónál csak egyszer kell eljátszani.
-
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.
-
Frawly
veterán
válasz
Shyciii
#5448
üzenetére
Ne barmold szét a rendszered. Az Arch amúgy sem foglal sokat, nálam, hogy minden sz@r fent van Gnome3-astól, 1058 csomaggal foglal 14 gigát, de volt már hogy csak 10-et. Ennyit csak rá tudsz áldozni egy partíción. Egy ezzel ekvivalens Ubuntu vagy Mint rendszer foglalna kétszer ennyit. Még ha csak 64-120 gigás SSD-t vagy 32-120 gigás pendrive-od is van, akkor sem halsz bele.
Ha nagyon kell a hely, pacman -Scc paranccsal töröld a letöltött csomagok cache-ét, azzal felszabadítható néhány giga.
-
Frawly
veterán
-
-
Frawly
veterán
válasz
Shyciii
#5412
üzenetére
Az rfkill unblock all parancsot futtasd. Annak elvileg tartós hatásúnak kéne lennie. Arra is figyelj, hogy notebookokon, netbookokon a hardveres Wi-Fi ki/bekapcsoló gomb engedélyezi a BT-t is, ha hardveresen lockolva van (OFF állásban van a gomb), akkor szopni lehet vele nagyokat, mire észreveszed.
-
Frawly
veterán
válasz
ubyegon2
#5401
üzenetére
Szerintem az az A10-5800K-es sem olyan gyenge proci. Jó, egy asztali i7-2600-nak és i7-3770-nek csak a felét hozza teljesítményben (mivel fele annyi szálat támogat, meg kevesbb a cache is benne, meg az egy magra eső órajel), de ahhoz bőven van olyan bika, hogy desktop linuxos felhasználással ne érezd lassúbbnak. Az Intel Core i5-i7 mobil (M-es meg U-s) procikkal meg kb. egy szintben van. Főleg, ha elég RAM és SSD is van mellé körítve, lassúnak nem kéne semmiképp lennie.
-
-
Frawly
veterán
válasz
ubyegon2
#5395
üzenetére
Ezért mondom, hogy mikor már több progi fut, vagy böngészés sok füllel, akkor már kiegyenlítődik, és kisebb WM-mel sem tudsz a memóriafoglaláson lefaragni, mert ugyanannyi fogyasztás fog kijönni, mint a nagyobb DE-knél. Valahol ezért szemfényvesztés kategória a kisebb WM-ek, kivéve, ha lightweight meg terminálos programokkal használod őket.
Azt gondoltam, hogy téged az a veszély nem fenyeget, hogy a gyári HP Windows-telepítést használod
SSD-t ma már mindenbe érdemes tenni, nagyon régi gépekbe is. Árban egyre hozzáférhetőbbek értelmes méretben is, és egész más dimenzióba tolják át a sebességérzetet. A HDD rendszermeghajtónak nagyon elavult már, visszafogja a gépeket. -
Frawly
veterán
válasz
ubyegon2
#5392
üzenetére
Lehet ez a HP modell kivételes volt, de eléggé csodálkoznék, mert ennél régebbi és újabb HP-kon is rendben van. HP-knál egyre kell vigyázni, a gyárilag előretelepített (és helyreállítópartícióról visszatehető) Windowst kell hanyagolni rajta, az tele van szutyokkall, mindenféle demo-val, reklámmal, kémszoftverrel. De mivel linuxozol rajta, ezt téged a legminimálisabb mértékben sem érint.
A legtöbbet az utóbbi időben a Unity fogyasztotta, de ugye azt egyre kevesebben fogják használni, így a helyét a Gnome Shell vette át. De a Cinmanónak is vastagon fog a ceruza, mikor a memóriafoglalást nézed, de ma már mindenhova ajánlott a 4 GB RAM 64 bites rendszerhez, azzal már nem jelentős tétel, főleg, hogy sok gépben van már 8-16 giga, ahogy írod is. Nem is annyira a grafikus felület fogyasztása a döntő, úgyis a sok füles böngészés eszi átlag felhasználáskor a legtöbb RAM-ot.
Én alig várom, hogy vagy a Sway forrja ki magát, vagy az Openboxot forkolják Waylandre, akkor arra váltok, de akkor már megint újrahúzom a rendszert, mert ez az f2fs nagyon nem jött be, lassú, bugos az fstrim-elése. Hiába istenítik SSD-re, visszaállok ext4-re, az nem csak gyorsabb volt, de semmi probléma nem volt vele. Az f2fs úgyis olyan Flash meghajtókra való, amelyeknek nincs aktív garbage collectiont végző vezérlője, mint pl. SD kártya, pendrive, stb.. A modern SSD-k vezérlője már intéz mindent, nincs rászorulva Flash-barát fájlrendszerre.
-
Frawly
veterán
válasz
ubyegon2
#5389
üzenetére
Az mit jelent, hogy kicsit széthúztad? A desktop gép behalhat akármitől, lehet kiöregedett benne az adott hardver, és csak egy cérnán függött az élete, a kánikulában üzemelés meg feladta neki az utolsó kenetet. Vagy még az sem, kipurcanhatott volna akkor is, ha nincs meleg.
Archot nyugodtan felteheted, kérdezhetsz is, úgyis az lesz a válasz, hogy RTFM vagy read ArchWiki
![;]](//cdn.rios.hu/dl/s/v1.gif)
8470p-n 1000%, hogy mennie kell az UEFI bootnak, az ilyen üzleti notiknak mindig szabványos, 64 bites UEFI-je van. Az UEFI inkább tableteken, netbookokon, kínai és belépő kategóriás Acer notikon problémás, vagy mert 32 bites, vagy mert nem szabvány implementáció, ami a Windowszal jobban össze van drótozni, persze ilyenkor is lehet UEFI bootot csinálni Linuxszal, csak szopósabb.
-
Frawly
veterán
válasz
ubyegon2
#5379
üzenetére
Ja, emlékszem milyen jól átláttad, napokat szenvedtél vele, mire végül feladtad. Kapásból Wi-Fi-t alig tudtál vele csiholni, annyira profi volt a script, pedig csak 1-2 alap csomag kellett neki. Persze attól függ, hogy ki hogyan definiálja a jól átláthatót. A Manjaróval nem is emlékszem mi volt a bajod, de azzal is volt valami.
Általában van túlszaporodás, de ezeknek a 90%-a Ubuntu vagy Debian, néhány Arch-klón, a többi ág (Red Hat/Fedora, Gentoo) csak elvétve van ezzel érintve. A distrowatch top 13-jávan 6 Ubuntu/Debian alapú van (beleértve ezt a kettőt, 4 Arch-alapú (beleértve az Archot), 3 Fedora-vonalhoz tartozó (bár ezek azért nem klónok), és csak 1 olyan nem származék, aminek nincs további származéka (Solus). De ha tovább nézed a top100-ig, akkor még jobban növekszik az első kettőnek az aránya. Persze ezzel nem azt akarom mondani, hogy ami származék, az már csak rossz lehet, hanem azt, hogy egyes vonalak túl vannak már tolva, ennyi klónra nincs szükség.
-
Frawly
veterán
válasz
ubyegon2
#5373
üzenetére
Nagy baj sincsen vele. Az Ubuntu alapúak már túl vannak tolva. De így sem támogatom, Mikrobi jól írja, ezek általában összegányolt valamik. Aki Archot akar használni, tegye fel Wiki alapján, ha meg ehhez nincs meg a tudása, akkor Manjaro-t telepítsen helyette és kifújt az értelmes Arch-vonal.
Ezt a custom installer scriptes Arch-gányolást a saját károdon tapasztaltad meg, ha jól emlékszem. Nem tudni egy ilyen script vagy fork miket tesz fel, miért nincs hang, miért nem megy a Wi-Fi, csak megnehezíti a hibakeresést.
-
#5368
Frawly
veterán
cyberpalko
#5367
Frawly
veterán
válasz
cyberpalko
#5367
üzenetére
Ne menj át a kezdőbe, ez ide való téma. Mindenképp próbáld meg, amit írtak, alsamixer futtatása, ugyanis sokszor telepítés után az alsa elnémítja a kimenetet, tehát jó a hang, csak te nem hallasz semmit.
Ezt az Arcolinuxot nem ismerem, azt hittem csak elgépelés.
-
#5363
Frawly
veterán
cyberpalko
#5362
Frawly
veterán
válasz
cyberpalko
#5362
üzenetére
Elvileg hanghoz az pulseaudio-t kell feltenni. Ha komplett asztali környezetet telepítesz (Gnome, KDE, Cinnamon, Xfce4, Mate, stb.), akkor azok függőségnek behúzzák, és nem kell egy napig szenvedni vele. Ha kezdő vagy, akkor lehet nem is az Arch a legjobb választás, helyette ugyanazt az életérzést és gyorsaságot megadhatja az Arch alapú Manjaro Linux is.
Ha fent van a pulseaudio, és továbbra sem megy, akkor vagy az AUR-ból tedd fel az inxi és tegyed be az inxi -Fxxx kimetetét, vagy az lspci kimenetet.
-
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
Nekem egyébként egyre kisebb jelentősséggel bír, ha lesz időm kísérletezni, akkor átállok saját fordítású kernelre, és a kernel.org-ról leszedve fordítok mindig magamnak újat. Az Arch-osból pl. nekem hiányzik a 16 bites alkalmazások támogatása, mert úgy lett lefordítva.
Csak addig idő, míg a fordítási profilt kikísérletezem, de utána ugyanazzal a profillal mindig lefordul pár perc alatt a legfrissebb kernel, és nem kell Tobias meg Heftig meg mit tudom kikre várni, hogy majd ha lesz elég szabadidejük, akkor esetleg betolják valamelyik tárolóba az újabb kernelt, meg kedvükre tiltogatnak belőle mindenfélét, ami szerintük nekem nem kell bele.
-
Frawly
veterán
Megkért valaki, hogy csináljak neki virtualboxos Win3.11-es virtuális gépet, de olyat, amivel fájlokat tud megosztani vagy fájlokat tud rá pakolni.
A virtuális gépet már megkreáltam, beállítottam, majdnem kész is van. A megosztás viszont bajos. Első körben arra gondoltam, hogy a .vhd lemezképet csatolom fel, erre van eszköz a libguestfs-tool-ban, a guestmount. Igen ám, de ez csak az AUR-ban van, és lefordítana forrásból egy tonna csomagot. Gondoltam, hogy a nagy lófütyit a valagukba, leszedem a vonatkozó deb-eket a debianos tárolóból a függőségekkel együtt, kibontom egy helyi mappába, és használom onnan. Ez nagyon szép gondolat is volt, amíg bele nem futottam abba, hogy guestmount függőségei között ott van az SELinux, az már van olyan bonyolult, hogy csak úgy tudnám feltenni, hogy szétgányolnám a rendszerem, így ezt az ötletet teljesen dobtam, nem használom a libguestfs-es eszközöket.
Ott van még, hogy DOS és Win.11 alá van Windows Client, ami elvileg olvas Samba-megosztást, de ez is bonyás, mindenféle más protokollverziók, titkosítás, stb.
Van valakinek ötlete, hogy Archon hogyan lehetne ezt kulturáltan, gányolás és több órás forráskódból forgatás nélkül megoldani? Egyelőre mkisofs-el kreálok a megosztandó fájlokból .iso lemezképet, és felcsatolom CD-ként a virtuális gépbe, de ez megint kényelmetlen és gányolás kategória. Esetleg létrehozok egy nyers lemezképet, azt megformázom, majd felcsatolom, és ezt a virtuális gépnek is oda lehetne adni másodlagos lemezként. Ennél tud valaki jobbat?
Ha majd kész a virtuális gép, akkor a használója majd Win7-en fogja használni, így lehet ez ott OFF topik, de megkérdezném azt is, hogy Windowson mi a módja .VHD fájl felcsatolásának? A lényeg, hogy tudjon a DOS-os virtuális gépbe fájlokat küldeni. Először azt tanácsoltam neki, hogy Bridge-hálózatba álítsa a virtuális gépet, telepítse a DOS-os hálózati drivereket és mtcp-t ftp-kliennsel, majd a host gépre egy FTP szervert, de ehhez nem elég az informatikai tudása, túl bonyolult megoldás neki, hiába linkeltem neki ezt bemutató videót.
-
-
Frawly
veterán
válasz
vargalex
#5318
üzenetére
Én is főleg akkor húzok újra Archot, ha új rendszermeghajtót vagy új gépet veszek (bár a legutóbb vett SSD-mre, már tar-ral klónoztam a rendszert, nem húztam újra). Amúgy csak kétszer kellett Archot ezen kívül újrahúzni, egyszer az én hibámból, elhánytam a jogosultságokat az új user home-jában, és polkit hiba miatt behalt a systemd, nem lehetett megjavítani. A másik alkalommal meg GPU és Wi-Fi bugos működése miatt váltottam Xorg-ról Waylandre, de akkor már az ext4-ről f2fs-re váltást is megléptem. Nyilván én sem telepítem újra hetente. Nagy ritkán viszont nem lámaság újratelepíteni. Nekem sose volt szent a belakott rendszer, ellentétben itt a PH-n sok emberrel. Majd belakódik újra, meg így a legjobb tiszta lappal kezdve kipróbálni teljesen új dolgokat. Ez a jó az Archban, nem vagy kiadásokhoz meg flavor-ökhöz kötve, bármit fel lehet rá tenni, bármilyen rendszert össze lehet rá legózni.
-
Frawly
veterán
válasz
ubyegon2
#5315
üzenetére
Szerintem a mintyegon19 jobb lenne
Nem hittérítettem. Jó a Mint, de azóta lettek még jobb alternatívák, azért ajánlgatunk mást. A disztrók körképe átrendeződött az utóbbi években, ezt fejezi ki a distrowatch toplistájának a megváltozása is. Elhiszem, hogy 5 éve neked bevállt, anno nekem sem volt vele bajom azon kívül, hogy ritkán van belőle új kiadás, mármint ez az ütem nekem ritka. Viszont 5 év után itt az ideje, hogy használj fő rendszerként valami más disztrót, hogy fejlődj. Az egyik legveszélyesebb dolog az informatikában, ha kényelemből meg megszokásból beszűkíted a látásmódod egyetlen rendszerre. Sokkal inkább kell a rugalmasság, nyitottság, kipróbálni új dolgokat, megismerni más megoldásokat, keresni miben mi a leghatékonyabb. Én még Archon is törekszek, hogy minden telepítéskor már DE-t vagy WM-et teszek fel, más megoldást, megközelítést használok, mindig próbálok ki új programokat, és nem csak a háttérképet, témát cserélgetem. Ez nem csak azért jó, mert fejlődsz, de nem is lesz unalmas meg monoton, hogy mindig ugyanazt bambulod és használod.
-
Frawly
veterán
válasz
ubyegon2
#5310
üzenetére
Nem vakították el. A nem hivatalos tárolók egyik disztrón sem voltak soha biztonságosak, csak saját felelősségre ajánlott a használatuk.
Amúgy meg én rühellem ezeket a flat designos, poligonos háttérképeket, az ilyeneket 1 mp. alatt cserélem le, hogy nyekkenni nincs idejük.
-
Frawly
veterán
válasz
#63718632
#5305
üzenetére
Azt világosan írják, hogy egy user tette bele az install scriptbe. Úgy kerülhetett bele. Ahogy olvasom, csak egy telemetriagyűjtő script volt egyenlőre, nem okozott kárt.
Egyébként mák, hogy nem használom többé az acroread-ot, régen minden disztróra feltettem, mert akkor annak volt a legjobb a renderelési minősége. De már a Okular, Evince is annyira felfejlődött ebben, hogy már majdnem 2 éve felesleges bármi mást feltenni, Qt-s rendszerekre elég az Okular, Gtk-sokra az Evince.
A yaourt nem véletlenül figyelmeztet évek minden AUR-csomag telepítése előtt, hogy potentially dangerous, utalva ezzel arra, hogy az AUR-ba 1 perces regisztrációt követően bárki hozzáadhat dolgokat, emiatt nem megbízható. Azt sem véletlenül ajánlgatja, hogy nyissuk meg szerkesztésre, átnézésre a pkgbuildet.
-
Frawly
veterán
válasz
attilav2
#5289
üzenetére
Ez ilyen. Minden DE NetworkManagert használ már.
Én is alternatív megoldást használok, igaz systemd-networkd-t, hanem netctl-t, ami épp úgy systemd-s megoldás. A NetworkManagert kidobtam, mert régóta van egy olyan bugja, hogy lehal vele a Wi-Fi, alig van net, pár perc után teljesen elakadnak az oldalletöltések, még újrakapcsolódni sem lehet normálisan.
Nálam is IPv6+IPv4 dualstack van, sose volt vele gondom.
-
-
Frawly
veterán
válasz
attilav2
#5268
üzenetére
Akkor nem hálózati hiba, ha ugyanazon a gépen Win10-zel bejön, meg Kubuntuval is.
Tedd fel az inxi-t és terminálból másold ki az inxi -inxxx és az ip ad kimenetét.
Proxyval nem baj, ha nem jutottál el a videók megnézéséig, tesztként hibát zártunk ki vele azzal, hogy a YT oldala bejött.
-
Frawly
veterán
válasz
attilav2
#5265
üzenetére
Probáld egy web proxyn keresztül meglátogatni a YouTube oldalát. Bár azt írod, hogy nem hálózati hiba, mert a többi gépeden jó, csak azon az egyen nem.
Próbaképp feltennél egy Win10-et? Ingyenesen letölthető, nem muszáj aktiválnod, drivereket sem kell feltenni a hálózati csatolón kívül, csak told fel az alaprendszert, indítasz benne egy Edge-t, és megnézed ott bejön-e.
-
Frawly
veterán
válasz
#63718632
#5260
üzenetére
Nekem nincs vele konkrét tapasztalatom, de a GPU-t alapból kéne vigye kernelbe épített radeon DRI modesetting driverrel, neked csak a Mesa csomagot kell feltenni a 3D-s gyorsításhoz. Más gondnak nem kéne legyen vele, de ezt csak akkor tudod meg ténylegesen, ha feltelepíted. Kezdd el telepíteni az Arch Wiki alapján, ha elakadtál, valami nem megy, jelezz, segítünk. Szerintem semmi olyan nem merül majd fel, amit egy kis utánaolvasással ne tudnál megoldani, általában minden beüzemelhető.
-
Frawly
veterán
Jó, de Live Archon nincs grafikus felület. Elvileg valóban lehet X nélkül is beröffenteni grafikus alkalmazást, így Gparted-et, de kérdés van-e értelme. Én mindig is egy rakás, lassú bughalmaznak tartottam a Gpartedet, a sima parted meg CLI-s, de nem felhasználóbarátabb, mint az fdisk. A cfdisk viszont felhasználóbarát, menüs, meg villámgyors is vele dolgozni, és alapból részét képezi az Arch iso-s rendszernek.
Annyi, hogy az fdisk, cfdisk nem formázza meg a létrehozott partíciót, de senki nem halt még bele egy plusz mkfs.akármifs parancsba.
Ilyen külön live rendszernek, rajta Gparteddel akkor van értelme csak, ha mondjuk partíciókat kell átméretezni a rajtuk lévő adatok törlése nélkül. Egyébként csak sima Arch telepítéshez nem éri meg.
-
Frawly
veterán
Ha már fent van a Windows, akkor még könnyebb is az UEFI boot, mivel a Windows telepítője már megcsinálta az EFI partíciót, meg létrehozta a /boot/loader/loader.conf-ot, így annyival is kevesebb munka van vele, neked a bootctl install után csak a kész loader.conf-ot kell szerkeszteni, meg egy arch.conf-ot a entries mappába és így csak bővíted a már meglévő UEFI bootos opciókat egy újabbal. Teljesen veszélytelen művelet, mivel a Windows bootolhatóságát nem érinti, még ha el is rontasz valamit, attól legfeljebb csak az Arch nem fog bootolni.
Van egy másik módszer az EFI systemd-booton kívül. Ez pedig a EFI stub boot, ezzel már egy másik Arch Wiki cikk foglalkozik. Itt nem az EFI partíción lévő .conf fájlokkal zsonglőrködünk, hanem efibootmgr futtatásával közvetlenül az UEFI-ben matatunk, adjuk hozzá kézzel a bootopciókat. Na, ez veszélyes, mert ha valamit rosszul viszünk fel, bootképtelenné vállhat a gép, és ha nincs defaultra állítás az UEFI-ben opcióként, akkor az egész UEFI-t haza lehet vele vágni. Ezt tényleg csak annak ajánlott, aki tudja mit csinál.
-
Frawly
veterán
Nincs hátránya, de Arch-nál felesleges, mivel ott eleve live iso-t töltesz be, és igaz nincs grafikus felület, de pl. a cfdisk text user interface-t tud nyújtani, ami legalább olyan használható, mint egy grafikus tool. Annyi, hogy utána a csatolásokat is neked kell csinálni, mivel az Archban nincs telepítő, de pont ez a poén benne, hogy mindent te csinálsz kézzel, látod mi futott le, mit tettél fel, így nincs az, hogy nem tudod miért nem megy. Különösen áll ez az UEFI bootra, amit a telepítők 90+%-a el szokott qrni, pedig a világ legegyszerűbb dolga, ha egyszer kézzel telepítve Wiki alapján megérted hogyan működik.
-
Frawly
veterán
válasz
Silεncε
#5249
üzenetére
Az Arch Wikinek ezt a cikkét nézd.
A lényeg, hogy fel kell lennie csatolva a EFI partíciónak, tipikusan /boot-ként. Ekkor arch-chrootban kiadod a bootctl --path=/boot install parancsot, és felteszi az EFI partícióra az Arch indítófájlait. Ezzel nincs vége, mert szerkeszteni kell egy konfigfájlt is, a /boot/loader/loader.conf néven, sőt, kell egy conf fájl a /boot/loader/entries/-be is, ennek a neve szabadon választott, de össze kell egyeztetni a loader.conf-ban írtakkal. Én is így csináltam meg az Arch EFI bootját, csak X220-on. Működik. Úgy is, hogy ha Win10 van mellette.
Ha elakadnál, akkor nyugodtan kérdezz még, lehetőleg a hibaüzenettel együtt, amit kiírt.
-
Frawly
veterán
válasz
attilav2
#5244
üzenetére
Az inxi kimenetéből az látszik, hogy rendben van a videódriver, van hardveres gyorsítás. Ha kikapcsoltad és úgy sem megy, akkor azt jelenti, hogy FF-ban szintén be volt kapcsolva. Az is biztos, hogy nem a böngésző beállítása, addonja, mert több böngészővel sem megy. A Chrome, Opera azonos böngészőmotort használ (Blink), de nem is lehet az, mert mind a FF, mind a Falkon más motorral fut.
Próbából az Xfce-ben kapcsold ki a kompozitort. Tényleg csak tesztképpen, kicsi az esélye, hogy segít. Ha az lenne a baj, akkor más oldalak sem jelennének meg.
-
-
Frawly
veterán
válasz
#63718632
#5234
üzenetére
Nem baj, hogy kérdeztél, megvan legalább itt is. Én is belefutottam, de magamtól rájöttem, ha ez a fájl létezik, akkor szimplán csak törölni kell rm paranccsal. Utána szépen megy a frissítés. Majdnem beírtam én is ide figyelemfelhívásnak, de aztán megjelent az Arch oldalán is a hírekben, aztán úgy voltam vele, hogy az elég figyelmeztetés mindenkinek.
Egyébként nem értem, hogy a csomagkészítő milyen nem vettem fel scriptbe, ha létezik a fájl, akkor telepítés során automatikusan törlődjön.
-
Frawly
veterán
válasz
ubyegon2
#5229
üzenetére
A systemd-analyze outputját felejtsd el, bullshiteket írogat. Stopperral mérd. A bootmenüben ahogy indítod a rendszerd, onnan indítsd a mérést, és ott állítsd le, ahogy minden ikon az asztalon, tálcán, stb. megjelent.
Az a HP Elitebook, ami neked van, elviekben UEFI-s és támogatja a GPT-t. Az UEFI-ben állítsd át a Boot type-ot vagy Legacy + EUFI-re, vagy UEFI-re. Tessék csak szépen próbálkozni vele.
A telepített rendszer csak akkor fog az UEFI-ben látszódni, ha az OS megtette a szükséges bejegyzést magában az UEFI-ben. Valószínű jó az a GPT-s átállás, csak az OS telepítésekor az UEFI boot részletei nem megfelelően lettek beállítva, ezért nem bootol.
-
Frawly
veterán
válasz
ubyegon2
#5227
üzenetére
Márpedig szerencsénk van, mert a DVD meghajtót a laptopból úgy kivágjuk, hogy csak nyekken. Konkrétan a bal vállunk felett hajítjuk hátrafelé. Persze nem mindenhol opció, mert az X220-ban mivel szubnotesz, eleve nincs ODD, így nincs az, hogy a HDD-t átrakod a helyére. Meg a 2. SSD sem azért kéne nekem, mert annyira szűkében vagyok a tárhelynek, csak inkább szeretném külön lemezen tudni a két OS-t.
Az 2,7 másodperces antergosos Cinnamon-boot az nagyon szép. Lehet ahhoz jobb gép kéne. NVMe-vel is max csak ilyen 0,1-0,5 mp-eket lehet lefaragni, inkább a procin, buszsebességen múlik, nem az SSD-n. Esetleg ha a kernelben a hardverdetektálást fel lehetne gyorsítani nem használt komponensek detektálásának a letiltásával.
-
Frawly
veterán
válasz
ubyegon2
#5225
üzenetére
Óó, ne aggódj, ha Archot teszel rá, azt azért SSD-n is érezni. Ha minimalista WM-mel használod, akkor a bootidő leszorítható 4 mp. környékére egy sima SATA3 SSD-vel. Ez Minten elérhetetlen.
Ennek az SSD-korszaknak már nagyon ideje volt, a HDD-k nagyon visszafogták már a mai gépeket. Főleg a Win10-nél fontos az SSD, mert mocskosul tekeri a lemezt, részben az NTFS fossága miatt, másrészt a registry írása, olvasása is elég lassú. Linux fronton el lehet lenni HDD-vel, de az SSD ott is sokat gyorsít. Ma már nem éri meg spórolni rajta, ha más nem egy olcsó 120 gigás Kingston A400-at be kell szerezni, vannak boltok, ahol 10 ezer alatt megkapod, alig drágább, mint egy nagyobb pendrive. Lesz ez még olcsóbb, ha lemennek reálisabb szintre az memória/SSD árak.
-
Frawly
veterán
válasz
ubyegon2
#5223
üzenetére
Jó neked, hogy ilyen 10-12 gigás SSD-kkel beéred, én 480-525 gigás kategóriában nézelődök
Tudom, hogy elgépelted, gondolom a 12-es az 120 gigás akart lenni, az Intelnél meg a 10 az lehet 120 vagy 180 giga?Abban igazad van, hogy átlag felhasználó, amilyen én is vagyok, elvan planár TLC-vel is, mivel nem ír annyit rá, hogy számítson a TLC, 3D TLC, MLC írásterhelhetőségi különbsége. Amúgy is a vezérlő fárad el, nem a cellák. Szóval nyugodtan meg lehet venni ilyen kifutó SSD-ket olcsón, nem baj az se, ha planár TLC, csak sokat nem szabad érte adni.
A 16K-s align onnan jön, hogy 3D TLC-nél 16K-s lapokba vannak a cellák szervezve, nem 4K-ba. Ez az átlag usert nem érinti, mivel a modern particionálóprogik és telepítők továbbra is úgy alignálnak, hogy mindenfajta eszköznek megfeleljen tekintet nélkül a fizikai szektorméretre, az OS felé meg tudják a 0,5K-s módot emulálni (egy szektor 512 bájt sémát). A lényeg, hogy ilyen DOS-os meg meg Win9x-es progikkal nem szabad particionálni, meg XP és annál régebbi Windows telepítőjével sem, azok a partíciókat 63-mal osztható szektoron kezdik, mivel a HDD-ken egy sávban 63 szektor volt. Ez az SSD-nek nem jó, jelentősen belassul tőle.
-
Frawly
veterán
válasz
ubyegon2
#5221
üzenetére
Valóban, Linuxon pl. a fájlrendszer is eleve tartalékol, az ext4-nél valami 5% ez, ami ha rájön az overprovisioningre, akkor az már magában elegendő lehet. Ezt a szabad hely hagyása igazából windowsos usereknél fontos.
Második OS futtatására venném, jelenleg egy külső SSD-t használok erre, de az kicsi (64 GB), és idegesít, hogy lóg ki a gépből USB-SATA átalakítós kanócon. A ThinkPad X220-amba már benne van egy SATA SSD, így már csak mSATA-nak marad hely. Viszont ez egy elavult, kifutott csatolófelület, egyre inkább nem kapni, ami van, az is drága.
A 3D TLC-s SSD-k még a 4K AF-es HDD-knél is jobbak, mert 16K-s alignálást igényelnek. A több pedig jobb
Persze nem kell aggódni, mert a modern particionálóprogramok, OS telepítők 1024K-n alignálnak (2048-cal osztható szektoron kezdődnek a partíciók, azaz egész MB-os határon), ami megfelel az 1K, 2K, 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K, 1024K-s alignálásnak is, mivel ezekkel is osztható maradék nélkül. -
Frawly
veterán
válasz
ubyegon2
#5219
üzenetére
Na, látod, azt nem tudtam, hogy a tartalék területet overprovisioningnek hívják. Az viszont vitatott, hogy egy 120 gigás meghajtónál 8 giga elég-e. Valamennyit biztosan segít, de hogy milyen mértékben, az vitatható.
Azt én sem szoktam javasolni, hogy particionálatlan helyet hagyjunk. Csak abban a speciális esetben jó, ha nagyon laikus felhasználóhoz kerül az SSD, akinek nem lesz adattárolási fegyelme, és állandóan csurig pakolva használja az SSD-t. Aki viszont nem ilyen, ne hagyjon particionálatlan helyet az SSD-n, csak arra figyeljen, hogy ne legyen állandóan csurig, legyen rajta tartósan legalább kb. 10% hely (néha be lehet menni ezalá, de ne legyen tartós állapot). Jobb, ha ez a szabad terület a partíción van meg, mintha partíción kívül. A hatása a wear levelingre mindkettő megoldásnak azonos.
Már a HDD-k sem örültek, ha csurig voltak töltve. Pedig azoknál nincs se TRIM, se wear leveling. Még a 4K alignálás sem csak a SSD-k specialitása. Igazából az SSD úgy kell használni, mintha HDD lenne. Egy plusz dologra kell figyelni, a TRIM menjen, meg pár havonta ránézni a SMART adatokra, nehogy valami bugos program írási kergekórt kapva szétírja. Meg ugye defragolni nem kell, de ez sem gond, mert Win7 és attól felfelé már alapból nem defragolja, Linuxon meg sose volt erőltetve a felhasználó tudtán kívül a defrag, ott neked kell futtatni, nincs az, hogy véletlenül lefutott, mert nem akadályoztad meg, elfelejtetted letiltani.
Így ha lehet is az SSD-vel bonyodalom, az csak a TRIM körül lehet, esetleg az ATA jelszavas titkosítás terén (de az meg megint lehet HDD-nél is).
-
Frawly
veterán
Pedig ugyanazt mondjuk, azért nem volt vita. Azt is elismertem, hogy pontatlanul használtam a fogalmakat, ebben sem volt vita. A lényeg lényegén meg amúgy sem változtat, Samu 850-en nem jó ötlet a discard TRIM-et erőltetni, és az is tény, hogy nem veszteni semmit a hiányával, de ha ez utóbbiakkal nem értesz egyet, cáfolhatsz nyugodtan. Érdemi cáfolatra gondoltam, nem elnevezéseken lovaglásra, azon túlvagyunk.
De ha már Gyurmafigura paprikás kedvében van, akkor mégis húznám még azzal az idegeit, hogy a security erase is trimmelés lényegében, és annak is van kétféle változata, egy rövidebb, és a meghajtó teljes felületén végrehajtott. A rövidebb azoknál a meghajtóknál lehetséges, amelyek támogatnak öntitkosítást. De a security erase-t nem a kernel intézi, hanem az SSD vezérlője, ha erre kap parancsot.
Júbájgön: az EFI partíció FAT32-es, bár az elméletileg nem igényel trimmelést, mert egyszer ráírod, ami rákerül, utána nem nagyon történik róla törlés, csak néha felülírás kernelfrissítéskor (initramfs, fallback). Egyébként másra nem használnék FAT-ot, NTFS partícióm sincs (jó, vagy egy nyomorult darab egy külső meghajtón). Viszont nem kerülne semmibe lefejleszteni, hogy az fstrim vigye a FAT-ot is, soha nem tudni mikor jön jól, elfér, ha tudja. Nem lenne bonyolult implementálni, lényegében a FAT a legegyszerűbb létező fájlrendszer a swap után, már ha utóbbit lehet fájlrendszernek tekinteni.
Az fstrim-nél meg nem értem, hogy miért lenne nekem kötelességem rájönni a futási sebesség rejtélyeire. Tippem persze van. Első futáskor végignézi a fájlrendszer foglalási tábláit, megnézi, hogy mely szektorokhoz nem tartozik fájl, és ezekre mindegyikre kiküldi a TRIM parancsot, akkor is, ha ezek közül van olyan, ami már TRIM-elve van (tehát az adott partíció egész üres területét trimmeli). Második futásnál viszont a fájlfoglalási táblában az újonnan kiürült szektorokat keresi meg, és csak azokat trimmeli. Pedig még a forráskódjából is puskázhatnék, ha nem lennék lusta.
SSD topikot meg jó nyomon követni, melyik szériával mik a tapasztalatok, hogy alakulnak az árak. Egyszerűen tanulságos, még akkor is, ha nem akarsz SSD-t venni. Már pedig akarok (mSATA-s menne bele a fő gépembe 2. SSD-ként, már csak annak van hely), de nem találtam még jó áron. Nagyon fent vannak az árak, de nézelődök.
Persze emlékszem a fénykorodra, mikor te is aktívan részt vettél SSD-s flame-ekben, hogy pl. kell-e kímélni, le kell-e tiltani az atime-ot. Akkor azzal csesztettelek, hogy ki kell venni az SSD-t a gépből, betenni üvegvitrinbe, akkor nem kap sok írást. Csak ezzel azóta nem poénkodok, hogy pár helyről kiderült, hogy üvegvitrinben is bedöglenek ezek, épp úgy a vezérlő adja be a kulcsot.
-
Frawly
veterán
Ilyen értelemben nem ugyanaz. Igazából ugyanazt mondjuk, csak a kifejezéseket használtam pontatlanul.
Ha nagyon a mélyére nézünk, TRIM-ből csak egy van. Ezt lehet kétféleképpen is kettébontani, attól függően, hogy milyen időbeli beosztásban van végrehajtva.
Az egyik a folyamatos TRIM (discard) a másik az időszakos (fstrim). Ez a felbontás Windows alatt is él, a Windows kernel (Win7 és attól felfelé) folyamatos TRIM-et alkalmaz (menet közben TRIM-el, mikor valami törlésre kerül, azzal együtt a TRIM parancsot is kiküldi), míg egy-két SSD-gyártónak és defrag progit fejlesztő szoftvercégnek van időszakos TRIM-es megoldása (ami viszont megy XP-n, Vistán is, ha a meghajtó és a driver tudja a TRIM-et).
Egy másik bontásban meg van a queued TRIM (a kiküldött TRIM parancsok későbbre ütemezve, kötegelve futnak) és a sima TRIM, aminek egyrészt ilyen terminológia miatt a felülete nem göcsörtös, és a TRIM parancsok valós időben hajtódnak végre, nem ütemeződnek kötegelt végrehajtásra.
Ezeket párokat keresztben is lehet párosítani, négyféle kombinációban. Kivéve, ha nem megy a queued TRIM, mert a kernelben tiltva van. Igazából még mindig áll, amit mondtam. A discard TRIM-et nem tanácsos használni feketelistás meghajtókon, mert nem kötegelve futnak, hanem azonnal hajtódnak végre valós időben egyenként, és ettől belassulhat a meghajtó. fstrim-nél ez mindegy, ahogy írtátok, „kevésbé zavaró”.
Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára, akkor is, ha trimmelt meghajtón fut. A 2-3., stb. futásnál már 0 mp. alatt végez. Majd egy reboot, és újra az első futtatásra mintha újra végigtrimmelné az SSD üres szektoraihoz tartozó cellákat.
Pont a queued TRIM miatt vettem anno Crucial MX300-at. Két fontos szempont volt, tudjon ATA-jelszavazható hardveres AES öntitkosítást a meghajtó, és ne legyen feketelistán a meghajtó queued TRIM ügyében. A Samsung 840, 850 emiatt esett ki, öntitkosítást tud, de a queued TRIM tiltva van. Kiderült, hogy felesleges volt aggódni, mert csak fstrim-et használva is normálisan trimelődik a meghajtó, és nem baj, ha nem használjuk a discard paramétert.
Igazából pedig a feketelistás meghajtók is tudnák, de firmwarehiba miatt okozna a használata anomáliát, ezért van a kernelben szoftveres úton letiltva. Ami duplán meglepő, hogy az illető SSD-k gyártói nem akarják ez ellen a firmware-t patchelni. Tudom, a Linux marginális platform, 0%-os részesedés, a kutya nem használja, mert csak a Windows a tuti. Az néha kísérletezik vele, akinek nincs pénze Mac-re vagy Windows licencre, de előbb-utóbb ők is letörlik, és ChromeOS-t vagy Androidot tesznek fel.
A másik, amit nem értek, hogy az fstrim miért nem támogat minden fájlrendszert. Olyan egyszerűt pl. mint a különböző altípusú FAT fájlrendszerek. A discard támogatja, az fstrim nem. Így ha valaki ilyen fájlrendszert akar trimmelni, feketelistás meghajtón is használni kell a discard TRIM-et.
-
Frawly
veterán
válasz
vargalex
#5208
üzenetére
De, 8xx-es Samsungon is megy a queued TRIM, de teljesítményvesztés léphet fel, ezért nem érdemes használni. Ez csak azzal jár, hogy a mount opciók között nem szerepelteted a discard-ot.
A hiánya egyáltalán nem fájó. Bőven elég, ha az fstrim-et használod helyette, vagy fstrim systemd service engedélyezésével, vagy néha napján kézzel lefuttatva a sudo fstrim -a -v parancsot. Ezek a megoldások is rendesen TRIM-elik a meghajtót, semmi hátrány nem ér.
Fájlrendszernek XFS semmiképp. Vagy ext4, vagy f2fs. Mindkettővel van tapasztalatom. Mindkettő egyformán gyors. Az ext4 szerintem jobb, mivel az f2fs bootkor néha lassan ellenőrzi a fájlrendszert (fsck), az ext4-nél ez is villámgyors.
-
Frawly
veterán
Kösz a válaszokat. Jó tudni, hogy nem csak én szívok ilyennel akkor. Pedig tényleg teljesen támogatott Intel Wi-Fi kártyával tolom, ami megint csak a Linux kernel által teljesen támogatott üzleti szubnoteszben működik.
Korábbi kernelre nem váltok vissza, mert amúgy más baj nincs vele, és ezzel a netctl-es trükkel használható a rendszer, de kezd már frusztrálni, hogy az utóbbi időben túl sok baj van ezzel, ha így megy tovább, akkor át kell állnom Gentoora.
Egyébként ezt sem értem, mert ha a kernel lenne hibás, vagy a csomagkarbantartó hibázna, akkor nem lenne az, hogy a 4.16.x-es kernelek közül egyikkel jó lenne, a másikkal nem, hanem akkor mindig konzisztensen rossznak kéne lennie egy bizonyos verziószám fölött. De nincs így, egyszer megjavult, jó egy ideig, aztán megint előjön. Nagyon komolytalan ez így, mint egy hullámvasút.
-
Frawly
veterán
Blogolásom folytatom ide, nem offolom vele a kezdő témát. Most megint nem jó a NetworkManager. Hetekig jó volt, tegnap előtt frissített a 4.16.6-os kernelre, és elkezdett megint szórakozni. Tegnap a 4.16.7-re frissült, és ez sem segített. Lehal random pontokon a Wi-Fi, persze nem szakad meg a kapcsolat, csak elkezdenek nem betöltődni az oldalak. Ahogy beszögelem a /etc/resolv.conf-ba a 8.8.8.8-as Google-féle DNS-t, egy rövid időre megjavult, majd újra lehal, és semmi nem segít rajta. Ráadásul beállítási módozat sincs, amin változtathatnék.
Úgyhogy megint az van, hogy NetworkManagert letiltottam, és wpa_supplicant-os profilt betöltve netctl-lel használom a netet, így jó, bár ennek a módszernek van egy olyan hátránya, hogy bootkor beakad néhány másodpercre, míg a wpa_supplicant kapcsolódik, ami kicsit kellemetlen.
Kezdek közelebb lenni a probléma gyökeréhez, eddig azt hittem, hogy a 238-as systemd-vel van gond, közben meg a kernel lesz a ludas. Abból is tesztelni fogom más disztrókkal, mert lehet csak a csomagkészítő hányja el a dolgokat Arch alatt, kihagy a fordítás során valamit, ami kéne a kernelbe.
Abban is biztos vagyok, hogy nem a Wi-Fi kártya, meg a tré Wi-Fi jelerősség az oka, mert bizonyos szoftveres megoldásokkal jó, Win10 alatt megint jó. Archon majdnem egy évig jó volt. Ha a kártya haldokolni, mindenféle környezetben lenne vele problémám.
-
Frawly
veterán
válasz
JonssoN
#5197
üzenetére
Ha a leírás alapján csináltad, próbáld átnevezni a glamor.conf-ot, hogy anélkül mit csinál. Kezdek arra gyanakodni, hogy nálad mégis valami más dolog lesz. Ahogy nézem friss X-et, Mesa-t használsz, modesetting drivert, kompozitor beállításai is rendben, GPU-d is támogatott. Egyszerűen nem értem miért szellemképezne. Esetleg ha csak böngészőben csinálja, próbáld megnézni más böngészőkkel, progikkal, görgess fájlkezelőben, szövegszerkesztőben.
Böngésző about:support lapján is nézd meg a hardveres GPU gyorsítás állapotát.
-
Frawly
veterán
válasz
JonssoN
#5195
üzenetére
Ez már rendben lévőnek tűnik, kéne lennie hardveres gyorsításnak, nem véletlenül írja, hogy „Direct Rendering”, meg DRI.
Hamarabb inkább a Compton beállításai között nézz szét, hogy renderelésre a glx backendet használja. Bár ha a conf-fájlban a Glamour be van állítva, akkor enélkül is kéne lennie 2D-s hardveres gyorsításnak. Arra is figyelj, hogy Comptonban legyen bekapcsolva a vsync.
-
Frawly
veterán
válasz
JonssoN
#5192
üzenetére
Ezek az adatok rendben lennének, egy kivétellel:
driver: none unloaded: modesettingItt azt kéne írja, hogy driver: i915 vagy modesetting, semmi unloaded vagy ilyesmi. Beigazolódott az a gyanúm, hogy 2D-s módban visszaváltott valami software render fallback driverre, aminek a kirajzolása lagol. Az i915-ös drivernek támogatnia kéne a HD630-at, és kéne lennie 2D hardveres gyorsításnak is.
Nagyon zavaró, hogy a hardver résznél azt írja, hogy az i915 driver hajtja, majd a Xorg résznél ezt az unloadedet írja.
-
Frawly
veterán
Igen, úgy jobban látszana. Egyébként a videó alapján sejtem, lagzik neki a kirajzolás, az oka az lehet, hogy a rendszer szoftverrendesen fallback drivert használ (llvmpipe), és nincs hardveres gyorsítás.
Nem tudom, hogy archmerged-re fel tudná-e szögelni az inxi progit, hogy lássuk inxi -Gxxx kimenetéből, hogy milyen drivert használ a GPU.
Bár most nálam az inxi is bugzik, az inxi -Gxxx-re ír ugyan néhány adatot, de a többi adatnál jelzi, hogy glxinfo kéne hozzá, feltettem, de a felbontást ezzel sem jeleníti meg, gondolom a glxinfo nem kompatibilis a waylandes Gnome-mal.
Még egy dolog: ha el lett távolítva a Xorg Intel driver, akkor mindegy mi van a 20-intel.conf-ban, meg pl. a TearFree opció sem érvényes, mert azt csak a Xorg driver tudja.
-
Frawly
veterán
Én tudok javaslatot. Fogod a kiírt Antergos-telepítőt, és laza mozdulatta a jobb vállad fölött hátra hajítod a Petőfi Csarnokba. Aztán kiírsz egy Arch-ot, megtanulod szépen scriptek nélkül telepíteni, és megoldod magadnak az EFI bootot. Csak egyszer kell megtanulni hogy működik, utána minden gépen hasznosítani tudod ezt a tudást, nem leszel többé GRUB-ra meg társaira szorulva.
-
-
Frawly
veterán
Akkor lehet Gyurmafigura volt, aki használja EFI partíció nélkül az UEFI bootot. Lehet azzal keverem, hogy te meg egész lemezes szoftveres titkosítást használsz titkosítatlan bootpartíció nélkül, az is olyan eset, amit nem sikerült megértenem.
Az Archra most haragszok. Újrahúztam bugok miatt, ugyanolyan bugos maradt, mint volt. Problémázik az Intel Modesetting driver és a NetworkManagerben lehal a Wi-Fi. Ez utóbbi problémát meg tudom kerülni, letiltottam a NetworkManagert, és bootkor automatikusan netctl-lel aktiválom a wifi-menu-ben wpa_supplicant-tal aktivált kapcsolatot.
Lehet lesz megoldás a Modesetting driverre is, az SDDM-et is átállítom Waylandre, nem csak a KDE Plasma5-öt. Így talán megszűnik ez a bug is.
Viszont a KDE továbbra is bugos, bezárok egy-két futó programot, Rendszerbeállítások, Konsole, erre jelenti a bugjelentő, hogy az alkalmazás összeomlott segfaulttal. De hiszen én zártam be. Meg a kernel is írogat hibákat leállításnál.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Tudom, hogy elgépelted, gondolom a 12-es az 120 gigás akart lenni, az Intelnél meg a 10 az lehet 120 vagy 180 giga?
Új hozzászólás Aktív témák
Hirdetés
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Vírusirtó, Antivirus, VPN kulcsok
- Assassin's Creed Shadows Collector's Edition PC
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Xbox Game Pass Ultimate kedvező áron, egyenesen a Microsoft-tól! - AUTOMATA BOLT
- BESZÁMÍTÁS! Gigabyte A520 AORUS R5 5500 16GB DDR4 512GB SSD RX 6600 XT 8GB Rampage SHIVA TT 500W
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- PS5 konzolod megvásároljuk: Budapest, Kecskemét, Szeged, Debrecen vagy akár GLS futárt küldünk!
- VÉGKIÁRUSÍTÁS - REFURBISHED - Lenovo ThinkPad 40AC Thunderbolt 3 docking station
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest