Sziasztok!

A korábbi hibára meglett a megoldás, amit egy fórumban találtam.
A kernel paraméterek közé be kellett tenni ezt: amd_iommu=on iommu=pt
A kérdés, hogy egy frissítéstől miért lett erre szükség?
Nagyon kiváncsi lennék a válaszra.

Előre is köszi!

[ Szerkesztve ]

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Gondolom a frissebb kernelben megváltozott az amdgpu driver, az tette szükségessé, bár nem tudom mit csinál ez a két kapcsoló, magamtól erre rá nem jöttem volna. Egyébként nem is az a gond, hogy ilyen kernelparaméterekre szükség lesz, hanem nincs lekommunikálva rendesen, és sokszor a kerneldokumentáció sem egyértelmű. Ez utóbbit elég sokan kritizálják is, hogy a kernel doksija nincs rendesen karbantartva, a kernelt fejlesztik ezerrel, a dokumentáció meg le van maradva jócskán.

Én ezt most az Arch-os vagy AMD-s kernel karbantartóknak róvom fel, mert Manjaro-t is megpusztult egy másik GCN IGP-n a kernel. [link]
Megsem próbálja GCN3-as IGP-n betölteni az AMDGPU-t, hanem radeon-nal próbálkozik, persze sikertelenül. Ezt még nem fejtettem meg.
Mindeközben Fedora-n mindkét gépen hasít minden.

[ Szerkesztve ]

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Szerintem meg nem az Arch/Manjaro hibája, vagyis olyan értelemben az, hogy ők nem adják hozzá automatice ezeket a kapcsolókat, vagy úgy fordítják le a kernelt, hogy szükséges a kapcsoló. De ez nem azért van, hogy téged szopassanak, hanem hogy vanilla állapotban tartsák a csomagokat, neked ettől még megvan ez a lehetőséged, hogy kernelparaméterekkel meg egyebekkel szórakozz. Ez az Archnak a „hekkeld magad” filozófiájából ered, ők nem foltozgatnak semmi disztróspecifikus dolgot a csomagokba.

Ehhez képest a Debian, Ubuntu és Fedora vonalán a disztrókészítők tengernyi patcht meg disztróspecifikus beállítást eleve odahekkelnek default, azért megy. Ez hihetetlenül kényelmesnek is tűnik, de ennek is megvan legalább annyi hátránya, csak máshogy jön ki, pl. ha egy vanilla csomagot forráskódból forgatsz (mert nincs meg semmilyen tárolóban, nem hivatalos külső tárolóban sem), akkor néha meg az a szopás, hogy nem fut normálisan a kód valami disztróspecifikus patch-csel összeveszve, ami épp ott csücsül a futó binárisokban. Vagy pl. ilyen külön patcheléssel nem tudják olyan gyorsan kihozni az új verziókat, mindig csak fáziskéséssel tudják kiadni.

Ami az Arch/Manjaro hibája, az az, hogy ezeket az esetlegesen szükséges kernelparamétereket, nem kommunikálják le, de ez részben a kernelkészítők igénytelensége is, hogy nem tartják rendesen karban a dokumentációt. A kerneldoksinak tartalmaznia kéne ezeket a GPU specifikus dolgokat, hogy melyik generációs kártyára milyen kapcsolók kellenek, meg az Arch Wikinek is ki kéne térnie erre, külön felhívva a figyelmet, hogy ilyen meg olyan AMD GPU generációknál erre szükség lehet, fokozottan kell rá figyelni.

De én még az AMD-től is elvárnám, hogy a linuxos driveroldalukon összehozzanak egy általános linuxos Wiki cikket, ahol sorra veszik, hogy milyen GPU generációknál milyen beállítások, driverek, stb. kellenek a főbb disztróvonalakon, hogy használható legyen a ×4rjuk.

És itt most nem az Arch-osokat akarom védeni, hanem azt kell érteni, hogy nem vagy nem csak miattuk szenvedsz, hanem több ember és cég érdektelensége miatt kell szívni, meg küzdeni, mire rájössz ilyen hekkelős megoldásokra.

[ Szerkesztve ]

Másfél hónapja új melóhelyen vagyok, és ott javarészt Debian van, meg egy Red Hat. Megdöbbenve látom, hogy a Debian 10.3-as Buster-en (stable) a Chromium 79-es verziónál tart. Értem én, hogy stable, és mégsem egy Arch, na de bakker. Nem véletlenül tart a 80-as verziónál (a sokadiknál), mert még a 80-asban is kritikus biztonsági rések vannak. Azért legalább ezt frissíthetnék a Debian stable kiadásánál normális tempóban. Ezt így gáznak érzem.

Sok bug volt mostanában az új csomagoknál, vagy a tárolókkal volt gond? Napok óta próbáltam rebornost telepíteni, de a telepítő állandóan elszállt különböző hibajelenségek közepette. Ma végre sikerült ugyanazt a pendrájvot használva felvarázsolni egy rendszert.

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.

Én nem tapasztaltam bugokat. Igaz pár napja Voidot használok helyette. Szerintem amibe belefutottál, az Rebornék bénasága.

semmi problémát nem vettem észre (bár én sima Arch-ot használok)

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

Szintén semmi probléma...

Alex

Én sem találtam problémát:

siriusb@archlinux ~ % find / -maxdepth 0 -iname 'probléma'
siriusb@archlinux ~ % 

Megkérdezném a nagyérdeműt, ki milyen biztonsági megoldásokat használ a gépén, mint pl. apparmor, firejail stb.
Kíváncsiságból feltelepítettem a vibert és firejail-lel akartam futtatni, de nem tudtam megoldani, hogy a szinkronizálás működjön. Ellenben nem ártana pl. a böngészőt firejail-ben futtatni, talán a rootless xorg sem lenne butaság...

Köszönöm, akkor így jártam, de már végre fenn van.

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.

No problem:_)

A bonyolultság elrejtése még bonyolultabb rendszert eredményez, és ezért kerülendő. KISS

Frawly:

Szia. Egyszer régen úgy rémlik, hogy leírtad, hogy mi van akkor ha valaikinek UEFI-s systems boot-os Arch van, és mellé akar egy másik linux disztrót, akkor hogyan lehet ugyanúgy UEFI-s megoldással. Muszáj feltennem a jelenlegi Arch-om mellé egy Debian 10-est, és netinstall-al felraktam egy teljesen minimal rendszert egy külön 15GB-os szeletre. Eleve érdekes hogy felrakott Grub-ot úgy, hogy meg sem kérdezte, hogy akarom-e, de mindegy. A /boot/loader/entries alatt létrehoztam egy Debian.conf-ot is az Arch mintájára. Nyilván a PARTUUID-t átírtam az új értékre. De mivel ez a szerencsétlen Debian grubosként installálta magát automatice, így persze nem működik, hisz a /boot/EFI alá létrehozott egy debian mappát amiben most van BOOTX64.CSV, fbx64.efi, grub.cfg, grubx64.efi, mmx64.efi, shimx64.efi.
Szerinted hogy tudom kikerülni egyrészt a grubot (úgyse működik, mert debian nem bootolbe, csak az arch), és hogy tudom az arch uefi+systemd-bootos megoldást megcsinálni debian esetében is. Ha egyáltalán lehet...

Frawly:

Jah azt elfelejtettem írni, hogy a Debian be se kerül az UEFI menüjébe, mert bár a boot/EFI alatt létrehoz egy debian mappát benne pár efi file-al, meg grub.cfg-vel, de a /boot/loader/entries alatt már nem hoz létre file-t. Valszeg azt hoztam én létre rosszul, de visszaolvasva pár írást, automtikusan be kellene kerülnie a debian-nak.

A leírásod alapján jól csinálod pedig. A /boot/loader/loader.conf hogy néz ki nálad? Tudni kéne ugyanis, hoyg indításnak mit adtál meg a debian.conf-ban. Ha GRUB jön a képbe, akkor a grubx64.efi fájllal kell indítani, de mivel nálad van shimx64.efi, ezért lehet mégis az kell helyette, a shim a Secure Bootot intézi, de ehhez a részéhez nem értek, mert én mindig letiltom a Secure Bootot.

A Debian, mint ahogy a legtöbb disztró, felteszi a GRUB-ot, ha kéred, ha nem. Nálam a Void is feltette sajnos, majd kigyomlálom belőle.

Bár annyi előnye lehet, hogy ha végképp sehogy nem boldogulsz, akkor nem a Debiant veszed fel a systemd-boot-os menübe, hanem fordítva, az Archot veszed fel a Debian GRUB-jába.

A loader.conf-ban csak ez van:

default Arch
timeout 3

Az Arch az Arch.conf-ra utal ami a /boot/loader/entries-ben van. Az Arch.conf-ban meg ez van:

title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=a76e14ae-961a-47e0-88df-b959e216185a rw quit loglevel=3

Gondoltam csinálok erről egy másolatot amit Debian-nak neveztem el, és utána a title értékét írtam án, és a PARTUUID-jét a blkid-ből kiolvasott értékével. Csak azzel nem tudom hol utalok a debian mappában levő grubos uefi-ra.

[ Szerkesztve ]

Most nézem, hogy ha bootlás előtt az F12-őt megnyomom, hogy a BIOS honnan bootoljon, ott szerepel a debian, és be is bootol de az uefi menüjében nincsen. Megnéztem, és a Secure Boot nincsen bekapcsolva.

Most én is ezzel küzdök, de Void alatt. Az GRUB-ot használ, és működik ugyan az UEFI boot, de csak akkor, ha F12-t nyomva a boot menüből kiválasztom a void_grub bejegyzést. Egyébként mindig az Arch akar indulni. Pedig az UEFI-ben be van állítva a bootsorrendnél, hogy a void_grub legyen az első.

Amit a entriesről írtam, azt visszavonom. Ez csak systemd-bootnál működik, ami közvetlen kernelt bootoltat initramfs-sel. Ha a Debian GRUB-os, akkor nem kellenek ezek a conf fájlok. Helyette Arch alatt efibootmgr-rel vedd fel a grubx64.efi-t indulásra. Még paraméterek sem kellenek neki, mert a GRUB ezt saját hatáskörben elintézi. A lényeg, hogy az UEFI BIOS találja meg a grubx64.efi fájlt:
sudo efibootmgr -c -L "Debian" -l '\EFI\Debian\grubx64.efi'

Vigyázat, az UEFI-nek visszafelé perjel kell, mint Windowsnál. Ugyanis egy DOS-ból származtatott implementáció! Nem a normál linuxos-unixos perjel kell neki. A harmadik kapcsoló az efibootmgr-nél egy kis L, nem nagy i, csak rosszul látszik a Prohardver által használt talpatlan betűtípussal. Arch alól csináld természetesen, ne Debian alól.

Köszi mindjárt kipróbálom, csak közben a debian-ra elkezdtem felpakolni ugyanazokat mint az archon (kivéve amit forgatni kell, mert nincs a tárolóban lásd termite, polybar pl). Még a felét se raktam fel, állítottam be, de már több memóriát foglal, mint az Arch...ez kicsit meglepő nekem, pedig full minimal Debian-nal kezdtem.

Esetleg még azt lehet csinálni, hogy teljesen megkerülöd a Debian GRUB-ját, és közvetlenül veszed fel a Debian kernelt és initramfs-t az Arch systemd-boot menüjébe, ahogy először próbáltad (GRUB-ból kimásolva a kernelparamétereket). De ezzel az a probléma, hogy ha Debian alatt frissül a kernel, akkor nem fogja megtalálni az új verziót. Mert a Debian beteszi ugyan az új kernelt a GRUB-jába is, de mivel ezt te megkerülöd, ezért nem fog látszani, és a régi kernellel indul a rendszer.

Az, hogy mi mennyit foglal, az attól függ, hogy mit mivel telepítesz. Egyforma csomagoknál azért nem kéne nagy különbségnek lennie.

A Termite nekem is érdekes, mert Archon kívül szinte semmilyen disztrónak nincs benne a tárolójában. Nem is értem az okát. Void meg Gentoo alatt is külön tárolóból kell forgatni. Mivel nem akartam én sem ezen tökölni, így most Voidon Alacritty-t használok, ez se rossz, csak speciális vim-módokat nem tud kijelölésnél és görgetésnél.

Szerintem az fstabban át kell írni, hogy az efi partíció hova mountolódjon ( /boot), és a két rendszer miatt az efi partíción mappákba kell pakolászni a szükséges fájlokat, hogy a két rendszer ne keveredjen egymással, bár valószinüleg nem lesznek benne tök azonos nevű fájlok. Ekkor már az Arch mintájára meg tudod csinálni a debian systemd bootját is. Ki lesz tömve sajnos így az efi partíció. De a debián ezután is a grub szerint fogja kernelfrissítéskor a fájljait pakolászni és neked sk kell majd ezek után az efi mappába bevongálgatni a szükséges dolgokat sajnos. Egy rendszer systemd bootja tehát csodás és nagyszerű tud lenni, ha eleve úgy van telepítve, két rendszer viszont már zavarja egymást. Két rendszer esetén már a grub sokkal elegánsabban és egymástr nem zavarva tud működni.

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.

Így már működik :) a lényeg hogy pontosan ugyanazt a rendszert hozzam létre, mint Arch alatt, csak debian alapokon. Ez a kérés, én meg nem mondtam nemet. De most ezt csinálva nekem nagyon úgy tűnik, hogy ez a debian max minimál install-al szervernek jó, mert innen felépítve desktopra eléggé pazarló. Nem csak memóriát foglal többet, de jóval több csomagot is tett fel, és még nem vagyok kész. Most egyelőre a polybar-al és az arra kirakott cuccokkal szenvedek. Halál jól működik Arch-on, debianon egyelőre nem akar. Mondjuk az külön vicc, hogy a netinstall közli, hogy az ath10-es drivert én külön adjam meg neki. Baszki netinstall. Hiányzik driver, akkor töltse már le.

[ Szerkesztve ]

Kizárt, hogy ez a debian nálam megérje a verzióváltást. Egyre inkább látom, hogy helyesen döntöttem, hogy anno a linuxozást a manjaro rolling distro miatt kezdtem el, és folytattam az arch miatt.

Végül melyik megoldás működött pontosan?

Debiant nem tudom, nagyon rég használtam már minimal netinstall, sok éve. Mennyi az a sok memóriafoglalás?

Én is Polybar-ral tolom, meg Openbox WM és Picom kompozitor, xautolock + i3lock képernyőzárnak. Login Managert nem használok, 1-es konzolról (tty1) jelentkezve be automatikusan indul a X.org, xinit-be fel van véve az openbox-session. A háttérképet a feh jeleníti meg, terminálnak Alacritty van.

Debian-nál az ath10 drivert azért neked kell feltenni, mert non free csomagként igényel egy firmware-t, és a non free alapból tiltva van rajta, alapból le sem tölt ilyeneket, mivel a Debian szigorúan GNU Free disztró, azaz alapból csak olyan csomagokat érsz el a tárolóból, aminek szabad licence van. Egyébként a Void Linux is ilyen. Meg a Parabola, ami egy Arch-klón. Ezekben, ahogy Debianban is, az első, hogy még telepítéskor vagy közvetlenül telepítés után engedélyezni kell a nonfree tárolót.

Végülis nem szórakoztam, hanem grubosra raktam mindent. Persze előtte az EFI partícióról csináltam egy image-et.
Nagyon hasonlót használunk. Én is Openbox, Polybar, xautolock, i3lock-blur, háttérképet nitrogen jeleníti meg, termite. picom-ot már nem használom, nem kell az átlátszóság, úgyhogy kilőttem. Login managert én sem használok. Igen azt tudom, hogy a non-free, és contrib-ot rögtön érdemes felvenni, na de egy kicseszett driverrel is már szívás van. Ráadásul egy elég gyakori Atheros driverrel.
TÖbbé-kevésbé beállítottam, de a polybaron jópár elem képtelen rendesen megjelníteni, mert azt mondja hogy nincs ilyen beépített modul. Úgy látszik debian alatt forgatva ez nagyon nem jó. Pulseaudio is felrakva, engedélyezve, és közben sehol nincs a modul. Ahhoz képest, hogy Arch-ra mondják, hogy juj semmi se működik, mindent konfigurálni kell blabla, ehhez képest sokkal működőképesebb minimális konfigurálással, mint a Debian.
Úgyhogy mindjárt le is gyalulom, teszt meg volt, ennyi.
Amúgy 244MB-os foglalt a Debian ugyanazon cuccokkal (leszámítva pár programot, és mondjuk a pulseaudio, ami mg megdobná a memóriafoglaltságot), míg az Arch 211MB-ot foglalt. De a legdurvább, hogy míg az Arch 747 csomagot mutat, addig a Debian 1362db csomagot. Értem én, hogy valszeg ami Archon egy csomagban van, az Debian-on 2-3db-ban, de azért ezt erősnek érzem, főleg úgy, hogy azért én eléggé minimális konfigot használok egy átlag userhez képest.

A 244 MB valóban sok, én is hasonló csomagokkal tolom, és nálam 160-170 MB között ingadozik (free -m). Kicsit az Arch 211 megáját is sokallom, nálam az sem volt SwayWM-mel 170 fölött soha. Az a 747 telepített csomag Archra reális, nálam is ennyi körül van, Void most 685 csomag, de ezen pl. nincs systemd, meg annak az összes szutyka. Debianon az 1362 csomag nagyon sok, azért nincs minden csomag 2-3 felé szedve. Ezt magyaráztam már ubyegonnak is, de jött azzal, hogy szerinte nem bloat. Közben meg de, csak a Mint is ilyen, amit használ és hozzászokott.

Azért nagyon nem mindegy, hogy csak fele annyi csomagot kell frissíteni, meg fele annyi szutykot betölteni, és a memóriafogyasztás is kb. fele annyi tud lenni egy Mint Cinnamonhoz képest. uby nem értette, hogy nem arról van szó, hogy nem fér bele a 16 GB RAM-ba, hanem minek töltsünk be felesleges szutyokokat, ami azért mégis időveszteség, még ha csak néhány ms is, azért a sok apró összeadódik, meg a sok felesleges csomagra frissítéskor netsávszélt és letöltési mennyiséget pazarolni.

Termite nekem hiányzik egy kicsit, szerettem a vim-mód miatt, de egyrészt ki kell próbálni más alternatívákat is, meg én minden rendszerújratelepítéskor kipróbálok új dolgokat, már csak azért is, hogy változatos legyen, ne legyen unalmas, ismerjek meg más megoldásokat is. Így most lett az Alacritty, de lehet Gentoo-n már egy harmadik megoldás lesz.

Picom nekem mindenképp kell, nem csak az átlátszóság és Aero-effekt miatt, hanem anélkül tearingelnének a mozgó grafikus elemek, pl. játék, videólejátszás, böngészőben oldalgörgetés. Kell a vsync meg a hardveres OpenGL videógyorsítás. Régen Comptont használtam, az is ugyanez a kompozitor, csak a szerző leállt a fejlesztésével, ezért forkolták, és lett belőle Picom, ezt rendszeresen fejlesztik.

Archon SwayWM-et használtam, ami az i3wm waylandes változata. Azon nem kellett kompozitor, mert a waylandes WM-ek egyben kompozitálnak is, de X.org-on kell. Nagyon elméleti esetben, ha a GPU drivere támogatja, akkor X.org-on is be lehet kapcsolni a tearfree opciót, meg a DRI gyorsítást, de ezek nem minden GPU-n állnak rendelkezésre.

Debiannal meg továbbra is az a bajom, hogy konzervatív, relatíve régi csomagverziókkal. Bár ebben fejlődtek, régen, pár éve még sokkal jobban el voltak maradva verziókkal, most már nem annyira vészesen, mint a CentOS. Ennek ellenére én soha nem láttam értelmét a Debiant erőltetni. Használható azért, azoknak, akik ebbe az apt/deb ökoszisztémába szoktak bele, és nem fontos nekik a legújabb verziók és legmodernebb technológiák (Proton, DXVK, Wayland, stb.) használata. Én a helyedben nem erőltettem volna fel az Arch mellé, nincs értelme egyszerűen.

Archon nekem ez 211MB kb megfelelő, mert én programok kipróbálásához mindig ezt a rendszert használtam, és bér -Rs -el szedtem le utána a progikat, de ahogy figyeltem így is marad valamennyi szemét. No meg nekem ilyen unikum cuccok is vannak, hogy flac fileok splittelése, sacd iso file-ok darabolása flac-be, szal nem mindennapi progik. Annyira nem szokványosak, hogy ezek sem gui-s felületűek Valszeg ha full újrahúznám a rendszert, akkor már kevesebbet foglalna.
Uby sok mindent képtelen volt felfogni. Debian tőlem mehet, de csak a legminimálabb telepítővel, és a szükséges cuccokkal, mint pl php, mariadb, nginx. Akkor érzem a létjogosultságát, de amúgy nem. És most az is kiderült, hogy az sem teljesen igaz, hog az ember mindegy milyen linuxot telepít, mert utána a programokkal ugyanúgy testreszabhatja, ugyanazt kapja. Hát ez így most látszott, hogy nem. Amúgy ez nem nekem készült volna. Egyik haveromnak megtetszett az enyém puritánsága, de ő debian-al szeretné, ezért gondoltam kipróbálom, hajtott a kíváncsiság, hogy mennyire lehet. Max ha debiant akar, akkor burnsenlab helium-ot telepít, az openboxos debian alapból, csak abban is vannak felesleges cuccok, no meg tint2, ami nekem nem jött be, mert keveset tudott.
Jah azt én is néztem anno, mikor a trizen szólt, hogy comptonnak vége, és helyette picom. Tearing hálistennek beállítható külön "kapcsolóként" Intelhez, így ezért nem kell nekem picom.

Voidról mi a véleményed? Vagy még nem használod olyan régóta?

Költöztetnék egy rendszert SSD-ről egy másikra. Adott egy EFi partíció, egy sima boot partíció, valamint még egy luks partíció lvm-mel megfejelve.
Arra gondoltam - mivel mehet offline az egész -, hogy létrehozom az új meghajtón a 3 partíciót és fájlrendszert (a régitől eltérő méretekkel), EFI és boot sima másolással átmegy. Luks partíciót létrehozom manuálisan, majd dd-vel a luks-ra rámásolom az lvm-et, ami feltételezésem szerint az lvm header-t is viszi, tehát egyszerű lesz az átméretezés. Ezután csak a grub telepítés marad.

Vagy hozzak létre az új meghajtón PV-t (pvcreate), adjam hozzá a már létező volume group-hoz, mozgassam át logical volume-okat és válasszam le a régi meghajtót?
Lvm-mel sajnos csak annyi a tapasztalatom, hogy egyszer használtam már.

Voidot nem használom még régóta. Nem rossz, használható, de az Arch szerintem lényegesen jobb disztró. Én csak azért váltottam, hogy a systemd-t elkerüljem. Ha nem zavar a systemd, mindenképp Archon maradj.

(#6629) Siriusb: ez LVM over LUKS vagy fordítva? Ilyen felállásban ez egyszerű módon nem oldható meg. Én úgy csinálnám, hogy a cél SSD-n létrehoznám a boot partíciót, meg a LUKS partíciót, LVM-mel. Létrehoznám rajta a logikai köteteket meg azon a fájlrendszereket is, és fel is csatolnám. Meg felcsatolnám a régi SSD-n is a fájlrendszereket. Majd egyszerű fájlmásolással mindent átvinnék a két SSD között, fájlrendszerenként. A végén meg az új SSD-n az Arch indulásához módosítani kell a fájlrendszer vagy partíció UUID-it. Lehet van ennél egyszerűbb megoldás, amit nem ismerek.

Lvm on luks.

Ez a legbiztosabb megoldás, az tény. Lehet ezt választom.

A LUKS miatt nem lehet egyszerűbben. Ha csak LVM lenne, azt elég lenne átklónozni dd-vel és utána a logikai köteteket és fájlrendszereket átméretezni. De a LUKS-ot tudtommal nem lehet.

De lehet, már csináltam, csak külön lépésekben kell végezni a luks, valamint a fájltrendszer átméretezését. Illetve a sorrendjére kell figyelni.
Mindenesetre jobb, ha újra felépítem a struktúrát, ahogy javasoltad, az a legbiztosabb.

[link]

You may corrupt the souls of men, but I am steel. I am doom.

Azonos gépre feltettem egy Fedorát, mert fontos munkák jönnek mától, és Arch vonalon volt több AMDGPU-s gond is.
A Fedora egyből beteszi a kernel paraméterek közé azt a két iommu kapcsolót.
Azt is megtudtam, hogy csak azért van nálam szükség ezen kapcsolókra, mert két AMD GPU van a gépben.

A tanulság, hogy ha gond van Archon, akkor érdemes Fedorával tenni egy próbát, és ha valaki ragaszkodik az Arch-hoz valami miatt, akkor átmásolni a Fedora működését.
A Fedora csapatának gondolom sokkal több kapacitása van az ilyen ritkább (két AMD GPU) esetek tesztelésére, kivizsgálására is.

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Jó, te tudod. Nyilván azt használsz, amit akarsz, nem mi szabjuk meg. De ha már egyszer Archon megfejtetted a hiba okát, akkor nem sok értelmét látom fedorázni. Egyébként az Arch ilyen, egyszer kell szívni vele, kiismered rajta a dolgokat, utána viszont kézreáll, kezesbárány, gondod nem lesz vele többet, legalábbis nem lényegi, meg semmi olyan, amit ne tanulnál meg egyszerűen megoldani. Emiatt bőven megéri bele időt feccölni, hosszú távon bőven meghálálja magát.

Ezzel szemben kiadás alapú és félrolling disztróknál minden kiadásban mást csesznek el, és mindig teljesen új felállással szívhatsz, sose tudod mire számíts.

Fedorán egyébként azért nem volt gondod ezzel, mert ott beletesznek mindenféle csomagot, meg kernelparamétert, és ugyan ez az esetek nagyobb részében kényelmesnek tűnhet, viszont sokkal bloatabbá is teszi a rendszert. Archon ezzel szemben minimalista vonalon építkezés a cél.

Megtartottam az Arch-omat is, mert általa jobban megismerem a linuxot, de mellette ott a Fedora is, mert ha munka közben jön negy ilyen Arch-os több napos keresgélés, hogy mit kell tennem, hogy legyen kép a VGA-n, akkor az nekem sok pénzembe fog kerülni.
Sajnos, nem az első eset, hogy Arch-on napokig áll minden.
Most néhány hete két különböző is volt két különböző gépen, igaz mindkettő AMDGPU kernel paraméterekről szólt. Arch iommu és Manjaro amdgpu.dc=0 egy GCN3-as IGP-n.
Mindkettő használhatatlanná tette az adott gépet, és mindkettő működött Fedorával és Ubuntuval is.
Évekkel ezelött is volt hasonló eset, és ott is meglett a megoldás pár nap/hét alatt.
Hobbi célra ez tökéletes, de munkára szerintem nem.

Valószínű, hogy egy gyakorlottabb júzernek ez sdokkal kevésbé probléma. Én most csak magamról beszélek, általánosítani nem célom.

És ne értsd félre, nem szidom az Arch-ot inkább építő céllal írtam le ezeket. Remélem, nem az ellenkezője érződik.

[ Szerkesztve ]

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Szia!
Bocs az offert, talan ez itt porgosebb.
Ferfiui kivancsisagtol hajtva felpakoltam a Fedora helyett egy Manjarot.
Eddig nagyon tetszik.
Az alignment is rendben van, elvileg:

A

sudo blockdev --getalignoff /dev/sda
sudo blockdev --getalignoff /dev/sdb
sudo blockdev --getalignoff /dev/sdd
(ugrott a betujel, nem tudom miert), 0-t ad vissza, tehat a telepito jol vegezte a dolgat.

Az fstab-ban a rendszer alkalmazott discard opciokat, mind a HDD-k mind az SSD-k eseteben. Ezeket mindenhonnan eltavolitottam, mert azt olvastam, hogy ez folyamatosan TRIM-el, igy engedelyeztem az fstrim service-t.

/etc/fstab:
UUID=D72B-22EB                            /boot/efi      vfat    umask=0077 0 2
UUID=e0f19ede-8a6c-499a-a6a1-b5f72e93cfdc /              ext4    defaults,noatime 0 1
UUID=6070260d-4eb6-4075-84ae-68ee25d1c35f swap           swap    defaults,noatime 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
# Internal HDs
UUID=78254e28-4f38-490a-ad5b-c2d1e87706c3 /mnt/78254e28-4f38-490a-ad5b-c2d1e87706c3 ext4 defaults,noatime 0 0
UUID=bb4fd23d-7a2e-4729-a327-4b443935324a /mnt/bb4fd23d-7a2e-4729-a327-4b443935324a ext4 defaults,noatime 0 0
UUID=e10ca82f-302c-4063-91d7-6fb16e3ad4ea /mnt/e10ca82f-302c-4063-91d7-6fb16e3ad4ea ext4 defaults,noatime 0 0
UUID=0a20e9a8-f876-40eb-88ad-24c17a0e1aef /mnt/0a20e9a8-f876-40eb-88ad-24c17a0e1aef ext4 defaults,noatime 0 0
sudo systemctl status fstrim.timer:
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
     Active: active (waiting) since Sat 2020-03-21 06:32:35 CET; 15min ago
    Trigger: Mon 2020-03-23 00:00:00 CET; 1 day 17h left
   Triggers: ● fstrim.service
       Docs: man:fstrim
Mar 21 06:32:35 armand-x570aoruselite systemd[1]: Started Discard unused blocks once a week.

Ez igy megfelelo? :)
Van esetleg egyeb teendom?

Koszi!

Udv. core2

Bici tapasztalatához csatlakoznék.

Én ezért nem vettem AMD-s laptopot magán használatra (sem). Régebben, de az elmúlt időkben is a sok linuxos topicba olvasgatva továbbra is sokkal több probléma van az AMD-s GPU-kkal, mint az Intel-ekkel. Amúgy én hogy írtad megnéztem a Fedorát, illetve terveztem, aztán elkedztem olvasgatni mit, merre, hogyan, és rögtön le is tettem róla, hogy ugyanazt kialakítsam rajta, mint Arch-on, mert Fedora-n is jó sok korlátba ütköznék, mint Debian esetében.
Egyébként csak hogy Arch mennyire nem való munkára. Ugye ez otthoni magánhasználatra van ez az Arch + Openbox. Ehhez képest most ezen home office-olok probléma nélkül: OpenVPN, VNC, Telegram, Teamviewer, Zoom. Közben avi-t dekódolok mkv-be AC3-as kódolással, de volt hogy közben konvertáltam szintén parancsosors progival SACD-t nagyfelbontású FLAC-re. Semmi bajom nincs. Egyszer összeállítottam, és működik rendben.

[ Szerkesztve ]

Írnál a debianos korlátokról?

Nem lehet vele pontosan ugyanazt kialakítani, mint nekem Arch-on. Vagy ha igen, akkor olan mértékű utánajárással (4 napot szántam rá max), hogy egyszerűen nem éri meg. Arról nem beszélve, hogy kb a felét alakítottam ki debian-on mint Archon, és már több memóriát foglalt, és jócskán több csomagot pakolt fel feleslegesen. És akkor még ott az a probléma, hogy volt olyan program, amit nem találtam debianhoz, és forrásból forgatva gondjai akadtak. A GTK-s téma se működött rendesen debian alatt ugyanúgy GTK-s rendszeren természetesen. Polybar pl teljesen kuszán működött. Csomó beépített elemre nem reagált Debian alatt, mondván nem létező elem (WTF??). Szal azonnan töröltem is. Az a kombó amire én használtam volna, arra a Debian nem jó. ELhiszem hogy Debian + KDE vagy Gnome jól működik, csak olyan bloat-os rendszer nekem nem kell.

Írom mindezt úgy, hogy jelenleg a cégben csináltam egy Debian szervert, Asterisk-el, MariaDB-vel, ODBC-vel, WEBRTC-s eléréssel. Márcsak a CDR adatainak realtime átvitele van hátrea MariaDB-be. Erre még rá kell jönnöm. Erre jó a Debian, meg PHP, NginX (gondolom Apache-ra is).

Én még mindig nem látom, hogy mi lenne vele a probléma. Bici esetében a laptopban lévő két GPU okozta a gondot, de ez minden disztrón, sőt, Windows alatt is szopás lehet. Tehát nem az AMD GPU-val volt a gond, hanem, hogy mindjárt kettő is van belőle! Sőt, ha Intel IGP és NV dedikált GPU van, azok között még nagyobb szívás váltani, mert zavarja egymást a kettő, meg NV-hez csak a zárt drivert lehet normálisan használni, amihez mindenféle dkms kernelmodullal kell szórakozni, ami miatt meg a kernel nem frissíthető normálisan, így összességében 100× nagyobb rémálom az 1-2 AMD GPU-s felállásnál.

Egyébként nemsokára teljes használatba veszem az asztali gépet, amit eddig csak néha használtam, akkor is csak offline windowsos játékkonzolnak, és az lesz a fő gépem, Linux is rákerül, majd megírom a tapasztalataim. Nekem egy AMD RX570 van (GCN4), ez az egyetlen GPU a gépben, elvileg vaj simán, mindenféle kernelparaméter és fekete mágiás voodoo varázslás nélkül mennie kéne első pöccre friss Arch installal, a kernelben benne lévő amdgpu driverrel, ehhez csak a linux-firmware-t kell feltenni, meg a mesa-t, és hardveres dekódoláshoz meg a libva-mesa-driver csomagot telepítve. Erre a gépre egyébként lehet Archot teszek, a systemd ellenére is, mert ezen linuxos játék is fog menni, amikkel szívás lehet systemd-mentes disztrón. Még nem teljesen döntöttem el, hogy nem mégis Gentoo lesz-e, de az Arch felé hajlok, mivel kevesebb munkával jár.

Ezek alapján minden jónak tűnik. De azért azt kéne tudni, hogy pontosan milyen SSD-kről van szó, gyártó, pontos típus.

Az alignálás valószínű rendben van, de én egy sudo fdisk -l kimenetet megnéznék a biztonság kedvéért.

Szia!

WD WDS100T2B0A 1TB SATA SSD

fdisk -l:

Disk /dev/sde: 119.25 GiB, 128035676160 bytes, 250069680 sectors
Disk model: SAMSUNG SSD 830 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C2409425-76F4-5D4F-BB91-006A5CE87158
Device     Start       End   Sectors   Size Type
/dev/sde1   2048 250066943 250064896 119.2G Linux filesystem
Disk /dev/sda: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC  WDS500G2B0A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6125EBAE-B56E-4E10-AC20-6553DA6C9CE1
Device     Start       End   Sectors   Size Type
/dev/sda1   2048 976773119 976771072 465.8G Linux filesystem
Disk /dev/sdc: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC  WDS100T2B0A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E1054FD9-3426-014C-A586-245D505A59A9
Device          Start        End    Sectors   Size Type
/dev/sdc1        4096     618495     614400   300M EFI System
/dev/sdc2      618496 1808582336 1807963841 862.1G Linux filesystem
/dev/sdc3  1808582337 1953520064  144937728  69.1G Linux swap

Ugralnak a /dev/sdX-ek ossze-vissza az fdisk -l kimeneteben. Ez normalis?

Udv. core2

A Samsung 830-ason jó a partícióeltolás. Viszont a WD Blue 3D 1 terás SSD-den az utolsó, azaz harmadik partíció eltolása nem jó, az 1808582337 kezdőszektor nem osztható sem 8, sem 16, sem ezek többszörösével. Talán a Gparted tudja javítani az eloltást, de Live rendszer alól kell csinálni, nem futhat róla a rendszer, míg a Gparted dolgozik azon a partíción.

Az normális, hogy a /dev/sdX-ek ugrálnak, minden bootkor másik meghajtó lesz sda, sdb, stb.. Ezért is kell fstab-ban meg bootmanagerekben /dev/eszköznév helyett partíció UUID-t vagy fájlrendszer UUID-t használni, az nem változik.

Frawly

Te a zsh shell-ed alatt állítottál olyat, hogy a historyban ne legyen duplikáció? Találtam egy ilyen lehetőséget, de abszolút nem reagál rá. Továbbra is duplikálva kerülnek be a parancsok. Ezt használtam beírva a .zshrc -be de már a .bashrc-be is:

export HISTCONTROL=ignoredups:erasedups

De probáltam csak ignoredups-al és erasedups-al is. Teljesen hatástalan. Már azon gondolkodtam, hogy zsh-ról visszaállok bash-ra, és ott is kipróbálom, mert lehet hogy csak zsh kakil rá.

Nem használok zsh-t. Pedig tetszene, de azért nem rakom fel, mert mindenhol a Bash/sh a sztenderd, a zsh meg ezekkel nem teljesen kompatiblis, és ez visszatart tőle, pedig a feature-ei kellenének.

Várjuk meg kékluficetet, ő használ zsh-t, tőle kérdezd.

Én a grml config-al használom, ott már alapból így van, nézd meg azt.

Frawly: még soha nem volt kompatibilitási problémám zsh miatt.

You may corrupt the souls of men, but I am steel. I am doom.