-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
samujózsi
#29331
üzenetére
Akkor is lehetetlen feltörni, ha ott a header. Ezt képtelen vagytok megérteni, nem tudom miért.
Én nem szoktam eladni háttértárat, használom, amíg tönkre nem megy. Ha SSD-t adnék el, akkor vagy security erase-t nyomnék neki hdparm-mal, vagy ha ezt nem tudja, akkor blkdiscard paranccsal végigtrimezném (ez sajnos az overprovisioning területet nem törli, de a gyakorlatban egész jó hatásfokú mégis). Ha HDD-t adnék el, akkor egyszerű dd if=/dev/zero segítségével mennék rajta végig, egyetlen menetben, senki nem talált fogást még ezen a módszeren a gyakorlatban, és sokkal gyorsabb, mint a random adattal teleírás. Ami a legfontosabb: ezt közvetlenül az eladás előtt tenném meg, nem napokkal, hetekkel előre. De itt most nem ez a lényeg. Hanem hogy nem hiszem el, ha egy gépben random teleírt meghajtót látok, hogy eladás a cél. Lehet hogy ti ilyen naivak vagytok, én azonnal tudom, hogy semmilyen eladásra szánás nincs itt, a gép tulajának rejtegetni valója van és titkosít. Ennyi. Nem kell ebbe mindent belegondolni, nem a technikai szintről van itt szó, hanem életszerűségi, élettapasztalati logikáról.
Kb. olyan, mint mikor mindenki veri a mellék, hogy ő csak azért használ torrentet, mert csupa legális anyagot tölt, pl. Linux .iso-k. És bár lehet valóban erre használni, azonnal tudjuk róla, hogy bullshit, mert kifejezetten azért találták ki a torrentet, hogy jogvédett meg fizetős anyagokat tudjanak vele letölteni, és akinek fent van torrentkliens, az 99,9999999999999999999999%-ban nem csak Linux iso-kat tölt. Amivel nincs is semmi baj, csak akkor a bullshit szövegeket nem kell tolni hozzá, pl. én is torrentezek, film, sorozat, néha zene, régi játékok, stb.. Épp így a titkosításban sincs semmi kivetni való, én is használok, csak nem nyomom mellé a kamu dumát, hogy bla-bla, nem tehetek róla, áldozat vagyok, NSA elől bujkálok, eladásra lesz, meg egyéb sóder.
Na, ugyan ez van, hogy ha egy gépben teljesen random teleírt meghajtó van, én tőlem mondogathatja a tulaj, hogy eladás, meg möhöhőő, nem fogok neki hinni. Mert nem vagyok naiv, és tökéletesen tudom, hogy nem vagyok ezzel egyedül, mert itt a szakmailag kompetens kollégák is így gondolják, ismerem őket annyira, hogy ők sem ma jöttek le a falvédőről. De ha akarjátok, nyugodtan ragozzuk még, nyomhatjátok mantrában, hogy biztosaneladás, biztosaneladás, biztosaneladás, meg nincsheader, nincsheader, nincsheadeer, elméletileg, elméletileg, elméletileg, hátha segít az önámításban.
-
Dißnäëß
nagyúr
-
Dißnäëß
nagyúr
válasz
samujózsi
#29331
üzenetére
Amúgy ez érdekes, én eleinte DD-vel gyalultam őket nullásra szintén, legutóbbi 3 Seagate vinyómat pedig eladás előtt HD Sentinel Surface test WRITE módban, random pattern-re állítva. Épp zenét hallgattam Foobar-omon és lusta voltam kikapcsolni és Linuxba át-boot-olni
Ez ekvivalens nagyjából egy dd if=/dev/urandom of=/dev/sdb bs=1M cuccal
-
Frawly
veterán
válasz
samujózsi
#29329
üzenetére
Onnan fogja tudni, hogy nem hülye. Eladásra szánt diszket kiszednek a gépből és nem hagyják benne. Ha bármilyen gépben olyan háttértárat látsz:
1) amin randomnak tűnő adat van
2) csurig van vele a meghajtó, akár úgy, hogy partíciók sincsenek rajta, vagy egy vagy pár partíció van, és az van tele ilyen adattal.
3) van rajta rendes titkosítatlan partíció és fájlrendszer, de van pár nagyon nagy fájl, amiben megint randomnak látszó adat van.Ezekből rögtön tudod, hogy mivel állsz szemben, egész lemezes titkosítással, partíciótitkosítással vagy konténerfájllal. Ja tudod ki hiszi el, hogy eladás előtt írta felül. Jó vicc. Mondom, ezzel csak azt tudod hülyének nézni, aki tényleg IT analfabéta a dolgokhoz, vagy annyira naiv, hogy hisz még a mikulásban. FBI, CIA, NSA, magyar ügyészség/rendőrség által felfogadott igazságügyi szakértő azonnal fogja tudni, hogy mivel áll szemben. Lehet őket is hülyének nézni, de nem azok, szakemberek ők is, nem most jöttek le a falvédőről.
-
-
Frawly
veterán
válasz
samujózsi
#29303
üzenetére
Nem azt írtam, hogy garantáltan nem lesz ütközés, hanem hogy „szerintem” nem lesz, és próbáltam megindokolni. Ezek szerint van, tévedtem, beismerem. Próbáltam reagálni a problémádra, mert nem látszott, hogy már kipróbáltad.
Az RO-ként felcsatolt meghajtók mindig szopófaktor, LUKS, LVM, névütközés nélkül is. Általában nem javasolt így csatolni semmit, kivéve, ha nagyon indokolt, hibás fájlrendszer, vagy a célmeghajtón valami kiritikus fontosságú adat van, ami a csatolás nem tehet tönkre, stb.. Először azt hittem, hogy RO alatt itt most ilyen DVD-t vagy hasonlót értesz.
-
Frawly
veterán
válasz
samujózsi
#29301
üzenetére
Igen. Használtam már több disztrón is, a szóban forgó Ubuntun és Archon is, évekig, ráadásul LUKS titkosítással. Ütközéses helyzetem még nem volt vele. Azt nem állítom, hogy garantáltan nincs ütközés, de ezek szerint van, mert kipróbáltad. Egyébként ha felcsatolod egy Live rendszer alatt, akkor át tudod nevezni az LVM csoportokat és köteteket, nem lesz ütközés. Adatvesztés nélkül átnevezhetők.
Read only médiára úgyse tárolnál le LVM köteteket, az ilyenekre fájl/mappaszinten érdemes menteni, nem low level szinten.
-
Frawly
veterán
válasz
samujózsi
#29296
üzenetére
Szerintem nem lesz névütközés, főleg, ha LUKS is van, mert akkor ilyen /dev/mapper/titkosításnév-lvmgroupnév vagy mi alapján jön létre a dev eszköz a LUKS titkosítás feloldása után. De nem vagyok biztos benne, próbáld ki. El nem tudod rontani, legfeljebb kiírja, hogy nem tudta felcsatolni. Szóval kárt nem okozhat, ingyen van kipróbálni.
-
-
haddent
addikt
-
haddent
addikt
válasz
samujózsi
#29280
üzenetére
2. -re: nem része, de nagyon egyszerű és elegáns megoldás van rá systemd -vel pl.:
https://wiki.archlinux.org/index.php/Rsync#Automated_backup_with_systemd_and_inotifyEz most épp backup, de nyilván a backup is csak egy copy, tehát ua.
-
CPT.Pirk
Jómunkásember
válasz
samujózsi
#29270
üzenetére
Na így már más!
SMART Attributes Data Structure revision number: 10Vendor Specific SMART Attributes with Thresholds:ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE1 Raw_Read_Error_Rate 0x000f 083 066 006 Pre-fail Always - 2056617603 Spin_Up_Time 0x0003 095 095 000 Pre-fail Always - 04 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 85 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 07 Seek_Error_Rate 0x000f 100 253 045 Pre-fail Always - 2641169 Power_On_Hours 0x0032 100 100 000 Old_age Always - 2 (236 70 0)10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 012 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 7183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 0189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0190 Airflow_Temperature_Cel 0x0022 057 057 040 Old_age Always - 43 (Min/Max 39/43)191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 23194 Temperature_Celsius 0x0022 043 043 000 Old_age Always - 43 (0 7 0 0 0)197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 1h+52m+02.507s241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 702777946242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 5398287 -
CPT.Pirk
Jómunkásember
válasz
samujózsi
#29267
üzenetére
Annyi a vége. A -d kapcsolónál mit kellene néznem? A manpage nem segít túl sokat.
Amúgy alapból UAS módban ment, most átkapcsoltam mass-driver driverre, így az írási sebességem már USB3-as lett, 118MB/s-el tudok másolni a cuccra, ez a quirk kellett hozzá:
[link]
Viszont ennek semmilyen hatása nem volt a smart-ra. -
haddent
addikt
válasz
samujózsi
#29262
üzenetére
Frawly elhiszem, már van 2-3 éve Digi FTTH (családi ház) és a mai napig kissé felfoghatatlan, hogy mennyire jó és olcsó. Számomra azt hiszem így életem során eddig tapasztalt legmeglepőbb/jobb szolgáltatás amit valaha bárki fel tudott mutatni. Még a Google Fiber is max. annyival tud többet, hogy az szimmetrikus 1G, nem 1G/300M, de ez már a Digi köcsögölése nyilván tudná röhögve. Kitartás, egyszer mindenhol véget ér az internet sötét középkor
samujózsi ki kéne próbálnom, mert fejből azért ennyire nem megy, de azt hiszem alapból az rsa kulcs még encryptálva lett a "jelmondat" (húdefaszafordítások
) által, ezért még azt kibontja sima b64 encodedbe, majd parasztvakítással "megkeveri" . Azt hiszem csak utóbbi verzióval tud aláírni certeket, az encrypted nem sok mindenre jó magában, mint egy ssh key a jelszava nélkül kb.
De ezt az oldalt engedd el, borzalom a fordítás is, meg maga a parancsok is. Mi a bánatnak generálja le X néven, hogy aztán +5 paranccsal kevergesse?
[link] ez szerintem sokkal érthetőbb -
CPT.Pirk
Jómunkásember
válasz
samujózsi
#29264
üzenetére
Nem persze, rendes telepítés alól.
sudo smartctl -A /dev/sdd1smartctl 7.0 2018-12-30 r4883 [x86_64-linux-5.2.11-3-CHAKRA] (local build)Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org=== START OF READ SMART DATA SECTION ===Ez nem jelent jót azt hiszem.
-
Frawly
veterán
válasz
samujózsi
#29257
üzenetére
Szerintem az Android nem kezeli le a fájlnevekben a karakterkódolást, vagyis nem tudja MTP-n rendesen átadni. A Linuxnak tuti nem kell gondot okozzon, ott be lehet állítani a kódolást UTF-8-ra. De majdnem biztos, hogy Android-bug, mert Windowson sem ment, azt írtad.
Egyébként nekem is van néhány számnál zárójel fájlnevekben, és nekem nem volt gondom MTP-n sem, de majd kipróbálom még egyszer, kifejezetten ilyen (0) ... (1) ... (2) fájlokkal.
-
samujózsi
senior tag
válasz
samujózsi
#29255
üzenetére
Hát ez van. Google találatok alapján néhányan úgy gondolják, hogy ez bug lehet a gvfs környékén, mások szerint az mtp protokoll úgy szar, ahogy van.
Én úgy emlékeztem, hogy régebben (igaz, régebbi androidok alatt) működött gond nélkül... ooooopss... hát most másolgattam párom Huawei P8 Lite mobiljáról rengeteg fájlt, azzal nem volt ilyen gond... És ugyanígy, az új Samsung A20e mobiljára is fel tudtam másolni.Valamit itt nagyon nem kerek, de én kevés vagyok ahhoz, hogy kiderítsem, mivel van baj.
-
-
Frawly
veterán
válasz
samujózsi
#29248
üzenetére
Biztos, hogy ide van felcastolva, ilyen mtp:host néven? Próbálj meg valami egész mást rámásolni.
Két lehetőség van: egy hosszabb másolás közben x idő után szétdobja a kapcsolatot a teló (pl. bekapcsolódó képernyővédő okoz neki gondot), és ez mindig annál a fájlnál mutatkozik meg.
Vagy abban a DCIM mappában az a fájl sérült a fájlrendszeren. Meg kéne próbálni csak ezt átmásolni. Szigorúan terminálban, cp vagy rsync paranccsal, hogy lehessen látni a folyamat közben, hogy mit ír ki hibaüzenetben. Grafikus alkalmazásnál alapból nem látni, hacsak nincs megint csak terminálból indítva.
-
unknownerror
tag
válasz
samujózsi
#29239
üzenetére
Szia!
Köszi, (belül) ezt a csoportot kerestem.
A windows server belső backup-jával mentek, a linux-os vm pedig megkap egy 1,5T-os vhdx lemezt, ami egy hardware raid5 köteten van. Megnézem az lvm-et, ki lehet-e alakítani itt, szerintem működhet. köszi!
Illetve lehet, hogy a raid vezérlő is szűk keresztmetszet a sebességben, ezt most tesztelem.Miklós
-
Frawly
veterán
válasz
samujózsi
#29232
üzenetére
Nálam eddig minden paramétert kiírt az efibootmgr -v (vagy ---verbose a megfelelője a hosszú paramtérnévnél), minden gépen, fizikain és virtuálison is.
Pl. ThinkPad-emen Arch alatt, ebből az első 3 sor, és a legutolsó számít:
[csaba@Piglet ~]$ efibootmgr -v
BootCurrent: 000A
Timeout: 0 seconds
BootOrder: 0019,000A,001A,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0012,0013
Boot0000 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0001 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850)
Boot0002 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0003 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
Boot0004 ME Configuration Menu FvFile(82988420-7467-4490-9059-feb448dd1963)
Boot0005 Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
Boot0006* USB CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0007* USB FDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0008* ATAPI CD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401)
Boot0009* ATA HDD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot000A* ATA HDD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot000B* ATA HDD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot000C* USB HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot000D* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot000E* ATAPI CD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35403)
Boot000F* ATAPI CD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35404)
Boot0010 Other CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406)
Boot0011* ATA HDD3 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603)
Boot0012* ATA HDD4 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot0013 Other HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)
Boot0014* IDER BOOT CDROM PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0)
Boot0015* IDER BOOT Floppy PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0)
Boot0016* ATA HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0017* ATAPI CD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
Boot0018* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot0019* Arch HD(1,GPT,068aec4c-eb24-443b-8ae1-ba5782bc6364,0x800,0x32000)/File(\vmlinuz-linux)r.o.o.t.=./.d.e.v./.s.d.a.2. .r.w. .i.n.i.t.r.d.=./.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g.Közben ezt megerősítve a /proc/cmdline tartalma:
mitigations=off random.trust_cpu=on initrd=intel-ucode.img initrd=initramfs-linux.img root=PARTUUID=a826f815-4fed-b440-907a-bca1e2633e6e rwA /proc/cmdline is teljesen jó, hiszen az UEFI átadja az összes paramétert, amit te megadtál. Ezzel direkt kisérleteztem, hogy az efibootmgr-es bejegyzéssel nem egyező, illetve ellentétes paramétereket adtam át az EFI shellben a kernelnek és a cat /proc/cmdline helyesen írta ki, hogy milyen paraméterek lettek TÉNYLEGESEN átadva.
-
Frawly
veterán
válasz
samujózsi
#29229
üzenetére
Pedig a QEMU hálókártyáját nekem simán kezeli a defconfigos kernel. Szerintem a soros konzol hiányáról sem ő tehet, ez valami QEMU-s vagy OVMF UEFI firmware-es probléma lesz.
Az efibootmgr -v leközli, hogy milyen paraméterekkel lett felvéve indításra az adott kernel. Ha viszont a jelenleg beboolt rendszeren valami egyszeri, speciális paramétert alkalmaztál, pl. EFI shellből, akkor ezt ezzel a paranccsal tudod lekérdezni:
cat /proc/cmdlineAz efibootmgr mindenféle kamu bejegyzéssel lefut. Az, hogy ez bootkor törlődik-e, azt UEFI BIOS-a válogatja. A legtöbb UEFI törölni szokta azokat a bootbejegyzéseket, amikhez a meghajtó vagy EFI partíció, EFI bináris nem érhető el. De nem mindegyik, egyes UEFI-k meghagyhajták.
-
Frawly
veterán
válasz
samujózsi
#29215
üzenetére
Még egyszer hangsúlyozom: ez minimalista, openrc-s Gentoo base rendszeren kézzel forgatott, defconfigos vanilla kernel, EFI stub bootal, GPT-s meghajtóról, FAT32 EFI partícióról indulva, ext4-es root partíciót használva. Se kernel patch-ek, se GRUB, se initramfs, se systemd, se Gnome, se dbus, semmi, se quiet, se spash screen, se semmi sallang. Nem csak a tanulás miatt szenvedek ilyesmivel, hanem nem akarok mainstream disztrót, mint az Ubuntu, ami tele van vágva 99%-ban számomra teljesen nélkülözhető dologgal. Ha csak az lenne a cél, hogy valami Linux működjön, 2 perc alatt felhúznék egy Ubuntut, Mintet, Manjaro-t, vagy 15-20 perc alatt egy Arch Linuxot. Itt most az a cél, hogy saját magam részére a legminimalistább, de még használható saját disztrót dobjak össze, amiben egy deka sallang nincs.
Egyébként valószínű, hogy ehhez, amit írsz, a kernelbe kéne forgatni valami plusz opciót, hogy működjön, a defconfig nem tartalmazza a szükséges dolgokat. Legalábbis én erre tudok gondolni, mert elhiszem, hogy Ubuntu-n ez simán megy, az ő foltozott, full extrásan fordított kernelükkel.
Kernelparamétereket persze meg tudok adni, az UEFI BIOS-ba belépek Esc-kel, ott a Boot Options-ben el tudom indítani az UEFI vészkonzolt, azzal kapok egy shell-t, ott el tudok navigálni az EFI partíció adott bzImage kernelfájljára, ami egyben egy EFI bináris is, és ott kézzel be tudom adagolni a paramétereket, úgy tudom indítani. Tehát csak az EFI shellben beverem ezt:
fs0:\EFI\Gentoo\bzImage console=/dev/ttyS0 console=ttyA "console=/dev/ttyS0 console=tty" paramétereket próbáltam egyszerre is. A kernel rendben bootol, de átváltva a QEMU serial console-jára, abban csak az UEFI shell látszik, a kernel kimenete nem.
-
Frawly
veterán
válasz
samujózsi
#29211
üzenetére
Nem működik ez a tty. Próbáltam ezeket console=/dev/ttyS0 console=ttyS0 console=tty. Külön-külön persze, nem egyszerre.
Kernelparaméter nincs, se quiet, se semmi. Vagyis root=/dev/sda2 mitigations=off logo.nologo, de ezek kernelfordításkor lettek a kernelbe beleforgatva.
(#29212) Jester01: örömmel olvasom. De nem vagyok benne biztos, hogy ez az a bug. Ugyanis próbáltam rw paraméterrel is root partíciót felcsatolni, és nem működött, de lehet rossz helyen adtam meg. Meglátjuk, két nap van hátra az RC3-ig.
-
Frawly
veterán
válasz
samujózsi
#29200
üzenetére
Igazatok van, egy működő kernel kimenetét csatoltam, de elfelejtettem a hibaüzenet elejét becsatolni. Íme:
Az 1.904...től érdekes:
BUG: kernel NULL pointer dereference, address: 0000000000000Azt a tty-os trükköt még nem próbáltam, amit írtál. A QEMU konzolját viszont néztem, nem látszik benne a kernelkimenet, csak az UEFI BIOS kimenete. De könnyen lehet, hogy ez az én hibám, mert a QEMU-nak még be kéne adagolni valami paramétert, hogy látszódjon.
-
bambano
titán
válasz
samujózsi
#29205
üzenetére
"Azért az érzed, hogy itt átlaguserről van szó, nem hobbista kernelfejlesztőről?": de itt az alapeszméről van szó.
nem mondtam, hogy hatékonyan fog belenyúlni, nem mondtam, hogy sikeres lesz, azt mondtam, hogy hagyni kell.az opensource és a linux alapeszméje, hogy mindenki buherálhatja. ezt az alapeszmét szerintem helytelen lenne megölni.
az egy másik tészta, hogy a hivatalos kernelbe mi hogyan kerül bele és az is, hogy a júzer saját energiáit vagy másokét hogyan pazarolja. ha be akar menni bekötött szemmel az erdőbe, hagyni kell, hagy menjen. ha koppan, koppan, ez téged ne zavarjon. de lehet, hogy felfedezünk egy új mingót.
-
inf3rno
nagyúr
válasz
samujózsi
#29205
üzenetére
Nekem hasznos igazából annyi lenne a napi dolgokban, hogy adjon valami tippet, hogy melyik hardver vagy driver vagy beállítás hibás. Az egész kb egy sor lenne. Ehelyett valami katyvaszt ad, amivel a fejlesztőkön kívül senki nem tud mit kezdeni. Weben is nem véletlenül írunk 500 internal server errort meg 404 not found-ot vagy ilyesmiket ahelyett, hogy a teljes trace-t odanyomnánk az end user pofájába. Egyrészt biztonsági kockázat, másrészt meg úgysem tudna mit kezdeni vele, mert nincs hatásköre hozzá és nagy valószínűséggel nem ért hozzá. Ugyanez a megközelítés lenne jó itt is. Aztán aki hozzáértő az megnézheti debug mode-ban a trace-t meg minden ilyen extra dolgot, aki meg nem, annak elég tudnia, hogy a videokártya adta be a kulcsot vagy annak a driverét kellene frissíteni. Na csak ennyi, gondolom még néhány száz év, mire ilyen OS is lesz.
-
bambano
titán
válasz
samujózsi
#29199
üzenetére
"És sokadszor: átlag felhasználó ne akarjon kernel dumpot fejteni.": miért? azok, akik most kernelt fejlesztenek, átlag felhasználóként kezdték és nulláról tanulták meg azt, a dump olvasást is.
a linux egy szabad világ, ne akarjuk előírni senkinek, hogy mit csináljon. azt mondhatod, hogy te nem tudsz átlag felhasználónak dump olvasásban segíteni. ha más tud, vagy megtanulja önállóan, akkor mindenki boldog.
-
inf3rno
nagyúr
válasz
samujózsi
#29193
üzenetére
Nem voltam benne biztos, de rákerestem: [link] Ezek alapján nem lehet az elejére scrollozni kernel panic esetében. Szerinted ennek így mi értelme? Biztos, hogy valahol ott van az elején, de az átlag felhasználó nem fogja tudni elolvasni... Aztán lehet, hogy 5 év alatt változott a dolog, nem szoktam kernel panicokat lapozgatni.
-
inf3rno
nagyúr
válasz
samujózsi
#29166
üzenetére
Az van, hogyha az ember kódot ír, akkor rétegezni szokás a kivételeket. Pl teszem azt fájlt akarok írni, szór egy kivételt, hogy lockolva van a fájl, elkapom, aztán szórok egy magasabb szintű kivételt, hogy sajnos nem sikerült a fájl írása, és ahhoz csatolom az előző kivétel, hogy miért nem. Utána megint elkapom, és dobok mondjuk egy olyat, hogy nem sikerült menteni a játék állását, és ahhoz csatolom az előző kettőt. Nyilván a user ebből csak a legfelső szintű kivételt látja, a maradék meg a fejlesztőknek jó, esetleg bekerülhet logba backtrace-estül, mindenestül. Nem tudom, hogy kernelnél használnak e try-catch-t, mert viszonylag lassú, de valami hasonló elgondolást azért jó lenne, ha követnének, mert most ott tartunk, hogy csak a legalacsonyabb szintű hiba van eldobva, aztán jöjjél rá, hogy az egymillió sorból melyik futott aknára, ami ezt eredményezte. Trace-ből vissza lehet nyomozni valamennyire, ha megvan a forráskód, egyébként meg csak hümmög az ember, hogy ezmiafszom.
-
Frawly
veterán
válasz
samujózsi
#29145
üzenetére
Initramfs sincs, nem is kell, anélkül is bootol ugyanezen a virtuális gépen Gentoo rendszeren a 4.9.86 és 5.5-RC1 kernel is. A modulnál már értem mit mondasz. A menconfig - Filesystems - Ext4 mind a négy opciója [*]-gal van (statikusan) belefordítva, nem modulként (ami M lenne).
De valami miatt mégse tudja felcsatolni a root partíciót, pedig biztosan /dev/sda2, a többi kernel, amiket említettem, azok fel is tudják épp így csatolni EFI stub bootban, initramfs nélkül. Csak ez a kernel.org-ról származó 5.5-RC2 nem tudja. Próbáltam úgy is, hogy root=PARTUUID=b14b1a-b1a-b14-b1ab1a formában adom meg, az sem segít. Így most vagy nem találja meg a root-ot, vagy megtalálja, de nem tudja felcsatolni.
Az is biztos, hogy a root partíció sima ext4, és fájlrendszerhibák sincsenek rajta, a működő kernelek is le fsck-zzák és mindent rendben találnak.
Egyébként a müködő kerneleknél ez látszik az md sorok mögött, ennek kéne történnie kernel panic helyett:
-
Frawly
veterán
válasz
samujózsi
#29143
üzenetére
Látod, ez jó kérdés. Szerintem max modulként van benne. Hogy fordítsam bele jobban?
Ahogy nézem, ez a baj. Most el sikerült olvasnom a kernel panic elejét (virtuális gép UEFI firmware-jében vettem fel a felbontást, így több sor marad meg). A RAID detektálás után fullad le. Nem a RAID a baja, mert olyat nem használok, meg letiltottam a raid=noautodetect paraméterrel.
Ami az md RAID betöltése után következne az a root filesystem (egy bootoló kernelnél megnéztem), ezt már nem írja, ehelyett van:
BUG: kernel NULL pointer dereference, address: 0000000000000Tehát az a baja, hogy a root filesystem-et nem tudja csatolni. Igazoltam ezt úgy, hogy megadtam neki kernelparaméterben egy szándékosan kamu rootot: root=/dev/sdb1. Akkor is ugyanilyen kernel panic kíséretében száll el.
Pedig sima GPT partíciókat használok, semmi spéci titkosítás, RAID, LVM vagy hasonló bonyolítás. UEFI EFI stub boot, de a Secure Boot is ki van kapcsolva.
-
Frawly
veterán
válasz
samujózsi
#29141
üzenetére
Nem maradt ki, a root fs ext4, és próbálkoztam már a rootfstype=ext4 kernelparaméterrel bootoláskor, az sem segít. Most a virtio támogatást fordítom bele, mert QEMU virtuális gépen fut.
Megnehezíti a hibakeresést, hogy nem tudok visszagörgetni, így nem látszik a kernelpanic legelső sora.
-
válasz
samujózsi
#29131
üzenetére
Na ne, az van mindben, csak elő kell szedni. Legrosszabb esetben ctrl-alt-f2...fakármennyi , és lesz terminálod. De ha elrontod valamelyik telepítőlépést, akkor kb. ugyanazt a menüt kapod, mint egy Debian text mode installerben, és abban is van...
Az meredek, én korábban csak kigyilkolni tudtam a diszk mód állítgatással OS-eket. Viszont megnézem majd, hogy mi van belőve a kvm-es gépeimen diszknek, ha már így mondod, hogy a SCSI gyorsabb és jobb SSD-hez.
-
válasz
samujózsi
#29128
üzenetére
Ez azért meredek, mert ha külön működik, akkor együtt is kéne. LVM bootolás megy, EFI megy, az EFI addig érdekes, amíg meg nem találja a lemezt.
A shell előtt nincs hibaüzenet? Nem ismerem nagyon az EFI-t, de ilyenkor a shellben nem lehet nézni valami logot, hogy mi történt előtte?
Az EFI shellből nem lehet megnézni, hogy mit lát winyó címén?Ja... most látom...
A SCSI-vel is be kéne tudnia bootolni, ha SCSI-n telepítetted. Ha nem azzal, akkor nyilván csak azzal megy, amivel feltetted. -
-
-
Papooo
senior tag
válasz
samujózsi
#29112
üzenetére
Hardverhiba kilőve.
Körbeguglizva, ez valami tipushiba, amit egy hdd cagy ram csere is előidézhet.
Egy bios frissítés talán meg tudja oldani.
Persze a frissítő egy futtatható exe program, amihez windows kell, ami persze nem megy, amíg a hiba el nem hárul.
Nincs külön hivatalos bios bin file, sem parancssori program amivel frissíthetném -
Dißnäëß
nagyúr
válasz
samujózsi
#29113
üzenetére
Köszi a tippet, ránézek.
Secure boot nincs, semmit nem jelent nekem, pláne már egy csak játékra használt Windows-on majd (az egyébként natívban lesz a Linux mellett, ritkán beizzítom néha, de amúgy nagyjából off).
Az is lehet, hogy virtualizáció + NAS módra átállok az egész asztalimmal, VGA-t eladom, proci RAM HDD SDD marad és egy billentyűzetbe beállítható tablettel megyek rá remote desktop módban (vagy VNC) kódolni, az egész meg elzümmög kint a nappaliban a TV alatt.
Most így ilyenek között billegek. Ha nincs játék és 3D, márpedig ez megszűnt egy ideje, nem látom értelmét tartani egy asztali gépet. Egyelőre kísérletezgetek még, aztán ha megtaláltam a megfelelő szintézist, mit hogyan, milyen módon, milyen beállításokkal, szerintem meglépem.
(Végre akkor a router-em is lehet egy VM-be beizzított OPNSense, a meglévő ASUS-om buta módban bírja az 1000-es netet, de VPN-el már nagyon köhög).
-
Dißnäëß
nagyúr
válasz
samujózsi
#29107
üzenetére
VBox tudja, egy beállítás, hogy a virtuális HDD az HDD-nek vagy SSD-nek jelentse magát a guest felé. Utóbbi esetén - most olvastam - működik a móka.
QEmu-nál nem tudom, találtam egy másik cikket arra az előbb, de kicsit mókolós. Ezen még gondolkodom.
Érdekes, hogy vajon szerver környezetben hogy megy ez, ahol a SAN-ok tele vannak rakva SSD-kkel és FC-n megkapva a targeteket egy VMWare farm VM-jeként, vajon ott mi történik mount-olás után
(Muszáj, hogy tudjon ilyet a Hypervisor, különben pillanatok alatt le-ko-zza az ember az SSD-ket).Mindegy, hangosan elmélkedtem. Köszi a kommenteket.
-------------------------
Arról van tapasztalatotok esetleg, hogy VBox (Linux) vagy QEMU/KVM ? Állítólag előbbi is nagyon jó már Linuxra is, teljesítményben ilyen 5% körüli az overhead elvileg, a gyakorlatban van erről mérése vkinek esetleg ? A QEMU kicsit néha jobb kézzel vakarom a bal fülem esete, bár elvagyok vele..
.. viszont olyat simán csinál, hogy a host-on mind a 12 proci szálam épphogy csak terhelve, miközben egy VM-en belül is elég light-os a CPU kihasználtság, én meg közben elalszok, mire egy apt upgrade végigmegy. Mintha nem tolná full kakaón a két vCPU-t a guest, így a host sincs szétterhelve, én meg rágom a kefét, hogy "most min gondolkodooooooool???" ..Ez annyira nem tetszik, amikor lehetne gyorsabb is, ne pihenjen az a vCPU basszus. És nem az SSD fogja a mókát, nem is az 1000-es optikai net. Ilyen szép lusta komótos minden, guest is és host is. Nem ezt várnám egy Ryzen 5 CPU-s motyótól, ott a pokol CPU erő, használja.
-
-
Frawly
veterán
válasz
samujózsi
#29099
üzenetére
Most hogy újra végiggondolom, igazad van. Mégis csak át kéne engedni, különben a fizikai host gépen hiába van TRIM, ha úgy látja, hogy az egész qcow2 fájl foglalja a saját lemezterületét, hiába lett valami törölve belőle, nem szabadul fel a már nem használt blokk belőle.
Ezen a linken az első válaszban adnak meg működő példát.
De a legtisztább az lenne, ha az SSD oda lenne dedikálva fizikailag a virtuális gépnek, mert akkor semmit nem kell átengedni, a guest-en elég simán beállítani a TRIM-et.
Illetve NVMe-n nem tudom hogy lehet megoldani. Mert a TRIM parancs csak PATA/SATA/AHCI SSD-khez van, az UNMAP csak SCSI/SAS/UASP interface-esekhez. NVMe-n viszont a TRIM-et végző parancs bele van integrálva más lemezműveletekbe, ezért külön nem lehet meghívni, meg semmin keresztül átengedni. Na már most nem tudom, hogy a discard átengedése ezen mit segít.
-
Dißnäëß
nagyúr
válasz
samujózsi
#29093
üzenetére
10-es elég flexibilis ilyen téren, rengeteg mindenen beindul ugyanaz a telepítés (próbáltam már, még az Intel-AMD-Intel dupla váltásomat is túlélte egy előző install-om, csak teleszemeteltem).
Lehet simán kiköltözök róla akkor és Linux alatt egy VM-es W10-re teszem át azt a keveset, aminek Windows kell.
Arról van infód, hogy host SSD-n ha létrehozok qcow2 default formátumú diszket, TRIM van-e egészen a fizikai SSD-ig kezelve ? A rátett Linuxnak megadhatom a discard-ot, de vajon értelmezi a host OS ezt ?
-
-
Dißnäëß
nagyúr
válasz
samujózsi
#29064
üzenetére
DD-zni azért root kell, ha meg mezei user kezdi el tolni ezt, eléggé falba ütközik és én user-ként használom a Linuxot, nem rootként, még sudo-t se adtam a saját user-emnek.
Persze rommá lehet törni bármit.. 100% biztonság nincs.Jött már be nekem ez a softraid, mert SMART szerint az egyik HDD-n lett 1 szem (!) bad sector-om, ami elvileg pótolva lett a tartalék területről (relocated), több nem szaporodott már hónapok óta, de intő jel, hogy sürgős csere, a diszket meg megtartom
porno-ralinux iso-ra -
Dißnäëß
nagyúr
válasz
samujózsi
#29061
üzenetére
Szerintem nincs kavarodás. Nekem például a softraid egy desktop kategóriájú gépen belefér, nincs igényem olyanra, hogy szünetmentes táp és külön belső akkuval ellátott kontroller kártya és ilyesmi megoldások. Jó, hogy egyben lát az ember logikailag olyan dolgot, ami mind sebességben, mind megbízhatóságban tolerál minimum egy diszk kiesést, még ha minden egyéb feltétel is nemredundáns.
Alaplap SATA vezérlő beszarás és társai ellen nem véd, nyilván. (Bár ha mindegyik alkatrész külön PCIe kontrollerről megy, a softraid ezt már kezelte is, de a többi ellen akkor sem véd, pláne nem memória hiba ellen, stb. De hát a desktop az desktop).
Kérdésedre válaszolva: lehet ezt feketén-fehéren is nézni és akkor semmi értelme az otthoni raid-nek sem, a szoftver raid-nek sem (a sebességen kívül), btrfs-nek meg pláne nem. Viszont lehet szürkén is nézni és akkor oda helyezed a megkötendő kompromisszum-csúszkát, ahova szeretnéd. Van aki feketébe tolja el, szeret kockáztatni egyre nagyobbat és van, aki fehérbe, a szürkén belül, minimalizál 1-2 kockázatot. És ez így jó és szép, hogy van lehetőségünk erre.
Nem túl sok kompromisszum, nem túl sok biztonság, több kompromisszum (enterprise szerverek, pénz, zúgás), több biztonság, ezek egyszerű dolgok, de semmiképp sem egybitesek, mint ahogy az igény sem egybites, ami ezen technológiák létrejöttét indukálta.
Ha NAGYON félsz adatvesztéstől, nyilván tudod a megfelelő védekezést ez ellen, de az tökmás liga, mint egy desktop motyó tele kompromisszummal, épphogy a bare-minimumot adva. Nálam ez a bare minimum tök elég évek óta. Lehet statisztikailag kimutatható lenne, hogy az elkövetkező 80 életévem alatt mekkora az esélye egy újra és újra átmigrált többterás raid5 tömbömön ülő adat részleges, vagy teljes elvesztésének, de nem nagyon rugózom ezt agyon, viszont annak igenis piszok nagy esélye van, ha 1 diszken tárolom mindezt, hogy akár 1 éven belül is bukjam őket. Számomra elégséges ezt a kockázatot mitigálni.
-
-
válasz
samujózsi
#29042
üzenetére
Ez a rész nekem is cseszi a csőrömet. Nagyon jó, hogy online elérhetőek a docker image-ek, meg a különböző alkalmazás image-ek, de nem lehet tudni, melyik hivatalos, ellenőrzött és melyek azok, amikben esetleg vki elrejtett egy sort, hogy küldje el pl. a billentyűzésedet...
-
Jester01
veterán
-
samujózsi
senior tag
válasz
samujózsi
#29015
üzenetére
A docksit (
) olvasva a válasz az, hogy 42! ... izé..., hogy igen: a docker módosítgat ezt-azt a netfilter szabályok közt.
Ami engem kicsit zavar: nem okozhat ez biztonsági problémákat? Nem kavarhat be, ha a használt tűzfal konfiguráló szoftverben saját szabályokat alkalmazok, netán eleve nulláról felépítve, iptables parancsokkal magam állítom be ezeket a szabályokat?
Nem az lenne a normális, ha ezeket nem csinálná meg helyettem a docker? (Kicsit windows feelingem van tőle) -
vargalex
félisten
válasz
samujózsi
#29000
üzenetére
Olyannal már találkoztam wifi esetén, hogy a routeren valami energiagazdálkodás miatt viszonylag sok idő kellett, hogy "észbekapjon". A jelenség az volt, mint nálad, URL-t megnyitva néhány másodpercre megállt, majd elkezdte a betöltést. Ilyenkor azt vettem észre, hogy a wifi kliensen (azaz a notebook-on) folyamatos ping-et futtatva (pl. index.hu-ra) megszűnt ez a jelenség. De ez kliens független volt.
-
Frawly
veterán
válasz
samujózsi
#28998
üzenetére
Abban egyetértek, hogy az rkhunternek utánanézhettem volna. De ha ettől boldog vagy, most megtettem. Egy rootkit elemző. Na már most két eset lehetséges. Vagy csak tévesen riasztott be valami heurisztika miatt, vagy a böngészőben futott valami olyan oldal, ami tartalmazott valami rosszindulatúnak minősített ad/miner scriptet. Emiatt én baromira nem aggódnék, hogy Ubuntun rootkitet szedtél volna össze.
Vagy ha mégis sikerült, akkor kitüntetünk, mert te lennél az első, akiről hallottam, hogy összeszedett támogatott desktop Linuxon valami csúnyaságot. Olyanról olvastam, hogy valaki hosszú évek óta nem frissített szerveren szopott be openssl heartbleedet, vagy valami ransomware-t, azt is valahol Kínában, de hogy még jelenleg támogatott desktop disztrón szedje össze valaki, olyanról nem hallottam még.
Ha viszont a GUI lefagy, akkor nem a böngészőben meg a hálózatban kéne a hibát keresni. Először a dmesg logban, journalctl-ben nézném meg, meg a X.org logban.
-
inf3rno
nagyúr
válasz
samujózsi
#28985
üzenetére
Nézd meg valamilyen wifi analyzer appal, hogy elég erős e a jel. Ha igen, akkor teszteld ookla speed test-el, vagy ezzel [link], hogy ténylegesen mennyit tud. Ha alacsonyabb az elvártnál, akkor a helyi hálózaton érdemes tovább folytatni a tesztelést. A legegyszerűbb, ha csinálsz egy http vagy samba servert, és fájl letöltéssel nézed meg, hogy milyen sebességgel megy a helyi hálózaton az adat. 2-3 gép között érdemes mérni, hogy kizárd a hálózati kártya hibát valamelyik gépen, illetve vezetékkel is érdemes kipróbálni, hogy a wifivel van e a gond. Érdemes még pingelni pl google.com-ot, hátha az magas, és azért akad meg egy pillanatra. Nagyjából ezek az ötleteim.
-
Frawly
veterán
válasz
samujózsi
#28966
üzenetére
Ez egy rossz gyakorlat. Ha sok parancs elé kell a sudo, akkor nem sudo -i-t kell kiadni, hanem su parancsot. Az root jogokkal futtat, de nem a /root mappájába szemetel, hanem abban a mappába, amiben épp terminálban dolgozol, ez lehet akármilyen tetszőleges mappa, akár a felhasználód home mappája is.
Ha rám hallgatsz, és desktop linuxról van szó, megfogadod a tanácsaimat. Csak a /home-ot és az /etc mented, meg a csomaglistát. Semmi mást, így mész át az új rendszerre, amit meg elve úgy telepítesz fel, hogy a /home a felhasználói adatokkal és mindenféle más adattal együtt egy adatpartíción legyen, külön partícióra a rendszer, külön bootpartíció, swap az nem kell (arra lehet swapfájlt csinálni), kivéve ha HDD-ről fut a rendszer (de arról nem akarod használni, pár nap híján lassan 2020-at írunk, már pendrive árában kaphatók SSD-k).
/root-ba semmit nem szemetelsz, ezt szokd meg, később sok szívástól megkíméled magad vele, meg ezt a mappát sem kell mentegetni. Felteszel normális, modern e-mailklienst, pl. Thunderbird, vagy ha minimalista kell terminálban, akkor neomutt, utóbbiban oda teszi az e-maileket, amelyik mappába mondod neki, nem kell később /var mappát mentegetni.
Most ezúttal a /var/log-ot se mentsd. Tudom, feltörték a gépet, rajtad van az NSA, most ezzel nem foglalkozol, ha ez a rendszered menni fog a levesbe úgyis. Újra lesz telepítve, normálisan, gányolásmentesen, nem lesz érdekes, hogy egy előző rendszerrel mit volt.
/usr-be semmi fontos nem kerül, ha van is konfigfájlt, akkor azt a ~/.config/ mappába kell tenni. Az /usr/share-ben általában az alkalmazások gyári, példakonfigja van, abban nem érdemes belebarmolni.
Eddig amit írtam, az mind szigorúan desktop linuxra értendő. Ha szerverről van szó, és ennyire nem vagy képben, hogy mi is kell neked, akkor meg az egész linux fájlrendszerről csinálsz egy tar.xz-s mentést a / mappából kiindulva, az a config, log, bináris fájlokat nagyon kicsire összetömöríti. Hosszú távon meg meglátod, hogy ebből mire lesz szükséged később. Mert lassan már az egész linuxos mappastruktúrát felsoroltad, hogy neked mind kell, talán csak a /bin /mnt /run /proc /sys /dev nem írtad, a többit mind sikerült felsorolni. Az /mnt /run mind csak csatolásra szolgál, /bin-be úgyis csak telepítsékor kerül bináris (meg az egy szimbólikus link, ami a /usr/bin-re mutat), a /proc /sys /dev /tmp mind illékony fájlrendszer, azoknak csak az aktuálisan futó rendszer alatt van értelmük. Van még az /srv, ha használod, szerveren el lehet azt is menteni.
Tudod, akkorra már úgy átalakul a társadalom és annyira nyitott dolog lesz ez, hogy még csak vállat vonni sem fognak, max elismerésként mutogatni minket, hogy "na ez igen, ezek aztán már 2020-ban is milyen felvilágosultak voltak !!!" 
) által, ezért még azt kibontja sima b64 encodedbe, majd parasztvakítással "megkeveri" 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Eladó Steam kulcsok kedvező áron!
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Samsung Flip 2.0 PRO 65" WM65R + Connectivity tray + Gurulós állvány
- Fujitsu USB Port Replicator PR09 docking station (1x5K vagy 2x4K felbontás) (DisplayLink)
- Bomba ár! HP 255 G7 - AMD A4 I 4GB I 128SSD I HDMI I 15,6" FHD I Radeon I HDMI I W11 I Cam I Gari!
- Apple iPhone 15 Pro Max - Natural Titanium - Újszerű karcmentes állapotban! 100% akku! Gyári garis!
- Bomba ár! Dell Latitude E7270 - i7-6GEN I 8GB I 256GB SSD I 12,5" FHD I HDMI I CAM I W10 I Gari!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest