Ebben a leírásban külön van az efi és a boot partíció, én jobban szeretem ha egybe van. A youtubeon vannak LUKS Arch telepítési videók, de többnyire Grub-osak, nem tudom miért ragaszkodnak annyira a Grub-hoz, mikor a systemd-boot sokkal egyszerűbb, mondjuk systemd mentes rendszeren érthető, de itt Arch LUKS telepítési videókról van szó, nem az Arch egy systemd mentes forkjáról ahol érthető ha Grub-ot használnak. Artixon én is Grub-ot használok, efistub meg hasonló csak uefi nvram-ba író megoldások jöhetnének még szóba Grub helyett, de ha átrakom a lemezt egy másik gépbe akkor már nem bootolna mert a másik gép uefi-jében értelemszerűen nincs ott a bejegyzés.
Egyelőre a jövő zenéje lesz a titkosított ökoszisztéma, mert csak akkor van értelme ha minden adatomat letitkosítom, a külső lemezeken levőket is, a külső lemezeket valószínűleg bitlockerrel oldom majd meg, hogy win alatt is használhatóak legyenek. Linux alá van bitlocker megnyitó tool, csak nem tudom mennyire stabil.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Az efistub nagy királyság, annak a lényege, hogy a kernel közvetlenül .EFI binárisként bootol, nincs semmilyen bootmaganer (az UEFI egymagában is egy bootmanager). De az efistub-ot nem támogatja sok nem szabványos gyártói UEFI, meg ha initramfs, titkosítás, stb. van, akkor vagy nehézkes lehet, vagy lehetetlen.

Én systemd nélküli disztrókon lehetőleg efistub bootot használok, systemd-s disztrókon systemd-bootot, mert az is még kellően egyszerű. GRUB-ot csak akkor tennék fel, ha valami RAID-ről, egzotikus partíciótípusról, spéci titkosítós mókáról kell bootolni, vagy MBR Legacy bootkor (bár akkor is hajlanék valami egyszerűbb bootmanager felé).

El tudnátok e képzelni az Arch-ot produktív munkában ? Pl Termelésirányításban egy gyárban az üzemvezetők ilyen rendszeren dolgoznának win10 helyett? Szerintem kijelenthető hogy a Win10 frissítési folyamata ma már több leállási kockázattal jár mint az Arch-é. Én jópár éve használom az Arch-ot, pár évet használtam újra telepítés nélkül is, folyamatos frissítéssel, bátran ki merem jelenteni hogy a w10 frissítési folyamata megbízhatatlanabb és jóval lassabb is. Csak a KDE-vel volt gondom az évek során, magával a rendszerrel nem, de produktív környezetbe lehet nyilván más akár pehelysúlyú megbízhatóbb desktopot választani. Ami aggasztóbb és akadálya a váltásnak hogy sok vállalatirányítási szoftver nem érhető el linux alá. Meg egyáltalán kérdéses hogy a válallatirányítási rendszerek szállítói mernének e garanciát vállalni a hosszútávú működésre egy rolling disztribúció alatt?
Egy jelentős érv a váltás mellett lehetne a vírusokkal szembeni immunitás, hiszen a vírusok jelentős többsége windows platformra készül.
Az Arch abszolút párhuzamba állítható a Win10-el, hiszen mindkettő rolling.
Nektek mi a véleményetek az Arch produktív környezetben való munkaállomáskénti használatáról?

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

évek óta kizárólag Arch fut a saját munkaállomásomon, bár nyilván ha valami nyűgöm volna, azt magamnak könnyen tudom orvosolni.
ennek ellenére nem nagyon volt bajom, sima irodai munkára bátran merném ajánlani.
termelésirányítónak, stb... ha az adott szoftver fut Linuxon, akkor nem érzem hogy bármivel nagyobb kockázat vagy probléma lenne, mint a Windows, sőt...

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Én is jópár éve használok Arch-ot, és volt hogy a frissítés után nem tudott bebootolni. 2-3 ilyen alkalom volt, míg Windows 10-es munkaállomások a melóhelyemen egyszer sem haltak meg. De ettől függetlenül nem az a gond, hogy valaki Windows-t használ, és összeomlik, és akkor kész vége. A jobb melóhelyeken, vagy nagyobb cégeknél, vagy akár kisebbeknél is ha jó rendszergazdájuk van, akkor ott kezdődik, hogy minimum van 2-3 gép tartalékban, felinstallálva+programok, és csak a user-t kell létrehozni, meg mondjuk microsoft365-be bejelentkezni, és kész. Persze ehhez kell egy olyan felfogás is, hogy lokálisan semmit nem tárolunk. Arra ott van a file szerver, vagy ha pl MS gold partner, akkor szinte biztos hogy OneDrive is van használatban. Innentől kezdve semmi extra egy új tartalék gépet üzembehelyezni. Gyorsabb, mint hogy helyrehozd a Windowst, vagy Linuxot. A még komolyabb MS technológiát használó cégek meg akár roaming profile-t is használhatnak pluszban, ami aztán végképp fullosan visszahozza még a profile adatait is, hogy milyen ikon és hol vannak az asztalon. Szal egy cégnél, főleg termelésirányítást is végző cégnél, ami kritikus munka minimális leállásal, ott nem az oprendszer számít, hanem a rendszer egészének működése.

Teljesen jó termelésirányításban, meg akármire is. Ezt már többször is írtam, hogy céges felhasználásra csak LTS az igaz volt régen, de már jó pár éve nem az.

Igazából a rollingságát is lehet tompítani az Archnak. Pl. nem frissíted olyan gyakran, meg helyi tárolót hozol létre, ahova csak olyan csomagot engedsz be, amit egy tesztgépen már teszteltél, a többi gép meg már csak ezeket húzhatja le. Ja, külön munka, de ha az egész cég archos ökosisztéma, csomó géppel, akkor simán megéri.

Inkább csak annyi, hogy általános ipari és céges felhasználásnál szerintem elveszik az Arch előnye, de hátránya se nagyon van. Igazából ízlés kérdése, hogy ki mit ismer, miben bízik, stb.. A legtöbb helyen nem azért van Red Hat alapú disztró, meg Ubuntu LTS, meg Debian, mert azok a legstabilabbak, hanem a legtöbb IT szakember azokat ismeri, így azokat vállalja be. Sokan csak egy Archot azért nem piszkálnának meg bottal sem, mert nem ismerik, nem szokták még meg, és úgy vannak vele, hogy éles környezetben nem fognak elkezdeni tanulgatni. De ez nem jelenti azt, hogy éles környezetben ne lenne bevethető.

Félig a lustaság is benne van. Az informatikus nem szeret dolgozni, minek frissítgessen állandóan Archot, ha egyszer egy CentOS-nél meg elmegy, hogy évente egyszer frissíti, és 10 évig nem kell komolyabban hozzányúlnia. Az LTS meg a miegymás ezt a lustaságot is kiszolgálja. Szintén a lustaságot van hivatva segíteni, hogy a nagy céges corporate disztrókra supportot is tudsz venni, ami ugye nem szükséges, de sok cégnél kényelmes, hogy ha gond van valamivel, akkor nem neked kell megcsinálni, hanem lehet a megoldásért más hátát verni, meg mindig mástól várni a megoldást.

Sőt, tovább megyek, a legtöbb helyen azért van Windows onlyság is, mert azt biztosan ismerik, van vele belső tapasztalat, ahhoz mindig találni szakembert is, mert Dunát lehet velük rekeszteni, van hozzá support. Nem azért használják, mert stabilabb meg jobb lenne.

Nekem még sose volt olyan, hogy egy Arch ne bootolt volna frissítés miatt. Soha!!! Volt, hogy frissítés tört el ugyan dolgokat, nagyon ritkán (kb 2 évente egyszer) 1-1 progi crachelt, meg produkált olyan bugot, amit workarounddal, csomag downgrade-del, stb. kellett megoldani (ilyenkor is megoldható pár perc alatt), de olyan sose fordult elő, hogy az egész rendszer enblock bootképtelen lett volna, meg rendszer nélkül maradtam volna akármikor is. Az is igaz, hogy nálam ez még Windowszal sem fordult elő, csak hogy 1-1 nem tetsző driver kékhalált okozott, de ilyenkor is elég volt egy csökkentett módú újraindítás, és a driver eltávolítása, vagy eszköz letiltása.

És itt azt kell érteni, hogy nem csak az Archot védem, meg istenítem, hanem igazából ez bármilyen disztróra igaz. Még talán BSD-kre is, ha a cég megtanulja magának megoldani, talál hozzá szakembert, akkor szinte bármilyen elterjedtebb modern OS-es ökoszisztémán el lehet lenni, annak bármelyik disztribúciójával.

Nekem még nem volt olyan hogy frissítés után ne bootolt volna be, igaz nem is nvidiát használok aminek csak zárt drivere van, az egy kernelfrissüléskor lehet megfagy bootkor, szerencsére amd vga-m van. Olyan már párszor volt hogy a KDE-t úgy hazavágta egy update hogy nem indult, de akkor használtam másik desktopot. Tv tuneremhez dkms-es drivert használok, volt hogy kernelfrissüléskor nem fordult le, de attól még bebootolt a rendszer, csak a tuner nem működött, néhány hét múlva javították a driverét, nem létfontosságú mert tv-m is van.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Hát nekem volt, hogy a grub-ot újra kellett építenem frissítés után, mert elpukkant. Ablakkezelő is pukkant meg. Ezek egy olyan szakmában nem férnek bele, ahol egy fél órás leállás komoly pénzbe kerülhet. Ezért van az, hogy nem az oprendszer a megoldás, hanem más rendelkezésreállási megoldás. Előző melóhelyemen is így volt, és a mostanin nem is. Legtöbbször nincs idő arra, hogy a rendszergazda megnézze mi a gond, hegesztgesse. Lehetőleg azonnal dolgoznia kell tovább. És mivel a Linux sem tökéletes rendszer, így nem az a megoldás.

Frissítettem a rendszerem, de leállt egy hibával. A Midnight Commander (mc) PGP aláírása sérült vagy érvénytelen hibával állt meg. Oké, leszedtem az mc-t, majd frissítettem a rendszert. Mondom megnézem, hogy felteszem az mc-t, de a hiba ugyan az maradt! Ilyenkor mit lehet tenni? Itt a pontos hiba.

Ha csalódni akarsz, bízz az emberekben!

"az aláírás a "Jakob Gruber <jakob.gruber@gmail.com>" -tól érvénytelen"

ez a lényeg
azt mondod neki, hogy
sudo pacman-key --refresh-keys
utána próbáld meg

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Igen, ezt már próbáltam. Ubuntunál is ez volt az első, így itt is megpróbáltam, de sajna ennél nem használt. Maradt a hiba továbbra is.

Ha csalódni akarsz, bízz az emberekben!

én is lefrissítettem, a következő kulcs tartozik Jakob Gruberhez
gpg: key 456C7A9B91B842AE: "Jakob Gruber <jakob.gruber@gmail.com>" not changed

nálad is? ha nálad nem, akkor arra kellene rájönni, hogyan lehet törölni egy kulcsot majd újra felvenni azt

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Na, ez érdekes, mert nálam is pontosan ez van!

gpg: key 456C7A9B91B842AE: "Jakob Gruber <jakob.gruber@gmail.com>" not changed

Viszont a hiba továbbra is ugyan az!

Ha csalódni akarsz, bízz az emberekben!

hmmm
ezt nézted már?

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Ennek alapján ? [link]

A pacman-key --list-sigs Jakob parancsra ezt írja. Próbáltam az ottani szerint ezt a két parancsot egymás után, de sajnos nem segített.

pacman-key --delete 2612B04099DBD9B9A3DD92A0456C7A9B91B842AE
pacman-key --populate archlinux

#8016 growler: Sajnos ez sem segít.

Ha csalódni akarsz, bízz az emberekben!

Lehet hogy hülyeséget írok, de meg lehetne próbálni a tükörkiszolgálót másikra
állítani.
Volt már úgy (igaz nem Arch alatt) hogy ez segített mikor a frissítéskezelő ilyen-olyan
hibát dobott.

A GRUB egy hulladék, az eltörik Ubuntun, Minten, meg mindenhol. Archnak előnye, hogy ott ki is kerülheted, ha nem teszed fel a GRUB-ot, akkor nem lesz mi eltörjön. Illetve, de, a rendszergazdának van erre ideje. Mert ez a munkája. Ha túl nehéz neki, elmegy szenet lapátolni, vagy munkanélkülinek.

Abban viszont egyetértek, hogy a Linux sem tökéletes. Az Arch sem. Ma már az OS-ek, böngészők kódbázisai olyan nagyok, hogy áttekinthetetlen kódméret, főleg, ha a csomagokat is hozzávesszük. Ráadásul egyre inkább rohannak a verziókkal. Nem csak a rolling, a Win10, fejlesztők, stb. is.

#8010 Sonja: nálam simán jó. Települ és működik az mc. Semmilyen PGP hiba nincs. Pedig semmilyen ilyen refresh-keys mókolást nem ejtettem meg.

Ilyenkor általában megéri egy pacman -Syu parancsot kiadni, mert az, ha van új keyring csomag, akkor azt is befrissíti, és utána menni fog az mc.

Nekem még sosem tört el a Grub (legfeljebb csak a Manjaro esetén,ha több linux van telepítve multibootban). Azért szeretem, mert nem tömi tele az EFI partíciót, mint a gummi-boot.

[ Szerkesztve ]

Kert, kütyük,munka,matek,morfondír...ennyi. Szóval ács nem vagyok, de nemrégiben sikerült faragnom egy mőködőképes fogpiszkálót.

Gummiboot tudtommal már nincs. Az a systemd-boot régi neve volt. De nem tömi tele a partíciót. Ennek ellenére nem írtam, hogy nekem sem volt még gondom a GRUB-bal, mikor még használtam. Egyszer volt, hogy nem bootolt, de akkor balfék Win7 update-je írta felül, nem Linux oldalán volt a hiba. Én csak azért nem használom a GRUB-ot, mert 1) feleslegesen nagy, bloat valami, 2) nincs rá szükségem. De ahogy olvasom a fórumokat, nagyon sok embernek eltörik, és rendszeren jönnek kérdésekkel, hogy nem bootol. Systemd-bootnál ilyet még nem hallottam, az is igaz, hogy annál lehet azért nem, mert aki olyat használ, az ért hozzá, és jól rakja fel magának. Na, meg sokkal egyszerűbb is, csak egy szál .EFI fájl, meg két darab plain text .conf fájl, az egész egy pirinyó megoldás.

De elvileg az EFI stub boot még elegánsabb, ott semmilyen bootmanager nincs (az UEFI már önmagában is egy bootmanager), ott a kernel bootol közvetlenül EFI binárisként. Ennek viszont van 1-2 hátránya, néhány nem annyira szabványos alaplap UEFI-je nincs vele kibékülve, meg ha pl. hirtelen átszerkesztett paraméterekkel kell hívni a kernelt, akkor azt nem lehet egykönnyen kivitelezni.

GRUB csak akkor kell, ha valaki ZFS-ről, btrfs-ről, RAID-ről, egész lemezes szoftveres titkosításos megoldásról (esetleg LVM-ről), stb. akar bootolni. Akkor kell. De ezek nem az átlag felhasználói réteg, az simán titkosítatlan ext4 partíciókat használ, ahhoz nem kell. Még legacy BIOS bootnál sem, mert vannak nála soványabb, biztosabb megoldások, amik nem törnek el.

Megtaláltam a megoldást az Arch fórumán! Méghozzá szintén magyar az illető, szóval talán olvassa ezt a topikot. Köszönöm neki!

Ha csalódni akarsz, bízz az emberekben!

úgy látszik egy magyar mirror a hibás, szóval főleg bennünket érinthet a dolog
örülök hogy kiderült

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Igen, ezért volt ez "nehéz" így hirtelen kideríteni. Én magam nem is gondoltam rá, hogy szervert cseréljek. Egyébként pedig neked is köszönöm a segítséget (growler-nek szintén)!

Szerk.: Azért írom, hogy "nehéz", mert én mindenféle kulcsos próbálkozást kipróbáltam, amit a google-vel találtam, de eredménytelen volt.

[ Szerkesztve ]

Ha csalódni akarsz, bízz az emberekben!

Én mondanám, hogy megmondtam, és mondom is. Talán nincs még 2 hete, hogy valaki az Linux OFF topikban jelezte, hogy gondja van a Void magyar mirrorjával. Erre írtam, hogy ez a baj a kicsi disztrókkal, nem sok mirror, de még nagy disztrónál, mint az Arch, ott sem mindegy, hogy mely mirrorokat használja az ember, és nem csak letöltési sebesség miatt, hanem a tier1 mirrorokhoz képest történő syncállapot miatt, amibe itt most ti is belefutottatok. Épp ezért nem csak pinget meg nyers letöltési sebességet kell nézni, hanem pl. készenléti időt (szerverkimaradás), sync-frissességet. A német szerverek általában jobbak ebben, mint a magyar. Az archlinux.org-on lévő mirrorösszeállítóval lehet nézelődni.

Egyébként nem is jártam messze a megoldástól az Syu-val, hogy nem volt teljesen lefrissülve, de ezek szerint nem user error, hanem mirror synclag miatt.

Arch ARM alatt is gond volt, csak mondom biztosan ARM specifikus hókuszpókusz ezért inkább nem írtam be.
Azóta német szervert használok.

[ Szerkesztve ]

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

Lehet használni többfélét is, és akkor a pacman sorrendben végigpróbálja őket, ha nem elérhető az elsőként szereplő szerver, akkor próbálja tölteni a másodikról. A rollingnak ez hátránya, hogy gyakran frissül, sok csomag, és nagyon le kell követnie a mirrornak is a sok apró változást, ha egy-két csomag nem frissül, dőlhet a függőségi sor, mint a dominóknál. Ez egy lassabban frissülő, kiadás alapú disztrónál (Debian, Ubuntu, Red Hat vonala) nem olyan nagy gond, de elméletileg ott is előfordulhat.

Találtam egy jó leírást, egyszerű LUKS telepítés, systemd-boot -al:
https://jherrlin.github.io/posts/arch-install/
VirtualBoxban kipróbáltam, nekem működött!
Itt meg egy magyarázó videó, szintén alap LUKS telepítés, Grub boot -al:
https://www.youtube.com/watch?v=XNJ4oKla8B0
Ezt is megcsináltam vboxban, ez is működött.
Vim vágólapkezelés:
https://vim.fandom.com/wiki/Copy,_cut_and_paste
konzolban hasznos

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Gyorsan újra raktam az Arch-ot a fő 1 terás ssd-n a systemd-boot -os LUKS leírás alapján. Kíváncsiságból fogtam bele, éles környezetben akarom tesztelni ha valami eltörik a frissítések során a titkosított renszernél az bootolhatatlanságot okoz e.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Persze, hogy működik. Ez egy teljesen sztenderd telepítés, annyi benne a csavar, hogy cryptsetup-pal letitkosította a második partíciót, és arra telepítette a rendszert. Illetve a systemd-boot menüjében hozzáadott egy extra sort: options cryptdevice=PARTUUID=bla-bla... Illetve, ha tudod így telepíteni, akkor ennél kell maradni, és hagyni a GRUB-ot.

Amire még figyelj, hogy ha SATA SSD-ről van szó, akkor a TRIM átengedéséről a LUKS rétegén gondoskodni kell. NVMe SSD-nél (amilyen a leírásban is van), meg HDD-nél nem kell ilyen.

Vim az hasznos, de nem kötelező azt használni konzolban sem. Bármit felrakhatsz magadnak, leginkább a micro nevű text editort ajánlom, de van helyette egy csomó másik: ne, e3, ee, nano, tilde, mcedit, emacs, uemacs, vagy amit akarsz. Van egy rakat, közülük egy csomó „hagyományosabb” a vim-nél. Régen a base csomag része volt a vi, de már nem az. De szerintem a vim a legjobb az összes közül, főleg, ha tud valaki gépírni. Illetve az Emacs is nagyon jó, de azt sem sokkal könnyebb megtanulni, mint a vim-et.

Így jó a LUKS discard vagy máshol is állítani kell valamit? Fstabba mehet a discard a opció?

a /boot/loader/entries/arch.conf -ban adtam meg az allow-discards paramétert ami a wikiben van, bebootolt a rendszer tehát nagy bajt nem csináltam. Jól adtam meg ezt az opciót?
A többi beállítással is foglalkozni kell, vagy ez így elég?

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

libreoffice-fresh-hu hibás a magyar szerveren. Megoldás a worldwide szerverről szedtem le és úgy jó.

Arch Linux, Void Linux, Network Radios, VoIP, HAM

Az Arch Wiki ajánlja még a rd.luks.options=discard kernelparamétert is, ahogy a screenshoton is látszik. Ezen túlmenően a crypttab-ba és az fstab-ba is kell a discard paraméter, ha az SSD-n lévő fájlrendszer támogatja, ha nem támogatja, akkor meg fstrim-et kell helyette ütemezni.

Egyébként az SSD-k nem szeretik a szoftveres titkosítást, mert az teleírja őket, és nem látják, hogy mi a hasznos adat, mi nem. Ezen a TRIM egy kicsit tompít, de az SSD-knek nem nagy barátja az egész lemezes szoftveres titkosítás.

Ezzel a linkeden azért nem foglalkoztak, mert ott NVMe SSD-t használtak, azon meg máshogy van megoldva a TRIM-nek megfelelő opció, hardveresen, így nem kell ezzel szórakozni.

Azért is támogat több SSD is hardveres öntitkosítást, közöttük a 860QVO is támogatja az AES-256-ot. De! Ehhez olyan alaplap kell, ami van TPM 2.0 chip, és a BIOS is támogatja az ATA jelszót. Az a baj, hogy a legtöbb konzumer gép nem támogatja, csak céges notik, céges desktop, thin client, workstation, server, stb.. Nem is értem, hogy a konzumer lapokról ezen mit spórolnak le, mert nem valami drága megoldás. Persze elméletben lehet úgy is használni, hogy az alaplap nem támogatja, hanem boot után te nyitod ki hdparm segítségével, de ilyenkor meg nem lehet róla bootolni. Csakis ATA, SATA, AHCI SSD-knél fontos ez..

Na, megnéztem ezt a hivatalos Arch installert, igaz csak videón. Ahogy mutatják is, nagyon gyatra és bugos, nem javasolt a használata. Csak még mielőtt belelovalná magát néhány ember, hogy már teszi is fel.

Hát ezt tényleg nem nagyon kéne erőltetni. Több a szívás ezzel egy nem annyira hozzáértőnek, mint ha 5-ször neki fut a Wiki alapján.

Letitkosítottam a windowsos lemezeket is, windowsos rendszer ssd + exfat adattároló ssd, bitlockerrel. Az aur ban levő dislocker meg tudja nyitni a bitlockerrel titkosított lemezeket, itt van egy leírás a használatáról: https://www.ceos3c.com/open-source/open-bitlocker-drive-linux/

Frawly:
További beállításokat eszközöltem hogy a LUKS átengedje a TRIM-et, létrehoztam a /etc/crypttab.initramfs -t és beleírtam ezt: rd.luks.options=2e1434a6-a4ac-49bf-91a0-d4f7dd5d3619=discard (a titkosított lemez uuid-je szerepel benne) ahogy a wikiből kihalásztam így kell csinálni, bár lehet elég lett volna a rd.luks.options=discard, inkább biztosra mentem, utána újra generáltam az initramfs-t. fstab-ba bekerültek a discard,noatime opciók.
Nem reklamált a rendszer bootoláskor, persze tudom ez nem azt jelenti hogy működik trim, de akár működhet is A wiki szerint, ha jól értelmezem. az /etc/crypttab -os bejegyzéseket az initramfs miatt nem veszi figyelembe bootoláskor a rendszer bootlemez esetén, illetve ez a fájl arra való hogyha a bootlemezen kívül van más titkosított lemez akkor azoknak az automatikus felcsatolását lehet benne defdiniálni a megfelelő opciókkal.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

A crypttabot azért nem tudom, mert ugyan használtam LUKS-ot már, de nem SSD-vel, hanem HDD-vel, és ott nem kellett TRIM-mel, discard-dal szórakozni.

Egyébként én még mindig amondó vagyok, ha SSD-id vannak, akkor az azokba beépített hardveres titkosítást használd. Neked is könnyebb, mert gép bekapcsolásakor a BIOS bekéri a meghajtók ATA jelszavát, onnantól kinyílik a titkosításuk, és a továbbiakban minden szoftver, OS, akármi úgy érzékeli, hogy titkosítatlan meghajtóra dolgoznak, közben meg titkosítás alatt van, de hardveresen, transzparensen.

Asztali gépek/alaplapok BIOS-ai/UEFI-ei általában nem ismerik a SATA jelszó funkciót, az én lapom is ilyen sajnos
Másrészt ha elgépelem a jelszót első megadáskor akkor a meghajtót dobhatom a kukába(utána már nem lehet használhatóvá tenni, ha nem ismert a jelszó, míg szoftveres titkosításnál újra partícionálás formázás után használatba vehető), ezért félek a hardveres titkosítástól.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Így van, ezeket teljesen jól foglaltad össze. Ha nem támogatja a BIOS, attól még használhatod, de bootkor, egy másik rendszer alól kell kinyitni hdparm-mal. Nyilván, így bootolni nem lehet róla, csak adattárnak használni.

Másrészt meg valóban, nagyon kell figyelni, hogy jól jelszavazd le, és ne felejtsd el a jelszót, mert a hardveres titkosítás nem csak az adataidat, hanem az SSD-t is védi lopás esetére, és ha nem tudod a jelszót, akkor reszeltek az egész drive-nak, nem lehet kinullázni, hekkelni, a gyártó sem tudja neked leoldani a titkosítást. Pontosan, ahogy írod, mehet a kukába. De ez téged véd, mert ha valaki megfújja a gépet, SSD-t, akkor hiába is próbálja elpasszolni, téglásítva lesz az egész SSD, se újraformázni, se semmit csinálni nem lehet vele. Jó, nagyon kevés kivétel van, mikor valami BIOS-os jelszavazási gyengeség (pl. üresen hagyja az admin jelszót, és az csak user ATA passwordot állítja, vagy az admin jelszót a gép sorozatszáma alapján generálja ismert algoritmussal, de ez ritka, gyártók kerülik).

A LUKS ezzel szemben törölhető, ha el is felejtetted a jelszót, csak az adatokat bukod róla, a drive bármikor leformázható. Meg a LUKS megbízhatóbb is, mivel opensource és auditált, így biztos lehetsz benne, hogy se NSA hátsó ajtó, se implementálási gyengeség nincs benne hagyva. Ha betartod a cryptsetupos ajánlásokat, akkor bombabiztos a LUKS, se az FBI, se a CIA ki nem nyitja a rohadt büdös életben, hacsak nem tudnak valahonnan szerválni egy qvantumszuperszámítógépet, ami bruteforce-szal belátható időn belül törni tudja.

A LUKS titkosítási paramétereibe nem mélyedtem bele, alap beállításokkal titkosítottam, a linkelt leírásnak és videónak megfelelően, remélem így is jól véd TRIM jó kérdés megy e, ha nagyon belassul egy idő után a rendszer akkor nyilván nem, de majd akkor keresek rá valami megoldást, sajnos az angolom elég sekélyes, arch fórumon / redditen, stb, nem tudok kérdezni LUKS vs TRIM témában, majd lehet valakit megkérek. A bitlockerrel titkosított meghajtót úgy tűnik csak olvashatóra lehet felcsatolni linux alatt dislockerrel, pedig írható megoldásnak hirdeti magát a dislocker, még tovább kell keresgélnem leírásokat. A ruby függőség nélküli dislocker-t érdemes telepíteni aur-ból(dislocker-noruby) az alap dislocker egy frissítés után elhasalt a ruby frissülése miatt.
Az viszont feltűnő hogy a bitlocker legalább 1-1.5 órát molyolt egy ssd titkosításával(256 AES XTS-re állítottam a gpedit-ben), míg a LUKS töredék idő alatt megvolt. Lehet hogy azért van ez a nagy időkülönbség mert a bitlocker a meghajtón levő adatokat titkosítja mikor átkonvertálok egy lemezt, a LUKS meg valószínűleg nem foglalkozik a meghajtón már rajta levő adatok titkosításával hiszen a LUKS kötetet létrehozása után formázni kell, és ha adatok kerülnek rá akkor röptében titkosítja. Az Arch mellett az Artix-ot is újratelepítettem titkosítva.
Nagy dilemma hogy mi legyen a külső hdd-kkel, hiszen a bitlocker írhatóságával gondok lehetnek linux alatt, lehet azt csinálom hogy a kritikus adatokat titkosított konténerbe rakom, nem egész lemezeket titkosítok.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Elvileg a cryptsetup defaultjai megbízhatók. AES256, XTS, meg valami min. 2048 bites hash.

Bitlocker megint olyan, hogy zárt forráskód. Próbálhatod helyette a VeraCrypt-et, az TrueCrypt formátumú konténereket és partíciótitkosítást tud, és azt el tudja olvasni írhatóra a LUKS.

A cryptsetup alapból nem titkosítja le az egész meghajtót, hanem csak headert ír fel, meg egy két adatot és csak annyit titkosít. A jövőben rákerülő adatok viszont titkosítva lesznek. Ennek ellenére cryptsetup után ajánlanak egy teljes dd if=/dev/rand parancsos végigírást, de szerintem ez nem szűkséges, majd ahogy telíted be a meghajtót, partíciót, majd titkosodik az egész adatterület.

Egyre jobban kezdem belakni az Artixot, tetszik az openrc, érthető logikája van. Viszont a disztró dokumentáltsága hagy kívánnivalót maga után, hol a gentoo wikiben hol az arch wikiben hol az artix saját oldalán van a megoldás. Arra nem találtam leírást sehol hogy melyik csomagot kell telepíteni az openrc-s bluetooth szolgáltatáshoz, illetve ami volt leírás az abban levő csomag már nem létezett, végül a google egy artixos github tárolóhoz vezetett amiben ott volt a csomagnév: bluez-openrc, ezt kellett felrakni és elindítani, és a megfelelő pulse bluetooth modulok betöltése után már ugrásra készen állt a bluetooth fejes. Bliuetoothctl-lel a párosítás simán ment, de kapcsolódni stabilan az istennek nem akart, végül a pulseaudio többszöri újraindítása oldotta meg a dolgot és ment a fejes. Openboxot kezdem belakni, beállítottam időzített képernyővédőt és lezárást(xscreensaver) a debian openbox wiki alapján, billkombóra bekapcsoló képernyőzárat(xlockmore) egy linuxos fórum alapján. Sokkal gyorsabb ez a sovány openbox wm+tint2 mint a KDE, csak minden kényelmi funkcióért meg kell küzdeni Az is tetszik még az openrc-ben hogy amikor elindítok egy szolgáltatást akkor általában kapok valami visszajelzést, mikor az nfs servert indítottam akkor is kaptam egy egész korrekt visszajelzést hogy milyen paraméterekkel indult, systemd-nél nincs visszajelzés. Szerintem az Artix az Arch és a Gentoo keveréke, a gentoo szállítja az init rendszert és nagyrészben a rendszer konfigurációs struktúrát, az arch pedig a csomagkezelőt és a rendszer konfigurációs struktúra kisebb részét. OpenRC-s szolgáltatásokat/gentoo specifikus részeket a gentoo wiki alapján állítom be. Arch specifikus részeket meg arch wiki alapján, ha valami ezekben nincs meg általában segít a google

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Az OpenRC-vel nekem vegyesek a tapasztalataim. Gentoo alatt bejött, Artix alatt hagyott kívánni valót maga után, de azért használható volt.

Amúgy isten hozott a minimalistább WM-ek világában. Igen itt minden kényelmi funkcióért küzdeni kell. De csak először, amíg meg nem érted mi kell hozzá, meg el nem mented azt a néhány .xml meg .conf fájlt a home-ból, .config mappából, utána elég csak azokat visszahúzni minden gépen, minden újratelepítésnél és meg fogod látni hogy így a fájlokat visszamásolva az egész sokkal gyorsabban újra bekonfigurálható, újra belakható, sokkal részletesebben testre szabhatóbb, mint a KDE valaha is volt/lesz, nem kell egyenként minden grafikus szarban hatodik fül eldugott menüjének akármijére kattintgatni végig, mire minden be lesz állítva. Az már csak hab a tortán, hogy mennyivel gyorsabb vele a gép, szemének alig hisz az ember, hogy a grafikus felület milyen gyorsan bevillan.

Azzal is egyetértek, hogy az Artix dokumentációja elég gyér, bár ők ezt úgy gondolják, ha valamit nem találsz benne, akkor az Arch Wikit olvassad. De a Gentoo Wiki is hasznos, meg tapasztalatom szerint a Debian Wiki is, utóbbi főleg a Wi-Fi driverek kinyomozásához, de vannak még benne egyéb jó dolgok, amik a többi Wiki-ben nincsenek benne.

Most virtualboxba gyorsan feldobtam egy Runit-os Artix-ot, a bootolás gyorsasága vetekszik a systemd jével. Így első benyomás alapján elég jónak tűnik a Runit.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Ja, az runit se rossz. Azt Void alatt használtam, egy elég egyszerű, problémátlan initrendszer. Bár ha bootolás gyorsaságára mész, akkor csakis Arch systemd-vel, és zstd-vel tömörített initramfs-sel. Annál jobban semmi nem száguld, még a Gentoo OpenRC/runit se.

A Runitban az nem tetszik így első blikkre hogy elég szűkszavú, pl mikor az OpenRC elindítja a dhcpcd-t akkor szépen látszik ahogy végbe megy a dhcp folyamat, ugyanígy az nfs szervernél is látom hogy miket írkál ki. Runitnál semmi visszajelzés, csak annyi hogy a szolgáltatás elindult... ez így nagyon systemd-s. Meg ha el akarok indítani bootoláskor egy szolgáltatást akkor symlink készítésével tudom megtenni, ez sem jön be, itt megvan az elégépelés esélye, szerintem macerásabb mint az rc-update. Persze OpenRC-nél is van szolgáltatás aminél symlinkelni kell, pl dhcpcd, de ezek kivételek, a nagy többség az rc-update-val felvehető az indítási listára. Talán azt lehet modani hogy az OpenRC konzervatív megodásokat használ, a Runit meg inkább systemd szerű.

-||- Asrock B660M HDV -II- G.Skill Aegis 2x16GB DDR4 -II- - i3 12100f -||- Sapphire RX550 4GB -||- AOC Q27V4EA 1440p -||-

Valahol már minden modern initrendszer kicsit systemd-szerű lett, mindegyik támogat párhuzamos service-indítást, service-függőségkezelést, eseményekre reagálást.

dhcp service-nek gondolom vannak kapcsolói, hogy kiírja mit csinál. Szerintem hosszabb távon jó, ha nem írja, nem hányja tele a képernyőt szeméttel, meg kicsit gyorsabban is fut.

Pénteken meglesz az új gép (remélem, kopp-kopp ), így végre az asztali gépre is felteszem már az Arch-ot. Legalábbis ez a terv. Remélem elsőre sikerül mindent jól csinálnom.

Ha csalódni akarsz, bízz az emberekben!

En is pentekre terveztem be a desktop gep szereldet Eddig ARM-on zuztam az Arch-ot, de vegul ugy dontottem megy vissza a PI servernek a szekreny tetejere

Memoriaval kapcsolatban lenne egy kerdesem. Sway melle (kb 400MB az alaprendszer) szerintetek eleg lesz a 8GB RAM ugy, hogy idonkent azert befigyelne egy kis virtualizacio? Semmi komoly, csak amolyan disztro mustra.
Illetve a gaming vonalat egy ideje mar elengedtem, de a retro (2000 elotti) jatekok azert meg a szivem csucskei. Szoval idonkent ezeket is Windows alatt inditanam WM-be, mert korabbi tapasztalataim szerint azert a Wine sem tud mindent elfogadhatoan futtatni. Mondjuk az is igaz h jo reg volt mar mikor utoljara hasznaltam...

Holnap adnam le a rendelest iPon-os ismerosnek, de ha azt mondjatok hogy felesleges a 16GB-os KIT akkor nem vennem meg.

[ Szerkesztve ]

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.