[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#588466: klibc-utils: kernel panic when resume failed and normal boot continues



tags 588466 moreinfo -patch
stop

On Thu, 08 Jul 2010, Bastian Kleineidam wrote:

> all my newly built kernels failed to boot with the following message:
> [...]
> kinit: No resume image, doing normal boot...
> E: /scripts/local-premount/resume failed with return 255
> Kernel panic - not syncing: Attempted to kill init!

is the /tmp on your box mounted noexec?
please sent output of:
cat /proc/mounts
 
> Attached patch fixes the issue by falling back gracefully to normal
> booting of the system.
> 
> My swap partition is crypted btw:
> $ cat /etc/crypttab | grep swap
> cswap           /dev/mapper/grog-swap_1 /dev/urandom    swap
> $ cat /etc/fstab | grep swap
> /dev/mapper/cswap       none    swap    sw              0       0
> 
> As a sidenote: I do not understand why my system is trying to resume
> from a crypted swap ?artition anyway.
> It tries this everytime, even though the system has always been
> rebooted cleanly without suspending anything to the swap partition.

please send output of
cat /etc/initramfs-tools/conf.d/resume
 
> --- /usr/share/initramfs-tools/scripts/local-premount/resume~	2010-07-07 23:13:20.000000000 +0200
> +++ /usr/share/initramfs-tools/scripts/local-premount/resume	2010-07-08 20:29:31.000000000 +0200
> @@ -58,6 +58,13 @@
>  # hardcode path, uswsusp ships an resume binary too
>  if [ -n "${resume_offset}" ]; then
>  	/bin/resume ${resume} ${resume_offset}
> +	res=$?
>  else
>  	/bin/resume ${resume}
> +	res=$?
>  fi
> +if [ $res -eq -1 ]; then
> +	# do not fail when falling back to normal boot
> +	exit 0
> +fi
> +exit $res

checked indeed resume from klibc does return -1 when
suspend doesn't happen.

I haven't seen the resulting bootfailure yet, currently I can only
explain it by noexec tmp and thus not precache run.

the errexit for hooks on run_script() mika would thus also be hit
on boot and not only on mkinitramfs. not sure that is what we want.

-- 
maks



Reply to: