Csak vaktába lövöldözök: csináld végig a konfot a GUI-ról és nézd meg hogy néz ki a config fájl. Csinálj erről a konfig fájlról egy másolatot. Indítsd újra a gépet és ellenőrizd, hogy megmaradt-e a fájl tartalma. Root-ként használod a rendszert vagy user-ként? Próbáld meg, hogy root-ként konfolod és újraindítás után root-ként használod. Akkor se tartja meg a beállításokat ?

Memento Mori

Igen végignéztem a dolgot. Van két konfig fájlja az openrazer-nek.
cat ~/.config/openrazer/persistence.conf
[DeathAdder35G]
dpi_x = 1800
dpi_y = 1800
poll_rate = 1000

cat ~/.config/openrazer/razer.conf -> ebből csak az utolsó sor lehet érdekes szerintem
# Apply effects saved to disk when daemon starts
restore_persistence = False

Amikor beállítottam a DPI értéket a razergenieben akkor átírta a persistence configot erre:
cat ~/.config/openrazer/persistence.conf
[DeathAdder35G]
poll_rate = 1000

supi007 userként használom a gépet és az openrazer-daemon is úgy lett engedélyezve a systemctl-ben ezzel:
systemctl --user enable openrazer-daemon.service

[ Szerkesztve ]

Hello darkness, my old friend...

a restore_persistence változó az pontosan mit csinál? hol is van a dokumentáció?

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Ezt találtam dokumentáció címszóval

Amúgy én sem teljesen értem mert hiába állítottam True/False értékre olyan mintha semmit nem csinált volna

Hello darkness, my old friend...

akkor passzolom, ha az RTFM se segít akkor ott már nagyabaj.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Favágó módszer: miután beállítottál mindent, fogod a konfig fájlt és azt mondod neki, hogy
chattr +i ~/.config/openrazer/persistence.conf
chattr +i ~/.config/openrazer/razer.conf.

Ettől "immutable" lesz a fájl, azaz nem lehet majd módosítani. Bár nem állítom, hogy a daemon nem fogja összecrashelni magát tőle..

Esetleg valami udev szabályt írni hozzá (mint itt), vagy megnézni, hogy a daemont felparaméterezve nem lehet-e indítani...

[ Szerkesztve ]

Hát nekem már csak ez jutott

urandom0 köszi megpróbálom ezt is hátha. Ha összeszarja magát tőle akkor majd visszaállítom.

Hello darkness, my old friend...

Itten 2020-ban már problémáztak ezen: [link]
Ekkor egy DeathAdder 2013 volt a tárgy, a tied egy 35G

Lehet a legutolsó OpenRazer-ben már nincs ilyen hiba.
[link]

[ Szerkesztve ]

Memento Mori

Köszi megnéztem ezt is. Végül úgy néz ki találtam megoldást a hibajegyek között turkálás közben. Köszi szépen mindenkinek a segítséget és az iránymutatást.
Ez a ticket volt a megoldás. A persistence fájlt kellett ro-ra állítani miután kitöltöttem a megfelelő értékekkel. Bár a DeathAdder3.5G kicsit fura mert csak 1 tengelyre van DPI értéke valamiért. De így egyelőre működik a dolog. Lehet megpróbálom majd úgy is, hogy mindkét tengelyre megadom a DPI értéket.
DeathAdder35G]
poll_rate = 1000
dpi_x = 1800
dpi_y = 0

Lehet akkor megpróbálom majd a git-eset is. Köszi!

[ Szerkesztve ]

Hello darkness, my old friend...

Úgyúgy Közben megnéztem. Ha mindkét tengelyre megadom a DPI értéket akkor nem működik a dolog. Csak akkor ha az "y" tengely 0.

Hello darkness, my old friend...

Adott egy laptop Arch+Gnome kombóval.
A root partíció luks-al titkosított.
Milyen megoldással tudnék a rendszerről egy olyan backup-ot csinálni, amivel teljes ssd törlés után, szintén titkosított root-ra vissza tudnám menteni a fájlokat?

Gondolom valami olyan megoldás volna ideális, ami elérhető egy Arch installer pendrive boot-ot követően.

[ Szerkesztve ]

Nem egészen világos a kérdés: a titkosított állapotról szeretnél backupot (offline), vagy a feloldottról (offline/online)? Előbbi esetben legfeljebb hw-encrypted drive-ról lehet szó - ez esetben sima disk clone, utóbbiban a target lehet sw-encrypted, ellenben ez egy sima sync.

https://www.coreinfinity.tech

dd miért nem jó ? Én dd -vel csinálnék egy másik lemezre egy teljes diszk mentést tokkal-vonóval, amire a dd határozottan képes. (Vagy nem értem jól, mit szeretnél.)

Memento Mori

Bocsánat, pontosítok.
Feloldott állapotról szeretnék (cryptsetup open) valamiféle fájlszintű backupot.
Aztán valamikor ugyanerre, de teljesen újra partícionált ssd-re vagy éppen másik ssd-re tenném vissza. Lehet titkosítatlan vagy éppen feloldott tikosított partíció is.
A lényeg, hogy maga a titkosítás ne legyen mentve, mivel nem tudni milyenre teszem vissza. Tehát nem byte-szintű backup, hanem fájl-szintű lenne. Lehetséges ilyen megoldás?

[ Szerkesztve ]

Na most lehet, hogy tévedek, de a titkosítás fájlrendszer szinten valósul meg. Ha átmásolod az adatot egy backup keretében egy másik lemezre, aminek nincs titkosítva a fájlrendszere, akkor elvész a titkosítás. (Persze bukik az okfejtésem, ha nem fájlrendszer szinten van a titkosítás.)

Memento Mori

Fájlrendszer szinten van titkosítva. A root partíciót titkosítom és /dev/mapper alatt van nyitva és mountolva.
Nagyjából így készült és lett rá telepítve a rendszer:
cryptsetup -y -v luksFormat /dev/sdb2
cryptsetup open /dev/sdb2 root
mkfs.ext4 /dev/mapper/root
mount /dev/mapper/root /mnt

A tervek szerint a restore is valahogy úgy zajlana, hogy a /mnt-re másolódjon vissza minden. Legyen az éppen titkosított (/dev/mapper/root) vagy éppen titkosítatlan (/dev/sdb2) ext4 partíció.

"Ha átmásolod az adatot egy backup keretében egy másik lemezre, aminek nincs titkosítva a fájlrendszere, akkor elvész a titkosítás."

Pontosan azt szeretném, hogy a fájl backup (kivéve ~/Documents, ~/Pictures, etc. könyvtárak, ezekről nem kell backup) ne legyen titkosítva. Azért szeretném ezt, mert visszaállításkor lehet, hogy más titkosítású partícióra fog kerülni. De az is lehet, hogy nem lesz titkosítva a partíció. A lényeg, hogy maga a backup ne tartalmazzon titkosításra utaló információt.

Visszaállítás után, ha mondjuk titkosítatlan partícióra teszem, akkor az fstab-ot kelljen csak beállítanom, illetve a hooks-ból esetleg kivenni az encrypt modult. Aztán egy mkinitcpio -P gondolom elég és máris futhat encrypt néküli helyről is.

Tehát ha jól gondolom, akkor fájlszintű backup kellene ami mondjuk kihagyja a home media tartalmakat és elindítható egy Arch telepítő pendrive alól.
Vagy tévednék?

[ Szerkesztve ]

Akkor szerintem egyet beszélünk. rsync-kel csinálsz egy backup-ot egy külső lemezre, ami nem titkosított fájlrendszerrel bír.
A visszaállítás is rsync-kel fog történni. Átmásolod a titkosítatlan adataidat egy lemezre, aminek a fájlrendszere titkosítva van, tehát a másolás pillanatában válnak a fájlok újra titkosítottá.

Memento Mori

Így van, rsync, rclone, Timeshift, FreeFileSync... bármi, ami fájlszinten megy és megbízhatóan működik.

supi007, urandom0: Köszönöm. Ezek indíthatóak egy telepítő pendrive alól?

Persze.

Szuper. Akkor kezdem is a próbát az rsync-el majd

supi007, urandom0, sh4d0w: Köszönöm a segítséget.

Chrome browser-ben és esetleg az ugyanarra építő Opera-ban van lehetőség HW Video Acceleration használatára?
Jelenleg így néz ki a helyzet:
$ vainfo
vainfo: VA-API version: 1.15 (libva 2.15.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.4.4 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   :    VAEntrypointVideoProc
      VAProfileNone                   :    VAEntrypointStats
      VAProfileMPEG2Simple            :    VAEntrypointVLD
      VAProfileMPEG2Simple            :    VAEntrypointEncSlice
      VAProfileMPEG2Main              :    VAEntrypointVLD
      VAProfileMPEG2Main              :    VAEntrypointEncSlice
      VAProfileH264Main               :    VAEntrypointVLD
      VAProfileH264Main               :    VAEntrypointEncSlice
      VAProfileH264Main               :    VAEntrypointFEI
      VAProfileH264Main               :    VAEntrypointEncSliceLP
      VAProfileH264High               :    VAEntrypointVLD
      VAProfileH264High               :    VAEntrypointEncSlice
      VAProfileH264High               :    VAEntrypointFEI
      VAProfileH264High               :    VAEntrypointEncSliceLP
      VAProfileVC1Simple              :    VAEntrypointVLD
      VAProfileVC1Main                :    VAEntrypointVLD
      VAProfileVC1Advanced            :    VAEntrypointVLD
      VAProfileJPEGBaseline           :    VAEntrypointVLD
      VAProfileJPEGBaseline           :    VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline:    VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:    VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:    VAEntrypointFEI
      VAProfileH264ConstrainedBaseline:    VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          :    VAEntrypointVLD
      VAProfileVP8Version0_3          :    VAEntrypointEncSlice
      VAProfileHEVCMain               :    VAEntrypointVLD
      VAProfileHEVCMain               :    VAEntrypointEncSlice
      VAProfileHEVCMain               :    VAEntrypointFEI
      VAProfileHEVCMain10             :    VAEntrypointVLD
      VAProfileHEVCMain10             :    VAEntrypointEncSlice
      VAProfileVP9Profile0            :    VAEntrypointVLD
      VAProfileVP9Profile2            :    VAEntrypointVLD

Az igazat megvallva keresgéltem a témában, de nem találtam eddig megoldást. Nem csak YT videókat szeretnék gyorsítani, hanem egyéb oldalakon lévőket is. Emiatt olyan plugin-ek használata, amik külső lejátszóban nyitnak meg YT videokat sajnos nem jelentenek igazi megoldást.
Tényleges browser-en belüli gyorsítás volna ideális vaapi használattal. Évek óta elvoltam enélkül ugyan, de szeretném a laptopot akkuról is használni és ott jól jönne.
Egyáltalán 2022-ben van erre lehetőség vagy még mindig ennyire periférián van a linux desktop?

Deja vu....januárban kb ugyanezt kérdezted, ez a válasz nem segített?

Mivel Arch-ot használsz, az nem rakja fel a szükséges programokat, tuti, hogy a hardveres gyorsítás csomagjait is fel kéne raknod sk!

[ Szerkesztve ]

Minden gyorsításhoz szükséges csomag fent van. Kodi és barátai szépen használják is.
Kizárólag browseren belül vannak gondok.
Viszont akkor valamiért nem működött (pedig nem wayland-et használtam akkor sem), de most működik az alábbi "intel-media-driver" mellett is:
$ opera --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoderTényleg nem tudom mi a változás azóta, de most egy YT 4K/60Hz anyagot elindítva rövid időn belül vissza esik a cpu 800MHz/15% körüli terhelésre is akár. Szóval elméletileg működik. Viszont mindkét paraméter kell.

(Gyakran megesik velem, hogy miután leírok egy problémát hamar meglesz saját kútfőből a megoldás. Ez lett most is )

[ Szerkesztve ]

Rémlik hónapokkal ezelőttről, hogy Chrome-mal kapcsolatban volt valami olyan gond a gyorsítással, ami miatt ki is kellett kapcsolni a hw acc-ot, elképzelhető, hogy abba futhattál bele, mostanra viszont az a gubanc kiküszöbölődött!

Gyakran megesik velem, hogy miután leírok egy problémát hamar meglesz saját kútfőből a megoldás. Ez lett most is

Ez egyébként teljesen normális, persze csak akkor működik, ha már benne van a fejedben a megoldás, akár csak sok különálló részletekben is... Azért a probléma leírásakor áll össze az infórészletekből a megoldás, mert az íráshoz az agy más részét kell beüzemelni és így végigmenve a problémán, az agy már dobja is a megoldást.

Lehet tényleg erről van szó.

Más:

Egy ideje küzdöttem, hogy win-hez hasonlóan a laptopomon lehessen energiatakarékosan az nvidia (rtx 2060) vga-t használni zárt driver mellett kilépés/újraindítás nélkül. Mégpedig olyan módon, hogy csak szükség esetén legyen bekapcsolva, amúgy ne fogyasszon energiát.
Tegnap sikerült beüzemelnem a hybrid megoldást és tényleg nem üzemel alapjáraton. Nem csak inaktív, hanem energiát sem kap. A laptopom ezt egy led-el jelzi, szóval biztosan energiatakarékos módban van ilyenkor.

Egyetlen kritérium, hogy az adott program indításakor pár változót be kell állítanom.
Az environment-be nem tehetem fixre, mert akkor annyi a hybrid megoldásnak.

Például a Superposition vga tesztet így indítva parancssorból bekapcsol az nvidia vga és azon is fut:
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME="nvidia" __VK_LAYER_NV_optimus="NVIDIA_only" __GL_SHOW_GRAPHICS_OSD=1 unigine-superposition

Egyetlen gondom csak, hogy fixen nem sikerül a Superposition.desktop fájlba megfelelően beállítanom.
Ha csak simán az "Exec=" után beírom az egész sort akkor eltűnik az ikon is, szóval valami nem tetszik neki formailag.
Ha az alábbi megoldás van, akkor van ikon, de nem indul a program.
Exec=sh "__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME="nvidia" __VK_LAYER_NV_optimus="NVIDIA_only" __GL_SHOW_GRAPHICS_OSD=1 /usr/bin/unigine-superposition"
Próbáltam úgy is, hogy az sh-hoz tartozó " heylett ' volt használva, de a változók idézőjele maradt. Hátha ...

A kérdésem tehát az volna, hogy miként lehetne a desktop fájlokat úgy megírni/átírni, hogy ezekkel a változókkal együtt induljon pár alkalmazás?

[ Szerkesztve ]

fájlrendszer szinten titkosírással írod a naplódat, amit a többi motyód mellett tartasz az éjjeliszekrényen.

blokkeszköz szinten a sima folyóírással írt naplódat zárod be egy megfelelően titkosított széfbe a többi motyóddal együtt.

így világos a különbség?

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Persze, világos, köszönöm. Amikor hibásan említettem erre gondoltam csak helytelen kifejezést használtam.
Itt igazából szépen leírják: "operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else"

Ergo esetemben titkosítom, feloldom, formázom, mountolom. Nem érdekli mire van formázva és hova mountolom. A teljes ssd titkosítást az EFI macera miatt nem tettem meg, mivel arról is boot-olok. Az maradt titkosítatlan.

[ Szerkesztve ]

mondjuk ide hozzá kell tenni a blokkeszköz lehet egy fiztikai blokkeszközön lévő partíció is (asszem ez igaz erre is)

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Nem lehet, hogy a leírásban a filesystem-el utalnak igazából erre? Végülis az egy partíció a blokkeszközön/partíciós táblán, ami valamire meg van formázva. Esetemben erre a partícióra az blokkeszközön sdb2-vel hivatkozok. (már ha jól értem a dolgot)

öö nem egészen. a fájlrendszer az egy absztrakciós réteg egy blokkeszközön vagy egy azzal analóg dolgon. nem maga a partíció.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Ezt tudom, de mi mást érthetnek egy blokkeszköz titkosítás magyarázatánál.
"operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else"

Lehet akkor helyesen így szólna talán:
"operates below filesystem layer: does not care whether the content of the encrypted block device is a partition, a partition table, a LVM setup, or anything else"

szerintem teljesen egyértelmű.

fájlrendszer szintje alatt működik: nem számít neki hogy a titkosított blokkeszköz tartalma fájlrendszer, partíciós tábla, LVM kötet vagy bármi egyéb.

vagy most elbeszélünk egymás mellett?

szerintem ez a rész azt hivatott kihajgsúlyozni, hogy a titkosítás blokkeszköz szintű, azaz a titkosított egységet feloldás után blokkeszközként tudod használni, tudod mondjuk formázni egy fájlrendszerre.

gondolom azt egyszerűsítették le hogy a titkosítást több szinten lehet megoldani, a lowest level a hardveres, efölött van a blokkeszköz szintű, a fájlrendszer is lehet titkosított illetve a fájlrendszeren tárolt állomány önmaga is lehet az (mondjuk egy titkosított archívum)

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Szerintem ugyanarra gondolunk, mindketten tisztában vagyunk azzal, hogy maga a titkosítás blokkeszköz szintű (azaz nem maga fájl van titkosítva).

Talán kicsit másképp fejezzük ki magunkat, én talán kissé pontatlanul is. Az egész abból az válasz elírásombol indult ki, hogy a fájlrendszerem van titkosítva, miközben magára a root partíciómra (a partíciós táblán belül jelzett területre) gondoltam. A folyamatból is kiderül, hogy eleve nem lehet a fájlrendszer titkosított, de egy hozzászólásra reagálva sajnos elírtam és fájlrendszerként utaltam rá. (#84767)

cryptsetup -y -v luksFormat /dev/sdb2 (partíciót titkosítom)
cryptsetup open /dev/sdb2 root (titkosított partíciót feloldom, mappelem)
mkfs.ext4 /dev/mapper/root (létrehozom a fájlrendszert a feloldott/mappelt eszközön)
mount /dev/mapper/root /mnt (telepítéshez mountolom)

Szóval, elképzelhető, hogy kicsit túlelemeztük vagy épp elbeszéltünk egymás mellett (vagy éppen a szokásos pongyolaságommal fogalmaztam - sry).
Mindenesetre az piszok jó, hogy minden apróságra figyeltek és korrigáljátok.
Így biztosan nem érti félre senki. Szóval köszönöm szépen a pontosítást.

[ Szerkesztve ]

No végre...fenn van a Mint 21 Cinnamon, Mate, XFCE ízekben, persze ez még a beta iso, de Mint esetén ez semmit nem jelent. [link]

#84724 :+1

A dolog furcsasága ha megnézed a telepítési naplót kétszer fut le a grub-install és a második alkalommal omlik össze a rendszer(linux mint alatt, ezt vettem észre elferdült szemöldökömmel wtf).
Ha meg van a boot mappa(nem az efi partición) akkor manuálisan utólag telepítheted a sudo grub-install /dev/sda paranccsal (mivel liveból fut így nem kell jelszó se értelemszerűen).Bár (talán) számolni kell azzal hogy a hátra maradt folyamatok így nem hajtódnak végre.Vagy kockáztathatsz ha meg adod grub-install-nak a efi particiót.

Remélem itt elfér - https://sites.google.com/site/geriprojekt/ - https://github.com/kgregoryan - Az ember téved,a gép hibázik.

linux mint 20.3 cinnamon
hogyan tudom beállítani, hogy egy jelszó nélküli "felhasználó" automatikusan bejelentkezzen gép indításakor?

megtaláltam, ne keressétek

Akkor egyezzünk ki egy gamma-teszterben. Egyébként ezen a notin még mindig a 19.3-at nyúzom. Szerintem kihúzom vele, amíg kapja a támogatást (2023 április), aztán kap egy cleaninstallt.

"A valóság az, ami akkor sem tűnik el, ha már nem hiszünk benne." - PKD \\\ CTRL+ALT+BAKANCSTALP ///

Lehetek akár theta-teszter is, nkem mindegy! Teljesen jó az a 19.3, sőt pár hónapja cseréltem le külhoni baráti népek egyik gépén a 18.03-at, aszongya a user, hogy neki teljesen jó volt az, minek cserélni, de szerencsére nem tudott mit csinálni, mert a 120gigás SSD-t is cseréltem 500gigásra a gépben. Az Elitebook workstation állapota alapján a koma még 15 év múlva is ugyanígy használta volna a gépet meg az OS-t. Ami persze egyáltalán nem rossz dolog.

Így legalább 5 évig megint el lesz vele gond nélkül. A stabil belakott rendszert én sem szívesen szántanám be, ha nem muszáj.

"A valóság az, ami akkor sem tűnik el, ha már nem hiszünk benne." - PKD \\\ CTRL+ALT+BAKANCSTALP ///

Kétévente pár napig nekem is szokatlanság van a tiszta telepítés után, szinte lehetetlen totál ugyanazt a megjelenést, fontokat élsimitással belőni plusz az addig megszokott programok közül is néha kiesik egy-kettő, no az nagyon idegesítő tud lenni. De hát ilyen ez a popszakma.

Leszedtem a beta fahéjat, majd felrakom egy külső SSD-re.