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 [EMAIL PROTECTED] -- 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][EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
