Package: initramfs-tools
Version: 0.38
Followup-For: Bug #339568
--- mkinitramfs 2005-10-24 01:05:05.0 -0700
+++ mkinitramfs 2005-11-20 09:49:08.881214220 -0800
@@ -167,13 +167,16 @@
cp -p "/etc/mkinitramfs/scripts/${f}" "${DESTDIR}/scripts/$(dirname "${f}")"
done
cp "${CONFDIR}/initra
Thats what I initially thought as well, all I can say is that it the
error messages related to it have gone away for me. Of course, the
errors I could be seeing could also have been due to the second run once
the real root was up.
Paul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
I tried Rusty's suggested patch to modprobe.c (moving the lock forward).
Works like a charm with stock 2.6.14-2 with an initramfs based upon
initramfs-tools.
Please ignore my comments about manual modprobes and the intel sound stuff
screwing up with unknown symbols, I realized that that is a DIFFE
Please ignore/delete the comments about snd_intel8x0, that is a totally
unrelated bug. I tried Rusty's proposed fix for modprobe.c (in bug
333052) and it solves the problem reported in 522 and 333052 for
me (running on a stock linux-image-2.6.14-2 with initramfs made by
initramfs-tools).
--
Package: linux-image-2.6.14-1-686-smp
Version: 2.6.14-2
Followup-For: Bug #333522
Well, I can pretty consistently reproduce this bug, and an interesting
datapoint is that even a manual modprobe after startup causes further
Unknown symbol problems.
I do not know if this is because udev/m-i-t/linux
Package: linux-image-2.6.14-1-686-smp
Version: 2.6.14-1
Followup-For: Bug #333522
udev/unstable uptodate 0.071-1
Just to cover the blanks, it is occuring as well with stock 2.6.14
debian kernels. This is a straight kernel built with an up to date
initramfs tools. initramfs-tools rebuilt the ini
Package: initramfs-tools
Version: 0.37
Followup-For: Bug #336617
Kernel 2.6.14, evms 2.3.3-6
root filesystem is on a lvm2 volume inside a md based raid, all held together
with evms.
Standard EVMS installs do not use the userspace md and lvm tools, but do
require their kernel modules, so it is no
Critical issue #1 was caused by the wrong config file (the new
autogenerated) config file being read instead of the expected one.
The other issues I will bring up on the mailing list on alioth.
I think I have happy solutions to them.
Paul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
OK, I thought I had understood things with the new version, but I missed
the -c flag in init.d/ ... honest, I did look for it...
So, the problem is that the default config of amavisd-new appears to be
blocking messages. The /etc/amavisd.conf file isn't looked at or used,
as you intended. Sorry
Package: amavisd-new
Version: 1:2.2.1-1
Severity: critical
Tags: experimental
Justification: causes serious data loss
Tagging critical per-debian policy, e-mail dropped.
The experimental version of amavisd-new uses a new config schema, but it
looks like it's not completely implemented yet, since
10 matches
Mail list logo
