> I am not quite prepared to upgrade to current at the moment I am
> running off the last snapshot but I did want to build a new kernel
> since there are some stability problems with this one.  This morning I
> got the kernel from the current snapshot and tried to boot from it.  I
> am getting ld.so errors.  As I mentioned this is the ld.so from the
> last snapshot.  To get this to work must I upgrade everything at once
> or can I get the new kernel to work with my present setup?

As the eagle-eyed amongst you will have noticed, there was no Snapshot
Report this week.  There's a good reason for this - the tar_files are
out of sync with the binary snapshots, as the tar_files were made
before some fairly important changes went into the sources from which
the binaries were made.

From what I can understand, this is all part of the move to 64-bit
offsets.  About two weeks ago, the old lseek, mmap, truncate and
ftruncate were renamed to olseek, ommap, otruncate and oftruncate, and
new 64-bit lseek, mmap, truncate and ftruncate system calls were added
(I think stat changed too).  This enabled your old applications
executables to work with the new kernel, and also allow any
newly-compiled executables to use the new 64-bit calls.  This week,
the tar_files were made, and then syscalls.h was changed again to move
the 64bit lseek etc back in place over the old 32-bit lseek etc.  I
believe old 32-bit off_t calls can be preserved by using "options
COMPAT_09" in your kernel config file.

Please don't get me wrong - I think this was a neat and elegant way to
make the painful upgrade to deal with 64-bit off_t's (if that was how
it was done).  However, it's fragmented the development and testing
people to such an extent that no-one is really sure what's working
anymore.

It's not possible to run a kernel built from the tar_files sources,
and the binaries' includes.  With or without COMPAT_09.  You'll get an
error from fsck when it finds itself unable to use lseek(2).  Others
have noted an error about "Cannot map ld.so" - this is presumabbly
from mmap(2) when running a kernel built from tar_files sources.

In addition, the com drivers don't seem to work for some people,
others are having trouble with wd.c, something screwy's going on with
crontab, and then there was a re-arrangement of the queues announced
yesterday.

My suggestion is for there to be a short regrouping time of about 1
week, whereby we can all get back to some semblance of order, and we
can all be sure we're running the same kernel, built from the same
sources.

I realise I'm going to get flamed for this, so flame away guys.  Yes,
I do realise the work you've put in on this, and yes, I know you're
not paid, and no, I'm not trying to be patronising or pompous.  But
when you can't build a kernel for your own machine (I'm still running
off the GENERICAHA kernel from the April 16th binaries until new
tar_files are made), it doesn't fill you with awe and wonder.  I'm
just asking for some time to get back to normal.

Alistair
--
Alistair G. Crooks (agc@uts.amdahl.com)                      +44 252 346377
Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK.
[These are only my opinions, and certainly not those of Amdahl Corporation]

------------------------------------------------------------------------------