-
GAMEPOD.hu
Utoljára frissítve: 2024.03.06.
Légy szíves olvasd el mielőtt kérdezel!
Az összefoglalóban sok helyen a fórumtársak hozzászólásai vannak belinkelve, vagy az ő információik alapján írtam meg, tisztáztam le az adott információt. Ezúton is köszönöm mindenkinek a segítséget!
Új hozzászólás Aktív témák
-
Csicsóka
őstag
válasz RedSwallow #58292 üzenetére
Korábban volt már ez téma. A probléma az, hogy hamarabb indul el a daemon, mint a hogy a HDD össze szedi magát, így nincsenek jelen a letöltési könyvtárak. Van viszont ennél 1xerűbb megoldás KODI TR addon.
Igaz, az előző, az összefoglalóban is linkelt 8.2.30 vezió nem működik 9-es CE alatt. Ezért összedobtam egy újat, ebben orvosolva van a túl korai indulás. 20 másodpercet vár, hogy feléledjenek a dolgok, és csak utána indul el a daemon. Nem kell elfeledni az addon beállításai alatt a letöltési könyvtárakat átírni, mert alapból a /storage/download-ba tölt. -
Csicsóka
őstag
Én máshogy csinálom. Persze nem azért, hogy az oled be ne égjen. (szét is taposnám ha ennyi ártana neki)
Unix bölcsőn nevelkedtem, ezért semmi csicsa nem kell botolás alatt, ezt szoktam meg. Ezért aztán nem is engedem, hogy a splash képet kitegye. Annál inkább érdekel hogy mit csinál bootolás alatt, ezért bőbeszédű módra váltok. Ehhez csináltam egy másik aml_autoscript-et, ami úgy módosítja az U-boot változókat, hogy átad vele a rendszernek két opciót. Ezt aztán a boot folyamat alatt még az initrd fázisban értelmez, és deaktiválja a splash-t és progress módba indít.aml_autoscript_nosplash_progress
Az eredeti aml_autosript-et át kell nevezni, vagy eltenni valahová.
Az aml_autoscript_nosplash_progress-t az SD gyökerébe másolni, és átnevezni aml_autosript-re
SSH-n belépve. reboot update parancs, és indul spalsh kép nélkül. -
Csicsóka
őstag
Az U-boot nem kérdezi a megjelenítőt, úgy indul ahogy az a változóiban szerepel.
Persze meg lehet neki mondani hogy induljon.720-ra így helyes:
fw_setenv hdmimode 720p60hz
fw_setenv outputmode 720p60hz -
Csicsóka
őstag
válasz DroiDMester #58317 üzenetére
Ezek direkt selejtes chipet raknak bele? Nekem legalább egy év után lett ilyen egy S905 boxban.
100-asra lassítva sem megy az ilyen hulladékon a tx irány?[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #58338 üzenetére
"De ha tudom a data particio kezdeti offset címét akkor ez működhet?"
Nekem nem működött, Oleg féle LE, 5.3.0-rc6 kernel. Z6 (S912 box)
Egyben látja az egész eMMC-t.LibreELEC:~ # cat /proc/partitions
major minor #blocks name
1 0 4096 ram0
1 1 4096 ram1
1 2 4096 ram2
1 3 4096 ram3
1 4 4096 ram4
1 5 4096 ram5
1 6 4096 ram6
1 7 4096 ram7
1 8 4096 ram8
1 9 4096 ram9
1 10 4096 ram10
1 11 4096 ram11
1 12 4096 ram12
1 13 4096 ram13
1 14 4096 ram14
1 15 4096 ram15
179 0 30535680 mmcblk1
8 0 7818152 sda
8 1 524288 sda1
8 2 7289768 sda2
7 0 91816 loop0VS CE:
root@CoreELEC-Z6:~# cat /proc/partitions
major minor #blocks name
7 0 158564 loop0
179 0 30535680 mmcblk0
179 1 4096 mmcblk0p1
179 2 65536 mmcblk0p2
179 3 524288 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 32768 mmcblk0p5
179 6 32768 mmcblk0p6
179 7 8192 mmcblk0p7
179 8 8192 mmcblk0p8
179 9 32768 mmcblk0p9
179 10 32768 mmcblk0p10
179 11 524288 mmcblk0p11
179 12 32768 mmcblk0p12
179 13 1048576 mmcblk0p13
179 14 28049408 mmcblk0p14
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0Kilesve a CE alól az offset értéke...
[ 2.721553@0] mmcblk0: emmc:0001 SDW32G 29.1 GiB
[ 2.721709@0] mmcblk0boot0: emmc:0001 SDW32G partition 1 4.00 MiB
[ 2.721872@0] mmcblk0boot1: emmc:0001 SDW32G partition 2 4.00 MiB
[ 2.722028@0] mmcblk0rpmb: emmc:0001 SDW32G partition 3 4.00 MiB
[ 2.722856@1] mmcblk0: unknown partition table
[ 2.723585@0] [mmc_read_partition_tbl] mmc read partition OK!
[ 2.723586@0] add_emmc_partition
[ 2.723840@1] [mmcblk0p01] bootloader offset 0x000000000000, size 0x000000400000
[ 2.724025@0] [mmcblk0p02] reserved offset 0x000002400000, size 0x000004000000
[ 2.724200@1] [mmcblk0p03] cache offset 0x000006c00000, size 0x000020000000
[ 2.724368@0] [mmcblk0p04] env offset 0x000027400000, size 0x000000800000
[ 2.724524@1] [mmcblk0p05] logo offset 0x000028400000, size 0x000002000000
[ 2.724686@0] [mmcblk0p06] recovery offset 0x00002ac00000, size 0x000002000000
[ 2.724855@1] [mmcblk0p07] rsv offset 0x00002d400000, size 0x000000800000
[ 2.725019@0] [mmcblk0p08] tee offset 0x00002e400000, size 0x000000800000
[ 2.725200@1] [mmcblk0p09] crypt offset 0x00002f400000, size 0x000002000000
[ 2.725361@0] [mmcblk0p10] misc offset 0x000031c00000, size 0x000002000000
[ 2.725533@1] [mmcblk0p11] instaboot offset 0x000034400000, size 0x000020000000
[ 2.725691@0] [mmcblk0p12] boot offset 0x000054c00000, size 0x000002000000
[ 2.725849@1] [mmcblk0p13] system offset 0x000057400000, size 0x000040000000
[ 2.726011@0] [mmcblk0p14] data offset 0x000097c00000, size 0x0006b0000000..se lehet mountolni.
Próbáltam a data, és cache-t nem jó.
Lementve LE alól dd-vel az egész mmcblk1-et image fájlba, úgy loop mountolva offset megadva, semmi eredmény.
CE alól kipróbálhatod, hátha. -
Csicsóka
őstag
válasz szabi__memo #58397 üzenetére
"De mi van ha több is van?"
Akkor fordul elő ilyen hibás működés.
Az SD-ről indul minden esetben, de a /falsh alá az SD-t, /storage alá pedig az USB-t teszi. Ez pedig így nem OK.
A problémát az okozza, hogy azonos lemez címkék vannak egyszerre a rendszerben, (ez alapján mountolódnak a partíciók) és ha már SD-ről indul, akkor a /storage alá a /dev/mmcblk1p2-t kell mountolni, de nem azt teszi hanem a /dev/sda2-t. (USB)A boot sorrend pont úgy van ahogy azt kovakovi77 kolléga leírta. U-boot változón keresztül ezt korábban (LE idején) lehetett változtatni az s905_autosript-ben. CE alatt nincs ilyen.
-
Csicsóka
őstag
válasz kovakovi77 #58442 üzenetére
Na ez szuper eredmény!
Ezzel annyival vagyunk előrébb, hogy jól működik ez a megoldás. Annyi vele csak a probléma, hogy csak úgy lehet ezt a módszert használni, ha egyedi kernel image készül, amiben, az initrd alatt ez a felcsatolás megvalósul. Csak így, ha akkor már jelen van a data, tudja a CE init folyamat a /storage alá csatolni.
Ha minden boxnál egyforma lenne az eMMC partícionálása nem is lenne probléma, mert csak egy módosítás kellene az init szkriptbe. Ugyan azt még nem néztem meg, hogy az ott lévő busybox értelmező ismeri e a losetup utasítást, mert ha nem, akkor meg sem lehet oldani. Az én vasamon a cache offset pont annyi mint a tiédben, de a data már teljesen más 0x000097c00000 (system is) Ezért nincs általános, minden boxra jó megoldás.
Persze magadnak csinálhatsz egy ilyen spéci, eMMC-ről futó CE-t. A módosított kernel.img előállításában tudok segíteni.
Ja, még egy probléma ezzel. Ugrott a frissítés lehetősége, mert egyből felülírná a módosított kernel-t, és megint csak SD-ről futna.
-
Csicsóka
őstag
válasz junkpod #58501 üzenetére
Igen, akkor pont úgy működhet, mint ahogy eddig megszoktuk, amikor data-t használtuk a /storage alá csatolva.
Kártyáról indult, de a "lényeg" (mediatár miegymás) már a gyors eMMC-ről volt elérhető.Most vannak új fejlemények az ügyben. Ránéztem a mostani CE kernel.img-re, és került az init szkript-be egy új, eddig nem létező lehetőség, amit minden induláskor ellenőriz. Így nem kell spéci egyéni kernel.img, és a későbbi frissítésekről sem kell lemondani.
Ha az SD gyökerében van egy mount-storage.sh nevű fájl, benne a mountolási lépésekkel, akkor az végrehajtja, és ott lesz a kívánt meghajtó a /storage alá csatolva. mount-storage.sh-ban aztán el lehet intézni a loopback eszköz létrehozását, megadva az offset értéket. kovakovi77 kolléga ha válalkozik rá, tesztelheti, az ő vasának megvannak az offset adatai, megírom a szkriptbe valókat még ma.
-
Csicsóka
őstag
válasz kovakovi77 #58525 üzenetére
Igen, már lehet dmesg is kérni pld. A sed nekem sem egy igazán, de meglehetne oldani úgy, én is úgy gondolom.
S912 vason (csak ez van most) a koncepció működé képes. A cache-t tettem a /storage alá, az említett mount-storage.sh-val.
Tartalma:
losetup -Pf -o 113246208 /dev/mmcblk0
mount /dev/loop0 /storage
#debug_shellEredménye:
CoreELEC:~ # df -h
Filesystem Size Used Available Use% Mounted on
devtmpfs 1.2G 154.8M 1.1G 12% /dev
/dev/sda1 511.7M 169.6M 342.2M 33% /flash
/dev/loop0 487.9M 6.3M 445.8M 1% /storage
/dev/loop1 155.0M 155.0M 0 100% /
tmpfs 1.3G 0 1.3G 0% /dev/shm
tmpfs 1.3G 9.1M 1.3G 1% /run
tmpfs 1.3G 0 1.3G 0% /sys/fs/cgroup
tmpfs 1.3G 2.6M 1.3G 0% /var
tmpfs 1.3G 0 1.3G 0% /tmp
/dev/sda2 6.6G 8.3M 6.6G 0% /var/media/STORAGEdebug_shell sor elől a hesmark-t kivéve, initrd stádiumba marad, lehet parancsokat futtatni.
Tesztelésnél is kellett, mert első alkalommal indítva megállt a bootolás, a kodi indítása előtt közvetlen.
Új fájlrendszert kellett létrehozni a cache-be, mert nem tudott írni abba amit a droid maga után hagyott.Ezzel az aml_autoscript-el indítva nem lesz splash, és verbose módban indul. Teszteléshez kiváló.
-
Csicsóka
őstag
válasz junkpod #58547 üzenetére
Ez jó, menni fog induláskor is.
Ha van droid a data-n, akkor inkább a cache-el próbáld, mert lehet hogy nem fog tetszeni neki amit a droid maga után hagy, és formázni kell.Ha formázni kell, így csináld CE alól (péda offset változhat a te vasadnak megfelelően).
losetup -Pf -o 113246208 /dev/mmcblk0
mkfs.ext4 /dev/loop1[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #58548 üzenetére
Átnevezed aml_autoscript-re felülírod az eredetit vele, CE alól reboot update, és mennie kell.
/dev/loop0 igen mert abban az init fázisban még nem foglalt, és ugye az jön létre először.
Azátn már a loop1 a SYSTEM fájl lesz felcsatolva./dev/sda1 511.7M 169.6M 342.2M 33% /flash
/dev/loop0 487.9M 6.3M 445.8M 1% /storage
/dev/loop1 155.0M 155.0M 0 100% /Itt is látszik.
-
Csicsóka
őstag
válasz kovakovi77 #58553 üzenetére
Nem bántja csak a cahe-t, így csináltam én is, mert debug_shell-ben nincs mkfs, se mke2fs parancs, buta busybox miatt.
De megcsináltam megint, és ok, persze ez az én cache-em az ő adatai NAGYON fontosak valóban.
Remélem azt a 4-es kernel is így akarja, mert ugye én S912-n próbáltam.
Te nem tudod kipróbálni?CoreELEC (official): nightly_20190904 (Amlogic.arm)
root@CoreELEC-Z6:~# losetup -Pf -o 113246208 /dev/mmcblk0
root@CoreELEC-Z6:~# losetup
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0 0 0 1 1 /dev/SYSTEM 0 512
/dev/loop1 0 113246208 0 0 /dev/mmcblk0 0 512
root@CoreELEC-Z6:~# mkfs.ext4 /dev/loop1
mke2fs 1.45.2 (27-May-2019)
/dev/loop1 contains a ext4 file system
last mounted on /storage on Tue Sep 10 20:40:50 2019
Proceed anyway? (y,N) y
Suggestion: Use Linux kernel >= 3.18 for improved stability of the metadata and journal checksum features.
Creating filesystem with 7606272 4k blocks and 1905008 inodes
Filesystem UUID: a376de4c-ce98-4ee2-bca4-73d70c4d419b
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #58557 üzenetére
Meg a tiéd is ilyen.
[ 1.085611@2] meson-mmc: [mmcblk0p03] cache offset 0x000006c00000, size 0x000046000000
Lehet minden boxnál a cache itt indul.
Így semmit nem kell változtatni a példában írton, csak kipróbálni. -
Csicsóka
őstag
válasz kovakovi77 #58562 üzenetére
Akkor már ne állj meg itt, próba ezek szerint. Megtudjuk az igazságot S905x2-n is.
-
Csicsóka
őstag
válasz kovakovi77 #58564 üzenetére
Nálam nem sérült semmi, bentről fut az "éles" rendszerem.
-
Csicsóka
őstag
válasz kovakovi77 #58568 üzenetére
Nem lett nagy, fél giga, ahogy szokott is lenni a cache. Itt látható, ez a futó rendszerről van, a loop0 a cache. Lehetséges, hogy itt azért nem ment tovább, mert a dtb-ben megvannak a partíció méretek, és írtam, hogy ez 3-as kernel, 912-es box. Az biztos, hogy x2, és 922-nél meg kell majd adni hogy meddig szaladhat az mkfs.ext4.
-
Csicsóka
őstag
válasz junkpod #58571 üzenetére
Nem akarunk mindenáron formázni, csak ha nem indul el a kodi.
Nálam nem indult el, volt valami a droid által használt cache-ben. Közvetlen a kodi indulása előtt fagyott bele, megnéztem, érdekes módon, a könyvtárakat (backup .update video, stb.) létre hozta rajta. Ezt sikerült ráírnia, de nem indult el, ezért formáztam.Ez másként működik, mint amit te említesz. (symlink) nem kell semmit sem sehová linkelni, az egész /storage alá kerül az emmc partíció. Induláskor pont úgy tiszta lappal indul, (be kell állítani) mint egy új telepítés.
Igaz, a belakott STORAGE az SD-ről, ott lesz felcsatolva a /media alatt, itt látszik a /dev/sda2 sorban. Onnan aztán mc-vel, vagy rsync-el simán át lehet másolni a /storage alá mindent, és ott lesz a belakott rendszer. -
Csicsóka
őstag
válasz kovakovi77 #58582 üzenetére
Na, akkor itt a bizonyíték, hogy megoldható x2 alatt is az eMMC ilyen jellegű használatára. Örülök hogy sikerült!
Ha nem veszem elő most az init szkriptet, nem találom meg ezt a /storage csatolós lehetőséget. Korább biztosan nem volt benne, mert elég sokat bújtam e témát az ext4 CE, és a **MC kapcsán. Nem is olvastam sehol, hogy a CE srácok ezt említették volna.Ezzel a megoldással, nem lehet bármit megtenni az init alatt, mert a folyamat egy adott pontján avatkozik be. Ez csak a /storage csatolása. Itt az említett rész az init-ből.
mount_storage() {
progress "Mounting storage"
if [ "$LIVE" = "yes" ]; then
# mount tmpfs and exit early. disk=xx is not allowed in live mode
mount -t tmpfs none /storage
return
fi
wakeonlan
if [ -n "$disk" ]; then
if [ -n "$OVERLAY" ]; then
OVERLAY_DIR=$(cat /sys/class/net/eth0/address | tr -d :)
mount_part "$disk" "/storage" "rw,noatime"
mkdir -p /storage/$OVERLAY_DIR
umount /storage
# split $disk into $target,$options so we can append $OVERLAY_DIR
options="${disk#*,}"
target="${disk%%,*}"
if [ "$options" = "$disk" ]; then
disk="$target/$OVERLAY_DIR"
else
disk="$target/$OVERLAY_DIR,$options"
fi
fi
if [ -f /flash/mount-storage.sh ]; then
. /flash/mount-storage.sh
else
mount_part "$disk" "/storage" "rw,noatime"
fi
else
# /storage should always be writable
mount -t tmpfs none /storage
fi
}Ha érdekel, az itt lesz az init és a platform_init szkript.
-
Csicsóka
őstag
válasz ViktorHUN79 #58583 üzenetére
Az 50 Hz, CRT TV-ken volt érdekes, hogy nem interferáljon a hálózati frekivel, és a PAL analog szabvány miatt. LCD-nél jobb a max, amit a panel tud. Ezért lehet 60 Hz. A droid alól át lehet állítani, ha nincs, akkor CE alól pld. így.
-
Csicsóka
őstag
válasz junkpod #58593 üzenetére
Igen ez lesz a /storage alá téve az SD helyett. Át is másolunk rsync-el mindent. Reboot után már eMMC-n lesz a belakott /storage
Offset adat tőled származik (hexa/dec konverzió után).
mkdir /tmp/mnt
losetup -Pf -o 4016046080 /dev/mmcblk0
mount /dev/loop1 /tmp/mnt
systemctl stop kodi
rsync -av /storage/ /tmp/mnt/
mount -o remount,rw /flash/
nano /flash/mount-storage.shA megnyíló szerkesztőbe ezt:
losetup -Pf -o 4016046080 /dev/mmcblk0
mount /dev/loop0 /storageMentés, kilépés, reboot
Ha nem indulna el, akkor nem tetszik neki az ami data-n van.
Kiveszed az SD-t, és átnevezed a mount-storage.sh-t mount-storage.sh.bak-ra.
Utána megy megint SD-ről.Mindenki mást óvok ennek az írásnak egy, az egybe másolásától, mert a TE vasadon más lehet az offset érték, és nem fog működni.
-
Csicsóka
őstag
válasz kovakovi77 #58600 üzenetére
Elvileg nem lehet baj a mount-storage.sh, mert nem dózeres szerkesztővel csinálta, nano meg jól kezeli a sorvégeket. Fájlrendszer hibára tippelek, ezért folytatva ott amit írtál, debug shell alatt lehet indítani fsck-t, hátha javít valamit, és elindul.
junkpod, ezt debug shell alatt próbáld, kell a boxra egy billentyűzet, angol kiosztás lesz.
e2fsck /dev/loop0
Ha javít valamit akkor ez volt a hiba, ha azt mondja hogy clean akkor:
losetup
dfmit mond?
reboot, poweroff debug módban is van.
-
Csicsóka
őstag
válasz kovakovi77 #58602 üzenetére
Ha nem rw-be csatolódott, akkor az rsync se tudott volna hiba nélkül lefutni.
Egy sync parancsot kellett volna még írnom, az rsync után, hogy kiürítse a pufferket, mert lehet hogy olyan gyorsan rebootolt, hogy valójában még írta a data-t. -
Csicsóka
őstag
válasz junkpod #58603 üzenetére
Ez így jó, ez kell hogy legyen.
A fájlrendszer ellenőrzést megtudod úgy is csinálni, hogy átnevezed a mount-storage.sh-t mount-storage.sh.bak-ra. Így nem kell billentyűzet a boxra.
Elindítod SD-ről, majd:losetup -Pf -o 4016046080 /dev/mmcblk0
e2fsck /dev/loop1Ha talál hibát akkor ki is javítja majd.
A frissítés itt nem kavarhatott be.
[ Szerkesztve ]
-
-
Csicsóka
őstag
válasz kovakovi77 #58613 üzenetére
Nálam van -P, és minden ok, cache, és data is működik, ahogy nálad is.
Kipróbálni persze kilehetne.
Belehet írni a végére egy losetupot, de ha nem verbose módban indít, nem fog látszani.[ Szerkesztve ]
-
Csicsóka
őstag
válasz junkpod #58616 üzenetére
Valahogy éreztem, hogy még is van valami szemét a data-n ami miatt, nem megy.
Ha a remote.conf a /storage/.config-ban volt akkor nincs táv. Ha az SD gyökérben akkor lennie kell.
Fel van csatolva az SD storage, a /media alá. Onnan lehet másolni.Közben szerkesztetted, nem fura, az automount oda teszi az SD storage-t.
[ Szerkesztve ]
-
Csicsóka
őstag
válasz junkpod #58623 üzenetére
Örülök, hogy csak összejött az eMMC használata x2 vason is. Így, hogy az utat kitapostuk, más akár GTK boxon is megvalósítható lesz. Lehet hogy nem lett érzetre sokkal gyorsabb, mint SD-ről, de kár lenne parlagon hagyni egy ilyen nagy tárhelyet, mint a data.
A driodot nem ismerem olyan mélységben, mint a Linuxot, az alapokat értem csak. Pont azt csinálja, mint amit írsz, ezért tart olyan sokáig egy vipe utáni indulás. Van a system-ben egy preinstall könyvtár, oda pakolják be a ROM készítők azokat az apk-kat, amit rá akarnak tenni az alap driodra. (kodi, netflix, stb.) Ezeket felpakolja, és van még egy davlink cache dolog is, amit első induláskor létrehoz. Azért kell ezeket a data-ra pakolni, mert root nélkül, egy rendes halandó, nem piszkálhat bele a system-be. Ezért aztán a droidot nem lehet teljesen kiütni, bármit is akar egy user, gyári resettel feláll mindig.
-
Csicsóka
őstag
válasz junkpod #58622 üzenetére
Lett még egy haszna ennek a "barkácsolásnak" A régebbi SOC banda (s905 s905x, s912) is használhatja ezt a mount-storage.sh megoldást. Legegyszerűbben így lehet használatba venni a data, vagy cache partíciókat. A korábbi megoldások mind bonyolultabbak voltak.
Akár mindkettőn is lehet egy egy rendszer, a cache-be pld. egy jól beállított alap rendszer, komoly media tár nélkül, mert az nem fér bele a fél gigába. Ezt bármikor elő lehet venni, ha a data-ra tett full rendszerrel valami gebasz történik. Vagy tesztelni pld. a kétféle távirányító kezelési megoldást, hogy melyik tetszik jobban.A 3-as kernelnél már boot időben jelen van a /dev/cache, és /dev/data, ezért nem kell offset értékekkel, loop eszközzel variálni. Egy minden boxra általánosan használható megoldás ez. A vason lakó droidot ez nem bántja, megférnek egymás mellett.
mount-storage.sh tartalma:
mount /dev/data /storage
#mount /dev/cache /storageVáltani a két partíció közt úgy lehet, hogy a nem használt (itt most a cache) sor elé kell egy kommentet (#) tenni. Mindkét sor elé téve úgy indul mit eredetileg SD-t teszi a /storage alá. Mindkét sor elől kivenni viszont nem szabad!
AZ SD-n belakott rendszert a korábban írtak szerint, rsync-el lehet a data-ba költöztetni.
-
Csicsóka
őstag
válasz szabi__memo #58641 üzenetére
A **MC teljesen más káposzta. Ott az egész rendszert úgy ahogy van, mindenestől be lehet tenni a data-ra.
A CE-nél ennek a megoldásnak az az értelme, hogy gyakorlatilag az az SD partíció amit ír, olvas a rendszer, az bekerül a data-ra. Mérések, és tapasztalat szerint is az eMMC legtöbb esetben, mindenféle SD-től gyorsabb, a gyűrődést is jobban viseli. -
Csicsóka
őstag
válasz Csicsóka #58640 üzenetére
Kiegészítés az előbbi témához.
Ha az SD első FAT partícióján (kernel, dtb mi egyebek vannak ott) kell bármit szerkeszteni SSH-n, nem kivéve a kártyát a boxból, mindig írhatóra kell remountolni, mert alapból csak ro.
Nagyon utálom, hogy ezt mindig meg kell tenni, mikor van lehetőség a szintén a gyökérbe tett post-flash.sh fájlal, rw-re vissza mountolni. Így mindig így fog indulni, nem kell kézzel variálni.post-flash.sh tartalma:
mount -o remount,rw /flash
Nálam SMB-n is megvan osztva a /flash, így SSH sem kell bohóckodni.
samba.conf ide vágó része:
[SD_card]
path = /flash
available = yes
browseable = yes
public = yes
writeable = yesA hirtelen felindulásból elkövetett törölgetésre mostantól vigyázni kell, mert a /flash alatt már nem véd a ro.
-
-
Csicsóka
őstag
válasz kovakovi77 #58678 üzenetére
Lehetne visszaszámolni 5,4,.. stb, de az rárondítana a szép spalsh képre, ami sokaknak fontos. intrd-ben nincs még IR kezelés, táv nem megy, billentyűzetet meg bedugni... Nem tetszene a népnek az tuti.
Ha van post-flash.sh akkor akár SMB-n lehet pillanat alatt átírni. -
Csicsóka
őstag
válasz kovakovi77 #58702 üzenetére
Mikor nekem megállt először a cache-be téve, verbose módban volt indítva, és végig ment egészen a framebuffer console indításáig, az pedig a kodi indítása előtti lépés. Ekkor már él minden, ezért nem kitáptem a tápot, hanem SSH-n poweroff-oltam. SMB is van már ilyenkor. Összefo*ott kodi nálam ezt csinálta. Cache formázás után 1ből indult.
Input beolvasásra read parancsot használok, de az mindenképp megállítja a folyamatot x sec time out-ig, és vár bemenetre.
Pld, a mount-storage.sh-ba lehet ilyet csinálni.#
#Kernel 3.x
mount /dev/data /storage
#mount /dev/cache /storage
# Kernel 4.x
#losetup -f -o 113246208 /dev/mmcblk0
#mount /dev/loop0 /storage
read -s -n 1 -t 5 -p "Press x" choice
case "$choice" in
x)
echo
echo "OK"
;;
esac
echo
debug_shellItt egyetlen karaktert vár inputként, 5 sec timeout-ig a leütött karakter nem teszi a képernyőre (-s silent)
Ha ez az x, akkor OK-vel válaszol. Ha nem az akkor nem foglalkozik vele tovább fut.
Ezt lehet bármilyen további parancs futtatásra használni, az echo "OK" helyett. -
Csicsóka
őstag
válasz kovakovi77 #58702 üzenetére
Így lett belőle egyfajta megoldás, használom majd.
read -s -n 1 -t 5 -p "Press c!" choice
case "$choice" in
c)
echo
mount /dev/cache /storage
;;
*)
echo
mount /dev/data /storage
;;
esacHogy kevés szöveg legyen a splash képen, csak ennyit ír a bal felső sarokba, Press c!
Attól a pillanattól van 5 sec, hogy c-t nyomjak, így elindul a cache-be tett KODI.
Ha mást, vagy semmit nem nyomok, akkor az alap működés szerint, a data-ra tett KODI fog elindulni.
Lehetne még szép magyarázó regényeket kiíratni, hogy mit, hogy, miért, de ez így elég szerintem.
S905x2-re majd átírod ha kell neked.Az üres echo soremelésre kell csak, mert nélküle a Press c! után, és nem alá írná ki hogy CoreElec.....
[ Szerkesztve ]
-
Csicsóka
őstag
RTL8153-al semmi probléma, már ha az van benne, és nem RTL8152. Páran megszívtuk már vele, mert az csak 10/100-as. Asix nem volt hamis, eddig.
Ha egy ilyen megérkezik, csak próba után dől el, hogy mi is van bent.
A DX mondjuk korrektebb volt mint Béni kolléga esetében, mert amikor rendeltem egy Asix chipest, pár nap múlva írták, hogy sajnos a gyártó áttért RTL8153-ra, és ha akarom módosítsam a rendelést, ha ez nem megfelelő.
Új hozzászólás Aktív témák
- APPLE Mac Studio M1 Max 10C CPU, 24C GPU, 32G RAM, 512GB SSD
- Eladó konfig! Ryzen 5 5600X 512GB M.2 SSD 16GB DDR4 RTX 3060Ti 8GB!
- HP 27-cr0757nz - ÚJ 27"-os FullHD All-IN-ONE PC - i7-1355U, 32GB, 1TB SSD, W11, 300nit
- HP Prodesk 600 G4 DM mini pc, G5420T, 4-8GB RAM, 120-240GB SSD, 2 év gari, áfás számla
- HP Prodesk 600 G4 DM mini pc, G5400T, 4-8GB RAM, 120-240GB SSD, 2 év gari, áfás számla
- 12.-generációs Gamer PC: 8Gb videokártya/16Gb DDR5 Ram/SSD/HDD/Win11/Garancia
- 4gen I5 félkonfig
- BRUTÁL ERŐS SZÖRNYETEG GAMER PC AMD Ryzen Threadripper 1950X 16 mag, 11GB VGA, ASUS ROG STRIX X399
- Raspberry pi 4 model B 4GB+extráka
- 12.-gen Core i5 Gamer PC: RTX 3060 TI / 16Gb DDR5 Ram /SSD/HDD/WIN11/Garancia
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen