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 a
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 arch-s
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 /etc/mod
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 com
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: bind_en
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
:
true
1
2
3
true
:
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,
pa
${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).
${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
> 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.
Thank
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')
Archi
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...
xserver-xo
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 separ
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"
Optio
> 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
> 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 a
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 e4a835d383dc582
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 e4a835d383dc58212a9648ef905cb8087e0c4
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.
-- Pa
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 p
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:
Deb
22 matches
Mail list logo
