| 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 + | +
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.
+
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.
+
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.
+
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
+ + + +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.
+ + + +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/.
+ + + +[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.
+ + + +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.
+ + + +[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.
+ + + +[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?
+
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.
+ + + +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.
+ + + +[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 ...
+ + + +The question was asked whether the -jn option could be reliably + employed to make installworld. It seems that it is not the case.
+ + + +[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.
+