Loppuraportti: LFS-käyttöjärjestelmän rakentaminen Raspberry Pille

Ryhmän jäsenet

Ilkka Jylhä ja Tom Himanen.

Tavoitteet

Tavoitteena oli rakentaa Raspberry Pille Linux tyhjästä ja testata järjestelmän toimivuus Quake3:lla.

Onnistuminen

Olimme aluksi varovaisen optimistisia asennusprojektin suhteen, joka kuitenkin osoittautui tiettyjen osa-alueiden osalta työläämmäksi ja hitaammaksi kuin kuvittelimme. Samaan hengenvetoon on kuitenkin todettava, että jotkut asiat olivat merkittävästi helpompia kuin kuvittelimme.

Järjestelmän kopioiminen ja pienentäminen dd-työkalulla osoittautui äärimmäisen paljon tuskallisemmaksi operaatioksi kuin osasimme kuvitella. Sen sijaan esimerkiksi käynnistysskriptien asennus oli niin helppoa, että siitä tuli suorastaan huono omatunto.

Lopputulos oli onnistunut. Testasimme järjestelmän toimivuuden ja suorituskyvyn asentamalla Quake3:n. Peli toimi sulavasti ottaen huomioon käytetyn laitteiston.

Loppusanat

LFS:n asentaminen oli oppimiskokemuksena erittäin hyvä ja valaiseva, mutta ainakaan omiin tarpeisiimme LFS:stä ei ole. Siirrymme itse kukin luultavasti käyttämään Raspbiania Raspberry Pi:llä, mutta LFS:n asennus ei ollut ajanhukkaa – päin vastoin.

Palaute

Kurssi oli erittäin nautinnollinen. Itsenäinen työskentely itselleen kiinnostavan projektin parissa sai ajantajun katoamaan, ja kurssin myötä ymmärrämme GNU/Linux -järjestelmiä entistä syvemmin. Aikaa oli vähän, joten keskityimme ensisijaisesti järjestelmän kasaamiseen.

Omalta osaltamme raportointi voi olla hiukan huolittelematonta, mutta pidämme tasoa resursseihin nähden riittävänä, sillä projektissamme olisi laajuudesta johtuen ollut ääretön määrä raportoitavaa. Raportointivelvollisuutta sinänsä emme missään määrin kritisoi, sillä on täysin perusteltua edellyttää todistusaineistoa itsenäisestä työskentelystä. Emme siis muuttaisi kurssissa mitään.

Emojärjestelmän poistaminen oman järjestelmän rinnalta + jakeluversion luominen

Kun Raspberry Pille oli saatu asennettua uusi järjestelmä, se käynnistyi moitteettomasti.

Seuraava vaihe oli poistaa emojärjestelmä, josta käsin uusi järjestelmä oli asennettu. /etc/fstabista poistettiin emojärjestelmän juuriosio (/dev/mmcblk0p2) ja emojärjestelmän swappiosio (/dev/mmcblk0p4).

Lisäksi pienensimme osion /dev/mmcblk0p3, mitä ei ilmeisesti ole (dokumentoidusti) tehty aiemmin LFS:n asennuksessa Raspille. Poistimme alkuperäisen osion, loimme uuden pienemmän ja kirjoitimme muutokset osiotauluun.

Tämän jälkeen järjestelmä ei kuitenkaan bootannut, ja järjestelmä itki seuraavaa:

* Mounting root file system in read-only mode… mount: / is busy [FAIL]
*****
Cannot check root filesystem because it could not be mounted in read-only mode.
After you press Enter, t system will be halted and powered off.
******
Press Enter to continue…[60.063950] mmc0: card 1234 removed
mmcblk0: error -110 sending status command, retrying
mmcblk0: error -110 sending status command, retrying
mmcblk0: error -110 sending status command, retrying
end_request: I/0 error, dev mmcblk0, sector 26501112
EXT4-fs error (device mmcblk0p3): ext4_find_entry:935: inode #765537: comm udevd: reading directory lkblock 0
EXT4-fs error (device mmcblk0p3): ext4_find_entry:935: inode #765537: comm udevd: reading directory lkblock 0

PiLFS:n rakentanut, IRC-tunnusta “mogwai” käyttävä henkilö arveli, että ongelmana voisi olla osioiden relatiivinen nimeäminen, jolloin juuriosio muuttuisi /dev/mmcblk0p3 -> /dev/mmcblk0p2 sen jälkeen, kun olemme poistaneet emojärjestelmän juuriosion (/dev/mmcblk0p). Tämä koituu kohtaloksi, kun /etc/fstabissa ja bootloaderissa järjestelmän juuriosioksi on määritelty /dev/mmcblk0p3.

Lähdimme testaamaan hypoteesia poistamalla osioita yksi kerrallaan; näin voimme abduktiivisesti todeta ongelman aiheuttajan. Aloitimme poistamalla uuden järjestelmän swapin (/dev/mmcblk0p4). Käynnistimme uudelleen, ja järjestelmä käynnistyi ihan hyvin, mutta valitti, ettei saa mountattua osiota /dev/mmcblk0p4. Näin ollen päätimme päivittää /etc/fstabin ajan tasalle kommentoimalla swappiosion rivi pois.

#/dev/mmcblk0p4 swap swap pri=1 0 0

Lisäsimme samalla /boot-osion /etc/fstabiin.

/dev/mmcblk0p1 /boot vfat defaults 0 0

Tämän jälkeen käynnistimme järjestelmän uudelleen. Käynnistyminen ei tuottanut yhtään virheilmoitusta. Seuraavaksi päätimme poistaa osion 2, arpoa oikeat asetukset bootloaderiin ja kokeilla, käynnistyykö järjestelmä. Viimeksi bootloaderissa ja fstabissa juurijärjestelmäksi oli määritelty osio kolme, joten vaihdoimme molemmissa tiedostoissa juuriosioksi osion 2.

Tämä oli huono lottorivi, sillä bootin tuloksena oli seuraavanlainen virheilmoitus.

PANIC: VFS: Unable to mount root fs on unknown-block(179,2)
Entering kbd (current=0xce82ac80, pid 1) due to Keyboard Entry

Määritimme cmdline.txt:ssä juuriosioksi osion 3:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p3 rootfstype=ext3 elevator=deadline rootwait

Myös /etc/fstab-tiedostossa muutimme juuriosioksi osion 3. Käytännössä palasimme yrittämään samaa ratkaisua, joka oli jo kerran pissinyt.

# Begin /etc/fstab

# file system  mount-point  type     options             dump  fsck
#                                                              order

/dev/mmcblk0p3 /            ext3     defaults            1     1
/dev/mmcblk0p1 /boot    vfat     defaults 0     0
#/dev/mmcblk0p4 swap         swap     pri=1               0     0
proc           /proc        proc     nosuid,noexec,nodev 0     0
sysfs          /sys         sysfs    nosuid,noexec,nodev 0     0
devpts         /dev/pts     devpts   gid=5,mode=620      0     0
tmpfs          /run         tmpfs    defaults            0     0
devtmpfs       /dev         devtmpfs mode=0755,nosuid    0     0

# End /etc/fstab

Jostain ihmeen syystä järjestelmä käynnistyi ongelmitta ja epäselväksi jäi, mikä meni ensimmäisellä kerralla vikaan yrittäessämme käynnistää järjestelmää käyttäen juuriosiona /dev/mmcblk0p3-osiota. Joka tapauksessa tästä voitiin päätellä, että käynnistyslatain ja fstab eivät kumpikaan numeroi osioita dynaamisesti. Ongelma kuitenkin liittyi todennäköisesti osion pienentämiseen.

Alun perin mukailimme ohjetta osion suurentamisesta, joka toimi niin että poistetaan osio, luodaan osio uudestaan koko levyn kokoisena, kirjoitetaan muutokset luodulle osiolle, bootataan ja bootin jälkeen komennetaan resize2fs.

Pienennettäessä osiota poistimme alkup. osion, loimme siihen kohdalle uuden pienemmän, kirjoitimme muutokset osiotauluun ja boottasimme

Osion pienentäminen kuitenkin hajotti juuriosion jonka johdosta emme kykeneet enää käynnistämään järjestelmää.

Osion pienentäminen tulee tehdä käänteisessä järjestyksessä, ensiksi resize2fs.
esim resize2fs -M
“”resize2fs -M     Shrink the filesystem to the minimum size.”

sen jälkeen muokataan osiota vastaamaan uutta kokoa. Ongelmana tässä on se että ainoastaan unmountatun osion kokoa voidaan pienentää. Niinpä osion pienentäminen on tehtävä järjestelmästä käsin, joka ladataan toiselta osiolta.

Tämän jälkeen teimme swappitiedoston, mutta minimoidaksemme muuttujia emme aktivoineet sitä ainakaan vielä.

dd if=/dev/zero of=/dev/swapfile bs=1M count=512

Päätimme kokeilla tässä vaiheessa osion pienentämistä uudelleen. Koska olimme jo poistaneet emojärjestelmän, jouduimme suorittamaan pienennysoperaation miniläppäriä käyttäen, johon liitimme Raspin ensisijaisena mediana käytetyn muistikortin.

Ensiksi poistimme muistikortilla olevan “tyhjän” tilan osioiden mmcblk0p1 ja mmcblk0p3 välistä, joka syntyi, kun emojärjestelmän sisältänyt mmcblk0p2 poistettiin. Tyhjä tila poistettiin siirtämällä mmcblk0p3 osio heti /boot osion jälkeen.
Operaation jälkeen tarkistimme, että tiedostojärjestelmä on kunnossa, ennen kuin aloimme käpälöidä tiedostojärjestelmää.

sudo fsck -n /dev/mmcblk0p3

Tämän jälkeen muunsimme tiedostojärjestelmän ext3-muodosta ext2-muotoon.

sudo tune2fs -O ^has_journal /dev/mmcblk0p3

Tarkistimme, että tämänkin jälkeen kaikki on tiedostojärjestelmässä OK.

sudo e2fsck -f /dev/mmcblk0p3

Ajoimme resize2fs-komennon pienentääksemme osion koon 3500 mibitavuun.

sudo resize2fs /dev/mmcblk0p3 3500M
resize2fs 1.42 (29-Nov-2011)
Resizing the filesystem on /dev/mmcblk0p3 to 896000 (4k) blocks.
The filesystem on /dev/mmcblk0p3 is now 896000 blocks long.

sudo fdisk /dev/mmcblk0
d
3
n
p
3
98304
+3700M
w
sudo fsck -n /dev/mmcblk0p3
sudo tune2fs -j /dev/mmcblk0p3
sudo sync

Kaikkien järkytykseksi totesimme homman toimivan.

OpenSSH:n asennus LFS:ään

Otimme ohjenuoraksemme CBLFS:n ohjeet OpenSSH:n asennukseen (http://cblfs.cross-lfs.org/index.php/OpenSSH). OpenSSH on riippuvainen paketista OpenSSL, joten aloitimme asentamalla sen.

Latasimme OpenSSL:n lähdekoodit (http://www.openssl.org/source/openssl-1.0.1c.tar.gz), purimme ne, käänsimme ja asensimme.

./config –openssldir=/etc/ssl –prefix=/usr shared && make MANDIR=/usr/share/man && make MANDIR=/usr/share/man install && ln -sv ../../etc/ssl /usr/share &&
cp -v -r certs /etc/ssl

OpenSSL asentui ongelmitta ja aloitimme OpenSSH:n asennuksen.

./configure –prefix=/usr –sysconfdir=/etc/ssh –libexecdir=/usr/sbin –with-md5-passwords –with-privsep-path=/var/lib/sshd –with-default-path=”/bin:/usr/bin”  –with-superuser-path=”/sbin:/bin:/usr/sbin:/usr/bin” && make

OpenSSH kääntyi ongelmitta, mutta asennuksen jälkeen SSH-demoni (= palvelu) piti saada käynnistymään järjestelmän käynnistyksen yhteydessä. Tähän tarvittiin Beyond Linux From Scratchin käynnistysskriptejä (http://www.linuxfromscratch.org/blfs/downloads/6.3/blfs-bootscripts-20080816.tar.bz2), joiden asennus- ja käyttöohjeet löytyvät täältä: http://www.linuxfromscratch.org/blfs/view/6.3/introduction/bootscripts.html. SSH-demonin käynnistysskriptien lisääminen kaikille ajotasoille oli ubuntumaisen helppo tehtävä ja se tapahtui seuraavasti.

tar blfs-bootscripts-20080816.tar.bz2
cd blfs-bootscripts-20080816
make install-sshd

Tämän jälkeen käynnistimme Raspberry Pin uudelleen ja sshd nousi ylös ongelmitta. Testasimme myös SSH-yhteyden ottamista Raspberry Pihin ja saimme yhteyden muodostettua.

Wgetin asennus

Wgetin asennus oli melko suoraviivainen toimenpide.

./configure –prefix=/usr –sysconfdir=/etc && make && make install

Kaikki ei kuitenkaan mennyt oletetusti, ja ./configure skripti itki seuraavaa:

configure: error: — with-ssl was given, but GNUTLS is not available

Configure-skripti siis olettaa löytävänsä järjestelmästä GNUTLS:n, mutta sitä ei ole. Sen sijaan OpenSSH:n vuoksi järjestelmässä on joka tapauksessa OpenSSL, joten neuvoimme wgetin configure-skriptiä hyödyntämään OpenSSL:ää salattujen yhteyksien käsittelyyn. Komento näyttä tämän jälkeen seuraavanlaiselta.

./configure –prefix=/usr –sysconfdir=/etc –with-ssl=openssl && make && make install

Fonttiongelman ratkaisu

Bashin promptin määrittävää $PS1-muuttujaa muotoillessamme huomasimme, että erikoismerkit eivät tulostu oikein. Aloimme testata ongelmaa ja jätimme Bashin promptin viilaamisen tuonnemmaksi.

Huomasimme, että ongelma muistutti sitä, kun ottaa SSH-yhteyden ISO-8859-koodausta käyttävältä koneelta UTF-8 -koodausta käyttävään koneeseen tai toisin päin. Näin ollen osasimme arvella ongelman johtuvan koodauksesta. Emme kuitenkaan sulkeneet näppäimistökarttaongelmiakaan pois.

Kokeilimme asettaa tiedostossa /etc/sysconfig/console asettaa $KEYMAP-muuttujaan arvot fi-latin9 ja fi-latin1. Kokeilimme myös asettaa muuttujalle $FONT arvoiksi lat1-16 ja lat0-16. Tämäkään ei tuntunut vaikuttavan asiaan. Jokaisen muutoksen jälkeen sourcetimme (source /etc/sysconfig/console) konffit ja käynnistimme koneen uudelleen.

Kun ratkaisua ei tuntunut löytyvän, kysyimme mogwailta neuvoa IRC:ssä. Koska hän on ruotsalainen, hän oli törmännyt samoihin ongelmiin kuin mekin, joten hänellä oli antaa meille valmis ja toimiva konffi, joka näyttää seuraavanlaiselta:

/etc/sysconfig/console:

UNICODE=”1″
KEYMAP=”fi-latin1″
KEYMAP_CORRECTIONS=”euro2″
LEGACY_CHARSET=”iso-8859-1″
FONT=”LatArCyrHeb-16 -m 8859-1″

Bashin promptin viilaus

Saatuamme erikoismerkit ja ääkköset pelaamaan terminaaliemulaattorissamme otimme Bashin promptin uudelleen työn alle. Prompti on terminaaliemulaattorissa se merkkijono, jonka perään komennot kirjoitetaan, ja joka sisältää usein tiedon sisään kirjautuneesta käyttäjästä, senhetkisestä sijainnista järjestelmän hakemistopuussa sekä sen järjestelmän nimen, johon on kirjauduttu.

Halusimme promptin, joka (1) erottuu muusta tulosteesta sekä (2) kertoo kirjautuneen käyttäjän, kirjautumisen kohteen sekä nykyisen sijainnin. Päätimme erottaa promptin muusta tulosteesta värin avulla. Näin ollen rootin ~/.bashrc näytti loppujen lopuksi seuraavanlaiselta:

#!/bin/bash
export PS1=”[\e[0;31m\u\e[m@\e[0;32m\h\e[m:\w]\e[0;31m\$\e[m ”

Tämän jälkeen meidän kuitenkin tarvitsi tehdä ~/.bash_profile, joka kutsuu ~/.bashrc:tä.

if [ -f ~/.bashrc ]; then source ~/.bashrc ; fi

[root@pilfs:~]#

LFS-käyttäjän luominen

Loimme perus käyttöä varten Raspberry Pille uuden käyttäjän.

useradd -m -s /bin/bash lfs
Kopioimme lfs-käyttäjälle ~/.bashrc:n ja ~/.bash_profilen root-käyttäjältä roottina.

cp ~/.bashrc ~lfs/.bashrc && cp ~/.bash_profile ~lfs/.bash_profile && chown lfs:lfs ~lfs/.bash*

Varmuuskopion ottaminen

Koska järjestelmämme oli runnottu Raspberry Pin alussa olevaan tilaan siten, että se mahtuu alle neljään gigaan, halusimme siitä vain neljään gigaan mahtuvan varmuuskopion. Dd:llä varmuuskopioitaessa dd kopioi ihan onnessaan levyä bitti bitiltä riippumatta mm. siitä, onko levyn viimeinen osio loppunut jo ajat sitten.

Tästä syystä meidän tarvitsi antaa dd:lle lupa lopettaa kopiointi ensimmäisen neljän gigan jälkeen. Näin voitiin tehdä count-attribuutilla, joka määrittää, miten monta blokkia kopioituaan dd saa lopettaa projektinsa. Varmuuskopiota ottaessamme määritimme blokin yhden megatavun kokoiseksi, jottemme sekoaisi laskuissamme.

dd if=/dev/mmcblk0 of=hiawatha_0.1.img bs=1M count=3700

Kun varmuuskopio siirrettiin neljän gigan muistikortille, se toimi yllätykseksemme mainiosti ja järjestelmä buuttasi. Törmäsimme ongelmiin vasta, kun meidän tarvitsi seuraavaksi mountata kortti lähimpään tietokoneeseen.

Tämä ei kuitenkaan onnistunut, koska muistikortin kolmannen osion tiedostojärjestelmä koki olevansa rikki. Ongelma kuitenkin korjautui helposti fsck:lla.

sudo fsck /dev/mmcblk0p3

Dhcpcd:n asennus

Dhcpcd:n asennus oli helppo toimenpide. Se onnistui ongelmitta noudattaen BLFS:n ohjeita (http://www.linuxfromscratch.org/blfs/view/svn/basicnet/dhcpcd.html). Järjestelmä buuttasi seuraavanlaisella konffilla:

[root@pilfs:~]$ cat /etc/sysconfig/ifconfig.eth0
##########################
# Config with dhcpcd
##########################

ONBOOT=”yes”
IFACE=”eth0″
SERVICE=”dhcpcd”
DHCP_START=””
DHCP_STOP=”-k”

###########################
# Old config with static IP
###########################

#ONBOOT=yes
#IFACE=eth0
#SERVICE=ipv4-static
#IP=10.42.0.2
#GATEWAY=10.42.0.1
#PREFIX=24
#BROADCAST=10.42.0.255

DHCP:n toimivuus testattiin ottamalla SSH-yhteys Raspberry Pihin ja tulostamalla yllä oleva konffi terminaaliin ja kopipeistaamalla se raporttiin.

Irssin asennus

Irssi on riippuvainen paketista Glib, joka puolestaanon riippuvainen paketista pkg-config. Niinpä aloitin irssin asennuksen kääntämällä paketin pkg-config.

wget http://pkgconfig.freedesktop.org/releases/pkg-config-0.27.1.tar.gz &&
tar xzvf pkg-config-0.27.1.tar.gz && cd pkg-config-0.27.1 &&
./configure –prefix=/usr \
–docdir=/usr/share/doc/pkg-config-0.27.1 \
–with-internal-glib &&
make && make install

Tämän jälkeen asensin Glibin, josta valitsin version 2.

wget http://ftp.gnome.org/pub/GNOME/sources/glib/2.27/glib-2.27.4.tar.bz2 && tar xjvf glib-2.27.4.tar.bz2 && cd glib-2.27.4 && ./configure –prefix=/usr && make && make install

Loppujen lopuksi pääsin asentamaan itse irssin.

wget http://www.irssi.org/files/irssi-0.8.10a.tar.bz2 && wget http://svn.cross-lfs.org/svn/repos/patches/irssi/irssi-0.8.10a-gslice-1.patch && tar xjvf irssi-0.8.10a.tar.bz2 && cd irssi-0.8.10a && patch -Np1 -i ../irssi-0.8.10a-gslice-1.patch &&
./configure –prefix=/usr –sysconfdir=/etc && make && make install

Irssiä kuuluu käyttää screenissä, joten sekin piti vielä kääntää.

wget http://ftp.gnu.org/gnu/screen/screen-4.0.3.tar.gz && tar xzvf screen-4.0.3.tar.gz && cd screen-4.0.3 && ./configure –prefix=/usr –with-socket-dir=/var/run/screen \
–with-sys-screenrc=/etc/screenrc && sed -i ”s%/usr/local/etc/screenrc%/etc/screenrc%” {etc,doc}/* && make && make install

Nanon kääntäminen

./configure –prefix=/usr –enable-all

Screen (http://www.linuxfromscratch.org/blfs/view/svn/general/screen.html) ja links (http://www.linuxfromscratch.org/blfs/view/svn/basicnet/links.html) asennetiin BLFS-ohjeiden mukaan.

Quake3:n asennus

Quake3 asennettiin pilfs-ohjeiden (http://www.intestinate.com/pilfs/#quake3) mukaisesti ongelmitta. Ainoastaan Alsan kuolleet linkit aiheuttivat päänsärkyä. Asia korjautui asentamalla uudet, SVN-käynnistysskriptit SVN-BLFS -ohjeiden mukaisesti.

Asennuksen aloittaminen

Onnistuimme rakentamaan oman Linux-kernelin päälle rakennetun käyttöjärjestelmämme Raspberry Pin päälle, ja tässä postauksessa kerromme, mitä kannattaa tehdä ja mitä ei.

Linux-ytimen päälle Linux from Scratch -kirjan ohjeita mukaillen itse rakennettua käyttöjärjestelmää kutsutaan yleensä ”Linux from Scratchiksi” (suom. ”Linux tyhjästä”), ja näin mekin teemme. Lopputuotteemme erisnimi on kuitenkin Hiawatha. ”Linux from Scratch” -käsitteeseen viittaamme usein vakiintuneen käytännön mukaisesti lyhenteellä LFS.

Käytimme ohjenuoranamme PiLFS-ohjekirjaa, joka käytännössä neuvoo noudattamaan LFS-ohjekirjaa kertoen muun muassa, missä kohtaa alkuperäisestä ohjeistuksesta kannattaa poiketa, tai mitä erityistä kannattaa huomioida.

Aluksi on syytä todeta, että Raspberry Pi (myöh. RasPi) eroaa normaalista tietokoneesta esimerkiksi BIOS:in osalta, jota RasPissa ei ole. RasPissa on asetustiedostoja, joita muokkaamalla muutetaan asetuksia, joita normaalisti muutettaisiin BIOS:in asetuksissa.

Jokaisen RasPille Linux from Scratchia asentavan on syytä huomioida se tosiasia, että 25 dollarin arvoisessa luottokortin kokoisessa yhden piirilevyn tietokoneessa on todennäköisesti hitaampi prosessori kuin kännykässäsi. Asentaminen on vieläpä aikamoista prosessorin huudatusta, sillä ohjelmat asennetaan kääntämällä ne lähdekoodeista, mikä tehdään pääasiallisesti prosessorilla.

Tästä syystä yritimme aluksi emuloida RasPia qemulla PiLFS-ohjekirjan mukaisesti. Aikeenamme oli rakentaa ja kääntää ohjelmistot emulaattorilla, tehdä aikaansaannoksestamme image ja siirtää se RasPille. Emulaattori ei kuitenkaan muutaman tunnin taistelun seurauksena alkanut toimia, joten lopetimme ajan haaskauksen ja aloimme rakentaa järjestelmää suoraan RasPilla.

Seurasimme PiLFS-sivuston (IRC-tunnuksen mogwai ylläpitämä) ja LFS-kirjan ohjeita. Koska em. kirjojen kirjoittaminen uudestaan ei ole mielekästä, eikä siihen ole resursseja, keskitymme lähinnä kirjoja seuratessamme kohtaamiimme ongelmiin ja yllätyksiin.

LFS:n RasPille asentavan on syytä tietää, että ohjelmien kääntämiseen käytettävät, mogwain tekemät skriptit rouskuttavat 60–70 tuntia putkeen.

Nyt se toimii

Raspberry Pi:lle rakennettu LFS-järjestelmä saatiin käynnistymään omin voimin. Lähipäivinä aiomme kertoa muistiinpanojemme pohjalta, millaisia haasteita kohtasimme. Stay tuned!