[ Posting on behalf of Salvo Bartolotta, who did all the hard work. See
http://www.FreeBSD.org/conspectus/index.html for more information. To
contribute, contact [EMAIL PROTECTED] -- N ]
FreeBSD-stable Conspectus, week ending 5th June 2000
Dates # Posts Subject
May 31 - June 01 3 3.5 Release date
May 30 - May 30 1 Announce: -stable commit lists
June 01 - June 01 1 HEADS UP: Data corruption bug in Vinum
found and fixed
June 01 - June 01 2 smbfs for FreeBSD 3.4
June 03 - June 05 5 PCCARD support
June 04 - June 05 2 3dfx driver
June 02 - June 04 5 3.4-STABLE -> 4.0-RELEASE upgrade:
unable to mount root partition
June 02 - June 02 2 Reboots on Alpha System running 4.0 Stable
June 05 - June 05 1 Spontaneous reboot with STABLE SMP kernel
May 30 - June 01 18 GENERIC 4.0 kernel compile fails on in_cksum.c
May 30 - June 05 3 Make world fails on latest 2.2.8...
June 05- June 05 1 FATAL FS Mount bug in -STABLE and -RELEASE
May 31 - May 31 1 Finally....A solution, It would appear
May 30 - May 31 6 -jn and -STABLE world
May 29 - May 30 9 4.0-stable, OpenSSH v1 & v2
---------------------------------------------------------------------------
May 31 - June 01 (3 posts): 3.5 Release date
On May 31, 2000, [Jordan K. Hubbard] announced to the -stable community a
possible date for the release of FreeBSD-3.5: June 20.
On the same day, [James Housley] reminded the -stable forum that CTM did
not still work as it should:
I have a PR that I think should be resolved before the release: http://
www.FreeBSD.org/cgi/query-pr.cgi?pr=18058
Description:
src/usr.sbin/ctm/ctm/ctm_input.c limits files to 10Meg (10485760).
cvs-cur.6200xEmpty.gz has a file, src/sys/dev/isp/asm_pci.h,v that is
greather than 11Meg, actually 11913588 bytes.
[Vivek Khera], replying to Jordan's letter, remarked:
I was just investigating the NIS server on 3.4-STABLE, and noticed that
the docs claim that TCP wrappers are not compiled in by default since
they are not shipped with FreeBSD... However, that is no longer the
case.
Can we get this security updgrade included in the next release? All
that seems to be necessary is to define YP_WRAPPER in the Makefile and
link to the libwrap that is part of the system now.
---------------------------------------------------------------------------
May 30 - May 30 (1 posts): Announce: -stable commit lists
On May 30, 2000, [David Miller] made this proclamation:
I've setup freebsd-stable-3 and freebsd-stable-4 majordomo lists at
sparks.net. These use procmail to filter the RELENG_[3|4] messages out
of cvs-all, so one can easily tell which commits affect them.
Anyone could use procmail to filter the list himself, but I thought
this was more convenient, especially for those not set up with
procmail.
To subscribe, send an email to freebsd-stable-[3|4][EMAIL PROTECTED]
Digest versions are setup as well.
---------------------------------------------------------------------------
June 01 - June 01 (1 posts): HEADS UP: Data corruption bug in Vinum found
and fixed
On June 1, 2000, [Greg Lehey] promulgated the following important result:
I've just discovered (and fixed) a serious data corruption bug in
Vinum. Under certain circumstances, serious data corruption can result:
1. You are using RAID-4 or RAID-5 plexes.
2. One of these plexes (not the first plex in the system, whether a
RAID-[45] plex or not) develops parity problems.
3. You correct these errors with the 'rebuildparity' command.
Under these circumstances, the corrected blocks will probably be
written to the wrong subdisk. The original parity errors will remain.
The fix is in 4-STABLE and 5-CURRENT (revisions 1.22.2.1 and 1.29,
respectively). I don't think that 3-STABLE currently supports the
rebuildparity command, but I shall check and MFC if necessary.
---------------------------------------------------------------------------
June 01 - June 01 (2 posts): smbfs for FreeBSD 3.4
On June 1, 2000, [Boris Popov] broadcast some good news:
Native smbfs for FreeBSD now supports version 3.4 of this OS (it may
also run on 3.2 or 3.3, but definitely 'll crash on 3.1).
Please note, that FreeBSD 3.4 doesn't contain src/sys/crypto directory
which is required if you want to use encrypted passwords. You have to
pull this directory from either FreeBSD 4.0 or -current (collection
src-sys-crypto).
The tarball is available at ftp://ftp.butya.kz/pub/smbfs/smbfs.tar.gz
---------------------------------------------------------------------------
June 03 - June 05 (5 posts): PCCARD support
On June 3, 2000, [Archie Cobbs] sent a new entry for pccard.conf (PreMax
PE-200 Ethernet card) as well as his woes in upgrading his laptop to
-STABLE.
[Warner Losh] replied that he would add that entry to pccard.conf, and that
he would also document a few minor points; the next day [Mitsuru Iwasaki]
MFC'ed the relevant code -- as had been agreed -- but ahead of schedule.
As an aside, Archie was able to solve all of his problems thanks to the
suggestions from the mailing lists.
---------------------------------------------------------------------------
June 04 - June 05 (2 posts): 3dfx driver
On June 4, 2000, [Coleman Kane] made this announcement:
I have finished the 3dfx driver for FreeBSD finally. What should I do
with it now, the tarball would be a little big to stick on the list I
assume. It is basically a device driver that can be compiled as a kld
or static kernel driver, and another module that is loaded after the
linux module to facilitate the linux ioctl interface (which requires
drivers to register their own ioctls for linux). Anyway, is there
someone in charge of taking care of this sort of thing, or some
testers?
The software is found at http://pohl.ececs.uc.edu/~cokane/.
---------------------------------------------------------------------------
June 02 - June 04 (5 posts): 3.4-STABLE -> 4.0-RELEASE upgrade: unable to
mount root partition
[Bharat Mediratta] met with some difficulties while trying to upgrade from
3.4-S to 4.0-R. The cause turned out to be "bad 144".
He was told that bad 144 tables were no longer supported under 4.0 - as is
well-known - and that there were no tools to deal with them on his updated
machine. After searching the 'Net, Bharat, thanks to [David Babler]'s
indications, came to the following conclusions:
When I installed FreeBSD 3.4-STABLE on my machine there was no
indication that bad144 (bad sector forwarding) was not a good idea.
Support for bad144 went away in 4.0, so if you are using it in 3.4 this
will get in the way of upgrading. After you reinstall the kernel and
reboot it will not let you remounte your root partition and will give
you an error message like this:
wd0: bad sector table not supported
wd0s1: bad sector table not supported
So here are some common questions and answers:
Q: How do I tell if my drive has bad144 on it, BEFORE I try to upgrade
to FreeBSD 4.0 and have it fail on me?
A: Use the disklabel utility. 'disklabel -r wd0' (replace wd0 with your
drive device) will give you the contents of your disk label. For
example:
# /dev/rwd0c:
type: ESDI
disk: wd0s1
label:
flags: badsect <--- NOTE!
bytes/sector: 512
sectors/track: 63
Q: How do I remove bad144?
A: The easiest way to do this is to use disklabel. You can dump the
current label out to disk and then reload it, or you can just edit it
in place with 'disklabel -e -r wd0'. All you have to do is remove
'badsect' from the flags line and you're all set. This won't affect any
of your data. bad144 is probably still taking up some space on your
disk but it is no longer in effect.
Bharat has also sent the following PR: docs/19010: bad144 obsoletion by 4.0
is undocumented; fix is undocumented.
---------------------------------------------------------------------------
June 02 - June 02 (2 posts): Reboots on Alpha System running 4.0 Stable
After updating a Digital AlphaServer 400 4/233 from 4.0-R to 4.0-S,
[Sparhawk] saw some reboots: fatal kernel trap, memory management fault
(trap entry=0x02). An opennap napster server had been running on the
machine.
[Kevin M. Dultzo] had the same experience on a PC164 500MHz running
(underclocked) at 466MHz
The problem is currently under investigation.
---------------------------------------------------------------------------
June 05 - June 05 (1 posts): Spontaneous reboot with STABLE SMP kernel
[Fritz Heinrichmeyer] encountered other spontaneous reboots on his SMP
server. He promised that he would send a detailed PR as soon as he found
the time.
---------------------------------------------------------------------------
May 30 - June 01 (18 posts): GENERIC 4.0 kernel compile fails on in_cksum.c
[Bharat Meditatta] could not upgrade from 3.4-S to 4.0-S because the kernel
build had died with an in_cksum.c-related error code 1.
He was advised to proceed in two steps -- 4.0-R, 4.0-S -- in order to avoid
any potential problems. However, [Warner Losh] pointed out that the -STABLE
update path (3.4-S --> 4.0-S) would still be considered as safe unless
there was actual evidence against it. Other people as well as Warner had in
fact succeeded in performing the above-mentioned upgrading operation a few
days before -- [Guido van Rooij] had done that even from 3.1 albeit this
required a suitable (but not difficult) sequence of actions. In the end,
Warner agreed to slightly modify the UPDATING file so that it would contain
a more reliable method.
As is (should be) well-known, the UPDATING file to be considered is the new
one downloaded via e.g. cvsup.
Here is Warner's upgrading scheme outlined in his own words:
make buildworld
<follow directions to build/install a kernel>
cd /usr/src/sys/modules
make install
cd /usr/src/sbin/mknod
make install
<follow rebuild disk /dev entries above> [1]
reboot
Rather than the current order, since I know that this works. It also
puts the system in an inconsistant state for a shorter period of time
since the modules are installed just after the kernel, rather than
before the build of the kernel starts.
Comments?
---------------------------------------------------------------------------
May 30 - June 05 (3 posts): Make world fails on latest 2.2.8...
The problem should have been solved by now. The cause was one of [Josef
Karthauser]'s; commits; which change was withdrawn by [Kris Kenneway].
Actually, Josef had not yet received the relevant letters (email problems);
he was going to analyze the whole matter in the next few days.
---------------------------------------------------------------------------
June 05 - June 05 (1 posts): FATAL FS Mount bug in -STABLE and -RELEASE
On June 5, 2000, [Troy Arie Cobb] reported that -STABLE and -RELEASE were
affected by a dangerous NFS bug:
I've found a fatal filesystem mount bug in both 4.0-STABLE and
4.0-RELEASE, tested on the 20000604 snapshot of 4.0.
With both the GENERIC kernel and a custom kernel, the system hangs
tight when more than about 256 filesystems are mounted. I've tested
this with loopback NFS mounts, remote NFS mounts, and local NULL
mounts. The machine freezes, responds to pings and changing of virtual
console, but accepts no input. No errors are written to /var/log or
console. A hard reset is the only way out, CTRL-ALT-DEL doesn't work.
The next day, he added that the bug did not concern 3.4-STABLE.
---------------------------------------------------------------------------
May 31 - May 31 (1 posts): Finally....A solution, It would appear
[Larry Rosenman] had found a number of errors while making the world in the
previous few days; on which errors he had reported in several other
threads. Eventually, the trouble turned out to be due to bad hardware.
After such an experience, it seems that his vendor is going to utilize
FreeBSD & "make world" in order to test hardware reliability ...
---------------------------------------------------------------------------
May 30 - May 31 (6 posts): -jn and -STABLE world
The question was asked whether the -jn option could be reliably employed to
make installworld. It seems that it is not the case.
---------------------------------------------------------------------------
May 29 - May 30 (9 posts): 4.0-stable, OpenSSH v1 & v2
[Kenneth W. Cochran] asked whether/when OpennSSH v2 would go into -STABLE,
and what exactly he should do in order to enable v2 and to turn off v1.
[Kris Kennaway] answered that OpenSSH v2 would soon be integrated into
-STABLE; he also confirmed that the right way to disable OpenSSH v1 is to
uncomment the NO_OPENSSH line in /etc/make.conf; finally, he stated that
the corresponding port would disappear as soon as they ceased supporting
FreeBSD 3.x in ports.
---------------------------------------------------------------------------
* The present Conspectus expresses my strictly personal understanding of
what occurred on the FreeBSD-stable mailing list during the specified
week.
* I may have made errors and/or mistakes as well as typos. If you feel
that this is indeed the case, and/or that I have omitted some
significant thread or part of a thread, feel free to contact me via
email. Constructive criticism is more than welcome.
Salvo Bartolotta
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
