From: Edward Shishkin <edward@namesys.com>
To: Matthew <jackdachef@gmail.com>
Cc: reiserfs-devel@vger.kernel.org
Subject: Re: reiser4-for-2.6.22-2.patch
Date: Sat, 18 Aug 2007 23:44:17 +0400 [thread overview]
Message-ID: <46C74C11.7020304@namesys.com> (raw)
In-Reply-To: <e85b9d30708181048v35301591vba01deced5e0824d@mail.gmail.com>
Matthew wrote:
>Edward,
>
>I just encountered a pretty strange situation:
>
>first some data:
>I'm running hardened Gentoo with glibc 2.6.1 & gcc-4.2.1 both with
>hardened use-flags enabled
>- my kernel running is a 2.6.22-based kernel with grsecurity and some
>other fine speed enhancements (ck-patchset, adaptive readahead, latest
>reiser4 patch 2.6.22-2)
>- this also happens with hardened-sources 2.6.22-r2 + latest reiser4
>patch 2.6.22-2
>
>every time I'm booting into that system I get a corrupted libuuid.so* file:
>it says things like: libfoo isn't an elf-file or similar
>
>it doesn't seem to matter if I'm using e2fsprogs 1.39 and
>corresponding ss and com_err or e2fsprogs 1.40 with corresponding ss
>and com_err, with booting I mean it only gets to that point and then
>refuses and reboots since it's dependent on that critical thing (??)
>other files also seem to get corrupted, I can't say which ones since
>it reboots pretty fast
>
>util-linux version is 2.12r-r7
>
>it's strange to say but it doesn't matter if I'm booting the kernel
>with ro or rw on /root data still gets corrupted (where /root is/was a
>standard formatted reiser4 partition with mkfs.reiser4 out from a
>livecd with 2.6.21-based kernel with reiser4-patch from namesys if I
>recall right
>
>there's also no difference whether I use the old baselayout-1 or the
>new and faster baselayout-2 (for that I have to append 'rw' at boot
>otherwise reiser4 won't boot since it isn't recognized right)
>
>gcc-version is 4.2.1 hardened with pie 9.0.7, I'm sure this also would
>happen with other gcc version
>
>I'm attaching my kernel-config so that you might be able to reproduce
>it (hopefully) or at least get an idea of it
>
>since I need this pc right now I had to replay my system from a
>tarball to a reiserfs partition, so I unfortunately can't collect any
>further data
>
>Mat
>
>
Hmm.. It would be nice to compare hexdumps of "corrupted" and original
files. Although, you have migrated to v3 already.. Well, I will keep it
in mind,
thanks for the report!
Edward.
next prev parent reply other threads:[~2007-08-18 19:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-27 23:35 Reiser4 for 2.6.22 Mat
2007-07-28 20:54 ` reiser4-for-2.6.22-2.patch Edward Shishkin
2007-08-17 14:50 ` reiser4-for-2.6.22-2.patch Matthew
2007-08-18 17:48 ` reiser4-for-2.6.22-2.patch Matthew
2007-08-18 19:44 ` Edward Shishkin [this message]
[not found] ` <e85b9d30708210555g533c5e2er42e628cdd97ae379@mail.gmail.com>
2007-08-22 14:36 ` Fwd: reiser4-for-2.6.22-2.patch Matthew
2007-08-23 10:42 ` Edward Shishkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46C74C11.7020304@namesys.com \
--to=edward@namesys.com \
--cc=jackdachef@gmail.com \
--cc=reiserfs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.