Hi, I have a DPT 2044W SCSI adaptor in this pc for a non-boot disk, and
previously had it working fine with dependency-based booting with the
required SCSI module eata listed in /etc/modules, all under Debian Sid
on i386. Module eata would load about 4 seconds into the boot before the
"INIT 2.86" message appeared.
I didn't do any kernel rebuild for a few weeks, and during that time the
following packages were updated, amongst others:
[UPGRADE] module-init-tools 3.12~pre1-1 -> 3.12~pre2-1
[UPGRADE] libgudev-1.0-0 151-2 -> 151-3
[UPGRADE] libudev0 151-2 -> 151-3
[UPGRADE] udev 151-2 -> 151-3
the update-initramfs operations triggered by the upgrades only updated a
different kernel's initrd from what I normally use.
When I built a new kernel (with async SCSI scanning disabled, and SCSI
driver eata as a module as usual), module eata failed to load and fsck
failed on the now not-found SCSI disk.
I reported it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574416
referencing an earlier bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562561
I was eventually able to get everything working again by adding eata to
/etc/initramfs-tools/modules and re-running update-initramfs on all kernels.
# ONLY RUN USING "-k all" WITH A KNOWN GOOD
# module-init-tools / initramfs-tools /
# anything else that effects module autoloading combination
# test first on a specific kernel with
update-initramfs -u -k test-kernel-version
# leave one or more known bootable kernel/initrd combination(s)
# to recover from a possibly unbootable kernel
# When test kernel boots fine and modules get loaded alright, update
# all kernels' initrds with:
update-initramfs -u -k all
Attempting to downgrade module-init-tools (only version 3.4-1 was
available in testing or stable, not the 3.12~pre1-1 I had when the whole
process last worked) resulted in an unbootable system.
<start recovery screed>
To recover, I used sysrescuecd to boot from a cd then did:
SHELL=/bin/sh:export SHELL
(as I didn't have zsh on my hard disk)
mkdir /mnt/newroot
mount /dev/sda7 /mnt/newroot
# /dev/sda7 was my root filesystem on my IDE hard disk
mount /dev/sda1 /mnt/newroot/boot
# I had a separate root file system on the first
# 1024 cylinders / 32 GiB of the disk to get around
# BIOS limitations of the machine
I also had to set my ethernet card up as per the sysrescuecd instructions:
ifconfig eth0 ...
route add default ...
then:
chroot /mnt/newroot
I could run aptitude to upgrade module-init-tools then run:
update-initramfs -u -k <version of kernel to boot from>
I would recommend testing different versions of module-init-tools and
initramfs-tools on only one kernel (using update-initramfs -u -k
<test-kernel-name>) rather than as I mistakenly used "-k all". That way
one can boot to a working kernel without a rescuecd.
</end recovery screed>
Anyway, back to the original problem:
I could get module eata loading at the initrd stage by adding eata to
/etc/initramfs-tools/modules and running update-initramfs, but wonder
why module would stop auto-loading at the initrd stage?
As suggested in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562561
I ran:
cd tmp
mkdir init
cd init
gunzip -c /boot/initrd.img-kernel-version | \
cpio -i -d -H newc --no-absolute-filenames
but was not sure what to look for. MODULES=most was already set (module
eata and all its dependencies were in the initrd), and the only
scsi-related commands seemed to be in:
init-premount/udev:
modprobe -q scsi_wait_scan && modprobe -r scsi_wait_scan || true
and in lib/udev/rules.d
How would a SCSI adaptor normally be auto-detected in the early stage of
the boot process once the initrd has been unpacked?
Where would I look for a change in the behaviour of what was run from
the initrd?
Arthur.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/dp1h77-p2c....@ppp121-45-136-118.lns11.adl6.internode.on.net
