Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am in the process of upgrading a machine from Debian Lenny to Squeeze (I know it was about time ;-) and ran into a weird error that boils down to the update-initramfs command complaining about some files already existing.

Here is the complete output I get:

Debian-50-lenny-64-LAMP:/tmp/mkinitramfs_Zq6I1R/usr/share# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.26-2-amd64
ln: creating symbolic link `/tmp/mkinitramfs_i1KKQH//usr/share/java/^^': File exists
mkdir: cannot create directory `/tmp/mkinitramfs_i1KKQH//usr/share/java/^^': File exists
ln: creating symbolic link `/tmp/mkinitramfs_i1KKQH//usr/share/java/^^': File exists
mkdir: cannot create directory `/tmp/mkinitramfs_i1KKQH//usr/share/java/^^': File exists
ln: creating symbolic link `/tmp/mkinitramfs_i1KKQH//usr/share/java/^^': File exists
mkdir: cannot create directory `/tmp/mkinitramfs_i1KKQH//usr/share/java/^^': File exists
ln: creating symbolic link `/tmp/mkinitramfs_i1KKQH//usr/share/java/^^': File exists
mkdir: cannot create directory `/tmp/mkinitramfs_i1KKQH//usr/share/java/^^': File exists
E: /usr/share/initramfs-tools/hooks/mdadm failed with return 1.
update-initramfs: failed for /boot/initrd.img-2.6.26-2-amd64

So I started investigating the above directory and made some interesting findings - the directory does indeed exist but can not be deleted by running rm -rf:

Debian-50-lenny-64-LAMP:/tmp/mkinitramfs_i1KKQH/usr/share# rm -rf /tmp/mkinitramfs_i1KKQH//usr/share/java/
rm: cannot remove `/tmp/mkinitramfs_i1KKQH//usr/share/java': Directory not empty
Debian-50-lenny-64-LAMP:/tmp/mkinitramfs_i1KKQH/usr/share# 

And further when changing into the given directory and running ls I get:

Debian-50-lenny-64-LAMP:/tmp/mkinitramfs_i1KKQH/usr/share/java# ls
ls: reading directory .: No such file or directory

I am not really sure where to go from here - needless to say I am logged in as root.

Everytime the command gets executed a new temp folder in the form of mkinitramfs_<randomstring>is created - so it seems unlikely that it is a disc corruption problem in my eyes as I am not running into this problem anywhere else on my system.

Thanks.

share|improve this question

migrated from stackoverflow.com Feb 23 '13 at 8:06

This question came from our site for professional and enthusiast programmers.

1 Answer 1

You should run update-initramfs -u -k all every time you change kernel, so you may do it while upgrading to squeeze. But since this is not working correctly, you may just upgrade to squeeze keeping the same kernel you currently run. Just put it on hold via apititude or dpkg --set-selections and upgrade. Holding the kernel will also prevent upgrading of other packages, like the initramfs tool.

Once you will be running the upgraded system, you will have the new update-initramfs tool, and you may try again to upgrade your kernel.

share|improve this answer
    
thanks for your answer - it turned out however that the machine got hacked and the way the attackers used to hide their payload was the cause for update-initramfs to fail –  bxr May 23 '13 at 9:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.