Barkácsolás – Winben blogja

Raspberry Pi 4: boot from usb

A helyzet a következő.

Raspberry Pi 4-en jelen pillanatban stable firmware-el még nem elérhető usb boot. Ez azt jelenti, hogy csak microSD kártyát bedugva képes üzemelni a bankkártya méretű kis számítógép.

Probléma lehet még továbbá az is, hogy ha kifogyunk a memóriából akkor a rendszer elkezd akadni, megállni és – mivel nem tud, nem lehet mindent kilőni – kb a használhatatlanságig lassul. Nyilván ezt a problémát lehet orvosolni azzal, hogy egy nagyobb memóriával rendelkező Raspi4-et veszel, de ha esetleg abból is kifogynál még mindig van cserehely (swap) ahova az oprendszer a memóriából a nem használt dolgokat ki tudja lapozni.

Igen ám, a probléma viszont ott kezdődik, hogy a kis gépecske alapesetben sd kártyáról üzemel ami nem a gyors/sok írás-olvasásra lett kitalálva, magyarán szólva a gépünk marhára lassú lesz az SD kártya miatt.

Ezért (és a nagyobb tárkapacitásért) érdemesebb venni egy SSD-t és egy usb 3.0-s sata átalakítót és a Raspbian-t átköltöztetni rá.

Jelen leírásomban nem azt mutatom be, hogy hogyan tud abszolút SD kártya nélkül üzemelni a bébi, hanem azt, hogy egy már meglévő alap, buta, lassú sd kártya mellé hogyan lehet ssd-re átköltöztetni és belakni a teljes alaprendszert.

Összetevők

minimum 8G-os sd kártya
sata csatolós SSD
sata-usb 3.0 átalakító, vagy beépítőkeret 2.5″-os meghajtóhoz
nem szükséges külső táposat venni, az ssd-t és lényegében a legtöbb hdd-t is képes a rpi üzembiztosan a saját hivatalos tápegységével meghajtani

Alaprendszer telepítése

Töltsd le az aktuális legújabb Raspbian-t (ez egyébként a 10-es Debian-nal egyenértékű), írd ki az sd kártyára, dugd be a raspi-ba, hálózatot is adj neki, indítsd el, hagyd, hogy összeszedje magát.

Ha megvan

sudo su

raspi-config

paranccsal az Interfacing Options alatt engedélyezd az ssh-t. Ezek után már monitor nélkül egy másik számítógépről is rácsatlakozhatsz PuTTY-ot használva.

Előkészítés

Miután már él az ssh kapcsolat az összerakott usb-s ssd-t csatlakoztasd a raspi kék színű aljzatához. A kék színű aljzat a 3.0-s csatoló.

Konzolon (putty) csekkold le, hogy látja-e az ssd-t a raspi:

fdisk -l

/dev/sda-ként meg kellene jelenjen.

Ha nem egy lsusb paranccsal nézd meg biztosan megfelelő-e a csatlakozás, ellenőrizd a kábeleket, nézd meg pc-re dugva az ssd-t, hogy okés-e vagy sem.

Ha az fdisk-ben látható a /dev/sda akkor nyert ügyed van, mehetünk tovább.

A másolást megelőzően le kell formáznunk az ssd-t, figyelj oda, nehogy fontos adatokat tárolj rajta!

fdisk /dev/sda
> o
> n
> p
> enter, enter, enter
> p
(ezután kellene láss /dev/sda1-et)
> w

mkfs.ext4 /dev/sda1

Nyitottunk egy új partíciós táblát, létrehoztunk egy partíciót, majd ext4-re formáztuk.

Költözés

mkdir /mnt/ssd

mount /dev/sda1 /mnt/ssd

rsync --exclude="mnt" --exclude="lost+found" --exclude="sys" --exclude="proc" --exclude="cdrom" --exclude="media" --exclude="swapfile" -aP / /mnt/ssd/

mkdir /mnt/ssd/{mnt,proc,sys}

Megtörtént az ssd felcsatolása, és a gyökér fájlrendszer tükrözése. Fontos, hogy e művelet közben semmi mást ne csináljon a raspi. Igazából élő rendszeren nem is egészséges ilyet csinálni, mert inkonzisztencia léphet fel a másolt/cél fájlrendszerben, de mivel egy zsír új rendszerről van szó nagy kár nem történhet, max újrakezdjük.

Ha sikeresen lefutott a másolás akkor rá kell vennünk a raspi-t, hogy a gyökér fájlrendszert ne az sd kártyán keresse hanem a csatlakoztatott usb meghajtón.

Kérdezzük le először is az ssd-n lévő partuuid-ját:

blkid /dev/sda1

Ilyesmi fog fogadni:

/dev/sda1: UUID="b1b85e84-6440-4b65-8dd7-35ee51314143" TYPE="ext4" PARTUUID="3ea0d1f6-01"

Ebből nekünk a PARTUUID fog kelleni, másoljuk ki az értékét valahova jegyzettömbbe.

Ezután jön az a rész, hogy megmondjuk a raspi-nak, hogy ez a partuuid lesz az ő root-ja a jövőben.

nano /etc/fstab

Illetve

nano /mnt/ssd/etc/fstab

helyeken keressük meg azt a sort ahol a második “oszlop” csak egy “/”

Itt a PARTUUID= utáni értéket módosítsuk az ssd partuuid-jára, majd

nano /boot/cmdline.txt

Itt egyetlen sort találsz, keresd meg benne a root=PARTUUID=… részt, itt is módosítsd az értéket az ssd-d id-jára. Ha ezzel is megvagyunk akkor kb végeztünk is, nézzük meg sikerrel jártunk-e:

df -h

Ha a “Mounted on” oszlopot figyeljük és megkeressük a /-t akkor az “Avail” oszlopban látható az sd kártyánk mérete. A rendszer ekkor még nem ssd-t használja.

Indítsuk újra a raspi-t:

reboot

Bejelentkezést követően ismét nézzük meg a csatolt lemezeket és tadam:

root@winben:/home/winben# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       880G   21G  815G   3% /
devtmpfs        358M     0  358M   0% /dev
tmpfs           487M     0  487M   0% /dev/shm
tmpfs           487M   31M  456M   7% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           487M     0  487M   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   53M  200M  21% /boot
tmpfs            98M     0   98M   0% /run/user/1001
root@winben:/home/winben#

Ha az Avail oszlopban látható az ssd nagyobb kapacitása sikerrel jártunk.

Swap beállítása

Alapból 100Mb default cserehely/swap van egy raspbian-on beállítva, ez pont elég ahhoz, hogy az alkalmazások elinduljanak és közben ne egye meg az sd kártyát, de nekünk egy gyors ssd-nk lett, így már lehet nagyban gondolkozni.

fallocate -l 16G /swapfile
chmod 600 /swapfile 
mkswap /swapfile 
swapon /swapfile

Készítettünk egy 16GB méretű cserehelyet az ssd-n és kvázi fel is csatoltuk. Nézzünk rá sikerrel jártunk-e:

 swapon --show

vagy

htop

vagy

 free -h

Ha látható a létrehozott 16G-s swapfile felcsatolva sikeres volt a létrehozás.

Viszont ahhoz, hogy újraindítás után is használja a rendszer fel kell vennünk fstab-ba:

 echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab

Mostantól újraindítást követően is nyomonkövethető lesz htop-ban mennyi ramot és mennyi swapot/cserehelyet használ a bébi.

Enjoy!

Rpi4 vs Do szerver

Elkezdett bennem érlelődni a gondolat, hogy mivel a weboldalaim jelenleg kisebb látogatottságúak simán áttehetném az épp egyik használaton kívüli rpi4-esemre.

Igazából néhány wp oldalam fut, amin tulajdonképpen cache sincs, tehát a php-nak kell eleget dolgoznia. Fogtam tehát billentyűzetet és első körben leteszteltem, hogy processzorban mekkora a különbség egy 5 dolcsis alap 1 magos Digitalocean szerver és egy Raspberry pi 4 (1G ram+ssd) között az alábbi módon:

sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 run

A Digitalocean szerver így alakított:

Threads fairness:
     events (avg/stddev):           680.7500/0.83
     execution time (avg/stddev):   9.9814/0.01

A kis bankkártya méretű számítógép:

Threads fairness:
    events (avg/stddev):           2500.0000/41.70
    execution time (avg/stddev):   65.5436/0.01

Nagyjából 6.5x az eltérés a Digitalocean javára.

Jelenleg a Digitalocean szerverem 5.8%-os átlag cpu terheltségével számolva a raspi-n ez az érték kb 40%-os átlagos cpu terhelésre emelkedne. A 40% körülbelül már az a határ amikor még éppen jók vagyunk, de azért belátható, hogy kevés tartalék marad. Viszont a WordPress oldalakat van még bőven hova optimalizálni, így a várható forgalomnövekedések során még mindig nem szalad ki a világba az rpi terheltsége.

Jelenleg a Digitalocean mellett szól a sebesség, az (elvileg) jó skálázhatóság és megbízható, stabil működés. Hátránya a magasabb üzemeltetési költség és drága/kis méretű tárhely.

A raspi mellett szól, hogy rádughatok egy 250G ssd-t usb3.0-n úgy, hogy erről bootol már eleve az alaprendszer is. Onnantól kezdve, hogy van stabil netem, helyem és megvalósításom az üzemeltetésre annyira keveset kér a raspi enni, hogy egy éven belül behozza a raspi a Do-al szemben az árát.

Elgondolkodtató.

Ezért érdemes sshfs-t -C kapcsolóval használni

Van ugye az a protokoll – remélem ismerős -, hogy “sftp”. Tegyük fel, hogy van egy linuxos adattároló szervered és egy linuxos géped. Közvetlen fel tudod csatolni sshfs-el a távoli gép valamely mappáját, ha van rajta unix felhasználói fiókod és hozzáférésed.
Namost az sshfs-nek van egy -C, mint compression kapcsolója, ami a két gép közötti átviteli sebesség növelésében játszhat szerepet, mivel a két gép közötti adatfolyamot képes tömöríteni. Ehhez persze némi processzor kell mindkét oldalon, de egy HP microservernek sem konnyan meg a dolog (nálam az érintett adattároló gép).
Tehát ha linuxot használsz az alábbi paranccsal felcsatolhatod a távoli gép könyvtárát a helyi gépedre:

 sshfs -o allow_other,default_permissions -o IdentityFile=/helyi_szerver/publikus_kulcs winben@szerverem.hu:/tavoli_szerver/csatolasi_pont /helyi_szerver/csatolasi_pont -C -o reconnect;

Mi az eset akkor, ha Windows használok?

Igen, sokan vagyunk így, kipróbálhatunk egy csomó sshfs-t megvalósító alkalmazást. Ilyen a fizetős expandrive, vagy az ingyenes win-sshfs.

Részemről egyik sem nyerte el a tetszésemet többek között azért, mert instabilak voltak, suttyomban a program files-ba cache-eltek és nem is a valós állapotot mutatták sokszor…és legfőbb problémám volt, hogy láthatólag egyik sem szolgált a tömörítős megoldással, ami miatt (vagy még mellett) dög lassú volt az adatátvitel.

Nos, ha van egy kis memóriád fölösen a gépben akkor van egy szuper jó hírem – a probléma baromi jól orvosolható.

Készíts egy linuxos virtuális gépet localhoston, ami NATolva csatlakozik a hálózatra, tehát a te géped oszt neki IP címet.
Ha megvan a telepítés csatold fel a távoli mappát a virtuális géped egy helyi mappájába.
Ezután telepíts sambát a virtuális gépre és oszd meg a felcsatolt mappa tartalmát.
Tallózd be Windows Intézőben a sambán megosztott tartalmat és örülj. Az adatátvitel gördülékeny lesz és megfelelő tartalom esetében gyors.

Ha olyan kontentről van szó, ami jól tömöríthető akkor sokszoros sebességet érhetsz el “logikailag”, mint egyébként “fizikailag”, tehát a fizikai vonalon.

Bizonyításként hadd mutassam a feladatkezelőmet:

Itt éppen egy lemezképfájlt másoltam. A képen az látható, hogy a Total Commander 176 Mb/s-al tölti felfelé az adatot, a VMware NAT Service pedig a virtuális gépet jelképezi és látszik, hogy 47,5 Mb/s a “fizikai” adatfolyam. Tudni kell azt is, hogy a mérés idején a laptopom céges wifi routerre volt csatlakozva vezetéknélküli hálózaton és nem egy irodában lévő másik gépre, hanem az otthoni szerveremre tolta át az adatot – ennek köszönhető, hogy csak ~50 Mbit környékén történt az adatátvitel. A másolás idején 50-70% között volt a 1.5 GHz-es HP microserverem cpu terheltsége (mivel kétmagos így 200%-ból), és 0,93-as volt a 15 perces átlag load.

Akik kicsi internetsebességgel rendelkeznek (100 Mbit alatt) és távoli szerverre dolgoznak bőven megfelel és tűrhetően is működik az ExpanDrive. Ha viszont helyi 100 megás hálón (vagy azzal egyenértékű neten) szeretnénk Windows-on sshfs kapcsolódást érdemesebb efféle perverzióhoz folyamodnunk.

Egér mizéria – már megint

Vettem néhány hete egy 1800 Ft-os egeret. Semmi extra, működött. Aztán olyan jelenségre lettem figyelmes, hogy a bal gomb vacakol – van, hogy kettőt kattint egy nyomásra, van, hogy a drag&drop-nál elengedte a “fogást”. Visszavittem a boltba, hogy kontaktos a bal gomb, csináljanak vele valamit.
Feljegyezték az adatokat, aztán másnap hívnak, hogy ezt nem lehet garanciázni, mert a vezeték meg van törve. Mondom:
“- De az egér működik, nem?
– Igen, működik.
– Akkor mit számít, hogy meg van törve a vezeték? Egyébként is ilyen volt már a dobozból kivéve (tudom, én voltam a hülye, hogy nem néztem meg az állapotát még a boltban).
– Hát de ezt akkor sem szervizelhetjük…”

Úgyhogy fogtam, hazahoztam szó nélkül, szétszedtem, a bal gombot kihajítottam belőle és egy kiselejtezett egérből kiszedtem egy pont ugyanolyan gombot és voilá – jó az egér.

Egér vezetékcsere

Volt egy régi egerem, amit még a 4 éves Asus laptophoz kaptam. A vezetéke még mindig jó, de a gombjai már tönkrementek, így egy ideje (cirka fél éve) nem használtam.

Van viszont egy új Genius egerem, ami az ideális munkaeszközömmé vált. Picike, pontos optika és nem ócsó. A probléma az, hogy kb 2 hete elkezdett ki-ki kapcsolgatni – hamar rá sikerült jönnöm – megtört a vezeték. Ez mondjuk várható volt…a vezeték vastagsága és ez a csévélős-tekerős dob feszítős mechanikája miatt nem hosszú életű az ilyen. Na és igen – feltehetitek a kérdést, hogy vajon miért nem vittem vissza a boltba? Hát azért nem, mert költözés volt a nyáron és többek között ennek a doboza (vele együtt a számla is) köddé vált, tehát bukta van.

Először venni akartam boltban új kábelt, meg usb csatit, de aztán megtaláltam ezt a régi egeret és mondom próba szerencse, megkísérlem összeházasítani őket.

Tehát szétkaptam mindkét kütyüt és a fent látható kép fogadott mindjárt.

Első pillanatban azt hittem, hogy a két egér belső csatlakozója egy séma szerint van elkészítve. Minden ugyanaz, párosítható szín színnel, satöbbi. A panelről való lehúzás után jött az első sokk – a csatlakozók még szélességre sem stimmelnek. Ugyanakkora lyuk, a villák között ugyanakkora távolság – csak a régi egér egy villával többel csatlakozott.

Aztán rá sikerült jönni, hogy tulajdonképpen “dupla föld” van a régi egérnél, tehát az usb csatoló mínusz ága mellett ki volt vezetékelve maga az usb csatlakozó fémháza is.

Természetesen e megállapításokra egy multiméter segítségével jutottam. Muszáj volt kimérnem, hogy mi merre hány méter.

Aztán.

Elkövettem egy kis hibát. A négy csatiból csak kettőt mértem be, amolyan szúrópróbaszerű vizsgálatszerűen, hogy a két csati bekötése amúgy megegyező-e. A teszt pozitív eredménnyel zárult.

Így tehát fogtam, lehúztam a villákat védő csati-bölcsőt, hogy ne csak 4-es érintkezőt fogadjon az új egér panele.

Majd a csatlakozót ráhúztam a panelre.

Az egér nemigazán működött. Gépbe dugás után féktelenül elkezdett villogni és amúgy nem reagált semmire. Hoppá mondom, mégse jó itt valami.

Úgyhogy hát fogtam a multimétert újra és végigmértem a csatikat. Egyesével. Kiderült, hogy baromira nem egyeznek a bekötések.

A csatikat kihuzigáltam a tokjából, majd a helyes sorrendben visszadugdostam őket.

Visszacsatlakoztattam a panelre a bölcsővel együtt.

Záróakkord: működik. Mint újkorában. 🙂