update-initramfs hooker script geht nicht mit neuem kernel

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
cpu4
Beiträge: 9
Registriert: 13.10.2015 17:07:12

update-initramfs hooker script geht nicht mit neuem kernel

Beitrag von cpu4 » 14.11.2015 13:05:15

Hallo,
ich habe ein großen Problem, denn ein von mir benötigtes hooker Skript für update-initramfs geht nach einem neuen Kernel nicht mehr.
Ich hatte vorher einen Kernel der mit dem Schalter "CONFIG_BLK_DEV_LOOP=m" kompiliert wurde, da aber ein Befehl in einem initramfs Skript nur mit dem Schalter "CONFIG_BLK_DEV_LOOP=y" funktioniert habe ich den neusten Kernelquellcode kompiliert.Jetzt geht das Skript zwar aber das dazugehörige hooker Skript geht laut update-initramfs nicht mehr:

Code: Alles auswählen

E: /etc/initramfs-tools/hooks/cryptgnupg_sc failed with return 1.
update-initramfs: failed for /boot/initrd.img-4.0.4 with 1.
Aber wenn ich mit dem alten Kernel boote dann geht update-initramfs für das initramfs des neuen Kernels.
Ich hoffe jemand kann mir helfen...

Hooker Skript(wurde von mir nur modifiziert damit es geht):

Code: Alles auswählen

#!/bin/sh

set -e

PREREQ="cryptroot"

prereqs()
{
        echo "$PREREQ"
}

case $1 in
prereqs)
        prereqs
        exit 0
        ;;
esac

. /usr/share/initramfs-tools/hook-functions

# Hooks for loading Gnupg software and key into the initramfs

# Check whether cryptroot hook has installed decrypt_gnupg_sc script
if [ ! -x ${DESTDIR}/lib/cryptsetup/scripts/decrypt_gnupg_sc ] ; then
    exit 0
fi

# Install cryptroot key files into initramfs
keys=$(sed 's/^\(.*,\|\)key=//; s/,.*//' ${DESTDIR}/conf/conf.d/cryptroot)

if [ "${keys}" != "none" ]; then
    if [ -z "${keys}" ]; then
        echo "$0: Missing key files in ${DESTDIR}/conf/conf.d/cryptroot" >&2
        cat ${DESTDIR}/conf/conf.d/cryptroot >&2
        exit 1
    fi
    for key in ${keys} ; do
        keydir=$(dirname ${key})
        echo "WARNING: GnuPG secret keyring ${keydir}/secring.gpg is copied" \
             "to initramfs" >&2
        if [ ! -d ${DESTDIR}/${keydir} ] ; then
            mkdir -p ${DESTDIR}/${keydir}
        fi
        chmod 700 ${DESTDIR}/${keydir}
        cp -p ${keydir}/keycontainer.bin ${DESTDIR}/${keydir}
        cp -p ${keydir}/pubring.gpg ${DESTDIR}/${keydir}
        cp -p ${keydir}/secring.gpg ${DESTDIR}/${keydir}
        if [ -e ${keydir}/gpg.conf ] ; then
            cp -p ${keydir}/gpg.conf ${DESTDIR}/${keydir}
        fi
    done
fi

# Install gnupg software
copy_exec /usr/bin/gpg2
copy_exec /usr/bin/gpg
copy_exec /usr/bin/gpg-agent


# some more libs for pcscd
copy_exec /usr/sbin/pcscd
copy_exec /usr/lib/pcsc/drivers/serial/libccidtwin.so
copy_exec /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so
copy_exec /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist
copy_exec /etc/libccid_Info.plist
if uname -r | grep -q amd64; then
        copy_exec /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0
        copy_exec /lib/x86_64-linux-gnu/libgcc_s.so.1
else
        copy_exec /usr/lib/i386-linux-gnu/libpcsclite.so.1.0.0
        copy_exec /lib/i386-linux-gnu/libgcc_s.so.1
fi

# we need some more stuff from gnupg2
copy_exec /usr/lib/gnupg2/gnupg-pcsc-wrapper
copy_exec /usr/lib/gnupg2/scdaemon
copy_exec /usr/bin/pinentry

exit 0

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: update-initramfs hooker script geht nicht mit neuem kern

Beitrag von rendegast » 14.11.2015 16:47:48

Vergleich mit den hooks aus Debiancryptsetup-bin 1.6.6-5 ist unübersichtlich.
# Check whether cryptroot hook has installed decrypt_gnupg_sc script
if [ ! -x ${DESTDIR}/lib/cryptsetup/scripts/decrypt_gnupg_sc ] ; then
exit 0
fi
decrypt_gnupg_sc ist ein Eigenprodukt?

Du könntest das Skript mal mit
'echo bla'
anreichern, um die Fehlerstelle einzugrenzen.
chmod 700 ${DESTDIR}/${keydir}
bringt gar nix,
da ein potentieller Angreifer, auch ein rechtloser,
einfach die (normalerweise zugängliche) initrd entpackt, fertig.




Dein hook sollte eigentlich kein Problem mit der Kernelvariablen resp. dem loop-Modul haben.
Zuletzt geändert von rendegast am 14.11.2015 17:53:23, insgesamt 1-mal geändert.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

cpu4
Beiträge: 9
Registriert: 13.10.2015 17:07:12

Re: update-initramfs hooker script geht nicht mit neuem kern

Beitrag von cpu4 » 14.11.2015 17:49:40

Wie es schein liegt der Fehler hier:

Code: Alles auswählen

copy_exec /usr/lib/i386-linux-gnu/libpcsclite.so.1.0.0
Was kann denn alles bei copy_exec einem Fehler auslösen?Kann es sein, dass copy_exec die Kernel Version überprüft?
PS: Danke für den Hinweis mit chmod, ich habe keine Ahnung warum ich das geschrieben habe.
Ja, decrypt_gnupg_sc ist zum Großteil von mir geschrieben

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: update-initramfs hooker script geht nicht mit neuem kern

Beitrag von rendegast » 14.11.2015 22:58:44

if uname -r | grep -q amd64; then
copy_exec /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0
copy_exec /lib/x86_64-linux-gnu/libgcc_s.so.1
else
copy_exec /usr/lib/i386-linux-gnu/libpcsclite.so.1.0.0
copy_exec /lib/i386-linux-gnu/libgcc_s.so.1
...

Code: Alles auswählen

# dpkg -l | grep libpcsclite
ii  libpcsclite1:amd64                                          1.8.13-1                             amd64
ii  libpcsclite1:i386                                           1.8.13-1                             i386
Hier benutzt fügen sich alle vier Dateien
unter amd64 in 64bit-initrd ein ohne Problem.


copy_exec ist nicht ganz konsequent,
nehme ich eine Reihe von libs in diesen hook, so machen zBsp.
$echo copy_exec /usr/lib/x86_64-linux-gnu/libFLAC.so.8.3.0
$echo copy_exec /usr/lib/x86_64-linux-gnu/libedit.so.2.0.51
$echo copy_exec /usr/lib/x86_64-linux-gnu/libffi.so.6.0.2
Probleme: "ist kein Link"
(bei anderen solchen nicht,
libdrm_radeon
libdrm_nouveau
libexif
libexpatw
...).
Die Links angegeben
$echo copy_exec /usr/lib/x86_64-linux-gnu/libffi.so.6
$echo copy_exec /usr/lib/x86_64-linux-gnu/libFLAC.so.8
$echo copy_exec /usr/lib/x86_64-linux-gnu/libedit.so.2
dagegen funktionieren, wobei die obigen Libs als solche kopiert werden.



Bei copy_exec steige ich auch nicht ganz durch.
copy_execc /usr/lib/i386-linux-gnu/libpcsclite.so.1.0.0
mit einer angereicherten copy_exec-Funktion:

Code: Alles auswählen

copy_execc() {
        local src target x nonoptlib
        local libname dirname

        src="${1}"
        target="${2:-$1}"
echo MARK0 src "$src" target "$target"
#ls -l "$src" "${src}"
        [ -f "${src}" ] || return 1
echo MARK0a
#ls -l "${DESTDIR}/$target/${src##*/}"
#ls -ld "${DESTDIR}/$target"
        if [ -d "${DESTDIR}/${target}" ]; then
echo MARK0if1
                # check if already copied
                [ -e "${DESTDIR}/$target/${src##*/}" ] && return 0
        else
echo MARK0if2
                [ -e "${DESTDIR}/$target" ] && return 0
                #FIXME: inst_dir
echo MARK0if2a
                mkdir -p "${DESTDIR}/${target%/*}"
echo MARK0if2b
        fi
echo MARK1
        [ "${verbose}" = "y" ] && echo "Adding binary ${src}"
        cp -pL "${src}" "${DESTDIR}/${target}"
echo MARK2
.....
bekomme ich nach MARK0if2 keine weitere Meldung mehr.
Egal ob Neuerstellung nach Löschung oder upgrade von "ohne" auf "mit"
oder upgrade von "mit" auf "mit".
Die Datei landet immer in der initrd,
obwohl copy_execc gar nicht bis zum 'cp' kommt(?).




Aber mit einer Kerneloption hat es wohl wirklich nichts zu tun.
Bei Dir ist wohl auch der erzeugende wie der Zielkernel i386 resp. 32bit?
(um ein mögliches multiarch-Problem bei Dir auszuschließen)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

cpu4
Beiträge: 9
Registriert: 13.10.2015 17:07:12

Re: update-initramfs hooker script geht nicht mit neuem kern

Beitrag von cpu4 » 15.11.2015 11:25:24

Vielen Dank für die Hilfe.
Ich habe übersehen dass ja "copy_exec /usr/lib/i386-linux-gnu/libpcsclite.so.1.0.0" ausgeführt wird obwohl ich ja einen 64-Bit Kernel nutze...
Trotzdem verstehe ich nicht warum "if uname -r | grep -q amd64; then" beim alten Kernel, der auch 64-Bit ist, funktioniert hat, aber beim neuen das Falsche ausführt.
Jetzt funktioniert es wunderbar nachdem ich einfach die Verzweigung gelassen habe(Habe sowieso nur 64-Bit Kerne).
Nochmals Vielen Dank für die Mühe.

Antworten