The same issue occured to me today and I could only find this question in the web. So I tried to debug it myself...
The script /etc/initramfs-tools/hooks/mount_cryptroot
(line 21) is trying to put a file into the /var/tmp/mkinitramfs_uIC6Q0/root/
directory. This directory happens to be missing, according to the error message. The relevant part of the script is:
SCRIPT="${DESTDIR}/root/mount_cryptroot.sh"
cat > "${SCRIPT}" << 'EOF'
The /var/tmp/mkinitramfs_uIC6Q0/
directory is a temporary directory in which the contents of the new initrd are collected. My guess was that the initrd does not have a root subdirectory any more. So I took a look at the contents of the existing initrd image:
# mkdir initrd
# cd initrd
# gunzip -c /boot/initrd.img-4.9.0-3-amd64 | cpio -i
125955 blocks
# ls
bin conf etc init lib lib64 root-aBcDeF run sbin scripts
#
The root
directory has a suffix with 6 random letters/numbers (changed here to aBcDeF
). This is probably for security reasons. I found out that the suffix is different each time the initrd is generated.
So the solution is to extend the /etc/initramfs-tools/hooks/mount_cryptroot
script to find out the true name of the root directory including the suffx and to use this instead of just root
.
This can be done by inserting
ROOTDIR="$(cd "${DESTDIR}"; echo root-*)"
before the failing lines and changing the failing lines to
SCRIPT="${DESTDIR}/${ROOTDIR}/mount_cryptroot.sh"
cat > "${SCRIPT}" << 'EOF'
. There are two more lines that contain root
without the suffix. Those have to be changed to
cat > "${DESTDIR}/${ROOTDIR}/.profile" << EOF
and
/${ROOTDIR}/mount_cryptroot.sh && exit 1 || echo "Run ./mount_cryptroot.sh to try unlocking again"
. This solved the issue for me and
update-initramfs -u -k all
as well as the entering of the password via SSH on bootup worked again.
My entire script /etc/initramfs-tools/hooks/mount_cryptroot
after adaption:
#!/bin/sh
# Author: http://www.dont-panic.cc/capi/2012/10/24/fully-encrypted-vserver-with-ubuntu-12-04/
# This script generates two scripts in the initramfs output,
# /root-xxxxxx/mount_cryptroot.sh and /root-xxxxxx/.profile
ALLOW_SHELL=1
# Set this to 1 before running update-initramfs if you want
# to allow authorized users to type Ctrl-C to drop to a
# root shell (useful for debugging, potential for abuse.)
#
# (Note that even with ALLOW_SHELL=0 it may still be possible
# to achieve a root shell.)
#
if [ -z ${DESTDIR} ]; then
exit
fi
ROOTDIR="$(cd "${DESTDIR}"; echo root-*)"
SCRIPT="${DESTDIR}/${ROOTDIR}/mount_cryptroot.sh"
cat > "${SCRIPT}" << 'EOF'
#!/bin/sh
CMD=
while [ -z "$CMD" -o -z "`pidof askpass plymouth`" ]; do
CMD=`ps -o args | grep 'open --type luks' | grep -v grep`
sleep 0.1
done
while [ -n "`pidof askpass plymouth`" ]; do
$CMD && kill -9 `pidof askpass plymouth` && echo "Success"
done
EOF
chmod +x "${SCRIPT}"
# Run mount_cryptroot by default and close the login session afterwards
# If ALLOW_SHELL is set to 1, you can press Ctrl-C to get to an interactive prompt
cat > "${DESTDIR}/${ROOTDIR}/.profile" << EOF
ctrl_c_exit() {
exit 1
}
ctrl_c_shell() {
# Ctrl-C during .profile appears to mangle terminal settings
reset
}
if [ "$ALLOW_SHELL" == "1" ]; then
echo "Unlocking rootfs... Type Ctrl-C for a shell."
trap ctrl_c_shell INT
else
echo "Unlocking rootfs..."
trap ctrl_c_exit INT
fi
/${ROOTDIR}/mount_cryptroot.sh && exit 1 || echo "Run ./mount_cryptroot.sh to try unlocking again"
trap INT
EOF
The issue is due to a conflict between hibernate and kASLR on x86-32. This can be solved by disabling kASLR with the nokaslr kernel boot option. x86-64 is not affected.
For Grub this can be done by editing /etc/default/grub and adding nokaslr to the boot options, e.g.:
GRUB_CMDLINE_LINUX_DEFAULT="quiet nokaslr"
Then run update-grub to update the configuration and reboot to give it a try.
I had exactly the same issue and it seems that only the PAE kernel is affected by that issue. The same kernel without PAE works without issues.
The workaround for me was to install linux-image-686 and uninstall linux-image-686-pae and linux-image-4.9.0-4-686-pae. The exact kernel version may change over time due to upgrades, but basically the currently running PAE kernel need to be replaced with a kernel without PAE.
It has actually nothing to do with PAE support of the CPU, as my CPU supports PAE according to /proc/cpuinfo. But PAE is anyway not of much use on old notebooks.
It has also nothing to do with kernel 4.9 PAE as the same issue happens with kernel 4.13 PAE from Debian backports.
Best Answer
thank you for all your answers. I solved the problem by using
ps faux
and identified that sync does nothing/waits forever.As i had an usb drive which somehow died and got disconnected the drive still showed up as being mounted.
I renamed
/bin/sync
to/bin/sync2
, copied/bin/ls
to/bin/sync
and ranapt-get upgrade
. It was successful so I renamed the files, rebooted and finally got rid of the disconnected drive.