- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Magga: PLEX: multimédia az egész lakásban
- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- gerner1
- kemotox: Ki érti ezt?
- Luck Dragon: Asszociációs játék. :)
- Oldman2: A KOReader ebook olvasó program
- Elektromos rásegítésű kerékpárok
-
LOGOUT
Arch Linux topik
Új hozzászólás Aktív témák
-
teleahocipöm
senior tag
Úgy néz ki, hogy TV-n látható már a noti kijelzőjének egy része, (mivel a noti full-HD, a TV HD-ready) beállításokban egyáltalán nem látható semmi, ami arra utalna, hogy van még egy kijelző, így beállítani sem tudom.
-
teleahocipöm
senior tag
Intel HD Graphics 520 van a gépben. Bocs félreértettelek, azt gondoltam, hogy a GPU-nak több kimenetéből melyiken van... (ha több kimenete van egyáltalán, mert lövésem sincs
)
-
Frawly
veterán
válasz
teleahocipöm #6497 üzenetére
Terminálban kiadod a glxinfo parancsot. Bár szerintem anélkül is sejtened kéne, hogy milyen GPU van a gépben, prociba integrált IGP, vagy valami dedikált GPU, abból is Nvidia vagy AMD.
-
teleahocipöm
senior tag
Igen eddig nem igazán voltak nagyobb problémák, a Peppermint egy darabig jól futott a ezen a notin, de az idő múlásával egyre lassabb lett, most beraktam +4 GB ramot és egy 120 GB SSD-t és gondoltam kipróbálom újra a Manjarot, mert korábban tetszett, csak akkor ha jól emlékszem a wifi-s nyomtatót nem igazán kedvelte.
Nem látszik a kijelzők között. Most ismét megnéztem, korábban a "Noteszgép" alatt felbontás, a frissítési sebesség (60,1 HZ) volt olvasható, most pedig noteszgép helyett a
"default" a felbontás ua. frissítési sebesség (0,0 Hz) olvasható, változtak bizonyos dolgod, de mitől.. egy frissítési csomagot töltöttem le max.
A GPU kimenetet hol tudom megnézni? -
Frawly
veterán
Átváltott az Arch zstd-csomagtömörítésre. Igaz még nem minden csomagnál, csak azoknál, amik frissültek dec. 27. óta. 1300%-os gyorsulást ígérnek. Ennyi szerintem nincs, de érezhetően gyorsabban csomagolja ki a csomagokat, tehát tényleg jelentős.
(#6495) teleahocipöm: üdv újra a fórumon. Emlékszem 2014-2015 környékén több linuxos topikban láttalak, aztán nem írtál a fórumra hosszú ideig.
A HDMI kijelző látszik a kijelzők között? Milyen GPU kimenetén van?
-
teleahocipöm
senior tag
Sziasztok! Segítséget szeretnék kérni! Egy HP 250 G5 notin a Peppermint-et lecseréltem Manjaro-ra, rákötöttem a tv-re hdmi kábelen, de nem működik. Még beállításokban sem találtam semmit amint működésre bírnám vagyis annyit, amit mellékelt képen van. Pepper alatt működött a HDMI TV kapcsolat. Előre is köszönet!
-
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!
-
Laszlo733
aktív tag
válasz
samujózsi #6491 üzenetére
Nem, nem az volt a megoldás.
Fogtam az ARandR -t megnyitottam, majd beállítottam a kívánt elrendezést.
Az elrendezések alatt van a mentés másként, mely a /home/user/.screenlayout alá létrehoz egy default.sh fájlt. Ennek tartalmát kimásoltam és beillesztettem az .config/openbox/autostart.sh -ba. -
-
Shyciii
veterán
válasz
Laszlo733 #6485 üzenetére
A feh esetén trükkös a háttérkép, ugyanis az általad megírt parancs kevés. Ez kell az autostartba:
~/.fehbg & Ez állítja vissza minden egy betöltődéskor az általad már beállított háttérképet.Egyébként ez igaz a Nitrogen-re is. Ott is az autostartba kell az előző visszaállítása (nitrogen --restore &)
Conky esetén úgy indítsd el, hogy a teljes útvonal szerepeljen. Tehát pl:
conky -c "/home/shyciii/.conky/conky/myconky" &A monitor esetén az arandr nem fog menni az autostartban, mert az csak egy frontend. Helyette az xrandr-t tedd be az autostartba.
-
Laszlo733
aktív tag
Közben kicsúsztam az szerkesztési időből és lenne még egy kérdésem:
Notebook -ot használok és van rajta plusz egy monitor. Hogyan tudom beírni szintén az autostart fájba, hogy újraindítás uán a monitor kiterjesztett módban induljon el?
A noti felbontása 1366x788, míg a monitor 1920x1080. Az ARandR alatt manuálisan gond nélkül megy. -
Laszlo733
aktív tag
Sziasztok!
A meglévő KDE/Plasma mellé felraktam az Openbox -ot, de pár dolgot még így elsőre nem sikerült megoldani.
Amit sikerült:
A .config fájlban létrejött az openbox mappa melynek tartalma az autostart.sh, menu.xml, rc.xml
Az austarton belül sikerült a tint2 -öt és a volumeicont beírni, így azok újraindítás után is megmaradnak.
Ami viszont sehogy sem akar működni az a háttér betöltődése újraindítás után.
feh --bg-scale /home/linux/Pictures/Háttérképek/music.jpg létre is hozta a
home alatt .fehbg fájl, de az autostart -ba bárhogy is próbálom elhelyezni a parancsot sehogy sem indítja el.
A másik dolog, hogy hogyan tudom azt elérni, hogy az autostart -ban lévő conky ne az alap / fekete / conky -t indítsa el, hanem a KDE/Plazma alatt használt és konfigurált conky -t?
A saját mappában már meglévő myconfig.rs -t kell valahová bemásolni, vagy csak az útvonatal kell neki megadni az .config/openbox/autostart -ban? -
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
A Fluxboxot Openbox-klónnak tartom, pedig lehet fordítva van, a lényeg, hogy az összes ilyen *box egy kaptafára megy. PekWM-et, EvilWM-et nem ismerem.
@Shyciii: valóban az Openbox nem nyújt se panelt, se háttérképkezelést, míg az IceWM tudja ezeket. Asztalkezelést egyik kisebb WM sem tud, azt valami fájlkezelővel kell pótolni. Minden WM mögött más koncepció húzódik meg. A billentyűzetről irányítás egyébként valóban hatékonyabb, gyorsabb egy billkombót megnyomni, mint egérért kinyúlni, elvinni a célterület fölé, pontosan becélozni, és csak utána kattintani. Persze vannak kivételek, rajzprogramok, videóvágó szoftverek, stb., oda jobb az egér.
Rofi helyett én a dmenu-t használom, de a Rofi is jó, sőt, van ezekhez hasonló terminálos progi is, az fzf. Igaz csak ritkán dmenu-zök, mivel minden kicsit is gyakran használt progi be van drótozva billentyűkre, kb. 52 darabra. Így általában nincs szükségem név szerinti indításra.
-
Shyciii
veterán
F34R
PekWM és Fluxbox kicsit régen volt frisstíve ha jól emlékszem (anno azokkal is kacérkodtam, de aztán az Openbox lett a befutó). Tán 2018-ban utoljára az egyik, a másik tán még régebben. Az Openbox-ra meg pont ma jött egy újabb verzió.
Frawly
Csak részben nyújtják, mert pl nincs klasszikus értelemben vett asztal, így ikonokat sem lehet kipakolni, max háttérkép, meg conky ilyesmik. Hálistennek nekem ezek sem hiányoznak. Vagy bill kombóval indítok progit, vagy Rofi launcherrel. Annyira hozzászoktam ehhez, hogy a melóhelyen is kerestem olyan progit, ami Rofi szisztémát használja, így ott is ilyen elven használom már.
-
Frawly
veterán
válasz
Shyciii #6478 üzenetére
Igen, az Openbox és az IceWM szerintem az a két legsoványabb WM, ami egy klasszik desktophoz szokott felhasználónak is használható, hiszen DE funkciókat nyújtanak. Az ennél minimalistábban csak power userekenek ajánlhatóak. Jelenleg Gentoo-n nekem is Openbox van, igaz csak átmenetileg, amíg nem találok jobbat. Az Archon használt SwayWM-et dobnom kellett systemd-logind függőség miatt.
-
Shyciii
veterán
Köszi. Faccán működik (csak én a zloginbe tettem). Így már nem gond, hogy ha véletlenül kihagyok egy betűt az openbox konfigjából, és az egész felület elhal
Viszont így nézve az Openbox csak 52MB-ot foglal. Egészt kellemes ahhoz képest, hogy átmenet a full dm és a tilling wm között. -
Frawly
veterán
-
Frawly
veterán
válasz
#63718632 #6474 üzenetére
BÚÉK neked is. Erről az Obarun-ról még nem hallottam. Ez az S6-rc elég bonyolultnak tűnik. A Wikije alapján így kell benne szolgáltatásokat indítani:
66-tree -nE szolgáltatásfa
66-enable -t szolgáltatásfa szolgáltatásA szolgáltatásfának olyan nevet adsz, amilyet csak akarsz. A szolgáltatás neve meg elvileg lightdm.
Lehet előtte a régi login manager le kell tiltanod:
66-disable -t fája -S neve
-
#63718632
törölt tag
B.U.É.K mindenkinek!
Kezdjük az évet egy számomra érdekes kérdéssel. Szóval itt az utóbbi két nap olvasgatásai itt és a HUP hasábjain. Arra juttatott, hogy most épp egy Obarun-t instaláltam, mert hogy systemd mentes,...... ecetera.
Felhúztam egy Xfce4 környezettel és telepítettem a LightDM+Greeter csomagot, hogy az legyen a bejelntkezés kezelőm, ne a gyári (passz nem tudom, de nem szimpatikus valami).
Itt S6 init rendszer van, hogyan lehet aktualizálni a LightDM-et?
(Nem kerestem még rá, mert nem tudom merre induljak). -
Frawly
veterán
válasz
Shyciii #6471 üzenetére
A felhasználód ~/.bashrc-jének a végére ez megy:
if [[ "$(tty)" == "/dev/tty1" ]]
then
startx
fiA ~/.xinitrc-nek a végére meg
exec wm_indító_bináris
Így ha a tty1-en jelentkezel be, és azzal a felhasználóval, akkor a WM automatikusan indul. De csak akkor. Ha tty2-7-en jelentkezel be, akkor nem, és a tty1-en akkor sem, ha másik felhasználóval, pl. root.
-
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.
-
Shyciii
veterán
Np például a dhcpcd azért sincs benne, mert van aki nem használja. Pl én sem.
-
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.
-
cigam
titán
Úgy tűnik érdemes volt fent maradni olvasgatni.
Ha jól emlékszem a reboot után kellett a dhcpcd xorg xorg-xinit és az icewm. Aztán beröffent az icewm. Igaz még kell hozzá a startx, nincs DM. -
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.
-
cigam
titán
Wiki böngészés közben még ide is eljutottam:
5.2systemd-resolve not searching the local domain
Mivel a leírásból egy bötüt nem értettem, léptem is vissza az előző oldalra...Kíváncsiságból most bebootoltam a telepítőt, kábel helyett a wifi-t konfigoltam fel (ilyet még nem csináltam), és a legmeglepőbb, hogy sikerült. No és mit látok a wpa_supplicant leírásának vége felé?
Once association is complete, you must obtain an IP address, for example, using dhcpcd.
A dhcpcd wlan0 parancs hatására szépen összebeszélt a pihole-al, és így már tudom név szerint pingelni a helyi lan gépeit is.Érdekes amit az UEFI 64bites DOS-ról írtál, ezt tőled hallottam előszőr, hogy ezek az .EFI fájlok tulajdonképpen .exe-k.
Ja, és köszi a bíztatást!
-
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.
-
Frawly
veterán
válasz
samujózsi #6461 üzenetére
Azért lebeszélni sem beszélnék le senkit az Arch-ról. Ha nem is neki való még, próbálkozni nyugodtan lehet vele, meg akár használni, nem kell bohócnak lenni hozzá, igenis megéri használni. Csak akkor ne azt várjuk már el tőle, hogy egy sor vagy egy installer után pöccre minden úgy fog menni, ahogy Ubuntun megszoktuk. Ez nem Ubuntu, nem kiadás alapú, nem installeres, itt az embernek magának kell kiépítenie a rendszer minden elemét. Más filozófia, más rétegnek van szánva. Ennek ellenére használható kezdőknek is, nem egy kezdőről tudok, aki Arch-csal kezdett. Persze teljesen kezdőnek inkább a Manjaro-t ajánlanám, de cigam kolléga van annyira régen jelen a linuxos topikokban, hogy annyira kezdőnek semmiképp nem minősül. Szóval gyűrődni ajánlott vele, minden napra fog tartogatni ilyen új ismeretet, ma a dhcpcd-ről, holnap valami másról, végül az ember így ismeri meg a Linuxon alaposabban.
Emlékszem, hogy pl. ubyegon kollégának is sokkoló volt, hogy Archon alapból nincs fent a mesa csomag, mikor az Mint-en alapból van. Persze azt hozzá kell tenni, hogy Archon azok a dolgok, amiknek kell, pl. kompozitorok, nagyobb DE-k, stb., behúzzák függőségnek. Ez a dhcpcd is azért nem probléma, mert ahogy elkezd valaki Gnome-ot vagy KDE-t vagy hasonlót telepíteni, az mindent behúz függőségnek, login manager, X.org, mesa, Network Manager, ez utóbbi behúzza a dhcpcd-t, meg minden görcsöt, ami kell neki, nem kell semmit nyomozni, hogy úristen, mi is kell nekem.
Ezt a mi is kell nekem kérdést azoknak kel végiggondolni, akik minimalista WM-mel telepítik, mert ott se háttérképkezelés, se panel, se launcher, se hálózatkezelés, se kompozitálás, se semmi nincs, mindenről az embernek magának kell gondoskodnia, meg előre tudnia, hogy mi kell neki.
-
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
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.
-
cigam
titán
Na de én honnan tudjam mi kell nekem? Lehet nem nekem való az Arch, mert itt elöbb tudni kell mit akarok és hogyan?! Mert olyan mélységében nem ismerem a rendszert. pl. A wiki egy eldugott zugában olvastam véletlenül azt is, hogy az os-prober csak akkor veszi észre a többi oprendszert, ha fel van csatolva. Ezt is most tanultam meg.
Próbálom az ilyen apró (tudás)szilánkokat egy egységesz egésszé formálni, de nagyon nehéz. pl. a telepítő videók/leírások többsége elavult, nekem meg szükségem lenne egy szájbarágósabb leírásra. Egyrészt azért, hogy meglegyen a sikerélmény, hogy működik, másrészt megtanulhassam belőle, hogyan működik. Viszont amikor ilyen mellékvágányra futok(vagy inkább szakadékba) az elég frusztráló...
Az EFI-ről ne is beszéljünk, még hátra van a feketeleves. Lassan kihal alólam a BIOS-os laptopom, és az UEFI lesz a következő nagy falat. -
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.
-
-
cigam
titán
Arra gondoltam, hogy ha feltettem a base linux linux-firmware csomagokat, akkor minden szükséges dolog meg lesz a használathoz.
Ezért próbáltam dhcpcd nélkül, hogy már van benne "gyárilag" egy működő megoldás.
A /etc/systemd/network/20-wired.network fájlt azért hoztam létre, mert nélküle nem éleszti fel azt az interface-t. Perze lehet ezt is másként kellene alapból, de a wiki telepítőjét annyira megnyírbálták, hogy az alapján egy angolul 8sem) értő kezdő simán kihagyja a bootloader telepítését.Most vettem észre az elején a bekeretezett részt:
The installation image enables dhcpcd
Hát de baszki akkor ha nem is base-be, de a linux-ba illene betenni!
Holnap nekiugrok megint de talán okosabban -
Frawly
veterán
válasz
#63718632 #6453 üzenetére
Imho a Gentoo nem éri meg mindenkinek. Még az is elképzelhető, hogy arra jutok, hogy nekem sem éri meg a beletett munkát. Nem tudom még, nem tartom valószínűnek, mert már így is volt pozitív hozadéka, egyszerűsödött az initrendszer, egyszerűsödött a boot, már tanultam belőle egy csomó mindent, hogy konfigurálunk fordítandó kódot, mely csomagok bloatak igazán. Ez az, amit nem tudsz addig, amíg meg nem próbáltad a Gentoo-t.
Archra átállni viszont teljesen megéri, ezt több év archozással a hátam mögött mondom. Szerintem simán jobb, mint akármelyik másik bináris disztró. Azért nincs telepítője, mert rád bízzák, hogy milyen funkcionalitást milyen megoldással valósítasz meg. Te döntöd el, hogyan bootolsz meg milyen hálózati kapcsolódásos megoldással éred el a netet, milyen grafikus felületet és protokollt használsz, stb.. Egyedül csak az van Archon eldöntve, hogy systemd-s és initramfs-ses. Minden mást meg tudsz változtatni (igazából ezt a két kötelező elemet is ki tudod belőle hackelni), csak azt a csomagot kell feltegyed, amire valóban szükséged is van. Az is nagyon jó, hogy rolling, friss csomagokkal, de ahhoz képest mégis elég stabil, nem kell distro-upgrade-ekkel szívni kiadások között, meg elavult csomagverziókkal küzdeni. Az Arch még nem über geekség.
Bár eddig nekem a Gentoo sem tűnik sokkal nagyobb számnak. Egyedül az macerás, ha valami spéci fordítási opciót akarsz, pl. hogy mit forgass bele a szoftver kódjából a bináris szoftverbe, vagy a legeslegfrissebb verziókat. Ott lehet vele szívni, de amúgy nem tűnik nagyobb számnak az Archnál. Na meg az egy kicsit kellemetlen, hogy állandóan várni, míg kódból fordul valami le, ha nincs izom géped, akkor nagyobb csomagoknál szívás annyit várni. Persze, míg fordul a kód, addig használhatod másra a gépet, de azért sokkal kellemetlenebb ahhoz képest, mint egy kész bináris csomagot felpasszintani.
-
#63718632
törölt tag
A Gentoo topik újra fog éledni, úgy gondolom. Egy darabig úgy gondoltam, hogy ha egyszer olyan szintre érek, ami már elfogadható számomra. Az az Arch tiszta telepítés lesz, viszont a Gentoo-s tapaszatlataidból azt szűröm le, hogy oda fogok kilyukadni a legvégén, amit sok évvel ezelőtt über geek-nek gondoltam. Amikor valaki már Gentoo Linux felhasználó.
-
Frawly
veterán
válasz
samujózsi #6451 üzenetére
Ja, pont ezt mondom én is, hogy nem kell, de azért a disztrók erőltetik, mert valakinek hátha kell alapon, rá van tukmálva mindenkire. Az a baj, hogy a systemd tele van ezekkel, ha kell, ha nem, le van nyomva az ember torkán, pedig vagy szüksége sincs rá egyáltalán, vagy ha van, sokkal egyszerűbb, könnyebben konfigurálható formában is rendelkezésre áll. Aztán ilyen flame-topikokban nem szokták érteni, hogy mi a baj a systemd-vel. Többek között az ilyen húzások.
-
-
samujózsi
senior tag
válasz
vargalex #6448 üzenetére
Arch-on még nem futottam dns problémába, de ubuntun hasonlókkal nyűglődök hosszú ideje. A dhcp ad neki egy dns-t, de lokálisan a systemd resolvert használja mindenki, az meg hol foglalkozik a dhcp-n kapott szerverrel, hol nem. Úgy tűnik, ez systemd hülyeség.
Sajnos nem emlékszem, hogy kerültem ki a dolgot, de valami systemd konfigba kellett belepiszkálnom. -
-
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.
-
cigam
titán
Ez alapján csináltam egy linket
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
Ill. itt meg ezt tanácsolták
/etc/systemd/network/20-wired.network
[Match]
Name=enp9s0
[Network]
DHCP=ipv4
A resolvectl status szerint a pihole-t kapja dns-nek az enp9s0, de az /etc/resolv.conf-ban nameserver-nek a 127.0.0.53 szerepel. Ami elég fura. -
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 -
cigam
titán
válasz
vargalex #6442 üzenetére
Köszi!
Kellett hozzá asystemd-resolved
is, és már működik is az internetes címek névfeloldása. A helyi háló neveit valahogy nem akarja
...1 a router, ...2 a pihole DHCP-vel.
Másik gépről tudom pingelni név alapján az Arch-os gépet, de én nem tudom a helyi háló gépeit név alapján elérni. Mindenikre azt írja: Átmeneti névfeloldási hiba.
Van ötlet hogy mi kell még? -
Frawly
veterán
válasz
samujózsi #6440 üzenetére
Neked ez volt az első, és utánaolvastál a telepítési útmutatóban. Aki viszont régebb óta archerkedik, az 17 év alatt már megszokta, hogy a base csomagcsoport tartalmazott egy kulcsra kész alaprendszert, fordításhoz, hálózatkezeléshez, configfájlok szerkesztéséhez. Aztán sok ember vagy emlékezetből telepít vagy sok kezdő megnéz olyan tutorial videót, mondjuk a distrotube YouTube-csatornán, ahol még a régi módszert mutatják be telepítésnél, és ott esnek pofára, hogy nem működik, mert se nano, se kernel, se semmi.
Egyébként itt az lett volna a megoldás Archék részéről, hogy megtartják a base csomagot, és base-new vagy base-minimal néven létrehoznak egy másik csoportot, amit csak haladóknak ajánlanak. Vagy a régi megtartották volna base-old vagy base-legacy néven, és mindenki könnyen aktualizálta volna a saját telepítési útmutatóját.
Megértem a döntésüket, hogy miért nyirbálták meg a base-t. Az Arch filozófiája a minimalizmus, keep it simple, csak az kerüljön fel a rendszerre, amit használsz is. Na már most a base csoport (bár nem volt kötelező használni, de leírások miatt mindenki használta) felnyomott egy rakat csomagot, linux kernel, nano, vi, stb., holott lehet a fele szükségtelen volt, mert valaki eleve a linux-lts vagy linux-zen vagy hasonló spéci kernellel akarta telepíteni, meg nano vagy vi helyett mással. Ezért kiszedtek minden felesleget, ergo szerintem teljesen kinyírták a base csoportot. Ez jó hír volt néhány minimalista advanced usernek, hogy többé az Arch telepítést nem úgy kell folytatniuk, hogy leszedegetnek felesleges csomagokat (noha a base-t használni eddig sem volt kötelező), viszont cserébe a kezdőket, meg a régi leírásból telepítőket csúnyán megtréfálta.
-
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..
-
cigam
titán
Létezik hogy az alap rendszer (base linux linux-firmware) nem teszi fel a dhcpcd-t? Mi van helyette? A telepítő wiki oldalán nem részletezik (vagy nem kattintottam rá)
-
Shyciii
veterán
Találkozott már valaki ilyen furcsa jelenséggel? Ma bekapcsoltam a notim, és látom, hogy bár a wifi-re felcsatlakozott, mégse kap ip-t. Természetesen más eszköz (mobilok, tv-k) kapnak ip-t. Kábellel csatlakoztatom, így már kap ip-t. Mivel semmit nem állítgattam mostanában, így kizártam az ügyködésem, viszont eszembejutott, hogy 2-3 napja a frissítéskor volt benne linux kernel, linux firmware, és networkmanager is. Nosza mindhármat az előző verzióra tettem, majd reboot. Így már kapott a wifi is ip-t. Szuper. No akkor egyesével visszarakom a frissítéseket, hogy lássam melyik rontotta el. Egyenként felraktam mind a hármat, és most is kap ip-t a wifi...Lehet hogy mikor mindhármat egyszerre rakta fel, akkor elbaxott valamilyen bejegyzést?
toxin2
Nagyon baba lett, ügyes vagy! Majd megsasolom én is működés közben, bár erre szerintem szilveszter előtt lesz csak esélyem. -
toxin2
tag
Sziasztok.
Minden kedves fórumtársamnak Boldog Karácsonyt.
Arch Linux használóknak, érdeklődőknek
egy friss live szerkesztésem:
https://www.youtube.com/watch?v=cgKpTcCAoeo -
_Dumber_
őstag
Ha a "Kevésbé biztonságos alkalmazások hozzáférése" beállításra gondolsz akkor azon már túl vagyok. Más alkalmazás (inboxer, kmail, kontact, korganizer) hozzáfér az accountomhoz, csak épp az "online accounts" nem.
Hidd el én is szeretem a terminalt. Nagyon is sokat használom, mert tudom hogy ott szabadabban beállíthatok sokmindent. Ezt is probáltam terminálból indítani: kcmshell5 kcm_kaccounts , de ott sem közlékenyebb. Illetve közli, hogy minden rendben, ennek ellenére nem látszik a kapcsolat.illetve ezt adja indítás képpen:
[dumber@Gabor-HP] / % kcmshell5 kcm_kaccounts
org.kde.kcoreaddons: Error loading plugin "kcm_kaccounts" "Az osztott függvénykönyvtár nem található."
Plugin search paths are ("/usr/lib/qt/plugins", "/usr/bin")
The environment variable QT_PLUGIN_PATH might be not correctly set
file:///usr/lib/qt/qml/org/kde/kirigami.2/Page.qml:301:18: QML QQuickItem: ScrollBar must be attached to a Flickable or ScrollView
"google"
Looking for plugin ""
Starting auth session with "oauth2"
Info:
Id: 4
caption: "google"
owner: ""
userName: ""
Received session response
Info:
Id: 4
caption: "google"
owner: ""
userName: ""Elején hiányol egy könyvtárat, de nem mondja meg, hogy melyiket.
A QT_PLIGIN_PATH-ra meg ez a helyzet:[dumber@Gabor-HP] /usr/lib/qt/plugins/kcms % locate kcm_kaccounts | grep /usr/lib
/usr/lib/qt/plugins/kcms/kcm_kaccounts.so
[dumber@Gabor-HP] /usr/lib/qt/plugins/kcms % echo $QT_PLUGIN_PATH
/usr/lib/qt/plugins/kcms/
[dumber@Gabor-HP] /usr/lib/qt/plugins/kcms %Ferltettem egy Chakra-t virtualboxba. Ott sem működik. ellenben ott már van bejegyzés az ablakban, csak a bejegyzésnek nincs neve, így működni nem működik.
Arra már rájöttem, hogy a ~/.config/signond/signon.db filban tárol. Töröltem, majd űjra végigvittem a bejelentkezést. A fiile újra létrejött, de jobb nem lett. Jogokkal is játszadoztam, eredmény 0.
Ötletem sincs. Max, hogy még mindig bugos..
-
Frawly
veterán
válasz
_Dumber_ #6430 üzenetére
Na, ez a fajta szívás nem hiányzik nekem, azért nem használok többé ilyen bloat megoldásokat, mint ezek a Kakrámik, KDE, Dolphin, stb.. Inkább terminálban csinálok mindent, inkább root jogozok, inkább szerkesztek konfigfájlokat, de terminálban legalább látni, hogy mi a hiba, és sokkal egyszerűbb is elhárítani őket.
Ami tippem lenne a problémád megoldására: ideiglenesen állítsd be a Google-nél, hogy minden alkalmazás és eszköz korlátlanul, engedélykérés nélkül hozzáférjen az accountodhoz. Majd próbálj újra kapcsolódni a lépések alapján. Ha így megy, akkor visszacsinálod a korlátlanra engedélyezést (bekapcsolva hagyva biztonsági kockázat), tehát újra egyéni engedélyezési alapon lekorlátozod, és tudni fogod, hogy az engedélyezéssel van a baj.
-
_Dumber_
őstag
Nem ez alapján, de ugyan így... csakhogy a "You will get back to the former dialog:" utáni 2 kép nálam már nem ugyanúgy néz ki. Hiányzik a xxx@gmail.com bejegyzés. Nincs semmi benne. Olyan mintha vagy nem futna végig a setting, vagy nem tudná hová lementeni, vagy ha le is menti nem olvasná be a kapcsolatokat az ablakba.
Pedig az írja, hogy:
"The autentication process is complete. You may now close..."Logokat erről merre találok?
-
samujózsi
senior tag
Wine... Summer wine...
-
Frawly
veterán
válasz
samujózsi #6424 üzenetére
Nyugi, ezeket a disztrós meg linuxos neveket senki nem tudja kimondani, még Amerikában sem. Össze vissza Díbiön-öznek meg Júbántuznak a Debiön és Úbuntu helyett, ahogy mondani kéne. Vagy a Gnome-ót hol Nóm-nak, hol Gnóm-nak, hol gö Nóm-nak mondják. Még maga a Linux név sem egyértelmű, mert a legtöbben a bevett Linöksz-ként ejtik, de lehet Linuksz-nak és Lájnöksz/Lájnuksz-nak is ejteni, Linus angolosított neve alapján.
A Gentoo-t és sokszor Gentó-nak mondom, pedig Dzsentú-nak kéne. Ez állítólag valami gyorsan úszó pingvinfajtáról kapta a nevét, de nagyon gyanúsan a Gen2-őt lehet beleérteni. A Mate sem Máte, sem nem Mé(j)t, hanem Ma Té.
De például a Wine-t is vine-nek mondom rossz megszokásból, mikor ~vájn-nak kéne.
-
Lenry
félisten
válasz
samujózsi #6424 üzenetére
Arch - ív, boltív
nézd meg a régi logókat, és megérted
-
samujózsi
senior tag
Mondjátok, az Arch Linux neve mit jelent?
Tegnap véletlenül egy magyar wikit sikerült megnyitnom és bevallom férfiasan, meglepett, hogy a -val/-vel ragozásnál így írták, hogy Arch-csal... ugyanis azt nem tudtam, hogy ez önálló szó, azt hittem, valami rövidítés (archive, architecture stb.) és magamban következetesen h-val mondtam... eddig.
-
_Dumber_
őstag
Sziasztok!
Kellemes Ünnepeket mindenkinek.
Adott egy ARCH + KDE telepítve. (kézzel), KIO és Kaccount elvileg teljesen felrakva.
Szeretnék egy gdrive accountot beállítani. Akár a Dolhinból akár a systemsettins-online accountsból indítom a csatlakozást a következőket tapasztalom:
Google account kiválasztva - csatlakozási folyamat végigmegy - email megjön - engedélyezés megtörténik, az ONLINE ACCOUNT ablakban mégsem jelenik meg a kapcsolat.
Van valakinek ötlete, hogy miért?
Hová menti ezeket a beállításokat (csatlakozási fiókokat) a rendszer?
Én már arra is gondoltam, hogy abba a könyvtárba nincs írásjogom...
Találtam ugyan BUGriportot, de nem erről. Úgy látszik a kaccount +kio párossal folyamatosan problémája van a KDE group-nak. -
toxin2
tag
Debianon megszokott, egyszerű volt számomra a systemback.
Mivel arch-on csak megszorításokkal megy nálam, és
egyszerűbb volt az archiso-hoz rendszermentő konfigot
készíteni, mint átírni az egész systemback forrást,
erre esett a választás. Ha valakinek live-iso mentés kell
a futó rendszeréből arch-on, megtalálja aurban:
archsysback, aud2u
ps.: manjaron is megy, teszteltem. -
toxin2
tag
Te tudod.
Rendszerindítás után a grub átadja a vezérlést a kernelnek,
azután u.úgy nem fog semmi erőforrást. Arch-on grub-git-et használok,
uefivel, mert a jelenlegi vasamnak az kellett. Lefordult, fél éve egyszer sem
kellett ránéznem. Itt jön be amit írtam. Csak azért, hogy minimalista rendszerem
legyen, minimalista bootmanagerrel, nem fogok napokat-heteket
szívni minden frissítéssel, meg fordítgatással. A gépet használni
akarom, nem OS fordításra meg optimalizálásra akarom használni
az időm 30-40%-ában. Ha neked erre van időd, legyen. Használok
MBR-t, UEFI-t vegyesen, évek óta. Laptopon nálam általában titkosított
fájlrendszer van, sima uefi boot már ezen elhasal. Nason raid van, azon is
elhasal. Egy Linux rendszer konfigurálása így is sok idő,
felesleges önszivatásnak tartottam az arch-ot is debian után,
de érdeklődő vagyok.Úgyhogy gentoo nálam sosem lesz.
Inkább próbálok fejlesztgetni a magam szintjén, és amit tudok
átadni a közösségnek. (ami kevés időm erre jut)
Szép estét neked, béke. -
Frawly
veterán
A GRUB egy nagy monstum. Ezt akkor veszed észre, ha pl. Gentoo alatt forráskódból fordítod, valami ~750 MB a forráskódja, és nálam az a gép, ami a defconfigos legújabb kernelt ~12 perc alatt fordítja, a GRUB-ot 25-30 percig forgatta. És ezt minden frissítéskor el kell játszani.
Ehhez képest az EFI stub boot csak egyetlen sor bejegyzés az UEFI BIOS-ba. És egy szabvány kernelbinárist indít, ami egyben EFI bináris is. Annyira egyszerű, mint a szög, nem kell hozzá adott esetben semmit telepíteni, semmit frissíteni, 0 dolog van, ami egy frissítéskor eltörhet, 0 erőforrást használ. Ugyanis az UEFI már egymagában is egy bootmanager, felesleges mögé beláncolni egy másikat. Ezeknek az egyszerű megoldásoknak szépsége van, ezt csak akkor érted meg, ha kipróbálod, megérted a működésüket.
Van itt egy kolléga, ubyegon, ő mindenáron ragaszkodik a Legacy BIOS MBR boothoz, MBR-hez, meg a GRUB-hoz. Kétszer megpróbált UEFI bootot is, de a szerencsétlen grafikus telepítők vagy elcseszték neki, vagy a HP laptopja nem szabványos UEFI-jű. Ebből levonta azt a következtetést, hogy az UEFI ×4r, egy átláthatatlan fekete mágia, ő azt soha többet. Az a baj, hogy az UEFI-val sokaknak az a baja, hogy nem értik meg, meg rosszul próbálják használni, és ez kudarcélményhez vezet, és máris rohannak vissza a jól megszokott MBR + GRUB-os megoldásokhoz. Nagy úr, ha valamit ismersz és mindig beválik. Sokan így ragadtak XP-n is, meg majd most 2020 januárja után Win7-en is. Pont ilyen indoklással, hogy régen jó volt, most is megy, minek piszkálni.
Már pedig ha valaki egy minimalista rendszert épít, akkor miért ne legyen a bootolás is modern, meg parádésan egyszerű? Ha GRUB kell, feltelepítek 2 perc alatt az Ubuntut, azon lesz minden szabvány megoldás out of the box, GRUB, systemd, Gtk + Gnome, X.org + Wayland, meg stb.. Csak akkor szopó, ha ezek többjére épp nincs szükségem, akkor minek tenném fel? Ubuntut feltelepíteni Áltsulis Pistike is tud, abban nincs semmi művészet, meg informatikai tudás.
-
toxin2
tag
Most őszintén, 2019-ben erőforrás-hiányra panaszkodni
egy linux/bsd rendszernél? Ahol nem zfs-t használsz,
kb. 4GB rammal meg egy c2d procival is hasít a rendszer.
Ez kb mindenkinek megfizethető kategória.
Efi bootnál nem a nehézséggel (tudásszinttel) van baj, mert kb. pár perc
megkeresni, elovasni, beilleszteni a konfigokat a megfelelő
helyre. Az "egyszerű" megoldás pedig az, amit jól ismersz.
Azzal boldogulsz a leggyorsabban. Manapság pedig
(számomra legalábbis) ez a lényeg. Ha valamit meg lehet
oldani gyorsan, és a maradék időmben számomra
fontosabb dolgokat is el tudok végezni. Sajnos mindenki
ideje véges, mindent megismerni fölösleges és lehetetlen.
Ez nem leragadás v.minél, hanem realista nézőpont. -
Frawly
veterán
Ez nem mazochizmus. Nincs semmi baj a GRUB-bal, de van egy tudásszint, ami fölött meg tudsz lenni nélküle, teljesen el tudod hagyni, és jóval egyszerűbb megoldásokat tudsz használni helyette, amik nem törnek el frissítéskor, és század annyi erőforrást sem esznek. Lásd előző hozzászólásom.
Ráadásul ezeket a minimalista EFI stub és EFI systemd bootos megoldásokat nem is nehéz megcsinálni. Szívni csak eleinte kell vele, amíg meg nem érted hogy működik, meg ki nem tapasztalod, onnantól viszont egyszerűbbé válik, mint a GRUB.
Ezért nem szabad egyféle megoldásnál leragadni, csak azért, mert azt megszoktad, meg már érted.
-
Frawly
veterán
válasz
samujózsi #6403 üzenetére
Ja, vagy az efibootmgr-rel kell a régi bootbejegyzést törölni és újat csinálni a helyére, vagy az UEFI BIOS-ban kell új bejegyzést kézileg felvenni, vagy ebben az EFI shellben kell indítani a kernelt, és ott mögé írni a paramétereket. Ez az ára, ha nincs bootmanager, de cserében nagyon egyszerű, bloatmentes megoldás. Egyébként a leírásodból úgy vettem észre, hogy ott rontottad el, hogy nem látta az EFI partíciót.
A systemd EFI boot annyiból könnyebb, hogy az nyújt egy minimális menücskét, ahol már nem is tudom milyen billentyűre lehet szerkeszteni a bootparamétereket, ahogy GRUB-ban. Meg kényelmesebben be lehet vele bootolni több OS-t és kernelt.
A GRUB-ot viszont nem szoktam erőltetni, ha nincs rá szükség. Az csak olyan speciális esetekben kell, ha ZFS partícióról akarsz bootolni, meg RAID van vagy hasonlók. Átlag desktop linuxnál kb. 0 értelme van, ha mindenből deafult beállítást használ valaki.
Azért mondtam, hogy minden megoldásnak megvan a maga előnye, maga rugalmassága vagy egyszerűsége, de ezek egymást kizárják, valami vagy bloat, vagy minimalista, vagy egyszerű, de akkor rugalmatlan, vagy bonyolult, de akkor rugalmas, többféle felhasználási kört is lefed. Ez mindenkinek egyéni, hogy mire van szüksége, mire használja, ehhez milyen megoldást választ, ezért mennyi bloatságot hajlandó fizetni.
Sőt, QEMU-n még olyat is lehet, hogy EFI partíció sincs, hanem a virtuális gép UEFI BIOS-ába az EFI kernel binárist a host felöl adagolod be, qemu paraméterként, és azzal indul a rendszer. Ennek csak az az egy kényelmetlensége, hogy a kernelt akkor a host gépen kell forgatnod.
-
toxin2
tag
Aki kevésbé szeretné magát kínozni az arch telepítéssel
így karácsony előtt,azok számára pár régebbi ('19 július)
Arch live-iso magyar nyelvű Zen installerrel:
https://drive.google.com/open?id=1YHOqm8K6Fj4m_tjivYt5bEdL9dyce0-h -
toxin2
tag
válasz
samujózsi #6403 üzenetére
Mi az a "menü nélkül működik"? Nem értem,
grubot nem raktál föl? Esetleg direkt?
Rakj föl egy grubot, megoldódnak a
"macerás módosítani a kernel paraméterein"
gondjaid.# pacman -Sy grub
# mkdir /boot/EFI
# EFI=`fdisk -l |grep EFI |cut -d' ' -f1`
# mount $EFI /boot/EFI
# grub-install --target=x86_64-efi --efi-directory=/boot/EFI --bootloader-id="Arch Linux"
# grub-mkconfig -o /boot/grub/grub.cfgKb. ennyi.
-
samujózsi
senior tag
Tűzfal (na jó, elsősorban packet filter) céljára mit szokás használni arch linuxon?
Ubuntun ott a ufw (sokáig azt hittem, UFW=Ubuntu FireWall), máshol a firewalld-t szoktam látni. Arch-on van valami ajánlott, amire a disztribúció fejlesztői jobban ráfeküdtek? Vagy tökmindegy mit használok?
-
Siriusb
veterán
Xorg cleanup requires manual intervention
In the process of Xorg cleanup the update requires manual intervention when you hit this message:
:: installing xorgproto (2019.2-2) breaks dependency 'inputproto' required by lib32-libxi :: installing xorgproto (2019.2-2) breaks dependency 'dmxproto' required by libdmx :: installing xorgproto (2019.2-2) breaks dependency 'xf86dgaproto' required by libxxf86dga
when updating, use:pacman -Rdd libdmx libxxf86dga && pacman -Syu
to perform the upgrade. After the update it will be safe to also remove the "xorgproto" package. -
Frawly
veterán
válasz
samujózsi #6400 üzenetére
Elvileg, amiket írtál, azokat jól csináltad pedig. A hiba abban lehet, amit nem csináltál lépésként. Azt viszont nem értem hogyan kapsz UEFI shellt. Ha nem is bootol a cuccos, akkor is egy bootmenüt kéne visszaadnia, hogy válassz másik bootmeghajtót.
Próbálj meg kézzel, Esc megnyomására előhívott UEFI-ben, rámenni a Boot Manager menüben az EFI internal shellre. Ebben kézileg kezdesz megint navigálni:
fs0:
vmlinuz-linux initrd=initramfs-linux.img root=PARTUUID=bla-bla rwÍgy mit ad vissza?
Új hozzászólás Aktív témák
- Amlogic S905, S912 processzoros készülékek
- Rengeteg pénzt kapott az USA-tól az Intel, de Trump kért cserébe valamit
- Chieftec játék értékes nyereményekkel!
- Milyen videókártyát?
- EAFC 25
- Formula-1
- PlayStation 5
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Hardcore café
- Szuper Szigettel futott be a HyperOS 3
- További aktív témák...
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Assassin's Creed Shadows Collector's Edition PC
- Eladó Steam kulcsok kedvező áron!
- Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával - Nint.hu
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Telefon felvásárlás!! Xiaomi Redmi 9, Xiaomi Redmi 9AT, Xiaomi Redmi 10, Xiaomi Redmi 10 2022
- Eladó Lenovo ThinkCentre M910q i7 16GB / 12 hó jótállás
- Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! Honor 90 Lite/Honor 90/Honor Magic5 Lite/Honor Magic6 Lite/Honor Magic5 Pro
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest