Fedora live készítése

A live rendszer készítésekor rögtön felmerül egy probléma: hogyan teszünk bináris állományokat a chroot-olt környezetbe? A gond abból fakad, hogy noha írhatunk a konfigurációs állományba bármilyen scriptet, az nem fog a chroot-olt környezeten kívülre látni, így a bináris állományt nem tudjuk bemásolni oda. Egy lehetséges, korrekt megoldás, hogy a saját dolgainkból rpm csomagot készítünk - az ötletet itt a HUP-on vetették fel -, majd lokális repóból ezt telepítjük. A másik megoldás az, amit én alkalmazok, hogy ha lehet scriptet írni, akkor abban elhelyezhetők string konstansok is. Amire figyelni kell, hogy az adat text legyen. Ennek a kívánalomnak a base64 kódolás éppen meg is felel. Az, hogy a konfigurációs file-ban több tíz vagy több száz megabyte adatot helyezünk el, legfeljebb nem szép, ugyanakkor jó megoldás.

Így hát írtam egy shell scriptet, amelyik egy template file-ból - valójában ez lesz az általunk szerkesztett konfigurációs állomány - generál egy olyan kickstart file-t, amelyben már a bináris tartalom is megtalálható base64-ben.

Azon a virtualizált rendszeren, amelyen a live-ot készítettem, létrehoztam egy ~/kickstart directory-t, ebbe tettem a fentebb említett scriptemet, majd szintén itt létrehoztam egy rootfs és egy repo nevű alkönyvtárat. A repo nevű alkönyvtárba másoltam azokat az rpm csomagokat, amelyekből vagy újabbat szeretnék a hivatalos update repóban kiadottnál - ilyen például a kernel-PAE, a selinux-policy, a firefox, xulrunner -, vagy eleve nem része a disztribúciónak, mint például a skype. Ebből a csomaggyűjteményből a scriptem készít egy másolatot egy rep nevű könyvtárba, s itt local repository készül, amelyet a live előállításakor használunk majd.

A rootfs nevű alkönyvtár alá létrehoztam a kívánatos alkönyvtárakat és file-okat, amelyet a live disztribúcióba szeretnék tenni. Ilyenek az etc, home, usr, var könyvtárak. Értelemszerűen ide csak azokat az alkönyvtárakat és file-okat hozzuk létre, amelyekkel a már telepített live disztribúciónk file-jait felülírnánk, illetve kiegészítenénk. A scriptem az itt található alkönyvtárakat bejárja, s a talált file-okat az általa létrehozott kickstart konfigurációs file-ba teszi base64 formátumban úgy, hogy a kickstart file felhasználása alkalmával ebből a tartalomból előálljon a kívánt file, alkönyvtár, természetesen a kívánt jogokkal. A jogosultságot a template file-ban kell megadni.

A scriptemet úgy írtam meg, hogy a felhasznált template lényegében egy olyan kickstart file, amelyben vannak speciális kommentek, amelyeket értelmez a script, a többi sort érintetlenül az általa előállított kickstart file-ba másolja. A template-ben kétféle speciális kommentnek van jelentősége. Az egyikben a # után kettőspont következik. Az így megadott sorok eval-lal ki lesznek fejtve, így a scriptben használt változók helyettesítésre kerülnek.

Példa:

#:%include $BASEDIR/fedora-live-base.ks

Ez a generált kickstart file-ba így kerül majd be:

%include /home/live/kickstart/fedora-live-base.ks

mivel a BASEDIR=/home/live/kickstart.

A másik eset az, amiért az egész felhajtást csináltuk, ez egy rekurzív másolás az eredményét tekintve, csak ugye a chroot-olt környezeten kívülről a chroot-olt környezeten belülre. Ez valahogy így néz ki:

#>$BASEDIR/rootfs/usr /usr *->root,:*->:root

Ez azt jelenti, hogy abban a környezetben, amelyben épp dolgozunk, a rootfs/usr könyvtár tartalma kerüljön a majdan elkészített live disztribúciónk /usr alkönyvtárába. A munkakörnyezetünk bármilyen tulajdonosú állománya a cél környezetben root tulajdonosú legyen, s a munkakörnyezetben bármilyen csoporthoz tartozó file a cél környezetben root csoportú legyen. Tehát a cél helyen minden, amit a rootfs/usr-ből adunk át, root:root legyen.

A script kezeli a szimbolikus linkeket, viszont fontos, hogy ezek relatív hivatkozások legyenek, hiszen ami a chroot-olt környezeten kívül jó helyre mutat abszolút hivatkozással, az butaság lesz a chroot-olt környezeten belül.

Álljon itt egy példa a template file-ra. Aztán az elején include-olt file. A ~/kickstart/rootfs alatt az etc/rc.d/rc.local és etc/rc.d/rc.local1 file-ok.

A végén az elkészül image-et a pendrive-ra másoljuk. A pendrive-ról természetesen minden adat elvész! Ellenőrizzük, melyik device a bedugott pendrive-unk:

fdisk -lu

Tegyük fel, az sdb az. A pendrive egyetlen filerendszere se legyen felcsatolva. Ekkor az image másolása root joggal:

dd if=*.iso of=/dev/sdb bs=1M; sync

Szektorosan írtuk az eszközt, így nincs lecsatolandó filerendszer. Ha elkészült, kihúzhatjuk a pendrive-ot.

A teszteléshez célszerű az imagefile-t virtuális gépben kipróbálni, úgyis lesz egy rakás javítanivaló benne. :)

Mivel adtam példa file-okat is, ha valaki valóban arra szánja el magát, hogy csináljon egy live Fedorát saját profillal, programokkal, akár böngésző és skype profillal, legfrissebb kernellel, annak szívesen segítek itt.

A local repo előállítása gyorsabb, ha a scriptben a createrepo helyett a createrepo_c nevű, C-ben implementált programot használjuk.

2013.07.26. update:

Időközben arra jutottam, hogy ha már a /home úgyis RAM-ban kell legyen, csinálok neki egy RAM-disket, és ez legyen rögtön tömörített. A fusecompress bugos, viszont a btrfs tud tömörítést. Vázlatosan ezt jegyzeteltem magamnak:

1. RAM disk


mount -t ramfs none /usr/local/.ram

2. Image file

HOMESIZE=`free | awk '/^Mem:/ {print int(0.2*$2); exit 0}'`
HOMEIMAGE="/usr/local/.ram/btrfs.img"
if [ $HOMESIZE -lt 90000 ]; then
    exit 0
fi
dd if=/dev/zero of="$HOMEIMAGE" bs=1k count=$HOMESIZE
chmod 0600 "$HOMEIMAGE"

3. BTRFS-re formázás

mkfs.btrfs -L home "$HOMEIMAGE"

4. /home alá csatolás tömörítés opcióval

mount -o compress=lzo "$HOMEIMAGE" /home

5. File-ok másolása, jogok

cp -a /usr/local/.home/* /home
chmod 0700 /home/{locsemege,guest}
chown -R locsemege:users /home/locsemege
chown -R guest:users /home/guest
restorecon -RF /home

Magyarázatként annyit, hogy a fizikai RAM 20%-át allokálom a /home-hoz, amelyen létrehozok egy btrfs filerendszert az illető image-ben, majd ezt tömörítés opcióval csatolom a /home alkönyvtárhoz. Ha annyira kevés a fizikai RAM, hogy annak 20%-a nem éri el a 90 MB-ot, úgy kilépek, már a user-eket sem hozom létre. Ekkor root joggal azért használható még a live oprendszer.

2013.10.08. update:

Kellett Start menü nekem az fbpanelre. Viszont Openboxon paranccsal közvetlenül nem lehet triggerelni a root-menü megjelenését, így azt a megoldást választottam, hogy egy billentyűkombinációt konfiguráltam a root-menü megjelenésére, majd futtatok egy nyúlfarknyi scriptet a Start menüre kattintáskor, amelyik az illető billentyűkombinációt beálmodja az X szervernek:

#!/bin/bash


exec xte 'keydown Super_L' 'keydown Control_L' 'keydown Alt_L' 'keydown w'\
         'usleep 50000' 'keyup w' 'keyup Alt_L' 'keyup Control_L' 'keyup Super_L'

Az xte parancsot az xautomation csomag tartalmazza.

Aztán, mivel az Openbox menüje elég lassú egy lassú pendrive tömörített filerendszeréről, talán az ábrázolandó ikonok miatt, így szerettem volna, ha a gyakran használt alkalmazások könnyen, gyorsan elérhetők. Erre egy másik fbpanelt hoztam létre a képernyő felső élénél, autohide tulajdonsággal. Ha feltolom az egeret, terülj-terülj asztalkám vár a legfontosabb alkalmazásokkal.

Shutdown, Reboot, Logout-ra ezt a scriptet írtam:

#!/bin/bash


if [ $# -eq 1 ]; then
    trap '' SIGHUP
    . /usr/local/share/configs/functions
    case "$1" in
        --shutdown|--poweroff)
            rundctl loginlock
            openbox_exit
            rundctl save
            rundctl poweroff
        ;;
        --reboot|--restart)
            rundctl loginlock
            openbox_exit
            rundctl save
            rundctl reboot
        ;;
    esac
    eval "exec $FD>&-"
    trap SIGHUP
    exit 0
fi
if [ `pgrep -c -u "$USER" -x '^exit\.sh$'` -gt 1 ]; then
    wmctrl -xa yad
    exit 0
fi
trap '' SIGHUP
export LC_ALL='hu_HU.UTF-8'

openbox_exit() {
    openbox --exit
    while pgrep -u "$USER" -x openbox &>/dev/null; do
        sleep 1
    done
}

RETVAL=1
while [ $RETVAL -ne 0 ]; do
    action="`yad --center --on-top --undecorated\
                --button 'OK:0' --button 'Cancel:8'\
                --entry --entry-text\
                $'Logout and load last profile\t\t\t(Kijelentkezés és az utolsó profil betöltése)'\
                $'LogOut\t\t\t\t\t\t\t(Kijelentkezés a személyes adatok megtartásával)'\
                $'Reboot\t\t\t\t\t\t\t(Újraindítás)'\
                $'Shutdown\t\t\t\t\t\t(Leállítás)'\
                $'Logout and restore default profile\t\t(Kijelentkezés és alapértelmezett profil betöltése)'\
                $'Cancel\t\t\t\t\t\t\t(Mégse)'`"
    RETVAL=$?
    if [ $RETVAL -eq 8 ]; then
        trap SIGHUP
        exit 0
    fi
done
. /usr/local/share/configs/functions
action="`cut -f1 <<<\"$action\"`"
case "$action" in
    Shutdown)
        rundctl loginlock
        openbox_exit
        rundctl save
        rundctl poweroff
        ;;
    Reboot)
        rundctl loginlock
        openbox_exit
        rundctl save
        rundctl reboot
        ;;
    LogOut)
        openbox_exit
        ;;
    Logout\ and\ l*)
        rundctl loginlock
        openbox_exit
        rundctl restore
        ;;
    Logout\ and\ r*)
        rundctl loginlock
        openbox_exit
        rundctl default
        ;;
esac
eval "exec $FD>&-"
trap SIGHUP
exit 0

2013.12.03. update:

Nem egyszerű jól megcsinálni egy live rendszert, de nem is lehetetlen. Úgy néz ki az egész, hogy van egy iso9660 image, benne egy squashfs tömörített image, ez tartalmaz egy ext4 image-et, amely egy snapshot. Ez utóbbihoz képest ha változás áll be a filerendszerben, az RAM-ban kerül tárolásra. Ez a terület default 500 MB. Ha a módosítások miatt ez a terület megtelik, akkor sarokba szorul a rendszer, hiszen képtelen lesz file-ok módosítására, sérül a filerendszer, amelynek következménye igen csúnya fagyás lesz. Éppen ezért törekedni kell arra, hogy a snapshothoz képest minél kevesebb módosítást végezzünk a file-okon futásidőben. Ha valamit módosítani kell, azt lehetőleg a live készítésekor még az image generálása előtt tegyük meg.

Mindenképpen javasolt a változó területeket - pl. /var/log, /var/cache, /var/lib - tmpfs-re tenni. A tmpfs előnye, hogy RAM-ba dolgozik, ám használja a swap-et is, ha van, így akkor sem feltétlen kerülünk bajba, ha a RAM már fogytán.

Ajánlott irodalom.

Fedora 20 live készítésekor futottam bele, hogy mindenképpen fel akarta tenni az nVidia driver-t. Ennek függőségi oka van. Elkerülhetjük, ha a csomaglistába felvesszük a mesa-libEGL csomagot, valamint én magam részéről töröltem a @hardware-support csoportot. A csoport itt telepítendő csomagok csokorba szedésére utal. :)

A /home ramfs helyett tmpfs lett, illetve azon létrehozott tömörített btrfs. Ennek oka, hogy a tmpfs képes swap-et használni. Apropó swap...

Írtam egy shell scriptet, amelyik a boot folyamat végén keres írható filerendszert, azt felcsatolja, létrehoz egy könyvtárat benne, abban egy swap image-et, aztán mkswap majd swapon. Ha már létezik a swap file, akkor nem hozza létre, csak használja. Persze megnézi, mekkora szabad hellyel rendelkezik. A létrehozott swap image mérete 512 MB és 1 GB között változik szabad helytől függően. 1 GB-nál többet nem lop a live-om a gépben esetlegesen lévő HDD-ről.

2013.12.04. update:

Elgondolkodtam azon, hogy ha már úgy adódott, egy 4 GB-osnak mondott, egyébként 3.6 GiB-os pendrive-ra teszem a live image-emet, jó volna kihasználni adattárolásra a pendrive egy részét. Problémát jelent viszont az, hogy a partíciós táblához nem nyúlhatok, hiszen a pendrive-ra egy iso9660 boot-olható image-et másolok, amely tartalmaz mindent.

Na jó, de miért is kellene partíciós tábla? Nekem filerendszerre van szükségem, ahhoz meg nem kell partíciós tábla, már feltéve, ha byte pontossággal tudom, hol van a pendrive-on a filerendszer. Úgy döntöttem tehát, hogy az első 2 GiB a live image-nek lesz fenntartva, utána pedig lesz egy 1.5 GiB nagyságú btrfs, amelyet boot alkalmával szépen fel is mount-ol magának.

Először létrehoztam a btrfs filerendszert file-ba:

dd if=/dev/zero of=fs.img bs=1M count=1536
mkfs.btrfs -L Heisenbug fs.img

Ezután felmásoltam a pendrive-ra, pontosan 2 GiB címre:

dd if=fs.img of=/dev/sdb bs=1M seek=2K; sync

Természetesen előtte leellenőriztem, hogy a pendrive-om valóban az sdb.

A live rendszerben az rc.local scriptem felcsatolja a filerendszert. Valami ilyesmi lett:

HNAME="`hostname -s`"
DEVICE="`blkid /dev/sd? | grep 'Fedora.*live' | head -n1 | cut -d: -f1`"
bs=1048576
seek=2048
((OFFSET=seek*bs))
if [ ! -z "$HNAME" -a ! -z "$DEVICE" ]; then
    mkdir -p "/mnt/$HNAME"
    if ! mount -o loop,offset=$OFFSET,compress=lzo,noatime "$DEVICE" "/mnt/$HNAME"; then
        rmdir "/mnt/$HNAME"
    fi
fi

Ezek után, amennyiben új live image-et készítek, azt bátran a pendrive-ra másolhatom, a filerendszerem nem fog sérülni, hiszen az image az alsó 2 GiB-ra kerül - sőt, jelenleg 1 GiB-ra elfér -, míg az írható-olvasható btrfs filerendszer felül, a 2 GiB-os címtől helyezkedik el.

Kívülről, partíciós tábla hiányában kényelmesen nem érhető el ez a filerendszer, ugyanakkor a live rendszer olyan dolgait, amelyről azt szeretném, hogy megmaradjanak kikapcsolás után is, már másolhatom erre a 1.5 GiB-os btrfs-re.

2014.02.08. update:

Úgy tűnik, a btrfs nem optimális kis filerendszernek, így aztán visszatértem ext4-re. A pendrive-on az adattárolásra használt filerendszer báziscímét az eddigi 2 GiB-ról 1.5 GiB-ra tettem, mert a live image bőven elfér 1.5 GiB-ban, hiszen jelenleg 1 GiB hosszúságú. Így nyertem 0.5 GiB hasznos helyet.

Mivel kellemes tud lenni, ha a felhasználói profil megmarad, benne böngészési előzmények, különféle beállítások, ezért azt találtam ki, hogy automatikusan mentse leállításkor, újraindításkor a felhasználói profilokat. Ehhez írtam egy shell script daemon-t, amelyik a felhasználókkal named pipe-okon keresztül kommunikál. A /tmp-ben létrehozok egy-egy alkönyvtárat, amelyek a felhasználókhoz tartoznak. Ezen alkönyvtárak root:root tulajdonúak 0755 joggal. Ezek mindegyikébe létrehozok egy FIFO-t, amelyek user:root 0600 jogúak. Ezzel elérem, hogy csak az érintett user tud a saját fifo-jába írni, míg törölni a user sem tudja azt.

A daemon olvassa a fifo-kat ciklikusan, s a benne lévő parancsokat végrehajtja. Mivel a felhasználóknak saját fifo-juk van, azonosítható, kitől jött a parancs. Maga a daemon egy root joggal futó folyamat. A parancsok a felhasználói profil mentése, betöltése, default betöltése, poweroff, reboot, login lock file létrehozása. Ezzel elérhető, hogy a gép leállításakor először kiléptetjük a felhasználót, utána a profilról egy tömörített tar.gz állomány készül a pendrive-ra. Induláskor ez kerül majd kibontásra, és a /home alá mount-olt tmpfs RAM disk-be betöltésre.

Természetesen meg kell oldani, hogy a felhasználó kiléptetése után a profil mentése alatt nehogy újra belépjen a user. Ezt openbox alatt úgy oldom meg, hogy az openbox environment scriptjébe írtam egy hurkot, amelyik nem engedi a belépést, ha létezik egy lockfile.

A kiléptetést végző script az imént taglalt daemon-nal kommunikál, írja a fifo-t. Elmondja a daemon-nak, mi történjék, a daemon pedig azt teszi.

Nagyon kényelmes, mert amit a $HOME alatt hagyok, az legközelebb is ott lesz, noha fizikailag RAM-ban van a /home, mi több, a következő alkalommal lehet, másik gépen boot-olom be a pendrive-omon lévő live Linuxot. Természetesen a $HOME/.cache alkönyvtárat nem mentem, mert felesleges, és nagyon sok helyet elvisz. A pendrive-ról és a RAM disk-ről egyaránt.

A daemon manageli, hogy csak a legutolsó 3 profil legyen a pendrive-on, a korábbiakat törli. Természetesen a backup alkönyvtár csak a root számára hozzáférhető.

2014.02.24. update:

Annak érdekében, hogy legyen lehetőség a jelszavak cseréjére, user valamilyen csoportba tételére, megoldottam, hogy leállításkor, reboot alkalmával mentse a

/etc/group
/etc/group-
/etc/gshadow
/etc/gshadow-
/etc/passwd
/etc/passwd-
/etc/shadow
/etc/shadow-

file-okat. A rendszer indulásakor ezek visszatöltésre kerülnek az archívumból induláskor, így a legutóbb módosított jelszavak lesznek érvényesek.

2014.02.25. update:

Régi gépen lassan indulnak az alkalmazások, kevés a memória, a felhasználó türelmetlen, így hajlamos az alkalmazást indító ikonra többször kattintani, ezzel tovább rontva a helyzetet, hiszen az illető alkalmazás több példányban indul el. Az alapgondolat a megoldásra log69 blogja. Létrehoztam a /usr/local/bin alkönyvtárba egy runrise nevű scriptet:

#!/bin/bash


PRG="${0##*/}"
[ x"$PRG" = x'runrise' ] && exit 1
if [ $# -eq 0 ]; then
    wmctrl -xa "$PRG" && exit 0
    [ `pgrep -c -u "$USER" -x "$PRG"` -gt 1 ] && exit 0
fi
PATH="${PATH/:\/usr\/local\/bin:/:}"
exec "$PRG" "$@"

Az érintett alkalmazások neveivel egy-egy symlinket tettem a /usr/local/bin-be. A menüből az alkalmazások a nevükkel hívódnak, de nem a teljes elérési úttal, így a menükhöz nem kellett nyúlnom.

A wmctrl parancs a wmctrl csomagban található.

2014.03.10. update:

Felfigyeltem a tar manuáljában az alábbira:

       --exclude-caches
              exclude  contents of directories containing CACHEDIR.TAG, except
              for the tag file itself

Más kérdés, hogy amikor kipróbáltam, nem működött, így utánaolvastam. Azt írják, hogy azon könyvtárak esetén, amelyeket nem akarunk menteni tar-ral, tegyünk egy CACHEDIR.TAG nevű file-t, amely file tartalmának így kell kezdődnie:

Signature: 8a477f597d28d172789f06886806bc55

Így könnyen elérhetjük, hogy egyes alkönyvtárakat kizárjunk a mentésből, például a ~/.cache nevűt.

2014.03.10. update:

Megtetszett a skippy-xd nevű exposé task switcher. Az én esetemben ugyan OpenBoxhoz, de ez a lényegen mit sem változtat. Beletettem hát a live-ba. Az indításához az xdotool nem vált be annak furcsa, bizonytalan működése miatt, így az autostart scriptbe ezt írtam:

if [ ! -d "$HOME/.config/skippy-xd" ]; then
    rm -Rf "$HOME/.config/skippy-xd"
    mkdir -p "$HOME/.config/skippy-xd"
fi
if [ ! -f "$HOME/.config/skippy-xd/skippy-xd.rc" ]; then
    sed "s/\\\${USER}/$USER/g" "$CONFDIR/skippy-xd.rc" >"$HOME/.config/skippy-xd/skippy-xd.rc"
fi


...

skippy-xd --start-daemon &>/dev/null &

...

xautolock -corners '0+00' -cornerdelay 1 -cornerredelay 240 -noclose -locker 'skippy-xd --toggle-window-picker' &>/dev/null &

Ehhez tudni kell, hogy a skippy-xd.rc tamplate-embe írtam egy ilyen sort:

pipePath = /tmp/skippy-xd-fifo-${USER}

Ennek oka az, hogy ha egyidejűleg több felhasználó van belépve, s több daemon fut, azok ne ugyanazt a fifo-t próbálják használni.

A skippy-xd nincs meg Fedorához, így a forrás letöltését követően csináltam belőle bináris rpm csomagot. Meg, ha már éppen rpm csomagot csináltam, akkor a compton kompozitort is lefordítottam a legfrissebb forrásból.

Ezen kívül észrevettem bugot az autostart scriptemben. Egyszerű elírás volt, de ez elég ahhoz, hogy ne csinálja, amit szeretnék. :)

Az alkalmazások indító ikonjait tartalmazó autohide-os panelt áthelyeztem felülről bal szélre. Ennek az az oka, hogy fent lévő ablak fejlécét megfognám, hogy lejjebb húzzam, erre feljött a menü. Ez ugyan nem hiba, de zavaró, kényelmetlen, hogy precízen kellett az egérrel navigálni. Bal szélen nem zavaró az eddigiek alapján.

2014.08.05. update:

Gondom volt, hogy a felhasználó létrehozásakor a jelszót stdin átirányítással tudtam az rc.local scriptben megadni titkosítatlanul. Ugyan a script futása után azt töröltem, de az image-ben ott a file, benne a titkosítatlan jelszóval, ami ugye nem a hosszú élet titka. Erre az alábbi megoldást eszeltem ki.

A live készítésekor a post install scriptben szerepelhet a jelszó, hiszen az nem kerül az image-be. Ha itt előállítom a titkosított változatát, akkor már csak az lesz az image-ben. A post install script releváns részlete:

password='nagy_titok'
salt=`read -rN8 </dev/urandom; echo "$REPLY" | base64`
salt="${salt:0:8}"
python -c "import crypt; print(crypt.crypt(\"$password\", \"\$6\$$salt\"))" >/etc/shadow--
chmod 0 /etc/shadow--

Ezután az /etc/rc.d/rc.local-ban a felhasználó így jön létre:

groupadd -g 1000 valaki
useradd -M -c 'Valaki' -g users -G valaki,wireshark -N -u 1000 valaki
sed -i '/^valaki:/ d' /etc/shadow
change=`getent shadow root | cut -d: -f3`
read </etc/shadow--
echo "valaki:$REPLY:$change:0:99999:7:::" >>/etc/shadow
groupadd -g 1100 guest
useradd -M -c 'Vendég' -g users -G guest -N -u 1100 guest
passwd -d guest &>/dev/null


2014.10.04. update:

A 2014.02.08-án keletkezett bejegyzésben írtam egy daemon-ról, amely root joggal fut, parancsokat vár felhasználókhoz rendelt FIFO-kon keresztül. Ebben volt egy bug, ezt javítottam. Nevezetesen, aszinkron módon olvasta a daemon a FIFO-t, amelynek következtében kis valószínűséggel, de előfordult olykor, hogy a parancs írása közben került olvasásra a buffer, ennek következtében nem érkezett meg az egész parancs. A megoldás az lett, hogy amikor a daemon olvassa a FIFO-t, egy lock file-lal zárolja az írást, elérve ezzel, hogy a sor nem tud eltörni.

2014.12.27. update:

Fedora 21-es image-et készítettem. Beletettem dual monitoros támogatást, billentyűre a monitorok felcserélését, eltérő monitorméretek miatt a háttérkép újrarajzolását. Szintén billentyű-kombinációra az eredendően alul lévő panelt felülre teszi, vagy vissza alulra. Xscreensaver-rel zárolás esetén new login hatására a lightdm felkínálja a másik felhasználó beléptetését. Ehhez a ~/.xscreensaver file végére az alábbi kell:

newLoginCommand: dm-tool switch-to-greeter

2015.05.13. update:

Belefutottam abba, hogy nem feltétlenül sikerül egy oprendszernek felcsatolnia egy filerendszert elsőre. Ezt ugyan nem gondolom helyénvalónak lokális filerendszer esetén, de ez van. Lett belőle workaround:

bs=1048576
((OFFSET=SEEK*bs))
if [ ! -z "$LNAME" -a ! -z "$DEVICE" ]; then
    mkdir -p "/mnt/$LNAME"
    repeat=4
    for ((mnt_cnt=repeat; mnt_cnt>0; mnt_cnt--)); do
        mount -o loop,offset=$OFFSET,noatime "$DEVICE" "/mnt/$LNAME" && break
        umount "/mnt/$LNAME"
        ! sleep 1
    done || rmdir "/mnt/$LNAME"
    log 'Mount repeat count:' "$((repeat+1-mnt_cnt))"
fi

2017.03.02. update:

Régen írtam ide. Egy függőségi probléma miatt hónapok óta nem tudtam image-et készíteni, de csak most jártam utána a problémának. A megoldás a kickstart file-ba, amely többek között a telepítendő csomagokat írja le:

-libcrypt
libcrypt-nss