Date: Mon, 3 Jul 2000 14:14:40 +0100 From: Josef Karthauser <joe@pavilion.net> To: Nik Clayton <nik@FreeBSD.ORG> Cc: stable@FreeBSD.ORG Subject: Re: [Conspectus] -stable, week ending 5th June 2000 Message-ID: <20000703141440.H29903@pavilion.net> In-Reply-To: <20000617140741.A6749@catkin.nothing-going-on.org>; from nik@FreeBSD.ORG on Sat, Jun 17, 2000 at 02:07:41PM %2B0100 References: <20000617140741.A6749@catkin.nothing-going-on.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Are we going to see any more of these Nik? Joe ;) On Sat, Jun 17, 2000 at 02:07:41PM +0100, Nik Clayton wrote: > [ 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 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?20000703141440.H29903>