Stephen Powell wrote, on 24/03/10 01:29:
On Tue, 23 Mar 2010 04:56:05 -0400 (EDT), Arthur Marsh wrote:
Stephen Powell wrote, on 2010-03-23 00:50:
OK, there are a couple of things to check. First of all, make sure
you have MODULES=most listed in /etc/initramfs-tools/initramfs.conf.
grep -v \# /etc/initramfs-tools/initramfs.conf|uniq
MODULES=most
BUSYBOX=y
KEYMAP=n
BOOT=local
DEVICE=eth0
NFSROOT=auto
Good.
Also check /etc/initramfs-tools/conf.d/driver-policy, if it exists.
$ ls /etc/initramfs-tools/conf.d/driver-policy
ls: cannot access /etc/initramfs-tools/conf.d/driver-policy: No such
file or directory
Good.
Generally, this file only exists if, during installation, you said
you wanted an initial RAM file system with only what is required
to boot the system. If this is the case,
/etc/initramfs-tools/conf.d/driver-policy will likely exist and
specify MODULES=dep. And that overrides what is specified in
/etc/initramfs-tools/initramfs.conf. Change
/etc/initramfs-tools/conf.d/driver-policy to specify
MODULES=most too. For now, do *not* list eata in
/etc/initramfs-tools/modules. Then re-run update-initramfs,
re-run lilo (if lilo is your boot loader), shutdown and
reboot. Let me know the results.
I ran:
update-initramfs -u -k 2.6.32-3-686
then rebooted with break=mount
cat /proc/modules
showed lots of modules but *not* eata.
What happens if you don't use break=mount?
Same problem, eata fails to load by fsck stage.
Are you using dependency-based booting?
Yes, but eata was loading ok with dependency based booting earlier.
Back then, listing eata in /etc/modules was enough to cause eata to load
before fsck.
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/sqjp77-rh3....@ppp121-45-136-118.lns11.adl6.internode.on.net
