os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Conspectus for w/e 5th June

Browse source
This commit is contained in:
Nik Clayton 2000-06-17 13:13:11 +00:00
parent c4e8cdc0d9
commit cd5e4f7a27
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=7396
2 changed files with 577 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

568
en/conspectus/stable/2000/06/05.sgml Normal file
View file

@ -0,0 +1,568 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
<!ENTITY title "FreeBSD-stable Conspectus, week ending 5th June 2000">
<!ENTITY date "$FreeBSD$">
<!ENTITY % includes SYSTEM "../../../../includes.sgml"> %includes;]>
<html>
&header;
<table cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="left">Dates</th>
<th align="center"># Posts</th>
<th align="left">Subject</th>
</tr>
<tr>
<td valign="top">May 31 - June 01</td>
<td valign="top" align="center">3</td>
<td valign="top"><a href="#1">3.5 Release date</a>
</td>
</tr>
<tr>
<td valign="top">May 30 - May 30</td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#2">Announce: -stable
commit lists</a></td>
</tr>
<tr>
<td valign="top">June 01 - June 01</td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#3">HEADS UP: Data
corruption bug in Vinum found and fixed</a></td>
</tr>
<tr>
<td valign="top">June 01 - June 01</td>
<td valign="top" align="center">2</td>
<td valign="top"><a href="#4">smbfs for FreeBSD 3.4</a></td>
</tr>
<tr>
<td valign="top">June 03 - June 05</td>
<td valign="top" align="center">5</td>
<td valign="top"><a href="#5">PCCARD support</a></td>
</tr>
<tr>
<td valign="top">June 04 - June 05 </td>
<td valign="top" align="center">2</td>
<td valign="top"><a href="#6">3dfx driver</a>
</td>
</tr>
<tr>
<td valign="top">June 02 - June 04</td>
<td valign="top" align="center">5</td>
<td valign="top"><a href="#7">3.4-STABLE -> 4.0-RELEASE
upgrade: unable to mount root partition</a></td>
</tr>
<tr>
<td valign="top">June 02 - June 02</td>
<td valign="top" align="center">2</td>
<td valign="top"><a href="#8">Reboots on Alpha
System running 4.0 Stable</a></td>
</tr>
<tr>
<td valign="top">June 05 - June 05</td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#9">Spontaneous reboot with STABLE
SMP kernel</a></td>
</tr>
<tr>
<td valign="top">May 30 - June 01</td>
<td valign="top" align="center">18</td>
<td valign="top"><a href="#10">GENERIC 4.0 kernel compile
fails on in_cksum.c</a></td>
</tr>
<tr>
<td valign="top">May 30 - June 05</td>
<td valign="top" align="center">3</td>
<td valign="top"><a href="#11">Make world fails on latest
2.2.8... </a></td>
</tr>
<tr>
<td valign="top">June 05- June 05</td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#12">FATAL FS Mount bug in
-STABLE and -RELEASE</a></td>
</tr>
<tr>
<td valign="top">May 31 - May 31 </td>
<td valign="top" align="center">1</td>
<td valign="top"><a href="#13">Finally....A solution, It
would appear</a></td>
</tr>
<tr>
<td valign="top">May 30 - May 31</td>
<td valign="top" align="center">6</td>
<td valign="top"><a href="#14">-jn and -STABLE world</a></td>
</tr>
<tr>
<td valign="top">May 29 - May 30</td>
<td valign="top" align="center">9</td>
<td valign="top"><a href="#15">4.0-stable, OpenSSH v1 & v2</a>
</td>
</tr>
</tbody>
</table>
<!-- 1 -->
<hr noshade>
<h3><a name="1"></a>May 31 - June 01 (3 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=424506+0+archive/2000/freebsd-stable/20000604.freebsd-stable">3.5 Release date</a></h3>
<p>On May 31, 2000, <a href="mailto:jkh@zippy.cdrom.com">[Jordan
K. Hubbard]</a> announced to the -stable community a possible
date for the release of FreeBSD-3.5: <b>June 20.</b></p>
<p>On the same day, <a href="mailto:jim@thehousleys.net">[James
Housley]</a> reminded the -stable forum that CTM did not still work as
it should:</p>
<blockquote>
<p><i>I have a PR that I think should be resolved before the release:
<a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18058">http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18058</a></i></p>
<p><i>Description:</i></p>
<p><i>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.</i></p>
</blockquote>
<p><a href="mailto:khera@kciLink.com">[Vivek Khera]</a>,
replying to Jordan's letter, remarked:</p>
<blockquote>
<p><i>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.</i></p>
<p><i>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.</i></p>
</blockquote>
<!-- 2 -->
<hr noshade>
<h3><a name="2"></a>May 30 - May 30 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=236089+0+archive/2000/freebsd-stable/20000604.freebsd-stable">Announce: -stable commit lists</a></h3>
<p>On May 30, 2000, <a href="mailto:dmiller@search.sparks.net">[David
Miller]</a> made this proclamation:</p>
<blockquote>
<p><i>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.</i></p>
<p><i>Anyone could use procmail to filter the list himself, but I
thought this was more convenient, especially for those not set up
with procmail.</i></p>
<p><i>To subscribe, send an email to
freebsd-stable-[3|4]-request@sparks.net. Digest versions are setup
as well.</i></p>
</blockquote>
<!-- 3 -->
<hr noshade>
<h3><a name="3"></a>June 01 - June 01 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=544758+0+archive/2000/freebsd-stable/20000604.freebsd-stable">HEADS UP: Data corruption bug in Vinum found and fixed</a></h3>
<p>On June 1, 2000, <a href="mailto:grog@lemis.com">[Greg Lehey]</a>
promulgated the following important result:</p>
<blockquote>
<p><i>I've just discovered (and fixed) a serious data
corruption bug in Vinum. Under certain circumstances,
serious data corruption can result:</i></p>
<p><i>1. You are using RAID-4 or RAID-5 plexes.<br>
2. One of these plexes (not the first plex in the system,
whether a RAID-[45] plex or not) develops parity problems.<br>
3. You correct these errors with the 'rebuildparity'
command.</i></p>
<p><i>Under these circumstances, the corrected blocks will probably be
written to the wrong subdisk. The original parity errors
will remain.</i></p>
<p><i>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.</i></p>
</blockquote>
<!-- 4 -->
<hr noshade>
<h3><a name="4"></a>June 01 - June 01 (2 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=543396+0+archive/2000/freebsd-stable/20000604.freebsd-stable">smbfs for FreeBSD 3.4</a></h3>
<p>On June 1, 2000, <a href="mailto:bp@.butya.kz">[Boris Popov]</a>
broadcast some good news:</p>
<blockquote>
<p><i>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).</i></p>
<p><i>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).</i></p>
</blockquote>
<p>The tarball is available at <a
href="ftp://ftp.butya.kz/pub/smbfs/smbfs.tar.gz">ftp://ftp.butya.kz/pub/smbfs/smbfs.tar.gz</a></p>
<!-- 5 -->
<hr noshade>
<h3><a name="5"></a>June 03 - June 05 (5 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=673073+0+archive/2000/freebsd-stable/20000604.freebsd-stable">PCCARD support</a></h3>
<p>On June 3, 2000, <a href="mailto:archie.@whistle.com">[Archie
Cobbs]</a> sent a new entry for pccard.conf (PreMax PE-200 Ethernet
card) as well as his woes in upgrading his laptop to -STABLE.</p>
<p><a href="mailto:imp@village.org">[Warner Losh]</a>
replied that he would add that entry to pccard.conf, and that
he would also document a few minor points; the next day
<a href="mailto:iwasaki@jp.FreeBSD.org">[Mitsuru Iwasaki]</a>
MFC'ed the relevant code -- as had been agreed -- but ahead
of schedule.</p>
<p>As an aside, Archie was able to solve all of his problems thanks
to the suggestions from the mailing lists.</p>
<!-- 6 -->
<hr noshade>
<h3><a name="6"></a>June 04 - June 05 (2 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3226+0+archive/2000/freebsd-stable/20000611.freebsd-stable">3dfx driver</a></h3>
<p>On June 4, 2000, <a href="mailto:cokane@one.net">[Coleman Kane]</a>
made this announcement:</p>
<blockquote>
<p><i>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?</i></p>
</blockquote>
<p>The software is found at <a
href="http://pohl.ececs.uc.edu/~cokane/">http://pohl.ececs.uc.edu/~cokane/</a>.</p>
<!-- 7 -->
<hr noshade>
<h3><a name="7"></a>June 02 - June 04 (5 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=549728+0+archive/2000/freebsd-stable/20000604.freebsd-stable">3.4-STABLE -> 4.0-RELEASE upgrade: unable to mount root partition</a></h3>
<p><a href="mailto:bharat@sinia.com">[Bharat Mediratta]</a> met
with some difficulties while trying to upgrade from 3.4-S
to 4.0-R. The cause turned out to be "bad 144".</p>
<p>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 <a href="mailto:dbabler@Rigel.orionsys.com">[David
Babler]</a>'s indications, came to the following conclusions:</p>
<blockquote>
<p><i>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:</i></p>
<pre>wd0: bad sector table not supported
wd0s1: bad sector table not supported</pre>
<p><i>So here are some common questions and answers:</i></p>
<p>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?</p>
<p>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:</p>
<pre># /dev/rwd0c:
type: ESDI
disk: wd0s1
label:
flags: badsect <--- NOTE!
bytes/sector: 512
sectors/track: 63</pre>
<p>Q: How do I remove bad144?</p>
<p>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.</p>
</blockquote>
<p>Bharat has also sent the following PR: <a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19010"><b>docs/19010:
bad144 obsoletion by 4.0 is undocumented; fix is
undocumented.</b></a></p>
<!-- 8 -->
<hr noshade>
<h3><a name="8"></a>June 02 - June 02 (2 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=633946+0+archive/2000/freebsd-stable/20000604.freebsd-stable">Reboots on Alpha System running 4.0 Stable</a></h3>
<p>After updating a Digital AlphaServer 400 4/233 from 4.0-R to
4.0-S, <a href="mailto:sparhawk@sparhawk.bc.ca">[Sparhawk]</a>
saw some reboots: fatal kernel trap, memory management
fault (trap entry=0x02). An opennap napster server had been
running on the machine.</p>
<p><a href="mailto:kdultzo@caffeine.gerp.org">[Kevin M. Dultzo]</a>
had the same experience on a PC164 500MHz running (underclocked)
at 466MHz</p>
<p>The problem is currently under investigation.</p>
<!-- 9 -->
<hr noshade>
<h3><a name="9"></a>June 05 - June 05 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=62057+0+archive/2000/freebsd-stable/20000611.freebsd-stable">Spontaneous reboot with STABLE SMP kernel</a></h3>
<p><a href="mailto:fritz.heinrichmeyer@fernuni-hagen.de">[Fritz
Heinrichmeyer]</a> encountered other <a
href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=211433+0+archive/2000/freebsd-stable/20000528.freebsd-stable">spontaneous reboots</a> on his SMP server. He promised that he would send a detailed PR as soon as he found the time.</p>
<!-- 10 -->
<hr noshade>
<h3><a name="10"></a>May 30 - June 01 (18 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=276640+0+archive/2000/freebsd-stable/20000604.freebsd-stable">GENERIC 4.0 kernel compile fails on in_cksum.c</a></h3>
<p><a href="mailto:bharat@sinia.com">[Bharat Meditatta]</a> 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.</p>
<p>He was advised to proceed in two steps -- 4.0-R, 4.0-S --
in order to avoid any potential problems. However,
<a href="mailto:imp@village.org">[Warner Losh]</a> 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 -- <a href="mailto:guido@mouse.gvr.org">[Guido van Rooij]</a>
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.</p>
<p>As is (should be) well-known, the UPDATING file to be considered
is the <b>new</b> one downloaded via e.g. cvsup.</p>
<p>Here is Warner's upgrading scheme outlined in his own words:</p>
<blockquote>
<pre>make buildworld
&lt;follow directions to build/install a kernel&gt;
cd /usr/src/sys/modules
make install
cd /usr/src/sbin/mknod
make install
&lt;follow rebuild disk /dev entries above&gt; [1]
reboot</pre>
<p><i>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.</i></p>
<p><i>Comments?</i></p>
</blockquote>
<!-- 11 -->
<hr noshade>
<h3><a name="11"></a>May 30 - June 05 (3 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=234161+0+archive/2000/freebsd-stable/20000604.freebsd-stable">Make world fails on latest 2.2.8...</a></h3>
<p>The problem should have been solved by now. The cause
was one of <a href="mailto:joe@pavilion.net">[Josef Karthauser]</a>'s;
commits; which change was withdrawn by <a
href="mailto:kris@FreeBSD.ORG">[Kris Kenneway]</a>.</p>
<p>Actually, Josef had not yet received the relevant letters (email
problems); he was going to analyze the whole matter in the
next few days.</p>
<!-- 12 -->
<hr noshade>
<h3><a name="12"></a>June 05 - June 05 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=88019+0+archive/2000/freebsd-stable/20000611.freebsd-stable">FATAL FS Mount bug in -STABLE and -RELEASE</a></h3>
<p>On June 5, 2000, <a href="mailto:tcobb@staff.circle.net">[Troy Arie
Cobb]</a> reported that -STABLE and -RELEASE were affected by a
dangerous NFS bug:</p>
<blockquote>
<p><i>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.</i></p>
<p><i>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.</i></p>
</blockquote>
<p>The next day, he added that the bug did not concern 3.4-STABLE.</p>
<!-- 13 -->
<hr noshade>
<h3><a name="13"></a>May 31 - May 31 (1 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=448130+0+archive/2000/freebsd-stable/20000604.freebsd-stable">Finally....A solution, It would appear</a></h3>
<p><a href="mailto:ler@lerctr.org">[Larry Rosenman]</a>
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.</p>
<p>After such an experience, it seems that his vendor is going to
utilize FreeBSD & "make world" in order to test hardware
reliability ...</p>
<!-- 14 -->
<hr noshade>
<h3><a name="14"></a>May 30 - May 31 (6 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=260048+0+archive/2000/freebsd-stable/20000604.freebsd-stable">-jn and -STABLE world</a></h3>
<p>The question was asked whether the -jn option could be reliably
employed to make installworld. It seems that it is not the case.</p>
<!-- 15 -->
<hr noshade>
<h3><a name="15"></a>May 29 - May 30 (9 posts): <a href="http://docs.freebsd.org/cgi/getmsg.cgi?fetch=168826+0+archive/2000/freebsd-stable/20000604.freebsd-stable">4.0-stable, OpenSSH v1 & v2</a></h3>
<p><a href="mailto:kwc@world.std.com">[Kenneth W. Cochran]</a>
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.</p>
<p><a href="mailto:kris@FreeBSD.ORG">[Kris Kennaway]</a>
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.</p>
<hr noshade>
<ul>
<li>
<p>The present Conspectus expresses my strictly personal
understanding of what occurred on the FreeBSD-stable mailing
list during the specified week.</p>
<li>
<p>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.</p>
</ul>
<p align="right"><a href="mailto:bartequi@neomedia.it">Salvo
Bartolotta</a></p>
&footer;
</body>
</html>
<!--
Local Variables:
mode: sgml
sgml-indent-data: t
sgml-omittag: nil
sgml-always-quote-attributes: t
End:
-->

9
en/conspectus/stable/2000/06/Makefile Normal file
View file

@ -0,0 +1,9 @@
# $FreeBSD: www/en/conspectus/stable/2000/05/Makefile,v 1.1 2000/05/31 20:35:47 nik Exp $
.if exists(../Makefile.conf)
.include "../Makefile.conf"
.endif
DOCS= 05.sgml
.include "../../../../web.mk"