Erreur sur apt-get install linux-image-3.2.0-4-kirkwood

Hello,

J’ai voulu faire quelques mises à jours sur mon serveur ; en particulier le package : linux-image-3.2.0-4-kirkwood
La mise à jour ne s’est pas correctement passée au moment du script post-installation :

[quote]Paramétrage de linux-image-3.2.0-4-kirkwood (3.2.60-1+deb7u3) …
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-4-kirkwood /boot/vmlinuz-3.2.0-4-kirkwood
update-initramfs: Generating /boot/initrd.img-3.2.0-4-kirkwood
Warning: root device ubi0:rootfs does not exist

Press Ctrl-C to abort build, or Enter to continue[/quote]

Et là, j’ai appuyé sur la touche “Enter”… mais rien… et le process SSH semble se freezer au bout de quelques minutes, donc je perd ainsi la main sur le serveur. (je peux toujours ouvrir une autre fenêtre SSH et killer apt-get process)
et si je fais “Ctrl-C” quand il me le demande, alors ça fais bien un “abort build” :slightly_smiling:

Que dois je faire pour m’en sortir avec cette mise à jour linux-image-3.2.0-4-kirkwood ?
Est-ce à cause de l’espace disque faible ?

PS: à propos de “Warning: root device ubi0:rootfs does not exist” :

df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 463M 426M 37M 93% / ubi0:rootfs 463M 426M 37M 93% / tmpfs 51M 124K 51M 1% /run tmpfs 5,0M 12K 5,0M 1% /run/lock tmpfs 10M 0 10M 0% /dev tmpfs 101M 0 101M 0% /run/shm tmpfs 252M 0 252M 0% /tmp /dev/sda1 291G 106G 171G 39% /media/usb1 /dev/sda2 5,1G 4,0K 5,1G 1% /media/usb0

PS 2 :

uname -a
Linux guruplug 3.2.0-4-kirkwood #1 Debian 3.2.41-2+deb7u2 armv5tel GNU/Linux

Du coup, désormais je peux relancer le process avec “sudo dpkg --configure -a” mais j’obtiens le même résultat.

Merci.

Quelques détails supplémentaires, je pense que c’est lié :

sudo cat /var/lib/dpkg/updates/0000 
Package: linux-image-3.2.0-4-kirkwood
Status: install ok half-configured
Priority: optional
Section: kernel
Installed-Size: 60715
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: armel
Source: linux
Version: 3.2.60-1+deb7u3
Config-Version: 3.2.41-2+deb7u2
Provides: linux-image, linux-modules-3.2.0-4-kirkwood
Depends: kmod | module-init-tools, linux-base (>= 3~), initramfs-tools (>= 0.99~) | linux-initramfs-tool
Pre-Depends: debconf | debconf-2.0
Recommends: firmware-linux-free (>= 3~), uboot-mkimage
Suggests: linux-doc-3.2, debian-kernel-handbook, fdutils
Breaks: at (<< 3.1.12-1+squeeze1), initramfs-tools (<< 0.99~)
Description: Linux 3.2 for Marvell Kirkwood
 The Linux kernel 3.2 and modules for use on Marvell Kirkwood based systems
 (SheevaPlug, QNAP TS-119/TS-219, etc).

Précise que ton système n’est pas x86

Description: Linux 3.2 for Marvell Kirkwood The Linux kernel 3.2 and modules for use on Marvell Kirkwood based systems (SheevaPlug, QNAP TS-119/TS-219, etc)

J’ai bien un sheevaplug mais pas sous forme de NAS donc je ne pourrais pas t’être d’une grande aide :confused:

Effectivement c’est une archi ARM

Hello again,

J’ai trouvé d’autres utilisateurs ayant des symptomes similaires; mais dans les 2 cas, la solution ne me convient pas:

  1. wiki.hackzine.org/hardware/guruplug-misc.html
    Je vais pas faire un lien symbolique sur /dev/root… mon message d’erreur est sur ubi0:rootfs…
    à noter que “/dev/ubi0” et “/dev/ubi0_0” existent

  2. bugs.debian.org/cgi-bin/bugrepo … =%23707789
    J’ai fais la methode de débug proposée ; mais une fois ajouté “set -x” dans “/usr/share/initramfs-tools/hooks/flash_kernel_set_root”, alors je peux reprendre la main à la fin du process… comme si tout fonctionnait correctement. Mais j’ai testé de laisser “set -x” et de relancer “dpkg --configure -a” ==> toujours en échec

essaye en libérant un peu d’espace ( [mono]apt-get install localepurge && localepurge[/mono] par exemple pour supprimer les traductions inutiles des pages de man ou des documentations )

J’ai un Dockstar avec le même SoC mais l’OS est stocké sur une clé usb, pas en mémoire flash.
[mono]Linux dockstarap1 3.2.0-4-kirkwood #1 Debian 3.2.57-3+deb7u1 armv5tel GNU/Linux[/mono]

Merci de votre réponse; les man pages sont déjà sur un disque externe depuis longtemps …, j’ai déjà cronisé localpurge de manière hebdo; donc à ce niveau là, je peux pas vraiment gagner…
cependant, mon problème est connu, voir les précédents liens que j’ai mis plus haut.

à la rigueure, ce qui me débloquerai dans l’immédiat ce serait :

  1. me confirmer que si je reboot le serveur je n’aurais pas de souci… d’ailleurs, quel kernel sera actif ?? => j’ai peur de la prochaine coupure électrique…
  2. me donner un conseil pour que le process apt-get puisse se débloquer, et donc que je puisse install et faire des “remove/purge” sur d’autres paquets… car actuellement, apt-get me réclamme systématiquement un “sudo dpkg --configure -a”.

Merci

Hello,

Bon, déjà, la commande suivante débloque ma situation :

Ensuite, lors de l’invite et du gros warning, je cancel la suppression…

“Débloque”, dans le sens où, il semble que j’ai désormais accès à apt-get pour manager d’autres packages…
Mais la méthode me parait étrange… j’ai peur qu’au prochain reboot, je n’ai plus rien du tout…

des avis ?

Fais un petit [mono]ls -al /boot[/mono] pour voir

-rw-r--r--  1 root root  107572 juil. 24 00:19 config-3.2.0-4-kirkwood
lrwxrwxrwx  1 root root      27 mai   27  2013 initrd.img -> initrd.img-3.2.0-4-kirkwood
-rw-r--r--  1 root root 7246026 août  13 21:46 initrd.img-3.2.0-4-kirkwood
drwxr-xr-x  2 root root     160 mai   27  2013 lost+found
-rw-r--r--  1 root root 1212465 juil. 24 00:19 System.map-3.2.0-4-kirkwood
-rw-r--r--  1 root root 1608456 mai   27  2013 uImage
-rw-r--r--  1 root root 7243905 mai   27  2013 uInitrd
lrwxrwxrwx  1 root root      24 mai   27  2013 vmlinuz -> vmlinuz-3.2.0-4-kirkwood
-rw-r--r--  1 root root 1612032 juil. 24 00:19 vmlinuz-3.2.0-4-kirkwood
dpkg -l | grep -Ei "linux-headers|linux-image"
pi  linux-image-3.2.0-4-kirkwood    3.2.60-1+deb7u3      armel    Linux 3.2 for Marvell Kirkwood
ii  linux-image-kirkwood            3.2+46               armel    Linux for Marvell Kirkwood (meta-package)

Je vais partir du principe que je peux tenter un redémarrage de la machine pendant un temps calme…

Il me semble que le bootloader recherche les fichiers [mono]uInitrd[/mono] et [mono]uImage[/mono]. Ce sont ces fichiers en tout cas qui sont générés “in fine” par l’installation d’un nouveau noyau.

Donc là, vu que ta mise à jour ne va pas au bout, tu as toujours les anciens [mono]uInitrd[/mono] et [mono]uImage[/mono], ça devrait booter comme avant.

(Au pire tu as moyen de te dépanner en bootant via une clé usb)

sinon un tout petit détail :

pas utile je pense, car localepurge, une fois installé, fait son boulot automatiquement quand on installe/met à jour un paquet.

Hello,

J’ai donc testé le redémarrage. aucun souci. tout va bien.

PS: en ce qui concerne le commentaire sur “localepurge” ; c’est un autre sujet qui mériterai un nouveau topic à lui tout seul. :slightly_smiling:

Merci de vos conseils.