Utolsó mondatoddal abszolút egyetértek, nekem sincs vele gondom.
Másik Ach-alapú rendszernek ott van pl. az EndeavourOS , Manjaro, ArcoLinux ... van választék bőven.

[ansible-core >= 2.15.3-1 update may require manual intervention

As of ansible-core 2.15.3, upstream moved documentation and examples to a separate dedicated repository (see the related changelogs).
This means that, starting from version 2.15.3 the ansible-core package will stop shipping documentation and a default configuration example under /etc/ansible/ansible.cfg.

Regarding the documentation, it is available online: https://docs.ansible.com/
As for the configuration file, as explained in the wiki, a base config can be generated with the following command:

ansible-config init --disabled > ansible.cfg

After updating from ansible-core <= 2.15.2-1 to >= 2.15.3-1, everyone using a custom global Ansible configuration file stored under /etc/ansible/ansible.cfg will have their configuration saved as a pacsave file.
To restore it, run the following command:

mv /etc/ansible/ansible.cfg.pacsave /etc/ansible/ansible.cfg

a Calam-Arch-al ugyan úgy grafikus felülettel lehet telepíteni.
csak hát a Magyarch magyar volt

Changes to default password hashing algorithm and umask settings

With shadow >= 4.14.0, Arch Linux's default password hashing algorithm changed from SHA512 to yescrypt.

Furthermore, the umask settings are now configured in /etc/login.defs instead of /etc/profile.

This should not require any manual intervention.

Ha nem hasznaljatok a systemd home service-t, viszont tele a log dbus-org.freedesktop.home1.service error uzenettel akkor az alabbi workaround megoldja a problemat [link]
NoExtract=usr/lib/security/pam_systemd_home.so
pacman -S systemd

[ Szerkesztve ]

Sziasztok,

Egy utóbbi frissítés után elromlott a videó gyorsítás a böngészőkben. Megfigyeltem egy nyílt meghajtós AMD videós gépen Firefoxon és Chromiumon is xfce/x11en, és egy inteles gnome/wayland gépen Firefoxon. Vlc mindkét gépen jónak tűnik.

Valaki más is figyelt meg hasonlót? Vajon ez majd magától megoldódik valamelyik frissítéssel?

Üdv

Arch - Windows 11 dual bootot akarok, a 2 rendszer 2 külön lemezen van, mindegyiknek saját efi partíciója van a saját lemezén. A windows bitlockerrel titkosított. Lehet ez kavar be, ugyanis amikor a systemd-boot menüből elindítom az arch systemd-boot wiki alapján lérehozott Windows bejegyzést, szépen el is indítja, de a bitlocker jelszóbekérő képernyőjén a jelszómező csillagokkal végig kivan töltve, a billentyűzetre nem reagál, tehát törölni és a helyes jelszót beírni nem tudom. Itt elakadtam. A windows.nsh efi script a linux efi partíciójára került, oda ahol a bootx64.efi és a shellx64.efi is van, a windows.conf indítóbejegyzést megfelelően felparamétereztem az arch systemd-boot wiki alapján, ötletem nincs miért produkálja ezt a viselkedést. Ha a systemd-boot menüből nyitok egy efi shellt(direkt benne hagytam a menüben a lehetőséget, hogy tudjam indítani a windowst, linuxot, az f11 bootoláskori szorgos nyomogatása helyett), és beírom windows.nsh akkor jól működik a bitlocker jelszóbekérő, üres jelszómezővel indul, bill. működik, be tudom írni a jelszót a windows elindul.
Van valami ötletetek hogy rendesen működjön a windows indító bejegyzés ?
Az arch wiki mellett még ez a leírás volt segítségemre: Link
Most cseréltem gépet, ahogy az aláírásomban is látszik, eddig a dual(trial) bootot OpenCore-val oldottam meg mert macOS is ment a gépen. Haswell-re viszonylag könnyű volt felrakni, 12.gen -re állítólag nehezebb, egyelőre nem akarok nekiállni új OC EFI-t készíteni, így a dual boot-ot systemd-boot al akarom megoldani.

Rájöttem a megoldásra, némi gondolkodás után, a -noconsolein opcíót kellett törölnöm innen:

Külső link a képhez
nincs kicsillagozva a bitlocker jelszómező, és engedi beírni a jelszót.
Tehát aki bitlockerrel használja ezt a megoldást, annak ez egy hasznos info.

[ Szerkesztve ]

StormOS ... Xfce felulettel. - Egy kis kedvcsinalo; [link] [link] [link]

Nálam most Most Pure Arch van teszting alatt a Plasma 6-os alfával. Ahhoz képest hogy alfa szinte használható.
Öreg hopper nem vén hopper - úgyhogy majd erre is ránézek! Ha jól látom nincs is fenn Distrowatch-on.

Eddig meg nem is hallottam rola.
Ezek kozott talaltam ra: [link]

Én felhagytam, az ilyen bloatware desktopok használatával, openbox+tint2 van, igaz sokkal macerásabb belőni hogy minden működjön, de frissítésekkor nincs vele probléma.

Sziasztok,

Egy régi gépre ráraktam az Archot. Amd Hd6450 videokártya van benne, nyílt radeon meghajtóval. Hardver gyorsított h264 lejátszásakor, vlc-ben és firefoxon is, fekete a film. Hang van. x11-en és Waylandonon is hasonló az eredmény. Amúgy a vainfo szerint minden jó, és a vlc és firefox szerint is jól megy a gyorsítás .
Esetleg valaki talált már megoldást erre a fekete kép problémára?

Üdv

Nekem régen HD6670-em volt, állandóan szürke színben jött be a konzol, utána kerestem és kiderült hogy ez egy általános régi radeonokat (ati meghajtót) érintő linux kernel hiba. Még 2018-ban lecseréltem a kártyát egy RX550-re,(úgy döntöttem nem kínlódok tovább a nagyon régi HD6670-el), az RX550 amdgpu meghajtóval megy, azóta nincs gondom linux alatt.

[ Szerkesztve ]

A nagyon régi ati/amd kártyák a "radeon" meghajtóval mennek. Olyat keress, ami amdgpu meghajtóval megy, azzal 99% hogy nem lesz gond.
Az arch eléggé friss kernelt használ, így szerintem ajánlott egy amdgpu meghajtót használó radeon beszerzése.

[ Szerkesztve ]

Régebben ez a kártya ment. Szerintem itt az van, hogy a grafikus meghajtóba, vagy mesába vagy a vaapi csomagba becsúszott valami bug.
Némileg szembemegy az Arch szellemével, de hogyan lehetne olyat, hogy a csomagokat (az összeset) egy meghatározott, korábbi időpontra ‘visszafrissíteni’? A grafikus rendszer elég sok csomagból áll, ha egyet-egyet kézzel (pacman -U) lebutítok akkor valami függőség elromlik, az biztos.
Aztán ha ez megvan, akkor a grafikus rendszer csomagjai szeretném ha nem frissülnének. Ilyen régi hardvernek a frissítések már többet ártanak mint használnak, ha menet közben jön a bug . Viszont azért volnának olyan csomagok is amik szeretném ha mindig naprakészek lennének.

Nem vagyok benne biztos, előbb megnézném a logokat, arch-on amúgy sem tanácsos a régebbi csomagok használata hosszú távon.

ennek vajh' mi baja lehet?

[root@vavatch lenry]# pacman -Syu
:: A csomagadatbázisok szinkronizálása...
core.db failed to download
extra.db failed to download
multilib.db failed to download
linuxkernels.db failed to download
hiba: nem sikerült a(z) 'core.db' fájlt letölteni a geo.mirror.pkgbuild.com helyről : OpenSSL/3.2.0: error:0A000438:SSL routines::tlsv1 alert internal error
hiba: nem sikerült a(z) 'extra.db' fájlt letölteni a geo.mirror.pkgbuild.com helyről : OpenSSL/3.2.0: error:0A000438:SSL routines::tlsv1 alert internal error
hiba: nem sikerült a(z) 'multilib.db' fájlt letölteni a geo.mirror.pkgbuild.com helyről : OpenSSL/3.2.0: error:0A000438:SSL routines::tlsv1 alert internal error
figyelmeztetés: too many errors from geo.mirror.pkgbuild.com, skipping for the remainder of this transaction
hiba: nem sikerült a(z) 'linuxkernels.db' fájlt letölteni a nhameh.ovh helyről : OpenSSL/3.2.0: error:0A000438:SSL routines::tlsv1 alert internal error
hiba: failed to synchronize all databases (letöltőfüggvénytár hiba)

de nem a pacman kehes, mert egy curl vagy wget sem működik

[root@vavatch tmp]# wget https://cdimage.https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.4.0-amd64-netinst.iso
--2024-01-07 10:15:35-- https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.4.0-amd64-netinst.iso
A hitelesítésszolgáltatói tanúsítvány („/etc/ssl/certs/ca-certificates.crt”) betöltve
cdimage.debian.org (cdimage.debian.org) feloldása… 194.71.11.173, 194.71.11.165, 194.71.11.163, ...
Csatlakozás a következőhöz: cdimage.debian.org (cdimage.debian.org)[194.71.11.173]:443… kapcsolódva.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [80]: Internal error
Nem lehet létrehozni SSL-kapcsolatot.