Rebuilding the kernel with CRYPTO_AES_NI_INTEL=y (and for that matter
CRYPTO_PCRYPT=y) produces the expected result (ie, hw-encryption) - even in
the...
FS (say, ext4) stacked on LV stacked on VG stacked on PV stacked on dm-crypt
blockdev stacked on partition
... case (which, now that I have
Package: cryptsetup
Version: 2:1.3.0-3
Severity: normal
It seems as if arch-specific crypto modules (for example - aesni-intel) are
loaded _after_ the root and swap devices are luksOpen'd (other devices are
open'd later in boot, late enough that the forced modprobe (I have aesni-intel
in
Actually this may be more serious than it first seems.
A typical* user might have...
FS (say, ext4) stacked on LV stacked on VG stacked on PV stacked on dm-crypt
blockdev stacked on partition (a reasonably common/ recommended deployment,
TRIM issues notwithstanding).
In this case - the
Leaving aside the dependancy bug (which is not dnet-common's issue at all) -
there's three distinct problems here, both of which definitely are :-
1/ The MAC address assigned in the default case is not unique (imagine the
effect of a stock-with-defaults install of this package on a 1000-way
Package: libssl0.9.8
Version: 0.9.8g-16
Severity: normal
${Subject}
$ openssl engine gmp -t -vvv
21922:error:2506406A:DSO support routines:DLFCN_BIND_FUNC:could not bind to the
requested symbol name:dso_dlfcn.c:261:symname(bind_engine):
/usr/lib/ssl/engines/libgmp.so: undefined symbol:
Package: xserver-xorg
Version: 1:7.4+1
Severity: important
HAL doesn't seem to pull in this file...
/usr/share/hal/fdi/policy/10osvendor/
debian-x11-keymap.fdi
A simple rename to...
15-debian-x11-keymap.fdi
results in the desired effect (ie call out to debian-setup-keyboard,
Package: xserver-xorg-input-synaptics
Version: 1.1.0-1
Severity: normal
ACK problem description; nb considering where the hotplug input stuff
seems to be going I have locally worked around this via...
/usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi
:
merge
${Subject} - also - wrt: getting the stock -486- image to boot,
add noreplace-paravirt to the boot command line.
Recompiling -686- with CONFIG_X86_GENERIC=y ought to address
the Int 6 at early boot; is this a possibility?
--
Nothing says Labor Day like 500hp of American muscle
Visit OnCars.com
${Subject} - rebuilding debian kernel per...
debian/config/i386/config.686: CONFIG_X86_GENERIC=y
rm debian/abi/2.6.26-1/i386_none_686 -- obviously not ideal, a quick hack to
prove the point
and installing the result boots just fine (again still using the
noreplace-paravirt boot commandline).
Package: packages.debian.org
Severity: wishlist
The thought occurs that it'd be neat if pdo included a hyperlink to
package changelogs - should be relatively simple to extract/ provide?
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Hmm, it already does... At least for the packages where it is indeed
simple to do (so not for backports/volatile atm).
Where exactly did you find it missing?
You're quite correct, indeed it does. Can't believe I've overlooked
it all these years.
Bin the bug. And have a beer on me.
Thanks
Package: nvidia-glx
Version: 100.14.11-1
Severity: important
nvidia-glx package appears to divert...
diversion by nvidia-glx from: /usr/lib/xorg/modules/extensions/libGLcore.a
diversion by nvidia-glx to: /usr/lib/nvidia/libGLcore.a.xlibmesa
however xserver-xorg-core provides...
Package: gnome
Version: 1:2.18.3
Severity: normal
As per ${subject} - from a /brief/ look, tomboy is the only package in
this installation that depends on mono runtime; given the choice I'd
think it more suitable to put packages liable to create dependancies on
mono/ CIL libraries into a
Still present in version 1:7.2-3
=
Package: xserver-xorg
Version: 1:7.1.0-18
Severity: normal
There does not seem to be a way to prevent the XINERAMA extension
being reported as a supported extension in xdpyinfo; from xorg.conf...
Section Module
:
Disable XINERAMA
SubSection extmod
Option
why?
Just saw the resulting error and reporting it and cause seemed the logical
thing to do...
nobody wants rootnfs over wlan.
... if this is the only reason we attempt to bring up networking this early
in boot I guess it's a non-issue as you suggest; I originally misdiagnosed this
locally as
sure but they look very differently from what you think.
the support needs to land in modprobe first.
Yep fair call, just noticed the discrepancy between the way we handle
modules ...
nothing to be seen there, just use copy_exec
... against that for firmware; I haven't got religion one way
Package: firmware-ipw3945
Version: 0.3
Severity: wishlist
Package ought to contain an initramfs-tools hook script so that
the firmware image ends up installed into initrd - for example
a minimal /usr/share/initramfs-tools/hooks/firmware-ipw3945
is (hopefully) attached.
-- System Information:
Package: firmware-ipw3945
Version: 0.3
Followup-For: Bug #406763
The thought occurs that firmware-nonfree could benefit from
a helper function specifically for firwmare in hook-functions;
have hijacked bts #406763 with some comments to this end.
-- System Information:
Debian Release: 4.0
APT
Package: initramfs-tools
Version: 0.85e
Followup-For: Bug #355881
Perhaps more generically there should be firmware support in
/usr/share/initramfs-tools/hook-functions orthogonal to the
support for modules.
firmware-nonfree would benefit from this in particular; see
bts #406763, #386172.
--
Package: linux-image-2.6-3-amd64
Severity: critical
Justification: breaks the whole system
Commit from 2.6.18.6 upstream is vitally important for Core 2 family.
Without this TSC drift between cores will result in unpredictable
hard locks and reboots.
commit
Package: linux-image-2.6.18-3-amd64
Version: 2.6.18-8
Severity: critical
Justification: breaks the whole system
Commit from 2.6.18.6 upstream is vitally important for Core 2 family.
Without this TSC drift between cores will result in unpredictable
hard locks and reboots.
commit
22 matches
Mail list logo
