RC4 includes the SATA and DRM fixes, along with a few other panic-preventing bugfixes. If everything goes well we can release 4.9 on Monday. Please help download and test before it's too late ftp.freebsd.org/pub/FreeBSD/releases/i386/4.9-RC4 ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/ http://www.freebsd.org/releases/4.9R/qa.html Thanks! - Release Engineering Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 155 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20031024/d41d1968/attachment.bin
Matthias Andree
2003-Oct-24 17:50 UTC
Final 4.9-RC (i386) available now, please help test.
Murray Stokely <murray@freebsd.org> writes:> RC4 includes the SATA and DRM fixes, along with a few other > panic-preventing bugfixes. If everything goes well we can release 4.9 > on Monday.May not be release critical, but rather fine tuning: The install program does strange things, even in -S mode. A regular -c install operation flow is similar to: kill destination file open destination file with mode 0600 copy content close fchmod fchflags Problem: there is a short period where the program, when overwritten, is not executable ("permission denied"). One could think install -S (S for safe) would fix that, but it doesn't, strace: rename("/tmp/INS@02eI", "/tmp/x2") = 0 <- here the /tmp/x2 file is not accessible close(4) = 0 open("/tmp/x2", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 fchmod(4, 0755) = 0 fchflags(4, 0) = 0 I'd suggest the order be fchmod close rename open fchflags ... That way, the program installed will always be executable if the user tells FreeBSD to "install -S". -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95
At 12:21 PM -0700 2003/10/24, Murray Stokely wrote:>RC4 includes the SATA and DRM fixes, along with a few other >panic-preventing bugfixes. If everything goes well we can release 4.9 >on Monday. > >Please help download and test before it's too late > >ftp.freebsd.org/pub/FreeBSD/releases/i386/4.9-RC4 >ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/I burned the ISO, and just like RC1 and RC2, after installing and rebooting, F2 (which should boot disk2s2a, my FreeBSD /) just reboots the system instantly; PhoenixBIOS banner. F1 boots XP okay, and I can boot from the CD and load & boot the kernel, but even after setting disk2s2 Active in the fdisk tool & reinstalling BootEasy, FreeBSD doesn't boot correctly after the install completes. Chris Pepper -- Chris Pepper: <http://www.reppep.com/~pepper/> Rockefeller University: <http://www.rockefeller.edu/>
At 11:01 AM -0800 2003/10/26, Murray Stokely wrote:>Ok, please try this : > >http://www.freebsd.org/~murray/4.8-20030801-snap.iso.bz2This worked for me. Now I am very confused. I was looking through my notes, and saw that I saw different behavior doing serial vs. VGA installs, so I installed 4.9RC4 via the physical (VGA) console, and it came up correctly. I then installed 4.9RC4 twice via serial console ("boot -hD"), and it was fine both times. I've since installed 4.9RC2 via VGA and serial 10-12 times (playing with BootEasy & no boot manager, and various other options), and it's been okay each time. Unless someone can figure out what was (but is no longer) biting me from the description, there seems nothing further to do on this issue at present. I'll sum up the history in hopes someone will have a clue what was wrong (bug report is "i386/58580: After sysinstall, F2 fails; wrong device specified for /?". My posting <http://lists.freebsd.org/pipermail/freebsd-stable/2003-September/004048.html> said:>>Booting [kernel]... >>root device disk0s4a: invalid >> >> >> >> >>Type '?' for a list of commands ... > > lsdev showed my disk2 properly, and I was able to unload, set >currdev, and boot successfully. When I next rebooted, BootEasy >defaulted to F1 (DOS -- FreeBSD is F2). When I hit F2, FreeBSD >booted correctly (sending console output to the serial port). After >this, both F1 and F2 worked correctly.I reproduced this problem several times over a few days around September 30th. I can no longer reproduce the problem using the same CD-Rs. There's obviously a critical element I haven't identified, but I wonder if it's related to BIOS/BTX level disk names (I don't know much about the conventions). Booting 4.9RC4 off the hard disk, I now see (this works):>BTX loader 1.00 BTX version is 1.01 >Console: internal video/keyboard >BIOS drive A: is disk0 >BIOS drive C: is disk1>ok lsdev >cd @ 0xff5c >disk @ 0xef68 > disk0: BIOS drive A: > disk1: BIOS drive C: > disk1s1: FAT-32 > disk1s2a: FFS > disk1s2b: swap > disk1s2e: FFS > disk1s2f: FFS > disk1s2g: FFS >pxe @ 0xd6d8 >ok show >LINES=24 >console=comconsole >currdev=disk1s2a: >interpret=ok >kernel=/kernel >kernel_options>kernelname=/kernel >loaddev=disk1s2a: >prompt=${interpret}Booting 4.9RC4 from the CD-ROM, I now see (this also works):>BTX loader 1.00 BTX version is 1.01 >Console: internal video/keyboard >BIOS drive A: is disk0 >BIOS drive B: is disk1 >BIOS drive C: is disk1lsdev shows:>cd @ 0xff5c >disk @ 0xef68 > disk0: BIOS drive A: > disk0a: FFS > disk0c: FFS > disk1: BIOS drive B: > disk2: BIOS drive C: > disk2s1: FAT-32 > disk2s2a: FFS > disk2s2b: swap > disk2s2e: FFS > disk2s2f: FFS > disk2s2g: FFS >pxe @ 0xd6d8currdev & loaddev are both "disk0s4a:" (which doesn't show up in lsdev, FWIW). Here's what sysinstall sees:>Disk name: ad0 FDISK Partition Editor >DISK Geometry: 5169 cyls/240 heads/63 sectors = 78155280 sectors (38161MB) > >Offset Size(ST) End Name PType Desc Subtype Flags > > 0 63 62 - 6 unused 0 > 63 12579777 12579839 ad0s1 2 fat 11 > 12579840 65575440 78155279 ad0s2 3 freebsd 165 C > 78155280 10080 78165359 - 6 unused 0> FreeBSD Disklabel Editor > >Disk: ad0 Partition name: ad0s2 Free: 0 blocks (0MB) > >Part Mount Size Newfs Part Mount Size Newfs >---- ----- ---- ----- ---- ----- ---- ----- >ad0s1 /c 6142MB DOS >ad0s2a / 1024MB UFS Y >ad0s2b swap 1024MB SWAP >ad0s2e /var 1024MB UFS+S Y >ad0s2f /usr 6144MB UFS+S Y >ad0s2g /home 22803MB UFS+S NThanks for everyone's assistance, and sorry I can't provide further info at this time. Chris Pepper -- Chris Pepper: <http://www.reppep.com/~pepper/> Rockefeller University: <http://www.rockefeller.edu/>
>> > RC4 includes the SATA and DRM fixes, along with a few other > panic-preventing bugfixes. If everything goes well we can release 4.9 > on Monday. > > Please help download and test before it's too late >>I downloaded the ISO image and used it to do a local network install. The initial installation went ok, but several of the 110 or so ports that I typically build failed this time. Technically the ports may not be part of the FreeBSD 4.9-release, but since a specific set is included in the distribution these errors may be of some interest: 1) /usr/ports/audio/mpg123: Building with "make WITH_NAS=yes WITH_ICONV=yes" failed because some referenced iconv header file was not already installed. The workaround is to install iconv before mpg123. 2) /usr/ports/audio/xmp: Installation generates and error message about not finding an xmms configuration file. The workaround seems to be to install xmms before xmp. 3) /usr/ports/games/cgoban: The compilation of net.c generates error messages about conflicting declarations of `butRnet_create' and `butRnet_destroy'. I have not attempted to debug this error. I don't know of any workaround. Everything else seemed ok, including the ICH5 SATA controller in native mode. I don't claim to have worked the system very hard. Dan Strick strick@covad.net
On Mon, 27 Oct 2003 at 16:00:52 -0800, Kris Kennaway wrote:> > On Mon, Oct 27, 2003 at 12:23:32PM -0800, Dan Strick wrote: > > > > 1) /usr/ports/audio/mpg123: > > > > Building with "make WITH_NAS=yes WITH_ICONV=yes" failed > > because some referenced iconv header file was not already > > installed. The workaround is to install iconv before mpg123. > > > > 2) /usr/ports/audio/xmp: > > > > Installation generates and error message about not finding an > > xmms configuration file. The workaround seems to be to install > > xmms before xmp. > > Was this a clean installation? Dependency problems are usually caused > by having stale files lying around on the machine.Yes, this was a clean installation. (It was not an upgrade. The file systems were completely wiped by newfs commands and fresh contents were loaded from the 4.9-RC4 iso image.) Dan Strick strick@covad.net