Package: kexec-tools
Version: 1:2.0.10-1
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Using Linux kernels later than 4.2.0 on a machine that uses the eata driver
to access a disk on a DPT2044W SCSI controller.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Discussed on the linux-scsi mailing list:
http://comments.gmane.org/gmane.linux.scsi/104634
given some patches, did testing and found:
After some more thorough testing I've encountered an ongoing problem trying to
use kexec with filesystems mounted with the eata driver.
If I boot up and have the eata driver loaded but no filesystem check or
mounting of filesystems on the disk attached to the DPT2044W controller, then
attempt a kexec reboot I get the reboot pausing after the "synchronizing scsi
cache" messages and getting the errors that I have included as pictures in my
previous reports.
If I do a normal boot which includes eata being loaded, the disk attached to
the DPT2044W controller having its filesystems checked and mounted, then
attempt a kexec reboot, I get the reboot pausing after the "synchronizing SCSI
cache" messages as before.
If I un-mount the filesystems on the disk attached to the DPT2044W controller
after start-up and try a reboot I get the same problem.
If I do modprobe -r eata after un-mounting the filesystems on the disk attached
to the DPT2044W controller after a start-up kexec *works fine*.
If I do:
start-up
un-mount filesystems on disk attached to DPT2044W controller
modprobe -r eata
modprobe eata
fsck -a of filesystems on disk attached to DPT2044W controller
mount filesystems
then a kexec reboot works fine.
I did some more experimenting and found a workaround:
I was unable to blacklist the eata module but if I did:
modprobe -r eata
modprobe eata
in a cron job before the fsck and mount commands then
I could then perform a kexec reboot successfully.
I also verified that if I did:
modprobe -r eata
after eata was loaded on boot-up without any fsck or mounting of filesystems on
the disk attached to the DPT2044W controller using the eata the kexec reboot
worked fine.
In summary:
if eata is loaded kexec reboot will fail unless a modprobe -r eata is done
either manually or by a cron job.
if a modprobe -r eata has been done, then even if I modprobe eata and fsck and
mount filesystems, kexec reboot works.
Any suggestions for further tests or checks welcome.
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.3.0-rc3+ (SMP w/1 CPU core; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages kexec-tools depends on:
ii debconf [debconf-2.0] 1.5.57
ii libc6 2.19-22
kexec-tools recommends no packages.
kexec-tools suggests no packages.
-- Configuration Files:
/etc/default/kexec changed:
LOAD_KEXEC=true
KERNEL_IMAGE="/boot/vmlinuz-4.3.0-rc3+"
INITRD="/boot/initrd.img-4.3.0-rc3+"
APPEND=""
USE_GRUB_CONFIG=false
/etc/init.d/kexec changed:
PATH=/sbin:/bin
. /lib/lsb/init-functions
test -r /etc/default/kexec && . /etc/default/kexec
do_stop () {
test "x`cat /sys/kernel/kexec_loaded`y" = "x1y" || exit 0
test -x /sbin/kexec || exit 0
mount
sleep 5
log_action_msg "Will now restart with kexec"
# Clear the screen if possible
printf "\033[;H\033[2J"
/sbin/kexec -e
log_failure_msg "kexec failed"
}
case "$1" in
start)
# No-op
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
do_stop
;;
*)
echo "Usage: $0 start|stop" >&2
exit 3
;;
esac
exit 0
-- debconf-show failed
