Date: Sat, 17 Jun 2000 14:07:41 +0100 From: Nik Clayton <nik@freebsd.org> To: stable@freebsd.org Subject: [Conspectus] -stable, week ending 5th June 2000 Message-ID: <20000617140741.A6749@catkin.nothing-going-on.org>
next in thread | raw e-mail | index | archive | help
[ 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 doc@FreeBSD.org -- 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]-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. --------------------------------------------------------------------------- * 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 majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000617140741.A6749>