[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Announcing new Prelinking Guide
From:       Terje Kvernes <terjekv () math ! uio ! no>
Date:       2003-01-03 16:52:08
[Download RAW message or body]

"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

[prev in list] [next in list] [prev in thread] [next in thread]