-
PROHARDVER!
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
-
#75135488
törölt tag
Persze. [link]
Eredetileg a jelenlegi 545-ös driverrel próbálkoztam, de nem sikerült összehozni.
Mivel azt írják az 525-től elkaszálták a VA-API támogatást, megpróbáltam régebbi driverrel.
Ez alapján most a régebbi (470-et néztem meg, ehhez volt opencl is, az 510-hez nem találtam) driverrel próbáltam libva-vdpau és nvidia-vaapi (libva-nvidia) megoldással is, de nem jött össze.
Lehet én szúrok el valamit talán, fene tudja.
Normál vdpau megy (pl. Kodi), de valami vaapi layer beüzemelése hozzá már nem. -
#75135488
törölt tag
Arch-on normal Linux kernel (tehat nem LTS, ZEN, stb) eseten van lehetoseg nvidia driver helyett nvidia-dkms csomagokat hasznalni?
Megprobalkoznek egy regi nvidia-511-dkms driverrel, hatha azzal meg mukodik a va-api a chromiumban.Eleg lehet vajon konzolba boot-olni es lekapni az nvidia, nvidia-utils, nvidia-settings, opencl-nvidia csomagokat es felrakni a dkms verziot?
-
#75135488
törölt tag
Chromium HW-VideoAccel gondom van NVidia kártyával
Arch + Gnome , Amd rizsa + NVidia 1660Ti
- zárt NVidia csomag fent (nvidia [545.29.06], nvidia-utils, nvidia-settings, opencl-nvidia)
- libva-nvidia-driver [0.0.11-1] [link]ENV-ben a driver beállítva:
$ printenv | grep -i libvaLIBVA_DRIVER_NAME=nvidiaA vainfo és vdpauinfo kimenetek: [link]
Chromium flags: [link] és gpu: [kép]
Mégis amikor nézek YT vagy Twitch stream-et, cpu-ból megy a dekódolás.Mit szúrok el?
-
#75135488
törölt tag
válasz
ubyegon2
#92854
üzenetére
Ezzel egyébként teljesen egyetértek.
Különösebben engem sem foglalkoztat az ssd trim és hasonló dolgok. Hamarabb cserélem azért az ssd-t, (1) mert kevés a tárhely, (2) eladom/odaadom a géppel együtt vagy (3) épp legutóbb amikor ellopták a gépemmel együtt.Mondjuk tavaly sikerült egy cache nélküli vackot venni az egyik gépbe, na az maga volt a katasztrófa
Olcsó volt, vacak volt.
Mivel még hardver szinten sem szoktam nagyon foglalkozni velük, kényelmi okból Samsung felé húzok leginkább. Azzal kisebb az esély, hogy melléfogok esetleg, mint a többivel.Kizárólag a kiinduló kérdés miatt mentem én is bele ennyire a dologba.
Nálam annyi ez az egész trim mizéria, hogy amikor éppen eszmbe jut "talán" kiadok egy ilyen parancsot. De leginkáb ...., nem. Amúgy fogyóeszközként tekintek rá.
De azt hiszem a témát rendesen körüljártuk. -
#75135488
törölt tag
Ha esetleg más is belefutna (Arch +Gnome) :
Frissült a gjs csomag -> gjs (2:1.78.1-1 => 2:1.78.2-1)
Ez nálam azt eredményezte, hogy a "gnome-extensions" panelon bármelyik extension beállítását nyitottam meg, az a panel pár másodperc múlva eltűnik, de elméletileg nyitva maradt és ezért egy másikét meg sem lehet nyitni.
Visszatéve a korábbi csomagot újra működik.
-
#75135488
törölt tag
válasz
ubyegon2
#92844
üzenetére
Igen van értelme logikai meghajtón futtatni.
Ahogy én tudom a dolgokat ... (tévedhetek)
Egy ssd lemezvezérlő hardver (ata vagy nvme) honnét tudja melyik blokkokat lehet felszabadítani a TRIM vagy DEALLOCATE megoldásával?
Mert ugye nem ismeri a tárhelyen lévő tartalmat.Onnét tudja, hogy megmondják neki.
És itt jön képbe a discard és az fstrim.A discard fájlrendszer paraméter, ami annyit csinál, hogy minden "törlés-alapú" műveletnél (delete, move) a handler küldi a kérést és a paramétereket a lemezvezérlőhöz.
Gyakorlatilag folyamatosan megy a TRIM vagy DEALLOCATE a hardveren.
(Kivéve NTFS-3G használatkor, mert az nem küldözget, de a kernelben lévő ntfs viszont igen)Az fstrim egy program, ami végigjárja az adott fájlrendszert a handler segítségével és összegyűjti a felszabadítható területeket, ezek paramétereit átadja a lemezvezérlőnek és az ata-TRIM vagy nvme-DEALLOCATE megoldással elrendezi.
(Ez működik az NTFS-3G-vel is, viszont nem működik a kernelben lévő ntfs-el)És itt jön a csavar ...
Logikai meghajtó esetében van egy layer a fájlrendszer felett.
Ez az én Luks-al kódolt lemezem esetében a DM-Crypt.
A DM-Crypt hivatalosan nem javasolja a TRIM használatát, mivel adatszivárgáshoz vezethet. Ezt mindenki saját felelősségre használhatja.Mint fentebb írtam: "
Encrypted partíció esetében némi adatszivárgást jelent amúgy, de nálam ennyi belefér"Gyakorlatilag az "allow-discard" paraméterrel mondom meg a dm-crypt-nek a grub-ban, hogy amikor induláskor feloldja a lemezt, akkor fogadjon el a fájlrendszert alkalmanként végignéző fstrim-től ilyen kéréseket és ezeket továbbítsa a lemezvezérlőhöz.
(Hogy ez az alkalom cron alapú [fstrim.timer] vagy kézi indítású egyéni meglátás kérdése.
Mivel esetemben ez adatszivárgással jár, én kézzel futtatok néha, ha épp eszembe jut.)
Az fstab-ban nem adtam meg a /dev/mapper/root eszköz ext4 mounthoz "discard" opciót, így a folyamatos "TRIM" nem megy.Amúgy szerintem a fejekben azért van sokszor kavar, mert tudomásom szerint a TRIM szabvány anno ererdetileg leírta a protokol szoftveres (OS-en történő) és az eszköz (S-ATA) hardveres megvalósítását is. Viszont ekkor még nem volt értelmezve nvme, sas, usb és egyéb logikai eszközökre.
Utóbbiaknál változott a hardveres implementáció, de OS-oldalról csak egy kiterjesztés történt. Ezért kb. OS-felől minden ilyesmi TRIM-nek látszik, de hardver oldalról már nem.Amúgy egy táblázat a discard, fstrim linux oldalról történő alkalmazásáról különböző fájlrendszereken: [link]
A dm-crypt megoldás discard elfogadáshoz és a figyelmeztetés: [link]
-
#75135488
törölt tag
válasz
#75135488
#92839
üzenetére
Az előző folytatása ...
Ez pedig a laptopon ugyanez. Most telepítettem és pakoltam tele cuccokkal.
Ebben az encrypted partíció m2.sata eszközön van.
Fstrim egymás után 2x lefuttatva csak példaként.
Néhány helyen régebben láttam encrypted-re rosszul beállított discard-ot. Olyankor mindig a teljes tárterületre futott le a user-nek. Ez itt most jó.Persze a tévedés jogát mindig fenntartom.
Lelkes vagyok, nem szakértő. -
#75135488
törölt tag
válasz
ubyegon2
#92838
üzenetére
Na akkor újra:
Amiről te beszélsz az egy sata vagy nvme hardver eszköz.
Amiről én beszélek, az egy logikai eszköz. Egy encrypted block device.
A logikai eszközön, esetemben a /dev/mapper/root eszközön engedélyezhető a discard funkció és mint ilyen eszközön futtatható az fstrim parancs.
Erre jelen esetben nem nvme vagy sata eszközként kell tekinteni, hanem egy logikai eszközként.
Nem volna szerencsés magát a titkosított blokkokat pakolni a hardveren ide-oda.Mások is használják: [link] , [link] , [link]
Működési sajátossága miatt:
- nem indítom el az időzített fstrim funkciót (fstrim.timer)
- nem használok állandó discard-ot (fstab-on belüli discard funkció)
- kizárólag a kernel paraméterben engedem, hogy fogadjon discard kérést (discard!=trim)Alkalmanként én futtatom és végzi a dolgát a dmcrypt blokkon belül:
Fstrim a /dev/mapper/root logikai blokkeszközön, ami egy decrypted partíció egy nvme eszköz egyik partícióján (/dev/nvme1n1p2) -
#75135488
törölt tag
válasz
ubyegon2
#92831
üzenetére
Teljesen jól látod, a discard opció az fstab-ban egy folyamatos trim, ami sata command.
De ez (allow-discard) jelen esetben csak azt jelenti, hogy elfogadja a discard opciót.
Nem szabad elfelejteni, hogy encrypted a root partíció amire ez meg van adva.
Mivel nem a "cryptsetup --allow-discards" opcióval dolgozom fixen, én kernel opcióként adom meg. Gyakorlatilag a /dev/mapper/root-ra értelmezve.
Az eredmény csak annyi, hogy ilyenkor elfogadja, ha valamiért ki van adva az fstrim parancs.
(Encrypted partíció esetében némi adatszivárgást jelent amúgy, de nálam ennyi belefér)
(Amúgy van, hogy hónapokig elfelejtek fstrim-et használni. Nagyon nem aggaszt egy ssd életciklusa. Fogyóeszközként tekintek rá. Backup pedig mindig van egy online és egy offline eszközön)De javíts ki nyugodtan, ha rosszul használom
-
#75135488
törölt tag
válasz
ubyegon2
#92829
üzenetére
Saját Arch telepítő script-hez lesz.
Luks encrypted root partíciót használok minden gépemen a sima EFI mellett és a grub-ba kerül bele, hogy induláskor a "cryptsetup open" bekérje a jelszót és a /dev/mapper/root alatt elérhető legyen. Aztán indulhat a rendszer.Eddig kézzel kellett telepítéskor ezt megadnom, ami nem volt kényelmes. Most megírja magának a paramétert, nem én írom be.
-
#75135488
törölt tag
válasz
#79484416
#92827
üzenetére
Hogy a fene ...
Az aposztróf-on átsiklottam és ezért nem akarta kiértékelni.
Pedig tudhattam volna, használom is script-ben, illetve egyéb prg nyelvekben is így van.
Köszi, hogy felhívtad rá a figyelmem. Így tökéletesen működik.
(Lehet le kéne mára pihennem mert olyan bakikat vétek ma ...)
-
#75135488
törölt tag
válasz
#79484416
#92825
üzenetére
Az alábbi sor már kicseréli a GRUB_CMDLINE_LINUX="" részt/sort egy ideiglenes test_grub.txt fájlban.
De ott ugyanúgy elakadtam, hogy az xxx helyére hogyan tegyem a blkid által visszadott UUID-t.sed -i 's/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX="cryptdevice=UUID=xxx:root:allow-discards"/g' test_grub.txtTalán valami: blkid -s UUID -o value /dev/nvme1n1p2 | sed ... ??
De akkor más paraméterezés kell a sed-nek. Agyalni kell még ezen ...
-
#75135488
törölt tag
válasz
#79484416
#92823
üzenetére
Nem. Amit írtál az, ha jól értelmezem, akkor a komplet sort beírja.
Sorry, ha pontatlanul fogalmaztam.
A sor maga megvan már. Hogy pontos legyek ennyi van belőle induláskor
(pontosabban grub install után):
GRUB_CMDLINE_LINUX=""Azt szeretném elérni, hogy mondjuk ilyesmi legyen:
GRUB_CMDLINE_LINUX="cryptdevice=UUID=ddfbfdda-e23b-4d63-ac18-0949f436213e:root:allow-discards"Tehát valahogy megtalálni ezt a sort és ebben a sorban a két "" jelet és oda beékelni a UUID-t (és persze a többi sallangot is)
Ez a "megkeresem a megfelelő részt és oda beszúrom" megoldás az, amit nem találok.
Lehet rossz kulcsszavakkal keresek??Vagy jobb lenne a komplett sort lecserélni? (sed??)
Update: sed lesz a barátom, úgy látom
-
#75135488
törölt tag
válasz
#02705152
#92820
üzenetére
Úgy áll, hogy például QT-alapú obs-studio esetében még az XSHM-et vagyok kénytelen használni screen-capture esetében, mert a PipeWire megeszi a GPU-t.
Az XSHM pedig vacakul megy még QT_QPA_PLATFORM=wayland ENV mellett is.
Természetesen tisztában vagyok vele, hogy Wayland az ajánlott, de a Chromium (ungoogled) is bugzik nálam --ozone-platform=wayland vagy --ozone-platform=auto mellett is.
Szóval alkalmanként rápróbálok, de valamibe mindig belefutok, amiért nem használom.Voltak még gondok, de most nem jutnak eszembe. Apróságok, de tömegével.
Teljesen más:
Nem sikerül rájönnöm, hogyan tudnék egy "blkid -s UUID -o value /dev/nvmexyz" által visszaadott UUID-t valahogy "be-echo-zni" (de szép kifejezés) a grub 'GRUB_CMDLINE_LINUX="cryptdevice=UUID=xxx"' sorába, az "xxx" helyére.
Telepítő scripthez volna jó.Mivel lehetne ezt megcsinálni?
-
#75135488
törölt tag
válasz
#79484416
#92810
üzenetére
Köszönöm a tippet
Amikor a GDM-Login után nem indul a Gnome, akkor:
Ctrl+Alt+F1 - visszaadja a GDM Login-t
Ctrl+Alt+F3 - ad egy konzolt és root-ként belépve látom a logokat és újraindítható a gép szabályosan.Ez már egy kis lépés.
Kicsit reszelek a rendszeren még, törlöm a logokat és a következő hibánál konzolból az aktuális session logjait mentem egy fájlba.
Aztán indulhat a "Where's Waldo?" műveletubyegon2:
-
#75135488
törölt tag
válasz
ubyegon2
#92808
üzenetére
Munkás, tudom, így van
Időnként egy update is tud meglepetést okozni 1-1 eltört dependency miatt.
(Megjegyzem erre az Ubuntu LTS esetén is volt már példa)
Ez főleg akkor van, ha a user (azaz én ) is bénázik és nem együtt fut a normál repo és az AUR. De most már mindenre pikaur-t használok (régebben yay-t)
Néha viszont elég csak várni pár napot. Persze van, hogy vissza kell tenni 1-1 előző csomagot ideiglenesen. Emiatt nem is szoktam törölni a pacman cache-t.
(Mondjuk anno a Gnome 45-re ugrás eltört pár dolgot (sok shell-extension-t), de mostanra ezek is rendben vannak már)Régebben Ubuntu és társai voltak a gépeimen, de az utóbbi időben (20.04 óta) kezdett valahogy nem tetszeni. Aztán lett a natúr Arch+Gnome. Most valahogy ehhez ragaszkodom éppen. X11 pedig amiatt van, hogy sokminden nem úgy megy Wayland-en még szerintem, mint szeretném. Persze nem a Wayland hibája, egyszerűen pár mgszokott alkalmazás ilyen.
Alkalmanként engedem a GDM-ben és rápróbálok, de leginkább le van tiltva és így marad az öreg X11.Szóval maradnék ezen az Arch+Gnome45+X11 vonalon egyelőre.
Leszámítva ezt az igazán semmi kis hibát, hogy vagy indul vagy nem ( ) jól megszokott rendszerem van és kényelmes használnom. Működés közben már nem tapasztalok problémát.Update:
Elkezdtem a telepítést. A telepítő indulásakor már írja az nvidia i2c időtúllépést, szóval az valóban nem lehet gond. Csak gondoltam megemlítem... -
#75135488
törölt tag
válasz
ubyegon2
#92804
üzenetére
Rövidesen csinálok a laptopon egy reinstall-t.
Annyi változás lesz a mostanihoz képest majd, hol a pulseaudio helyett pipewire lesz a szükséges modulokkal (pl. pipewire-pulseaudio, pipewire-alsa)
A pipewire-alsa a Kodi miatt lesz. Jelenleg nem szereti a pipewire-pulseaudio-t és ALSA használattal kell indítani, hogy ne akadjon meg audio váltásnál. A 21-es verzióra ígérik a teljes támogatást.Továbbra is a GDM-et tenném fel, hogy kiderüljön a hiba majd. De tippre nem azzal van a gond, mivel maga a login screen megjelenik, beírom a jelszót, elveszi a képernyőt és láthatóan akarja is indítani a gnome-ot, de nem mindig sikerül elindulnia.
Emiatt én jelenleg nem a GDM-re gyanakszom, hanem a Gnome-ra, pontosabban valami olyanra amire annak szüksége van.
Persze simán tévedhetek, nem értek én ehhez sajnos. Még... majd belejövök Amint újra bekövetkezik a hiba és nem indul a Gnome a GDM-Login-t követően, akkor csinálok arról a boot eseményről egy pastebin bejegyzést.
Gondolom nem lesz rövid, de ott kell legyen valahol benne a "titok".Köszönöm az eddigieket
nemethg66:
Nem figyeltem a billentyűzetet, de kipróbálom ... hátha legalább a leállítás megoldható. Már az is megnyugtató lenne. Nem kéne paráznom, hogy fejreáll az ext4 (Luks-al titkosított) particica -
#75135488
törölt tag
válasz
ubyegon2
#92802
üzenetére
Arra gondoltam talán érdemesebb volna magára a boot eseményekre szűkítenem:
journalctl --list-boots
Ezzel ugye megkapom a boot eseményeket, ahol ID 0 az aktuális, ID -1 az előző és így csökkenő ID visszafele az időben.Tehát számomra a "journalctl -b -1" megfelelőb lehet talán az előző folyamat kijelzésére.
"... a 20-21. soroknál lehet a gubanc ..."
Elképzelhető, bár ugyanaz ott van a beindult rendszer esetén is.
Igen, az i2c szerintem sem gond, gyanítom, hogy az nvidia-utils (nvidia-smi) indulásáig azon semmi nem elérhető.
Mit javasolsz? Mi lehet ez a "gubanc"?
Érdemes volna esetleg feltennem egy teljes journalctl kimenetet arról, amikor nem indult a gnome? -
#75135488
törölt tag
válasz
#02705152
#92798
üzenetére
Töröltem (archiváltam) a logokat addig amíg lett egy nem induló és aztán egy iduló rendszer.
sudo journalctl --rotatesudo journalctl --vacuum-time=1s
Az alábbi kimenetet kaptam: [link] (pastebin)
(az i2c timeout valamiért a desktop és mobile nvidia gpu esetében is jelen van)ubyegon2:
Átsiklottam a hibakereső részen, köszönöm a linket.
Érdemes volna egy teljes (nem csak error-t taratalmazó) részt néznem?
Amúgy az linkelt részben említett (journaltcl -b) utolsó boot részletei nem jók nekem szerintem, mert pont az előző kellene, ami nem sikerült. -
#75135488
törölt tag
válasz
#02705152
#92796
üzenetére
Igen, a sima nvidia, nvidia-utils, nvidia-settings, opencl-nvidia csomagok.
Normál linux kernel, de próbáltam már linux-lts-el is, de ugyanez volt.
(más kernel és dkms nem volt)Most épp a desktop-on az initram-ba be van pakolva az "nvidia nvidia_modeset nvidia_uvm nvidia_drm" részeket az mkinitcpio modulként.
Laptopon nincs bepakolva és kernel paraméternek sincs megadva az nvidia_drm, különben folyamatosan megy az nvidia vga az intel mellett.(Grub van mindegyik gépen, a desktop-on 'nvidia_drm.modeset=1' paraméterrel indítok)
Amúgy a journalctl kimenetre nem lehetne valahogy szűkíteni, hogy csak hibákat mutasson? Hátha abból több dolog kiderülne valahol a gdm után, gnome-session elötti résznél.
A laptop teljes újratelepítés előtt áll, szóval ott garázdálkodhatok, próbálgathatok ezt-azt, ha esetleg van ötlet.
-
#92794
#75135488
törölt tag
tordaitibi
#92793
#75135488
törölt tag
válasz
tordaitibi
#92793
üzenetére
Be van állítva, de ilyenkor nem indul még el a Gnome és a beállítás sem él sajnos.
A fura, hogy letiltva a GDM-et (systemctl disable gdm) amikor csak karakteres üzemmód van, akkor is működik a power gombra a leállítási folyamat, de a hiba esetén nem.
Tehát ilyenkor, amikor a GDM-Login megvolt és indulna a gnome-session, de nem indul, akkor már nem tudom így leállítani.Szóval ilyenkor valami nagyon fejreáll. Ezért volna nagyon fontos, hogy kiderüljön mi okozza mindkét gépemen ezt.
(esetleg még ssh-server mehetne a gépen és távolról le tudnám állítani (talán), de na ...)
-
#75135488
törölt tag
Sziasztok.
Adott két gépem (laptop+desktop), mindegyiken Arch+Gnome+X11 kombó van telepítve.
Laptop: i7/9750H+IntelHD VGA+RTX2060
Desktop: AMD 5900x+GTX1060TiMindkét gépemet érinti már egy jó ideje a következő probléma:
A GDM-Login után alkalmanként nem töltődik be a desktop.
Ilyenkor csak szürke (monochrome-matrix pontok) háttér van és a mouse-pointer "X" ikonja jelenik meg. Gondolom ez az X11 képernyője lehet.
Ilyenkor az egér mozgatja az X-et, de semmi egyéb nincs. Leállítani is csak a bekapcsoló gomb hosszas nyomásával tudom.
Persze következő indításnál fut a lemezellenőrzés és azért ez nem túl jó jel az adatbiztonság tekintetében.
Aztán a GDM-Login megjelenését követően, miután belépek vagy elindul vagy újra ugyanez az X11 képernyő jelenik meg és megint csak a gép lekapcsolás az egyetlen lehetőségem.
Ha netán elindul, akkor a szokott módon működik.Első gondolatom az volt, hogy talán a manuális install közben elrontom az Arch telepítést, de a telepítő szkriptet használva is csinálja ugyanezt. Szóval nem ilyen gond van.
Amikor elindul, akkor ránézek a "journalctl" kimenetére, de elképesztően sok sorból áll és több boot log-ját tartalmazza.
Abban szeretnék segítséget kérni, hogy miként ugorjak neki a hiba felderítésének?
(Nagyon szeretném megoldani, mert ezen a rendszeren dolgozom és nem örülök a "nem indul/power off/lemezellenőrzés" hármasnak ) -
#75135488
törölt tag
Sziasztok.
Hogyan tudnám ellenőrizni, hogy Chrome + Chromium esetében működik-e a hardveres video gyorsítás lejátszásnál? (laptop, intel és nvidia vga esetében is lepróbálnám)
Főként YT és Twitch esetében érdekelne.A chrome://gpu szerint be elméletileg van kapcsolva.
Olcsó volt, vacak volt.
Fstrim a /dev/mapper/root logikai blokkeszközön, ami egy decrypted partíció egy nvme eszköz egyik partícióján (/dev/nvme1n1p2)
Új hozzászólás Aktív témák
Hirdetés
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Assassin's Creed Shadows Collector's Edition PC
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Telefon felvásárlás!! Samsung Galaxy S24/Samsung Galaxy S24+/Samsung Galaxy S24 Ultra
- ÁRGARANCIA! Épített KomPhone i9 14900KF 64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- VÉGKIÁRUSÍTÁS - REFURBISHED - Lenovo ThinkPad 40AC Thunderbolt 3 docking station
- Eladó megkímélt állapotban levő Apple iPhone 13 Pro Max 128GB / AKKU 84% / 12 hónap jótállás
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest