Bonjour, j'essaie de faire fonctionner une debian bullseye sur un vieux téléphone arm (Archos Titanium 40C) fonctionnant sous KitKat (rooté). Ça se passe plutôt bien à part pour dpkg et apt, qui ne fonctionnent pas du tout. Pourtant ils fonctionnent lorsque je fais tourner mon image sous un chroot de mon PC (avec qemu)…
Lorsque j'essaie d'installer un paquet avec « dpkg -i », j'ai le message :
dpkg-split: error: --auto requires exactly one part file argument
(...)
subprocess dpkg-split returned error exit status 2À part ça le système semble tout à fait fonctionnel, j'arrive notamment à lancer openssh-server (à l'ancienne vu que KitKat n'utilise pas systemd…)
Quelqu'un aurait-il une idée SVP ?
J'ai créé l'image avec :
debootstrap --verbose --arch armhf --foreign bullseye debian http://ftp.fr.debian.org/debian
Puis, sous un chroot une fois qemu installé :
tasksel install standard
dpkg-reconfigure locales
apt-get install sudo openssh-server net-tools
echo "deb http://security.debian.org/debian-security bullseye-security main" >> /etc/apt/sources.list
groupadd -g 3001 android_bt
groupadd -g 3002 android_bt-net
groupadd -g 3003 android_inet
groupadd -g 3004 android_net-raw
usermod -g 3003 _apt
mkdir /var/run/dbus
chown messagebus.messagebus /var/run/dbus
chmod 755 /var/run/dbus
usermod -a -G android_bt,android_bt-net,android_inet,android_net-raw messagebusEnsuite, une fois l'image transférée sur mon téléphone, j'exécute ce script de démarrage :
echo "Mounting system as R/W"
mount -o remount,rw -t ext3 /dev/block/mmcblk0p12 /system
echo "Setting some stuff up.."
export bin=/system/bin
export img=/sdcard/debian/debian11.img
export mnt=/data/local/debian
export PATH=$bin:/usr/bin:/usr/sbin:/bin:$PATH
export TERM=linux
export HOME=/root
if [ ! -d $mnt ]; then
mkdir $mnt
fi
echo "Mounting the Linux Image"
losetup /dev/block/loop5 $img
mount -t ext4 -o noatime,nodiratime /dev/block/loop5 $mnt
mount -t devpts devpts $mnt/dev/pts
mount -t proc proc $mnt/proc
mount -t sysfs sysfs $mnt/sys
echo "Setting Up Networking"
sysctl -w net.ipv4.ip_forward=1
echo "nameserver 192.168.1.1" > $mnt/etc/resolv.conf
echo "nameserver 8.8.4.4" >> $mnt/etc/resolv.conf
echo "127.0.0.1 localhost" > $mnt/etc/hosts
echo "Mounting sdcard and emmc in /mnt"
if [ ! -d $mnt/mnt/sdcard-int ]; then
mkdir $mnt/mnt/sdcard-int
fi
/system/xbin/busybox mount --bind /storage/sdcard1 $mnt/mnt/sdcard-int
if [ ! -d $mnt/mnt/sdcard-ext ]; then
mkdir $mnt/mnt/sdcard-ext
fi
/system/xbin/busybox mount --bind /sdcard $mnt/mnt/sdcard-ext
chroot $mnt /bin/bash --login
# piste pour deboguer
Posté par moi1392 . Évalué à 4.
Apparement les arguments de l'appel à dpkg-split sont faux.
Une première chose à faire, est de trouver quelle différence il y a entre ton system fonctionnel (sous ta VM) et celui installé.
Tu peux tenter, par exemple, de remplacer dpkg-split dans /usr/bin par un script qui affiche ses arguments sur la sortie standard et transmet (ou pas) l'appel ensuite au vrai dpkg-split.
Si tu vois une différence entre les deux systèmes, c'est probablement en amont qu'il faut chercher. S'il n'y en a pas, essaye de voir (dans ton script intermédiare, ils sont certainement effacé ensuite) si les fichiers mentionnées existent. Il y a peut être un soucis de droits d'écriture ou d'espace disque.
[^] # Re: piste pour deboguer
Posté par xneggoum . Évalué à 1.
Ah oui, pas mal, ça !
Apparemment il lance :
Je ne vois pas de fichier /var/lib/dpkg/reassemble.deb, je vais creuser la question. Merci du tuyau !
[^] # Re: piste pour deboguer
Posté par moi1392 . Évalué à 3.
Attention, si c'est un fichier temporaire, il se peut qu'il soit supprimé par dpkg quand dpkg-split échoue.
Pour être sur qu'il est bien manquant, fait le test depuis ton script dpkg-split que tu as mis en place pour creuser le problème.
[^] # Comportement inattendu de dpkg
Posté par xneggoum . Évalué à 1.
Bon, visiblement c'est bien dpkg qui se comporte curieusement…
Lors d'une commande « dpkg -i nom_paquet.deb », il devrait invoquer dpkg-split ainsi :
Au lieu de ça, il ne passe pas le nom du paquet, il tente de l'invoquer comme ça :
Forcément, ça marche pas… Ici le fichier reassemble.deb est apparemment le résultat du traitement de la commande.
[^] # Re: Comportement inattendu de dpkg
Posté par xneggoum . Évalué à 1.
Dans unpack.c, on trouve cette ligne :
Souci de pointeur, on dirait…
[^] # Re: Comportement inattendu de dpkg
Posté par xneggoum . Évalué à 1.
Dans unpack.c, il vérifie que le paquet filename existe bien. Ça, ça fonctionne.
Ensuite il invoque deb_reassemble(&filename, &pfilename).
Cette fonction est définie comme ça :
Et dans cette fonction, on a :
À l'appel de execlp(SPLITTER, SPLITTER, "-Qao", reasmbuf, *filename, NULL), on dirait de *filename est vide… Peut-être un lien avec le fork ?… Je sèche un peu, là…
[^] # Re: piste pour deboguer
Posté par xneggoum . Évalué à 1.
Bon, ben il y a un peu de nouveau… J'ai transféré mon image sur mon PC, j'y ai fait un apt-get install, ça a mouliné un peu (il devait rester un truc mal digéré), puis j'ai retransféré l'image sur mon téléphone.
Et là ce n'est plus le même souci, il ne se plaint plus de dpkg-split, mais de manière aléatoire mais assez souvent, ça échoue :
Mais, assez rarement, ça fonctionne. Chose curieuse, j'ai fait plusieurs tests en faisant :
Et là ça fonctionne à chaque fois, pas de segmentation fault…
Une idée de ce qui cloche ?
À+.
[^] # Re: piste pour deboguer
Posté par moi1392 . Évalué à 3.
Pas d'idée à priori, mais si ça passe à tous les coups avec un strace, il y a des chances que ça soit lié à une race condition.
Genre le filesystem qui met du temps à valider un nouveau fichier (je ne vois pas pourquoi mais bon…) et qui du coup, en passant par le strace, tu es sur que l'opération et finie et que ton fichier est bien présent.
ça peut être nimporte quelle race condition du genre, en général c'est une notif qu'un boulot fait pas un autre process est fini (process se termine, pipe se ferme, …), mais quand tu vas chercher le résultat trop vite derrière, il n'est pas encore là.
Je ne sais pas trop comment débuguer ce genre de chose à la ligne de commande, je tenterais vraiment des trucs au cas par cas.
Une dernière idée si tu veux tenter d'autres trucs, c'est de :
1) tenter de compiler une version debug de dpkg-deb et voir si tu as toujorus le crash
2) remplacer le lancement de dpkg-deb par un appel à "gdb --batch --args dpkg-deb $#" et n'oublie pas de placer un .gdbinit quelque part avec la commande run
quand le sous process va planter (s'il plante) tu auras le prompt gdb et tu pourras tenter de voir ce qu'il se passe.
C'est une solution qui demande un peu d'expérience, et qui a de fortes chance de ne pas marcher cas ça ne plantera pas depuis gdb.
Si c'est le cas et que la version debug crash quand même, tu peux tenter la solution (plus compliquée, et sur android je ne saurais pas comment faire perso) d'installer un crash handler qui va attacher à gdb le process qui plante une fois le crash survenu.
Voila, c'est vraiment si t'as envie de t'amuser tout ça….
[^] # Re: piste pour deboguer
Posté par xneggoum . Évalué à 1.
Merci pour tout ça, pour le moment, tant pis, je ferai mes mises à jour en les lançant via strace, vu que ça a l'air de marcher. Et si j'ai envie de m'amuser ;-), comme tu dis, je tenterai d'explorer une de tes pistes !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.