- Októberi bevetésre indul a hardveralakulat
- Továbbfejlesztette az SP szériás, kompakt tápegységeit a Lian Li
- Itt van az ASUS legfrissebb, AMD platformra épülő mini PC-je
- Jegeli pénznyelő projektjét az Apple, az okosszemüvegben látják a jövőt
- Olcsónak ígérkező, madzagos egér jelent meg az ASUS ROG-os portfóliójában
- Apple asztali gépek
- Épített vízhűtés (nem kompakt) topic
- Milyen egeret válasszak?
- Egérpad topik
- Lenovo Legion Go: a legsokoldalúbb kézikonzol
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen belső merevlemezt vegyek?
- Vezetékes FEJhallgatók
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- iPad topik
-
PROHARDVER!
Amit érdemes tudni a Raspberry Pi-kről:
A legelső változat 2012-ben jelent meg. Pici, olcsó és nagyon alacsony fogyasztású, hobby-célú kártyagép. Felépítése ARM alapú, nem PC-architektúra, hanem kb. egy régi mobilhoz hasonló. Nagyon sok mindenre használható! A Linux-nak és a magas eladási mennyiségnek köszönhetően jelentős fejlesztőtáborral rendelkezik.
Új hozzászólás Aktív témák
-
vpleft
tag
Kijött a stabil 64 bites Raspberry Pi OS
-
vpleft
tag
válasz
Tyson5
#41890
üzenetére
A ram miért sérülne alapból egyáltalán?
Az a lényege, hogy a root partíciót read only-ba mountolja fel és minden módosítás a fájlokon egy overlayre fog menni.
Előnye ez, hogy nem sérülnek a fájlok.
Hátránya pedig az, hogy nem marad meg semmi módosítás a rendszeren. (De bármikor ki-be kapcsolhatod a scriptet) Egy újraindítás és visszaáll az az állapot, amikor az overlayfs-t aktiváltad. :)WoL felesleges szerintem, mert valszeg nem sokkal fogyasztana kevesebbet tőle, mintha üresjáratban menne. Szvsz érdemesebb bekapcsolva hagyni 0-24, vagy tényleg egy esp-s relével/sonoff-al teljesen lelőni. Sok sikert a szakdogádhoz!
-
vpleft
tag
Na, örülök, hogy meg lett a gond. Milyen jó is ilyenekkel órákat szívni...
Arch wikin írják azt is, hogy lehet "elmenteni" ezeket. Próbáltad udev rule-al?
nano /etc/udev/rules.d/69-hdparm.rulesACTION=="add|change", KERNEL=="sd[a-z]", ATTRS{queue/rotational}=="1", RUN+="/usr/bin/hdparm -B 255 -S 240 /dev/%k"
Ez ha jól értelmezem, minden hdd-re vonatkozik. (queue/rotational)
Persze a cron is megoldás lehet. -
vpleft
tag
válasz
vpleft
#41472
üzenetére
(A szerkesztési idő lejárt)
Itt az arch wiki-n is írják, hogy a 128-nál alacsonyabb apm leállíthatja a hdd-t még a beállított spindown előtt is. Akár beállíthatod a 256-ot is apm level-nek és emellé egy spindown timeout-ot, és akkor nem fog energiatakarékosan menni, viszont a spindown leállítja később. Vagy leveszed 128-ra az apm-et, a timeout-ot kikapcsolod, és hagyod, hogy pörögjön egész nap, amennyire tud, energiatakarékosan. -
vpleft
tag
válasz
oOKitsuneOo
#41402
üzenetére
Hali!
Tipp: Ejts meg egy force fsck-t, hátha az segít:sudo touch /forcefsck && sudo reboot -
vpleft
tag
Szia!
Nincs felmountolva a partíció, mert az lsblk sem mutatja a mount mappáját, szóval tényleg az sd kártyára másolszÚgy nézem, mintha a nobootwait paramétert nem támogatná az ext4. Próbáld meg kiszedni.
Ha nem ez a baj, akkor vlaszeg elírtad az uuid-t, vagy ilyesmi az fstab-ban és mivel ugye nofail paramétert adtál meg neki, ezért csak ignorálja azt a mount-ot, nem ír ki hibát.Pròbáld meg hogy kiveszed a nofail-t belőle (ne indítsd utána újra a pi-t mert nem fog bebootolni a hiba miatt) és mountoltasd újra az fstab-ot:
sudo mount -a
Ki fogja írni mi a baj. -
vpleft
tag
válasz
betyarr
#40817
üzenetére
Szerintem még a 120gb is overkill lesz ilyen célokra :) Én filmnézős-böngészős-fejlesztgetős desktopként használtam 32gb-os sd kártyával, (kevéske)qbittorrenttel 2 hónapig a 32bites raspbiant. Tárhely gond soha nem volt.
A 64 bites rendszernek/programoknak sem fog olyan sokkal több hely kelleni, mint most a 32 bitesnek
-
vpleft
tag
Hali!
Szerintem egy overlay fs megoldás lehet a problémádra, nem feltétlen kell hozzá akksi meg ilyesmi.
Ugye ez miután beállítottad, akkor read-only-ba fogja felcsatolni neked a root particiót minden induláskor, (szóval ha hirtelen elvágják a naftát akkor nem korruptálódik semmi a partíción) és erre húz egy rw overlay-t. Ez után persze minden újrainditaskor elveszik minden modositas, de cserebe biztos hogy működőképes marad a rendszer.
A raspi-config megcsinálja ezt neked könnyen ha szépen kéred
Ugyanigy ki is tudod kapcsolni ha modositani kell valamit. -
vpleft
tag
válasz
atesss
#38114
üzenetére
Nem a cat a gyorsabb, az csak egy alternativa lehet dd helyett.
Ugye dd-nél blokkokat olvasol és írsz, szóval blokkokat passzol tovább a kimenetén is. (ennek a mérete a bs paraméter) Ha a blokkméretet nem lövöd be pontosan a cél és a forrás maximum olvasási sebességére - ami valljuk be, nem olyan könnyű feladat és értelemszerűen eszközfüggő - akkor nem lesz a maximális a sebessége a mentésnek, mert vagy az olvasás fog loholni az írás után vagy épp fordítva. (Úgy kell ugye belőni, hogy kb folyamatos legyen az írás a cél fajlba és az olvasás a forrásból)
Szóval ha kihagyod a dd-t a mókából, és közvetlenül az eszköz driverén keresztül olvasol/írsz, akkor rábízod magad az os bufferelésére, amit az próbál mindig optimálisan belőni.
Két napja jöttem erre rá én is. A dd-s mentés 7 perccel tovább tartott a sima pv-s olvasásnál úgy, hogy gyors sd kártyát használtam, lassú olvasóval. 3x teszteltem és mindig 7 perccel tovább tartott dd bs=8M -al mint dd nélkül pv-vel. Bs=4M-ot meg is szakitottam mert megtovabb tartott mint a 8M.
Amúgy ez az utasítás:pv /dev/sdc > ./bckp.img
Byte-ra pontosan ugyan azt az img-t hozza létre mint ez:dd if=/dev/sdc of=./bckp.img bs=8M status=progress
(sha1 megegyezik)
Majd később még írok erről hogy lehet kisebb img-t létrehozni -
vpleft
tag
válasz
atesss
#38106
üzenetére
status=progress paraméterrel, tehát pl.:
dd if=/dev/sdc of=./backup.img bs=8M status=progress
De ez amúgy nem valami informatív szerintem és dd-nél tapasztalataim szerint sokkal gyorsabban le tudod menteni, hogyha pl így csinálod:cat /dev/sdc > ./backup.img
Így a lemez/sd kártya sebességétől függően a lehető leggyorsabban végez. És pont ugyan olyan megbízható is mint a dd
Hogyha státuszt is akarsz, arra tökéletes a pv nevű program:pv /dev/sdc > ./backup.img
Ez rajzol rendesen egy progress bar-t, illetve számol egy ETA-t is, stb -
-
vpleft
tag
válasz
atesss
#38056
üzenetére
Nekem rpi3 model B-m van és az a tapasztalatom vele, hogy bármilyen sd kártyát rakok a pi-be, nálam nem kicsit laggolni kezd tőle a rendszer és hamar korruptálni kezd fájlokat. Pár boot után alig akar indulni a desktop, aztán még néhány boot után már el sem indul...
Éppen tegnap egy samsung evo+ 32gb-os kártyával próbáltam, de azzal is ezt csinálta, az eredeti táppal.Szóval lazán instabilitást okozhat. Érdemes backupot készíteni mielőtt valaki kísérletezni kezd!
Van teszt is, igen. Pl. ezt találtam: benchmark
Én inkább nem piszkálom, de lehet hogy valakinek érdemes lehet kísérleteznie vele -
vpleft
tag
válasz
Márton
#37887
üzenetére
Örülök hogy sikerült megoldani!
Én is úgy tapasztaltam hogy fura hibákat okoz, úgyhogy szerintem simán lehet hogy amiatt volt... Sajna nem szól a rendszer, ha baj van. Én pl. kenyszeritem hogy fsck-zzon minden inditaskor.
(A boot particio cmdline.txt-jéhez hozzáadtam, hogy fsck.mode=force)
Mondjuk fura, hogy az fsck senkinek nem jutott eszébe eddig -
vpleft
tag
válasz
Márton
#37873
üzenetére
Király!
A fajlrendszer az sd kártyán fat32? Mert arra a fájlméret maximum kb 4gb. (csak egy tipp. Mondjuk fura lenne hogy 5.7gb-os fájl készült mégis
)
Ha ez a baj, akkor formázd exfat-ra vagy ntfs-re. Előbbi a legjobb amugy egy sd kártyához, de előbb telepíteni kell linuxra és mountolaskor a '-t exfat' parametert még meg kell adni hozzá -
-
vpleft
tag
Szerintem az nem lehet a baj, mivel a script a saját mappájába felcsatolja magának a /boot-ot, amit aztán kilépéskor le is csatol.
Részlet:# Átmeneti tároló mappák létrehozása
mkdir SRC_PART1 SRC_PART2 DST_PART1 DST_PART2
# Beállítja a forráspartíciót
mount $SDCARD'p1' SRC_PART1 # <- Ez a /boot
mount $SDCARD'p2' SRC_PART2 -
vpleft
tag
válasz
Márton
#37861
üzenetére
Van egy tippem.
Nyisd meg egy szerkesztővel a scriptet és az rsync utasításokhoz írd hozzá, hogy
'--modify-window=1'
Szóval az rsync utasítások kezdődjenek így:rsync --modify-window=1 ...2db ilyen rsync-es sor van a fájl vége felé. A többi részét a soroknak ne módosítsd. Hátha segít...
-
vpleft
tag
válasz
Márton
#37850
üzenetére
Szívesen!
"A /media alatt alapból szerepel az SDCARD, akkor is, ha nincs is bedugva a kártyaolvasó. Tehát az mkdir parancs nem is kell. Ez normális?"
Normális, persze. Lehet az OS már automatikusan becsatolta ezelőtt valamikor (?)
Egyébként mount-olni kb. bármelyik mappába lehet. Akár a home könyvtáradba is mountolhatod egy üres mappába az SD-t."...alapértelmezésként a /dev/mmcblk0 lesz használva. Ez ugye nem stimmel"
A scriptre ránézve szerintem nem az SD olvasót kell megadni paraméternek, hanem a rendszer SD kártyáját, ami a raspberry-ben van, amiről backup-ot akarsz csinálni. Szóval alapesetben szerintem de, stimmel. -
vpleft
tag
válasz
Márton
#37847
üzenetére
Csatold be valahova az SD kártyát.
lsblk #Kilistázza az elérhető particiokat.
Itt megkeresed az SD kártyád particióját pl. mmcblk1p1
Később majd úgy hivatkozhatsz rá, hogy elé írsz majd egy '/dev/'-et pl. /dev/mmcblk1p1sudo mkdir /media/sdcard #Létrehozol egy mappát a csatolási pontnaksudo mount -o uid=$UID /dev/mmcblk1p1 /media/sdcard
Így pedig becsatolod az előbb létrehozott mappába az SD-t a saját felhasználódnak($UID), mert különben root-nak csatolná és nem tudnál módosítani rajta semmit. (Persze ha minden utasításod elé sudo-t írsz majd, akkor tudsz módosítani mindent ugyanúgy. Mondjuk ennél a scriptnél ez a '-o uid=$UID' rész tökre elhanyagolható lehet, mert a script maga úgyis root-ként fut majd, de azért érdemes lehet megjegyezni.)Utána csak odanavigálsz a mappába:
cd /media/sdcardls #Kilistázod a fájlokat/mappákat
és voilá, a scriptnek elvileg ott kell lennie.chmod +x ./script_neve.sh #Futtathatóvá teszed a scriptetsudo ./script_neve.sh #Root-ként lefuttatodAztán ha végzett, lecsatolod a kártyát:
cd ~ #A home könyvtáradba navigálszsudo umount /media/sdcard
vagy:sudo umount /dev/mmcblk1p1
Eddig semmi problémába nem futottam bele.
Ugyanigy ki is tudod kapcsolni ha modositani kell valamit.
Új hozzászólás Aktív témák
- Új DDR5 Gamer PC i5-12-14400F -ig/RTX 3080 10Gb + 12 Féle VGA/500Gb - 2Tb SSD/16-32Gb Ram 2-4Év Gar
- Gamer PC-Számítógép! Csere-Beszámítás! R5 5500 / RTX 3060 12GB / 32GB DDR4 / 500GB SSD!
- Gamer PC - Ryzen 7 2700X, RTX 2070, 16gb RAM
- Lenovo S510 tower, i5-6400, 8GB DDR4, 500GB SSD Samsung 970 EVO, 500GB HDD
- Új Gamer PC i7 12-14700KF-ig/RTX 3080 + 12 Féle VGA/500Gb - 2Tb SSD/16-32Gb DDR4/600-850W 2-4Év Gar
- GYÖNYÖRŰ iPhone 11 Pro 256GB Midnight Green -1 ÉV GARANCIA -Kártyafüggetlen, MS3370,94% Akkumulátor
- Lenovo ThinkPad T14 Gen1 Intel I7 10610U Akció! 11.10.2025-ig kedvezménes, 130.000ft-os áron!
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Samsung Galaxy S24/Samsung Galaxy S24+/Samsung Galaxy S24 Ultra
- BESZÁMÍTÁS! MSI B760 i7 13700K 32GB DDR4 2TB SSD RTX 4080 16GB be quiet! 500DX Seasonic 750W
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest