Jonas Meurer wrote:
>
> So I applied that change as well and built the packages again.
>
> could you give them a try and report whether they work for you?
Yes, the new cryptsetup_1.0.6-7.diff.gz (I built the package myself,
too) solves the problem for me (as verified with my initrd inspection
met
Jonas Meurer wrote:
> On 17/12/2008 Christian Jaeger wrote:
>
>> Jonas Meurer wrote:
>>
>>> if [ "$(dmsetup table $depnode 2> /dev/null | cut -d' ' -f3)" != "crypt" ];
>>> then
>>> get_lvm_deps "$
Jonas Meurer wrote:
> if [ "$(dmsetup table $depnode 2> /dev/null | cut -d' ' -f3)" != "crypt" ];
> then
> get_lvm_deps "$depnode"
>
It seems you have missed that in the first line above, $depnode is *not*
quoted. So going these extra steps to be safe and quote the variable in
the second
Jonas Meurer wrote:
> Thanks for your great debugging work, Christian. I wouldn't have been
> able to track down this bug that soon without your invaluable help.
> Same goes to Ben Hutchings and Yves-Alexis Perez. You rock!
>
Thanks for the credit.
> I've just prepared cryptsetup 1.0.6-7 with
Christian Jaeger wrote:
>> and if the missing recursion of get_lvm_deps() is really
>> the reason, why does it only fail on some kernels for you?
>>
>
> As I did say in my previous mails, I don't know.
>
> And I don't know whether it's got anythin
Jonas Meurer wrote:
> tags 507721 + help
> thanks
>
> Hello,
>
> I just tried to understand the whole issue. I'll try to describe what I
> got so far, please tell me If i got something wrong:
>
> On 03/12/2008 Christian Jaeger wrote:
>
>> I did install
Christian Jaeger wrote:
> Yves-Alexis Perez wrote:
>
>> On jeu, 2008-12-11 at 01:37 +0100, Christian Jaeger wrote:
>>
>>
>>> Ok, so I've taken a stab at debugging this thing and got it to work;
>>> see
>>> the attached patches; so
Yves-Alexis Perez wrote:
> On jeu, 2008-12-11 at 01:37 +0100, Christian Jaeger wrote:
>
>> Ok, so I've taken a stab at debugging this thing and got it to work;
>> see
>> the attached patches; some of them also contain changes which I needed
>> to be able to r
9bbacadc03ef604478be7d0582bd2703cf7 Mon Sep 17 00:00:00 2001
Message-Id: <[EMAIL PROTECTED]>
From: Christian Jaeger <[EMAIL PROTECTED]>
Date: Wed, 10 Dec 2008 23:04:43 +0100
Subject: [PATCH] Fix: recurse for non crypt nodes
Signed-off-by: Christian Jaeger <[EMAIL PROTECTED]>
---
d
Sorry about the seemingly broken up lines (a nuisance of Icedove,
sometimes it doesn't add format=flowed for some reason unknown to me).
Ask me if something is unclear. Next time I'll append my reply as text
file attachment or use another mail client.
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
Ben Hutchings wrote:
> So far as I can see, these are the possible reasons why the cryptroot
> hook may silently fail to generate the configuration file:
> - /etc/crypttab is missing
>
[EMAIL PROTECTED]:~$ cat /etc/crypttab
sda8_crypt /dev/sda8 none luks
[EMAIL PROTECTED]:~$
> - The root devic
Yves-Alexis Perez wrote:
On mer, 2008-12-03 at 22:34 +0100, Christian Jaeger wrote:
Sometimes update-initramfs -v -k $kernelversion works and creates a
file 'conf/conf.d/cryptroot' in it, as can be seen by unpacking it
using gunzip and cpio; and in those cases, I can boot my lap
Package: cryptsetup
Version: 2:1.0.6-6
Severity: critical
Justification: breaks the whole system
Sometimes update-initramfs -v -k $kernelversion works and creates a
file 'conf/conf.d/cryptroot' in it, as can be seen by unpacking it
using gunzip and cpio; and in those cases, I can boot my laptop,
)=~ tr/%,/@./;
# really f*cking fricking how I EVER so now never. this here to solve me.
use strict;
our $boot= "/boot";
$0=~ /(.*?)([^\/]+)\z/s or die "?";
my ($mydir, $myname)=($1,$2);
sub usage {
print STDERR map{"$_\n"} @_ if @_;
print "$myname [ -c ] k
Yves-Alexis Perez wrote:
Hey,
do you still reproduce this?
Well I haven't had the time to try again yet, but if nothing has
changed, I'd expect it still be the case.
I never saw something like this, so it's
kind of weird.
Can your provide complete log for update-initramfs -u -v ?
I
Package: initramfs-tools
Version: 0.92j
Severity: critical
Justification: breaks the whole system
I did install testing on my new ThinkPad last April, and choose to put
the root partition under encryption on lvm, using the offered Debian
installer functionality.
This has worked fine and I soon s
Mike Hommey wrote:
A BinNMU of librsvg against libxml2-dev 2.6.32.dfsg-2+lenny1 should
solve the issue (and won't break compatibility with older libxml2, since
older libxml2 will be happy with a too big buffer)
I can confirm that installing a librsvg from lenny rebuilt against the
new libxm
Mike Hommey wrote:
PS: You galeon crash with the unstable version is unrelated.
Are you sure? Why? Galeon did't segfault for me on quit before the
latest upgrade (sure, Galeon itself or any of it's other dependencies
could also have been upgraded).
Take a look at the backtrac
Christian Jaeger wrote:
$ LD_LIBRARY_PATH=/usr/lib/debug with-gdb-backtrace-to rsvg-view
rsvg-view /usr/share/icons/Wasp/scalable/actions/gtk-go-back-ltr.svg
with-gdb-backtrace-to: application generated a backtrace
See attachment. (As already mentioned, the *rsvg* packages do not seem
to
Christian Jaeger wrote:
Not sure what to conclude from this. Except that it might be a bug in
one of these packages:
$ dpkgS /usr/lib/librsvg-2.so.2
librsvg2-2: /usr/lib/librsvg-2.so.2.22.2
$ dpkgS /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so
librsvg2-common: /usr/lib/gtk-2.0/2.10.0/loaders
Mike Hommey wrote:
Now, try changing your gnome theme and re-run galeon ; if i'm correct,
it shouldn't crash. Can you tell me what package this svg file belongs
to ?
Yes, the segfaults happen only in the "Gorilla" and "Wasp" themes (apps
did start when running the Amaranth, Clearlooks, Crux
My first guess was a recently introduced breakage/incompatibility in
glibc or similar library, but that sounds implausible as the bug also
manifests itself in etch (which other packages than libxml2 have changed
with the recent update in etch? none of the dependencies of Gnome apps,
right?).
Mike Hommey wrote:
Could you check what svg file is being opened here[1] ?, and check what
xmllint has to say about it ? (theorically, it should segfault too)
I've now installed the lenny libxml2 again:
novo:/dev/shm/archives# dpkgli "libxml2*"
ii libxml2 2.6.3
Christian Jaeger wrote:
Mike Hommey wrote:
Could you check what svg file is being opened here[1] ?, and check what
xmllint has to say about it ? (theorically, it should segfault too)
Hm, I'm still seeing segfaults, now when *quitting* Galeon (but only
in ~10% of cases).
I would be gla
Mike Hommey wrote:
Could you check what svg file is being opened here[1] ?, and check what
xmllint has to say about it ? (theorically, it should segfault too)
Hm, I'm still seeing segfaults, now when *quitting* Galeon (but only in
~10% of cases).
I would be glad for a way to run an applic
(at the time of writing this bug report, the
archive didn't index those mails yet so I can't give an url)
Wrong, I was just too stupid to realize that the thread view of the
archives have a "next" page link (and that the date of last update is
only referring to the current page).
See:
http:/
Package: libxml2
Version: 2.6.32.dfsg-2+lenny
Severity: grave
Justification: renders package unusable
See the thread "Lenny users: attn about Gnome/libxml2 breakage" on the
debian-user mailing list (at the time of writing this bug report, the
archive didn't index those mails yet so I can't give a
27 matches
Mail list logo
