diff --git a/en/conspectus/stable/2000/06/05.sgml b/en/conspectus/stable/2000/06/05.sgml index b73232f8fc..2909f02629 100644 --- a/en/conspectus/stable/2000/06/05.sgml +++ b/en/conspectus/stable/2000/06/05.sgml @@ -1,568 +1,569 @@ - + + %includes;]> &header;
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]-request@sparks.net. 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.

Salvo Bartolotta

&footer;