From: Terje Kvernes <terjekv@math.uio.no>
To: "Stefan Jones" <cretin@gentoo.org>
Cc: <gentoo-dev@gentoo.org>
Subject: Re: [gentoo-dev] Announcing new Prelinking Guide
Date: 03 Jan 2003 17:52:08 +0100 [thread overview]
Message-ID: <wxxu1gqtbuv.fsf@nommo.uio.no> (raw)
In-Reply-To: <23454.213.121.89.82.1041585748.squirrel@webmail.churchillrandoms.co.uk>
"Stefan Jones" <cretin@gentoo.org> writes:
[ ... ]
> > oh well. sigh. I guess I'll have to rebuild GCC. mental note:
> > usermode-linux was made for testing stuff like this. I wish I
> > wasn't so trusting towards new things all the time. :-)
>
> Well I'm sorry about this but I have had no reports about any such
> problems.
it's not your fault, nothing to be sorry about. there are
eventualities one cannot predict without reading the source and
trying very hard to think "what if" everywhere. my only concern is
that prelink alters the one thing you really need to survive,
library management, and a small note might be appropriate. it might
also just be me, but why does prelink need to place its temporary
files on the same filesystem as the original file? atomic mv?
> Prelink was tested by many people (10's of system which included
> installing prelink at the start and upgrading a system to prelink)
the problem is that /usr went full while prelink was doing undo.
that caused it to report I/O errors and corrupt libraries and
binaries for a while. no, it wasn't harddrive problems. the system
logs don't mention anything with regards to hda. trust me, I
checked that rather quickly when something returns I/O errors.
I doubt that the filesystem (reiserfs in this situation) manages to
report I/O error to an application without logging the event. I
will however do a badblock readonly test just to be sure.
> The error you got is fairly unique, could anyone else confirm?
try filling /usr and then run prelink. preferably leave a little
space so it'll start on its job. when it then starts to fail, and
things crash, use "undo" for maximum carnage. I'm not in a position
to test this for another day or two. I'm still digging up broken
libraries.
it might also be a good idea to create a log from what prelink did?
prelink -afmRv > /tmp/prelink.log 2> /tmp/prelink.error.log
if the user has tee, errors should probably be sent both to STDERR
and to a logfile. at least I think it's -v for prelink?
[x200 /usr/bin] # man prelink
-bash: /usr/bin/man: cannot execute binary file
life is interesting. for some reason I'm not booting the box or
closing my already open applications. :-)
> Note that prelink is statically linked, and so is sash, so rescue is
> always possible,
of course, and I have enough hardware to be able to get or build
whatever I need. it's just not overly fun to rebuild stuff like X,
Gnome and KDE in Gentoo. buildpkg? right. stupid me saw that /usr
was very full and zapped the files. I'm creating a small LV for the
packages now. and my other Gentoo-box runs 1.2 still, so I can test
my builds with gcc-2.95 before committing them to bugzilla.
> I haven't seen prelink --undo fail, did it for you?
yup. it keeps segfaulting when it reaches the KDE-libraries that
were bitten by the I/O issues.
> I am guessing this is a compound error,
I am guessing that someone needs to handle error situations better
in prelink. the exact error message is lost, since the shell died
quickly after the problems started.
--
Terje
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-01-03 16:53 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 1:27 [gentoo-dev] Announcing new Prelinking Guide John P. Davis
2003-01-03 8:06 ` Terje Kvernes
2003-01-03 8:25 ` Terje Kvernes
2003-01-03 9:22 ` Stefan Jones
2003-01-03 16:52 ` Terje Kvernes [this message]
2003-01-03 19:21 ` Terje Kvernes
2003-01-03 20:54 ` Terje Kvernes
2003-01-04 15:55 ` Stefan Jones
2003-01-04 21:36 ` Terje Kvernes
2003-01-04 14:45 ` Stefan Jones
2003-01-04 22:18 ` Terje Kvernes
2003-01-04 23:11 ` Bart Verwilst
2003-01-04 23:24 ` William Kenworthy
2003-01-05 16:19 ` Paul de Vrieze
2003-01-05 0:10 ` Terje Kvernes
2003-01-03 13:57 ` John P. Davis
2003-01-03 17:23 ` Terje Kvernes
2003-01-03 18:47 ` Toby Dickenson
2003-01-03 19:05 ` Terje Kvernes
2003-01-03 16:11 ` Paul de Vrieze
2003-01-05 1:09 ` Caleb Shay
2003-01-05 3:12 ` Terje Kvernes
2003-01-05 3:52 ` Caleb Shay
2003-01-05 4:39 ` Caleb Shay
2003-01-05 5:27 ` Terje Kvernes
2003-01-05 6:23 ` Caleb Shay
2003-01-05 7:13 ` Terje Kvernes
2003-01-05 8:01 ` Caleb Shay
2003-01-05 13:20 ` Stefan Jones
2003-01-05 14:30 ` Werner Van Belle
2003-01-05 14:41 ` Stefan Jones
2003-01-05 15:10 ` Dewet Diener
2003-01-05 15:17 ` Bart Lauwers
2003-01-05 15:29 ` Stefan Jones
2003-01-05 14:36 ` Dewet Diener
2003-01-05 5:25 ` Terje Kvernes
2003-01-07 4:02 ` Spider
2003-01-07 7:01 ` Viktor Lakics
2003-01-08 18:49 ` Stefan Jones
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=wxxu1gqtbuv.fsf@nommo.uio.no \
--to=terjekv@math.uio.no \
--cc=cretin@gentoo.org \
--cc=gentoo-dev@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox