staging.inyokaproject.org

Hallo,

ich habe ein debian-Paket gebaut, welches unter ubuntu 18.4 funktioniert, unter 16.4 jedoch abbricht:

1
2

dpkg: error processing archive /boot/bananapi-r2-image-4.14-main_4.14.59-1_armhf.deb (--install):                                                                                                                         
 error setting ownership of './boot/bananapi/bpi-r2/linux/uImage_4.14.59-main': Operation not permitted  

dpkg versucht also den owner zu setzen...geht natürlich nicht, weil das Ziel auf einer fat-partition liegt...

kann man irgendwie über die control/rules o.ä. für einzelne Dateien verhindern, dass owner/permissions gesetzt werden?

mein code zum Erstellen des Paketes ist hier: https://github.com/frank-w/BPI-R2-4.14/blob/ea33882e1b8cee17de7cea8231ed4340348c93f8/build.sh#L139

ich erstelle also die Dateistruktur (auf einer ext-partition) inkl. control-Dateien (control,preinst,postinst,postrm) und erstelle das Paket mit:

1

fakeroot dpkg-deb --build bananapi-r2-image ../debian

Gruß Frank

Ja, mit dem Target override_dh_fixperms in debian/rules klappt das glaube ich.

ist das nicht ein zusätzliches chown/chmod nach dem install?

oder meinst du, wenn man es "leer lässt" bzw. so:

https://askubuntu.com/questions/439780/how-to-create-directory-and-change-its-owner-with-the-deb-package

1
2

override_dh_fixperms:
    dh_fixperms --exclude ./boot/bananapi/bpi-r2/linux/uImage_4.14.59-main

so funktioniert es schonmal nicht:

1
2
3
4

    cat > debian/bananapi-r2-image/DEBIAN/rules << EOF
override_dh_fixperms:
    dh_fixperms --exclude boot/
EOF

gleicher Fehler mit dem ownership...

jemand eine idee?

Unter welchen Umstaenden ist /boot eigentlich FAT?

Auf dem zielsystem immer (arm-board) ob das ein mountpunkt ist prüfe ich grob im preinst

Auf ARM scheint die Installation der Kernel auf /boot ganz anders zu funktionieren: https://wiki.ubuntu.com/ARM/RaspberryPi#Update_flash-kernel_database

The flash-kernel package is used to copy the kernel and initrd to the fat system-boot partition.

Ich habe bereits mehrere kernel manuell so kopiert. Mein kernel braucht keine initrd, hat ein appended devicetree und kein bootscript o.ä. nur eintrag in uenv.txt (postinst)

Prinzipiell funktioniert der weg... nur halt nicht mit dem dpkg von ubuntu 16.4

Eventuell so?

dpkg --no-triggers   #Resultierende Triggerverarbeitung übergehen oder erzwingen

welche trigger werden da übersprungen? hoffentlich nicht meine post/pre-scripte

Das weiß ich leider auch nicht, eventuell steht da in der man-Page mehr? Das lief mir nur so über den Weg. Falls es was bewirken sollte, müsstest Du ja nur eine Abfrage der OS-Version und/oder des Zieldateisystems einbauen.

Ansonsten gilt wie immer: Versuch macht kluch ☺

Hatte genau das gleiche Problem beim Bau eines Kernel debian Pakets für den Raspberry Pi. Wie schon richtig beschrieben ist die boot Partition als vFat formatiert. So wie ich es verstanden habe, unterstützt dpkg-build nicht die debian/rules. Dafür müsste man debuild verwenden. Das wollte ich jedoch vermeiden. Bei mir hat es mit der Option --root-owner-group geklappt. Der gesamt Befehl sieht bei mir so aus:

1

dpkg-deb --build --root-owner-group -Zxz raspberrypi-kernel

Das Paket kann jedoch nur installiert werden, ein Upgrade beispielsweise funktioniert leider nicht. Das Problem wird hier genauer beschrieben: https://raspberrypi.stackexchange.com/a/94827

Deswegen ist der Bau eines Kernel Pakets für den Raspberry Pi sehr umständlich.

Ich habe es folgendermaßen gelöst. Bevor das Paket installiert wird, wird das alte Paket gelöscht ohne die Abhängigkeiten aufzulösen.

1
2

dpkg -r --force-depends raspberrypi-kernel
dpkg -i ./deb-package/raspberrypi-kernel.deb

Mit dieser kleinen Einschränkung kann ich gut leben. Danach setze ich das Paket noch auf hold, damit es nicht automatisch upgedated wird:

1

sudo apt-mark hold raspberrypi-kernel

Hier das Repository, wo ich das Ganze umgesetzt habe: https://github.com/theAndreas/raspberrypi-kernel64-rt