-
GAMEPOD.hu
Arch Linux topik
Új hozzászólás Aktív témák
-
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?
-
-
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. -
samujózsi
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?Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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.
[ Szerkesztve ]
***** Linksys WRT160NL ***** http://www.gubamm.hu/ *********************************** ***** OpenWRT telepítési útmutató *****
-
toxin2
tag
válasz samujózsi #6407 üzenetére
efistubot nem ismerem. grubot szeretem a
live cd-imet pedig refind-efi/syslinux segítségével
készítem. Grub nagyon jól konfigolható,
legtöbb konfigot képes indítani (iso-t is)
ergó NEKEM ez marad.***** Linksys WRT160NL ***** http://www.gubamm.hu/ *********************************** ***** OpenWRT telepítési útmutató *****
-
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***** Linksys WRT160NL ***** http://www.gubamm.hu/ *********************************** ***** OpenWRT telepítési útmutató *****
-
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.
[ Szerkesztve ]
-
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.
-
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.***** Linksys WRT160NL ***** http://www.gubamm.hu/ *********************************** ***** OpenWRT telepítési útmutató *****
-
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
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.[ Szerkesztve ]
***** Linksys WRT160NL ***** http://www.gubamm.hu/ *********************************** ***** OpenWRT telepítési útmutató *****
-
samujózsi
tag
-
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.[ Szerkesztve ]
***** Linksys WRT160NL ***** http://www.gubamm.hu/ *********************************** ***** OpenWRT telepítési útmutató *****
-
_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. -
samujózsi
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.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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
[ Szerkesztve ]
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
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.
[ Szerkesztve ]
-
samujózsi
tag
Wine... Summer wine...
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
_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?
-
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
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..
-
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***** Linksys WRT160NL ***** http://www.gubamm.hu/ *********************************** ***** OpenWRT telepítési útmutató *****
-
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. -
cigam
félisten
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á)
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
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..
-
samujózsi
tag
Igen, nekem ez már elsőre ilyen volt, szóval számomra az a meglepetés, hogy van akinek meglepetés
Mondjuk első körben anyáztam egy sort miatta, dehát fapados telepítő, legyen meg az öröme.Szerk: ja, bocs, látom, más is megírta...
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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.
[ Szerkesztve ]
-
cigam
félisten
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?Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
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[ Szerkesztve ]
-
cigam
félisten
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.Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
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.
-
vargalex
félisten
Azon az IP-n pont a systemd-resolved válaszol. Azaz most az a DNS szervered és gondolom nem forward-oldja a helyi kéréseket a pihole felé.
Azt nem értem, hogy miért kellett neked, ha a DNS szerver címe jön DHCP-n.
Pontosan milyen config-ot állítottál be?[ Szerkesztve ]
Alex
-
samujózsi
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.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM