Keresés

Hirdetés

!! SZERVERLEÁLLÁS, ADATVESZTÉS INFORMÁCIÓK !!
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!

Új hozzászólás Aktív témák

  • azbest

    félisten

    válasz BestofJAVA #40823 üzenetére

    Közben a pi forumán pi specifikus részleteket még írtam. Relatíve régi boot kódot használnak a 22.10 -ből kinyert fájl alapján.

  • azbest

    félisten

    válasz azbest #40820 üzenetére

    közben megnéztem, a release 22.10 képben is 5.19.0-1004-raspi verziós a kernel, mitn a dailyben.

  • azbest

    félisten

    válasz BestofJAVA #40819 üzenetére

    A 22.10-es pri ubuntuban 5.19.0-1004-raspi verziós a kernel. Ja bocs, most látom a daily buildet néztem először [link] esetleg próbáld ki ezt a lemezképet, hátha újabb.
    És a boot partición úgy látom, hogy nem az alapítványos a tartalma, szóval problémás lehet simán csak odamásolni a hivatalos rendszerben lévő boot és /lib/modules tartalmát. De minimum plusz konfigurálás kellhet, ha azzal a kernellel próbálnád elindítani (cmdline.txt), mert más a kernel fájlneve a boot meghajtón, mint az alap.

    Az alpítványos kernel verziója 5.15.76+. Szóval full mást használnak ubuntuék a daily build nevűben.

    Az imagerben lévő 22.10 link az a hivatalosan kiadott verzióra mutat [link]

    Az is lehet, hogy az okoz valami bugot, hogy magán a raspin akarod kiírni. Lehet szimplán egy rendes pécén kéne csinálnod a letöltött image kiírását. Akár nincs elég hely és azért döglik le, akár megszakadt a letöltés valami miatt... vagy hibás a háttértárad... szóval ennyit tudok neked segíteni.

    JA meg arra is figyelj, hogy lehet nem mindegy melyik hdmi kimenetbe dugtad a monitort
    display must be connected to HDMI port closest to power jack.
    Alapból lehet csak az egyiken ad képet más rendszerrel. A tápbemenet mellettit használd. hdmi0.

    Ha első indítás előtt a boot meghajtón létrehozot egy fájl ilyen névvel hogy ssh , kiterjesztés nélkül, akkor bekapcsolja az sshd-t és ki tudod próbálni hogy valójában elindult -e csak képet nem ad. Bár ez az aktivitás jelző ledeken is látszik azért.

    Esetleg megpróbálhatod a legfrisebb NOOBS rendszerrel telepíteni, valamiért nem linkelik ki az alapítványosok [link]

    Ha másnak van rev1.5 -össel működő ubuntuja, akkor nálad lehet a hiba. Ha mégis az ubuntus / vanila kernelük nem támogatja még az újabb változatot, akkor ubuntuéknál kell reklamálni valami hibajelentő részen. [link]

    Régebben is voltak már olyan hardver változások, aminél új boot csomag kellett. Csak azok általában ázsiai piacra szánt változatokon jelentek meg, ami kevésbé hangos nyugaton. Péládul amikor másik fajta ram chipet is elkezdtek használni, azokhoz is új boot firmware kellett és ehhez szoftveres összetevőket a telepített oprendszerben is frissíteni kellett.

    Ennél többet tényleg nem tudok tenni.

  • azbest

    félisten

    válasz BestofJAVA #40815 üzenetére

    Első körben raspberrry os-t futtass. de ha jól értem, akkor az megy és arról futtatod az imagert.
    A raspberry os alól listáztasd ki a pi-d pontos adatait.
    cat /proc/cpuinfo

    Valamikor 2022 tavaszában adták ki a pi4 rev 1.5-öt, amin más power management ic van már. A 2021 áprilisi firmawe csomagtól kezedve támogatott. Ha a rendszer, amit indítani próbálsz régebben készült, akkor jó eséllyel még a régebbi rendszerhez tartozó bootloadert és firmware dolgokat tartalmazza. Esetleg ez okozhatja az indítási gondodat.

    Volt több revizió is már előtte is [link] A cpuinfo kiírja elvileg [link]

    Ha nincs még hivatalos új image, amibe ez bekerült, akkor megpróbálhatod az, hogy kézzel odamásolod a boot fat particióra az újabb verziót valamiből. Viszont a kernelből lehet a meglévőt érdememes rajta hagyni, mert a rendszer partición a kernel modulok ahhoz tartoznak. mivel a kernelt is tartalmazza a boot partició, így azt érdemes meghagyni. Ha az is cserélve lesz, akkor oda kellhet másolni a kernel modul mappát is a rendszer partició megfelelő helyére.

    Régebben úgy emlékszem pi2w-n élesztettem fel így olyan rendszer, aminek a támogatása nem volt még az adott oprendszer fw csomagjában / boot particióján. [link]

    Hibakereséshez pontos infók kellenek, az kevés, hogy nem megy, meg az is kevés, amit mások írtak, hogy nekik meg megy :P

  • azbest

    félisten

    válasz Regirck #33687 üzenetére

    úgy látom van bug report róla ubuntuéknál [link]
    a kommentek alapján kernel verziónként változik, hogy hol jó, hol nem jó

    Van egy pár ötlet köztük, például
    - a psmouse driver modult modeprobe-bal újratölti alvás után

    - a kernel opciókhoz betesz egy kapcsolót, ami tán megoldja
    az /etc/defaults/grub -ban:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash psmouse.synaptics_intertouch=0"

    és sudo update-grub

  • azbest

    félisten

    válasz sonar #33685 üzenetére

    mostanában az android studióval érkező, android sdk részét képező emulator-t használom. Leginkább azért, mert már van olyan rendszerkép, ami nem csak play servicest hanem play storet is tartalmaz (nexus 5 és 5x).
    Megy simán, csak mintha a studio és az emulator is leakelne memóriát, ha nem kapcsolom ki csak altatom az emulator instancet, akkor van hogy 5-6GB ramot felszed és a leaket is visszatölti folytatáskor.

    Mondjuk van, hogy jól jönne más fajta eszköz is. Például tévéből sincs teljes értékű.
    Régebben genymotion-t használtam kézzel felvarázsolt open gapps-szal, de ugye az nem minden körülmények közt ingyenes, plusz hivatalosan nem támogathatja a gapps-ot és ezért kézzel kell feltenni. Nameg voltak gondok a geny-vel virtualbox verziók kapcsán is. Bár az win10 alatt volt még főleg.

  • azbest

    félisten

    Úgy tűniktényleg valami bug és talán a 4.16-os kernelbtől van benn a javítás [link]
    Ez annyiból szívás, hogy a 18.04 lts nem igazán fog mostanában kernelt váltani, ha jól értem.

    Az utóbbi napokban zram helyett megpróbáltam a zswap-et, ami állítólag jobban passzol ahhoz, hogy van háttértáron swap. Nem is volt addig baj, amíg kósza ötletként el nem kezdtem nyitogatni több android szimulátort, hogy stresszeljem. Mivel ez is eléggé beállt, bár most volt minimális log is a beakadáskor, ott is ext4 fájlrendszerbe kiírásnál lettek döcögősek a dolgok, szóval rákerestem most zram helyett zswap kontextusban is, hogy panaszkodnak-e kressekre... és dobott találatot, s meg is lett hamar, hogy a kernelhez úton van egy fix, amit linkeltem.

    szerk: ah... a hivatalos kernelbe valamiért máig sem került be [link], bár lehet félreértem és pont egy korábbi módosítást talált meg, mint a hiba okát :)

  • azbest

    félisten

    válasz ubyegon2 #33681 üzenetére

    Jó, hát az optimális az egy sokmagos desktop lenne, sok (32+) rammal, csak az kézipogyászban nem annyira egyszerű :D Néha irígykedem a kollégák karcsú macbook projára, amit csak úgy elő tudnak bármikor kapni, mint egy tabletet... de az árát és a bővíthetetlenséget nézve már nem annyira irígykedem, főleg hogy sebességben az újonnan vásárolt 15 colos gépük fogja felvenni a versenyt a 6 éves, kimaxolt, bár vaskosabb thinkpademmel :)

    Hogy ne csak off legyek, a tartalék gépemen (t430, i5-3320m, ssd, hdd, 3GB ram) valószínűleg kialakítok egy stressz környezetet és majd megpróbálok valami használható logot gyűjteni, mondjuk a logok másik háttértárra vagy particióra tükrözésével / irányításával. Hm, sőt, ha a t61esemmel (c2d t8300, 8GB, hdd) is tudom reprodukálni, az még külön segtheti a kivizsgálást. Gyanítom valami bugra futottam rá, csak mivel nagyon kevesen használják ezt, ezért nehéz külön infót találni hozzá, de a részletes bugriportot általában szívesen kivizsgálják.

    Stressz teszte mit érdemes szerinted használni? Múltkor
    stress --cpu 8 --io 4 --vm 8 --vm-bytes 1024M
    futtatás közben indítottam virtuális gépeket és fordítottam rá a projektet, az eléggé lepadlódott mindent :)

  • azbest

    félisten

    válasz ubyegon2 #33677 üzenetére

    Az, hogy hány lemez van a gépben irreleváns, korábban már írtam, hogy az ssd-re rakott rendszerrel merevre fagyott vele, a tiszta telepítést egy hdd-re tettem. Irreleváns, hogy van egy harmadik meghajtó is, ami szintén ssd. A rendszer particióval van probléma mindig, az válik csak olvashatóvá, amikor a hiba jelentkezik. Olyankor, ha aktív a zram. Mióta kikapcsoltam nem fagyott egyszer sem, pedig direkt stresszeltem.

    Az ssd-re tett swap nem gyorsabb, mint a memóriában lévő tömörített swap. Ezért hozták létre. Az a cél, hogy ne kelljen a lassú háttértárhoz fordulni, még a tömörítés overheadjével is megéri. (ha jól emlékszem, memteszt azt írta, hogy 16GB/sec a memória sávszélessége, ami egy-két nagyságrenddel még mindig gyorsabb, mint egy sata ssd)

    Többféle swap is lehet párhuzamosan, prioritást is lehet megadni. De nem kavartam kézzel ezeket, van zram-config, ami mindent beállít alapértelmezetten.
    A tömörítés nem fix, tartalomtól függő. A virtuális gépek miatt esélyes, az lenne a tippem, hogy sokszor csak üres, foglalt területet csinálnak, amikor növelgetik a szükséges ramot, de nem csökkentik vissza, mikor felszabadul.
    Egyébként nem teljes lemezt felhasználó szabad rablós telepítést szoktam csinálni, hanem külön, megfelleően nagy swap particiósat, hogy az altatással se legyen probléma. Multiboot rendszer, win is van és tartalék ubuntu telepítés is, ha a fő rendszer összehalja magát. Terepen nincs lehetőség napközben újratelepítéssel tölteni az időt.

    Ezt egyébként nem tudtam, hogy automata telepítésnél swap fájlt használna, mert évek óta mindig kézzel adtam meg a particionálást. A fájlrenszeren lévő swap szerintem csak növeli a megbízhatatlanságot, mivel pl a fájlrendszer hibája a swapre is hatással lenne és pl altatásnál sem tűnik ez jó ötletnek.

    Ettől persze még lehet valami nagyon megbújt hw hiba, de azért gyanús, hogy kifejezetten a zram kapcsán jön elő :)

  • azbest

    félisten

    válasz Frawly #33675 üzenetére

    A harmadik generációs intel core-i/chipset tudtommal csak 8GB-os modulokat kezel. Szóval a két slotba csak 2x8 ddr3 ram megy be. Elvileg létezik 16GB-os ddr3-as ram, arany áron és csak néhány géppel kompatibilisként. A w530-cassal keverheted, ami 4 slotos és valóban belemegy 4x8GB.

    Amúgy a zram teljesen jó volt a fagyásokat leszámítva. A szokásos nyitott chrome, skype*, slack*, thunderbird, android studio és 1 szimulátor, ami kb elvan 16GB rammal swappelés nélkül (*: azok is chromium alapúak). Zrammal ezek mellett 5 szimulátor is elfutott szépen, alapbeállításokkal ~8x1GB tömörített ram-swappel, amelyek valós ram foglalása kevesebb volt összesen, mint 1GB. Tehát egy marha gyors swapként szinte észrevehetetlen lassulást okozott. Csak hát az nem jó, hogy összeakad a fájlrendszerrel...

    Ha más nem, akkor annyit tudok tenni, hogy az egyik ssd-n van a rendszer és a másik ssd-n meg a swap, hogy még gyorsabb legyen, ha nem fér a ramba.

    Amúgy a kollégák macbook pro-kat használnak. Beforrasztott 8 és 16GB-os rammal, még opcióként sincsen több. Csak a swapelés miatt képesek kb használni. Nameg win és osx alatt is van ram tömörítés alapból, linuxon elvileg ez a zram a megfelelője annak.

  • azbest

    félisten

    válasz gyulank #33671 üzenetére

    egy thunderbird bug frissítéskor, álam is megjelentek.

    Kétféle szimlumokat tartalazó fontot érint. A megoldás innen [link], amíg a thunderbirdhöz nem jön meg a javítás.

    letölteni a linken lévő fontot
    EmojiOneMozilla.ttf [link]
    NotoEmoji-Regular.ttf [link]
    és bemásolni /usr/lib/thunderbird/fonts/ mappába (lehet létre kell hozni, mert nincs ott alapból). A thunderbird újraindítása után jó lesz a méret, csak a címsorban látszik.

    Előtte és utána

    Nem pont ugyanazok az ikonok, de legalább nem olyan, mintha megtámadtak volna a tamagocsik.

  • azbest

    félisten

    válasz stopperos #33669 üzenetére

    egyikkel sincs gond, sem az első ssd-vel, sem a hdd-vel, amire a tiszta renszert telepítettem. Egyébként mióta kikapcsoltam a zram-ot, azóta nem volt fagyás, ro újracsatolás a tiszta rendszeren, pedig rendesen meg volt hajtva most is.

  • azbest

    félisten

    Használ valaki zram-ot ubuntu 18.04-gyel?

    Az utóbbi időben kb napi egyszer lefagytam, de az utóbbi frissítések után volt, hogy 5x is. Sajna olyankor teljesen beragad minden, nem lehet átváltani sem konzolra, a háttértárra sem kerül kiírásra semmi onnantól. Ez egyébként 17.10-ről frissített rendszer, lehet ennek is van köze hozzá.

    Szóval telepítettem eg tiszta renszert, másik háttétárra. Ott stabilnak tűnt, majd bekapcsoltam a zramot és utána később elkezdtek hibát dobni a programok, hogy ro a háttértár.
    [16838.702681] EXT4-fs error (device sdb3): ext4_validate_inode_bitmap:137: comm java: Corrupt inode bitmap - block_group = 1648, inode_bitmap = 54001680
    [16838.805776] Aborting journal on device sdb3-8.
    [16838.824965] EXT4-fs error (device sdb3) in ext4_reserve_inode_write:5762: Journal has aborted
    [16838.895184] EXT4-fs (sdb3): Remounting filesystem read-only
    [16849.383414] EXT4-fs error (device sdb3): ext4_lookup:1575: inode #17432578: comm java: deleted inode referenced: 3409803

    Dmesg-ből sikerült látni, hogy tényleg háttértár problémát dobott, az új telepítés nem fagyott telibe, így ki tudtam szedni ennyi logot.

    Egyelőre kikapcsoltam a zram-ot, meglátom megint fagyok -e. Azért kérdem, hogy másnak van-e bármi tapasztalata, hogy hátha hamarabb meglesz mi a probléma oka. Egyelőre még nem tudom 100%-ra, hogy csak szoftveres bug-e vagy talán hardversen kezd valami galyra menni. A gép önteszte, memteszt, ilyesmi minden ok,

    Mielőtt valaki azt javasolná, hogy legyen több ram, sajna 16G a max a gépben, ssd háttértár, 4mag8szál proci, amúgy agy thinkpad t430. Csak sajnos a 16GB sem mindig elegendő, az android studio és a szimulátor eszi a ramot.

Új hozzászólás Aktív témák