-
PROHARDVER!
Arch Linux topik
Új hozzászólás Aktív témák
-
Laszlo733
aktív tag
...bocsi, csak közben voltunk korizni a gyerkőcökkel...
Persze:
xrandr --output LVDS1 --primary --mode 1366x768 --pos 1920x312 --rotate normal --output DP1 --off --output HDMI1 --mode 1920x1080 --pos 0x0 --rotate normal --output VGA1 --off --output VIRTUAL1 --off &Rengeteget tanulok tőletek itt és egyéb fóromukban / linux kezdőknek, haladóknak, Pi / + net az érdem a tiétek!
-
Shyciii
veterán
cigam
Nem tudom, hogy ez tud-e kirakni ikont Openbox alá. Nem kerestem semmi ilyen lehetőséget okosban, mert teljesen feleslegesnek tartom az asztali ikonokat egy Rofi Launchar, vagy Ulancher mellett. Arról nem beszélve, hogy ha már egy ablakod nyitva van, akkor az jó eséllyel komolyabban eltakarja az ikonokat, szal még kényelmetlen is a legtöbb szituációban. Persze ez rám vonatkozik
Frawly
Emlékeim szerint a Fluxbox és Openbox semmilyen módon nem klónja egymásnak, mert mind a kettő a Balckbox-ból alakult ki, így inkább a Blackbox-nak a klónjai. PekWM szintúgy. Nagy különbség amúgy a config file. Egyik xml alapú, másik sima text file. Kinek mi a kényelmesebb mikor állítgatja. Mivel előző munkahelyemen elég sok webes cuccot üzemeltünk, így nekem az Openbox XML konfigos megoldása nem probléma.
Dmenut amúgy én is kipróbáltam, de a Rofi launcher + Arc Dark Mandy theme-el nagyon tetszik, így végülis a külső miatt lett Rofi
Pár bill kombóra nekem is be van lőve gyakran használt progi, de csak nagyon gyakori. 52db bill kombót nem tudok megjegyezni Így is pl az átlátszóság 0.5-ös lépcsőben való állítása ablakonkénti bill kombó se jut most eszembe, pedig ezt is én állítottam be Openbox alá (mert ezt sem tudja alapból). Szal felesleges nekem minden bill kombóra állítani
Amúgy most egyik napról a másikra nem működik az automount a csatlakoztatott usb-s winyóknál. Nálam ezt az udiskie csinálja, de lehet hogy akkor most kipróbálom hogy ezt lelövöm, és mivel úgyis van pcmanfm filekezelőm, így azt futtatom daemon-ként, és akkor az is elvégzi. Még lehet hogy jobban is járok, mert kevesebb memóriát foglal, és még kevesebb csomag is lesz. -
Frawly
veterán
Arra még érdemes figyelni, hogy az IceWM menüje nem tartalmazza a telepített alkalmazásokat. Ezért a menumaker csomagban lévő progival kell minden egyes újabb szoftver telepítése után aktualizálni:
menumaker -f icewmIlletve ha csíkoz a kép ablakmozgatás, görgetés, videólejátszás közben, akkor Intelnél belőni a X.org-ban a tearfree opciót, vagy feltenni kompozitort, utóbbiból most a picom a legjobb. Illetve IceWM-hez van egy csomó jó téma a themes.ice-wm.org, box-look.org, deviantart.com oldalakon.
Más tudnivaló nincs, szög egyszerű WM, eleve panellal jön, amit le tudsz cserélni, vagy ki tudsz kapcsolni. Esetleg ha bloatabb alkalmazást használsz, azoknak kellhet a d-bus meg a pulseaudio, de ez már nem IceWM specifikus.
-
Frawly
veterán
DM nem kötelező, indítható startx-szel .xinit.rc-ből. De DM-et se nehéz telepíteni, egyszerűen pacmannal felrakod. Ami trükkös ezen a ponton, hogy feltelepül az adott DM, de ahhoz, hogy boot után betöltődjön, ahhoz systemctl enable dm-neve és systemctl start dm-neve parancsokkal tudod beröffenteni.
Egy ideje login managert se használok. Konzolos bejelentkezést követően automatikusan betölt bashrc-ből a sway, ha a tty1-en jelentkezek be. Ennek csak annyi a kényelmetlensége, hogy a felhasználónevet is be kell pötyögnöm, meg a képernyőzároláskor külön progit kell használnom. Ha meg el akarom kerülni a grafikus felületet, akkor tty2-7 valamelyikén jelentkezek be, vagy a tty1-en, de másik felhasználóval.
-
Frawly
veterán
Igen, egy sima viewer progival majd csak nézd meg őket. Látni fogod, hogy ugyanazzal az MZ-s fejléccel érkeznek. Nincs új a nap alatt, meglévő technológiák mentén építkeznek tovább.
Azt meg előre megmondtam, hogy nem kell hozzá mindenféle resolvd. Amiben helyi DNS-felülbírálást akarok, azt a hosts fájlba teszem, azt minden figyelembe veszi. Még a Chrome/Chromium is figyelembe vette, pedig az nagy ívben tesz az alternatív DNS beállításokra. Lényegében a pihole is egy hosts fájl, csak ki van helyezve egy hálózati eszköz formájában, hogy minden gép tudja használni, ne kelljen egyiken sem külön állítgatni.
-
Frawly
veterán
Nagyon helyes. Szakmai fejlődés csak úgy van ha kilépsz a korábbi komfortzónából. Nehogy feladd, már van egy telepített Arch rendszered, ezt próbáld minél jobban belakni, megismerni. Az bőven nem gond, ha az első néhány telepítésnél nem sikerül valami, vagy kifejezetten gallyra megy. Az lesz a tanulópénz, meg egy jó alkalom az újratelepítés gyakorlására, meg a rendszer újra működőképessé hozására.
Nálam most ugyanez van Gentoo-n. Igaz én bonyolítom is magamnak, hogy minimalizmus möhöhőő, csak azért is legújabb RC-kernel, meg git v-9999-es bleeding edge csomagok, mert L'oreál és megérdemlem. Aztán a Gentoo meg OFF topikban ott vihognak rajtam a tapasztaltabb gentoo-sok, már előre tudják, hogy szívás lesz belőle, de szórakoznak rajta, olyan olyan vagyok, mint a prérifarkas, hogy még nem tudni hogy, de tutira szakadékban köt ki porfelhőt hagyva maga után. Meg mikor feltelepítettem, örültem, hogy van egy működő alaprendszerem. Gyorsan kiderült, hogy lófütyi nincs, nem ment az i915 driver, nem ment az Intel Wi-Fi, nem ment a Thinkpad speciális gombok és ACPI, nem volt jó az UUID az fstab-ban, nem ment semmi, csak alaposabban tesztelni kellett a rendszert, folytatni a belakását, már tornyozódnak a nehézségek. Ez az, amit nem lehet könyvből meg tanfolyamon megtanulni, csak ha az ember már azt az adott rendszert használja ténylegesen.
Nekem is voltak frusztráló dolgok az Arch Wiki-ben. Pl. eleinte Intel GPU-n állandóan lefagyott a Login Manager, mindegy melyiket raktam fel. De csak a Login Manager, az is csak néha, zároláskor fagyott le, mással nem volt gond. Hónapok után derült ki, hogy ott van a releváns infó az Intel Arch Wiki cikkben, amit ugyan el is olvastam, de ott negyedik generációról volt szó (nem szabad a X.org drivert feltenni az ezeknél újabb GPU-kre), nekem meg 2. genes Core i-s a gépem. Csak a negyedik generáció az Intel GPU-k generációjára vonatkozott, és valójában az én 2. genes procimban már 6. generációsnak számít az IGP. Nem olvastam figyelmesen, csak fourth generation, bla-bla, aztán ugrottam is át a színes dobozt, hogy csak valami nagyképű hülye okoskodik benne, mert nincs élete a lúzerjének. Kiderült nem erről van szó, kifejezetten azért volt színes dobozban, mert az inteles felhasználók zömének releváns infó, aminek a hiányától sokan szívnak.
-
samujózsi
senior tag
Neked sem való¹. Ehhez kell nem kevés alapismeret, a doksik precíz olvasásának, megértésének képessége és türelem. Utóbbiból elég sok. Ha van időd és kedved kísérletezni, tanulni olyan dolgokat, amikre vélhetőleg két telepítés közt nem lesz szükséged, akkor érdemes foglalkoznod vele.
Egyébkén valószínűleg jobban jársz bármelyik egyéb, elterjedt disztróval.¹ Én pár évtizedig ilyesmiből éltem, de elég hamar eljutottam oda, hogy nekem sem való. Öreg vagyok bohócnwk, ahogy mondaninszokták. Használninakarom a gépet és rendszert, nem hackelni.
-
Frawly
veterán
Igen, ha nem tudod, mi kell neked, akkor jó eséllyel nem való az Arch. Persze gyűrődni akkor is lehet vele, tanulási célzattal. Pont ezért jó, tapasztalatszerzés miatt, hogy legalább tisztában leszel vele, hogy mi is kell neked. Meg ahogy egyre régebb óta linuxozol, úgy változni is fog, hogy épp milyen megoldásra esküszöl.
Az EFI-től nem kell félni, mert pont, hogy egyszerűbb. Nem kell ilyen os-probe-os, mountolós varázslás sem. Az EFI boot lényege, hogy van egy univerzális FAT32 bootpartíció. Egyetlen egy (elméletileg lehet több, de nem ajánlom), az összes azon a lemezen lévő OS-nek (de fel lehet venni közéjük más lemezen lévő OS-eket is). Mivel GPT UEFI boot esetén nincs MBR, ezért nem oda írja be az OS az indítókódját, hanem egy .EFI fájlba, az EFI partícióra. Így nem írogatják át az OS-ek egymás alatt az MBR-t, hanem mindegyik tud indulni a saját loaderjével.
Így ha már van fent a gépen egy UEFI-s OS, mindegy, hogy Linux vagy Windows vagy mi, akkor eleve el lesz készítve az EFI partíció, lesz loader.conf vagy valami hasonló megoldás. Akkor csak bootctl installal-lal beteszed a systemd-boot .EFI fájlját az EFI partícióra, meg a loader.conf-ban kitöltöd az EFI fájl indulási paramétereit. Vagy alternatív megoldásként nem foglalkozol loader.conf-fal és systemd-boottal, hanem mindjárt az EFI partíción lévő kernelt használod indításra EFI stub boottal, ezt efibootmgr -c paranccsal tudod hozzáadni az UEFI BIOS bootbejegyzései közé az NVRAM-ba.
Egyébként meg UEFI-s gépen lehet továbbra is hagyományos BIOS bootot használni MBR-rel. Egyedül 2020 után készült, vadi új Intel lapoknál lesz csak megvonva ez a lehetőség. A régebbi lapokon, meg az összes AMD-n támogatva van.
Egyébként az EFI egy nagyon érdekesre kitalált dolog. Lényegében egyfajta 64 bites DOS. Nem röhögni, tényleg ez az igazság. Ezért is van FAT32 kitalálva EFI partíciónak, és nem ext, nem NTFS, nem más. Hiszen az .EFI fájlok MZ-fejléces DOS .exe fájlok, .exe kiterjesztés nélkül (a kiterjesztés mindegy), de nem tartalmaznak DOS vagy BIOS hívásokat (mint a legtöbb DOS program), hanem bare metal binárisok, közvetlenül a „vason” futnak, OS közbeékelése nélkül. A neten vannak olyan pihent agyú kockák, akik ilyen ASM-ben írt DOS bare metal progikat bootolnak be UEFI-vel (primitív játékok, képernyővédők, grafikus demók), pontosabban EFI stub boottal
![;]](//cdn.rios.hu/dl/s/v1.gif)
A sors iróniája, hogy hagyományos MS/PC/stb. DOS nem bootolható be UEFI-vel, mivel még ugyan .EFI binárisként be lehetne bootolni elvileg, de az UEFI 64 (ritkán 32) bites védett módra lövi be a procit, a DOS meg nem kapcsolgat bootkor x86 proci módot, hanem csak 16 bites valós módból (x86 real mode) tud indulni. Bár elvileg a FreeDOS-t fel lehetne készíteni erre. -
Frawly
veterán
Ezt értem, hogy neked frusztráló, sajnálom. Nem is védeni akarom őket, de azt értsd meg, hogy az Archnak az a szemlélete, hogy semmit nem tesz be a telepítési folyamatba, ami nem minden embernek kell, vagy nem csak egy verzió van belőle. A linux csomagot is azért vették ki a base-ből, mert nem mindenki a legújabb stabil kernelt akarja használni, hanem mondjuk Zen-t vagy LTS-t, és akkor az így a base részeként nem kerül fel feleslegesen a legfrissebb kernel, és nem kell felesleges csomagot frissítgetni, meg leszedegetni. dhcpcd szintén zenész, mert mint olvasod, van, akinek nem kell. Tehát akinek kell, külön fel kell tegye, ami egyébként a legtöbb ember, mert a desktop felhasználók 99,99%-a Wi-Fi routerről nyomatja, ami tipikusan DHCP-s. Ez az Arch alapfilozófiája, ha nem feltétlenül kell az userek 100,00%-ának, akkor opcionális csak. Épp ezért nincs az Archnak telepítője. Azt honnan látnák előre, hogy te majd milyen kernelt, hálózati megoldást, stb. szeretnél? Ubuntun ez el van döntve, itt nincs.
Arch Installation Guide-ból régen kettő volt, egy felületes nagyon kezdőknek, meg egy részletes haladóknak. Ez utóbbi lett meghagyva, a kezdőknek szóló törölve lett az Arch Wiki-ből, mert párhuzamosan futottak, és a kezdős anyag nem volt rendesen karbantartva, el volt avulva, ellentmondott a másiknak. A mostani Installation Guide-ban ott van benne az a bekeretezett rész a dhcpcd-ről, amit te is észrevettél. Meg a Guide legvégén ott van a bootloader telepítésére utalás, ami elkalauzol linkekkel a vonatkozó cikkekre, amik az egyes bootloaderekkel és bootolási módokkal foglalkoznak. Tehát ott van minden, csak át kell látni, mindent el kell olvasni, nagyon figyelmesen. Nem szabad vakon csak a parancsokat követni, úgy valami könnyen kimarad.
-
-
-
Frawly
veterán
Akkor szerintem én vagyok a villamos, mert használtam már Archot, többféle gépen, Wi-Fi-on és Ethernet-en keresztül is netezve, és a /etc/systemd/network/ mappában soha semmit nem kellett matatnom, az pl. most is holt üres. Rendesen telepítettem őket, kézzel, semmi segédszkript, meg 3rd party installer.
A network mappában matatást két esetben tudom elképzelni, hogy fontos: 1) több Ethernet vagy több Wi-Fi-chip van ugyanabban a gépben, és választani kell melyikkel kapcsolódjon, vagy 2) speciális DNS szabályokat akarsz felállítani (piehole) csak kifejezetten arra az eszközre, de ez utóbbit lehet Network Managerben is, még csak grafikus felület sem kell hozzá, mert van TUI-s része is (nmtui vagy nm-tui vagy minek hívják), vagy módosítások ellen védeni a /etc/resolv.conf-ot.
De mint írtam, Archon sem engedem beavatkozni a systemd-t a hálózat kezelésébe. Azért mert a netctl vagy akár a NetworkManager hol elvesztette a Wi-Fi-t (ez régebben volt), vagy feleslegesen sokáig vártak rá, és feltartották a bootfolyamatot, ez utóbbiból lett elegem. Persze, működik systemd-vel is, csak köszönet nem lesz benne. Helyette a szög egyszerű, wpa_supplicant (Wi-Fi) + dhcpcd simán működik egymagában, mindenféle systemd-s beavatkozás nélkül, és megy, se Wi-Fi-ról leszakadás, se bootkor várakozás. Ethernetnél wpa_supplicant sem kell, csak dhcpcd egymagában. Az egyszerűség sokszor kifizetődő. Pedig van speciális DNS szabályom is, a szolgáltatói DNS-sel sok oldal nem jön be, ezért 1.1.1.1-es nyílt DNS-t használok. A dhcpcd meg eleve úgy van kitalálva, hogy működik systemd-vel és anélkül is.
Ezt nem hiszik el nekem a Debian, Ubuntu, Mint szentháromságon nevelt MBR GRUB Matyik sem, hogy az egyszerűség sokszor kifizetődő. Felhörögnek, hogy GPT soha, fújj UEFI, nem bootol, kiazakiesztaszrtkitatálta. Közben meg GPT UEFI EFI stub vagy EFI systemd boot holt egyszerű, semmi MBR-kód, semmi elsődleges meg kiterjesztett partíciózás, semmi bootflag, semmi GRUB meg grub.cfg meg GRUB-frissítési gikszer. Helyette csak egy FAT32 EFI partícióról betöltődik az UEFI BIOS-ban hivatkozott .EFI fájl (ez a kernel), esetleg felparaméterezve (systemd bootnál .conf fájlból), és a rendszer bootol. Sose törik el semmi bootolás megkezdésekor, mert nincs külön bootmanager, ami eltörjön, és az EFI partíció megmarad bootképesnek egy teljes rendszerújratelepítéskor is (pl. ha újrahúzza valaki az Archot). Ezt meg hiába mondod neki, lázadnak, hogy GRUB az akkor is kell, mert a fogakat is tisztíccsalya, meg Debianék jobban értenek hozzá, és ők nem tévedhetnek. Közben meg én leszek a hülye, mert simán bootol GRUB nélkül nálam, nem csak az Arch Wikiben terjedő mendemonda, még Gentoo-n is megy, ahol systemd sincs (vagyis van, ha úgy akarod, de default nincs). Persze megy az UEFI boot GRUB-bal is, meg lehet oldani, csak minek plusz egy bootloader a működési folyamatba beláncolni. Ez kb. olyan, mintha egy szekrényt kulccsal bezárnék, azt betenném egy másik szekrénybe, és azt kulcsra zárva annak a kulcsát hordoznám, ennyi erővel az első szekrény kulcsát is őrizgethetné az ember. Ez a fő rákfenéje újabban a linuxos világnak, a dolgok felesleges bonyolítása, főleg olyan átlagos desktop rendszeren, ahol csak Pistike netezik, meg ext4 partíciókat használ mindenféle LVM, RAID, LUKS, ZFS, snapshotok meg minden nélkül. Mert valóban van, ahol bonyolítani kell, de az nem desktopos felhasználás, vagy nem átlagos.
Pedig nekem GRUB-bal sem volt soha bajom, személy szerint, nálam mindig probléma nélkül működött, pöccre. De minek legyen egy felesleges telepítési lépés, felesleges csomag letöltése, (esetleg felesleges fordítása forráskódból emerge-kor), telepítése, felesleges frissítése, felesleges hibaforrás. Minek, ha egyszer felesleges, ráadásul tényleg hibaforrás, mert sok felhasználót látok vele szenvedni, hogy el-eltörik nekik frissítéskor.
-
Frawly
veterán
Szerintem nem használja a helyi pihole-os DNS-t, hanem helyette azt a szolgáltatóit, amit a routertől kap, a szolgáltatói DNS-ben meg csak a WAN címek vannak, LAN-os nincs. Csak tipp. Rá kéne erőszakolni a hálózati kapcsolatok beállításánál, hogy a pihole-féle DNS-t használja. Ezt végső soron be lehet írni a /etc/resolv.conf fájlba, nameserver Mö.Hö.Hö.Hő IPv4 formában, de azt alapból felülírja a drágalátos systemtré (igen, jól mondjátok, tényleg zseniális alkotás) bootkor, amit meg lehet ugyan akadályzni, ha elveszed róla az írási jogot, de az meg nagyon favágás (amit Archon meg is léptem).
Egyébként a helyi háló neveinek feloldására egyáltalán nem kell systemd-resolvd. Az csak ahhoz kell, ha azt akarod, hogy a systemd is állítgassa a /etc/resolv.conf-ot vagy valami másik systemd-megoldást akarsz mögé, pl. Network Manager.
Nálam Archon is, system-resolvd nélkül működik a dhcpcd, simán kezeli a resolv.conf-ot. Gentoo-n meg megint csak egymagában dhcpcd, ott az OpenRC miatt szóba sem jön egyéb megoldás.
Helyi címeket fel tudsz venni a /etc/hosts fájlba is, pl.:
192.168.2.1 router
192.168.2.2 pihole
192.168.2.3 gép2 -
-
Frawly
veterán
Nagyon megritkították a base csoportot. Már csak a gcc-libs-et teszi fel, meg a pacman-t. Minden más kikerült belőle, nano, vi, dhcpcd, meg minden. Nem csak a linux, linux-firmware. Fel kell tenned kézzel: pacman -S dhcpcd, de ha már ott vagy, nézd meg mi nincs fent a rendszeren, és mindent telepíts. Bár függőségnek úgyis behozzák a programok, amiknek kell, pl. wicd, wpa_supplicant, Network Manager, stb..
-
-
qisqaqas
senior tag
Én úgy csinálnám a helyedben hogy:
letörlöm a windowstprimary particiót hozok ottan létre, jó lesz az swapnak vagy /bootnak vagy ilyesminek. Aztán létrehozok egy extended partíciót, a windowsos után és azon belül garázdálkodnék.Ez volt az egyszerű mód. Ha saját maganak kellene akkor UEFI, GPTvel, és az úgy jó. Ez persze magában foglalja az Májkrémszaft operációs rendszerének újratelepítését, amit amúgy is megtennék ha ilyen elba
rmolt módon telepedik fel. Én a windows helyett ezt szoktam használni. Teljesen jól működik.
-
-
Nem értek az Arch telepítéshez, de a kép alapján létrehoztál sda4 néven egy extended partíciót 3,7 GB mérettel és erre szeretnél logikai partíciót sda5 néven, ami az extended mérete miatt nem lehet több 3,7 GB- nál.
Elképzelhető, hogy ennél többet írtál sda5- nek?
Ha kijelölöd a maradék területet extended- nek, akkor menni fog a dolog, overprovisioninggal se nagyon kell foglalkoznod, mivel 120 GB- os a meghajtód, nem 128 GB- os!
Képzeld magad elé a gpartedes partícionálást, akkor könnyebb ezt a parancssoros módszert is átlátni.
Nagyon az elején vagy még az Arch telepítésnek, kitartást hozzá és az ilyen apróságokra érdemes figyelni, mert szerintem ez a partícionálás volt a legegyszerűbb része!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
A sors iróniája, hogy hagyományos MS/PC/stb. DOS nem bootolható be UEFI-vel, mivel még ugyan .EFI binárisként be lehetne bootolni elvileg, de az UEFI 64 (ritkán 32) bites védett módra lövi be a procit, a DOS meg nem kapcsolgat bootkor x86 proci módot, hanem csak 16 bites valós módból (x86 real mode) tud indulni. Bár elvileg a FreeDOS-t fel lehetne készíteni erre.
Új hozzászólás Aktív témák
Hirdetés
BoB
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- BESZÁMÍTÁS! Apple MacBook Air 15 M3 8GB 256GB SSD garanciával hibátlan működéssel
- Garmin Fenix 8 Amoled 51mm Sapphire Carbon Gray DLC - Használt, karcmentes
- Bomba ár! Lenovo ThinkPad T470 - i5-G6 I 8GB I 256GB SSD I 14" FHD I HDMI I Cam I W10 I Garancia!
- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Fotós felszerelés - Stúdió lámpa / Softbox / Vaku
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest