article.xml (109543) | article.xml (109583) |
---|---|
1<!-- 2 FreeBSD errata document. Unlike some of the other RELNOTESng 3 files, this file should remain as a single SGML file, so that 4 the dollar FreeBSD dollar header has a meaningful modification 5 time. This file is all but useless without a datestamp on it, 6 so we'll take some extra care to make sure it has one. 7 8 (If we didn't do this, then the file with the datestamp might --- 22 unchanged lines hidden (view full) --- 31 &release.current; 32]]> 33 Errata</title> 34 35 <corpauthor> 36 The &os; Project 37 </corpauthor> 38 | 1<!-- 2 FreeBSD errata document. Unlike some of the other RELNOTESng 3 files, this file should remain as a single SGML file, so that 4 the dollar FreeBSD dollar header has a meaningful modification 5 time. This file is all but useless without a datestamp on it, 6 so we'll take some extra care to make sure it has one. 7 8 (If we didn't do this, then the file with the datestamp might --- 22 unchanged lines hidden (view full) --- 31 &release.current; 32]]> 33 Errata</title> 34 35 <corpauthor> 36 The &os; Project 37 </corpauthor> 38 |
39 <pubdate>$FreeBSD: head/release/doc/en_US.ISO8859-1/errata/article.sgml 109543 2003-01-19 23:32:07Z bmah $</pubdate> | 39 <pubdate>$FreeBSD: head/release/doc/en_US.ISO8859-1/errata/article.sgml 109583 2003-01-20 19:34:05Z chris $</pubdate> |
40 41 <copyright> 42 <year>2000</year> 43 <year>2001</year> 44 <year>2002</year> 45 <year>2003</year> 46 <holder role="mailto:doc@FreeBSD.org">The FreeBSD Documentation Project</holder> 47 </copyright> --- 63 unchanged lines hidden (view full) --- 111 112 <para>No active security advisories.</para> 113 114 </sect1> 115 116 <sect1 id="late-news"> 117 <title>Late-Breaking News</title> 118 | 40 41 <copyright> 42 <year>2000</year> 43 <year>2001</year> 44 <year>2002</year> 45 <year>2003</year> 46 <holder role="mailto:doc@FreeBSD.org">The FreeBSD Documentation Project</holder> 47 </copyright> --- 63 unchanged lines hidden (view full) --- 111 112 <para>No active security advisories.</para> 113 114 </sect1> 115 116 <sect1 id="late-news"> 117 <title>Late-Breaking News</title> 118 |
119 <bridgehead renderas="sect3">GEOM</bridgehead> 120 |
|
119 <para>The &man.geom.4;-based disk partitioning code in the kernel 120 will not allow an open partition to be overwritten. This 121 usually prevents the use of <command>disklabel -B</command> to 122 update the boot blocks on a disk because the 123 <literal>a</literal> partition overlaps the space where the boot 124 blocks are stored. A suggested workaround is to boot from an 125 alternate disk, a CDROM, or a fixit floppy.</para> 126 | 121 <para>The &man.geom.4;-based disk partitioning code in the kernel 122 will not allow an open partition to be overwritten. This 123 usually prevents the use of <command>disklabel -B</command> to 124 update the boot blocks on a disk because the 125 <literal>a</literal> partition overlaps the space where the boot 126 blocks are stored. A suggested workaround is to boot from an 127 alternate disk, a CDROM, or a fixit floppy.</para> 128 |
129 <bridgehead renderas="sect3">&man.dump.8;</bridgehead> 130 |
|
127 <para>When using disk media with sector sizes larger than 512 128 bytes (for instance, &man.gbde.4; encrypted disks), the 129 &man.dump.8; program fails to respect the larger sector size and 130 cannot dump the partition. One possible workaround is to copy 131 the entire file system in raw format and dump the copy. It is, 132 for instance, possible to dump a file system stored in a regular 133 file:</para> 134 135 <screen>&prompt.root; <userinput>dd if=/dev/ad0s1d.bde of=/junk/ad0.dd bs=1m</userinput> 136&prompt.root; <userinput>dump 0f - /junk/ad0.dd | ...</userinput></screen> 137 138 <para>A simpler workaround is to use &man.tar.1; or &man.cpio.1; 139 to make backup copies.</para> 140 | 131 <para>When using disk media with sector sizes larger than 512 132 bytes (for instance, &man.gbde.4; encrypted disks), the 133 &man.dump.8; program fails to respect the larger sector size and 134 cannot dump the partition. One possible workaround is to copy 135 the entire file system in raw format and dump the copy. It is, 136 for instance, possible to dump a file system stored in a regular 137 file:</para> 138 139 <screen>&prompt.root; <userinput>dd if=/dev/ad0s1d.bde of=/junk/ad0.dd bs=1m</userinput> 140&prompt.root; <userinput>dump 0f - /junk/ad0.dd | ...</userinput></screen> 141 142 <para>A simpler workaround is to use &man.tar.1; or &man.cpio.1; 143 to make backup copies.</para> 144 |
145 <bridgehead renderas="sect3">&man.mly.4;</bridgehead> 146 |
|
141 <para>Hangs have been reported during &os; 5.0 snapshot 142 installations when installing to &man.mly.4;-supported RAID 143 arrays, in hardware configurations that appear to work fine 144 under &os; 4.7-RELEASE.</para> 145 | 147 <para>Hangs have been reported during &os; 5.0 snapshot 148 installations when installing to &man.mly.4;-supported RAID 149 arrays, in hardware configurations that appear to work fine 150 under &os; 4.7-RELEASE.</para> 151 |
152 <bridgehead renderas="sect3">NETNCP/Netware File System 153 Support</bridgehead> 154 |
|
146 <para>NETNCP and nwfs appear to be as-yet unadapted for KSE, and 147 hence not working.</para> 148 | 155 <para>NETNCP and nwfs appear to be as-yet unadapted for KSE, and 156 hence not working.</para> 157 |
158 <bridgehead renderas="sect3">&man.iir.4; controller</bridgehead> 159 |
|
149 <para>During installation, the &man.iir.4; controller appears to 150 probe correctly, but finds no disk devices.</para> 151 | 160 <para>During installation, the &man.iir.4; controller appears to 161 probe correctly, but finds no disk devices.</para> 162 |
163 <bridgehead renderas="sect3">&man.truss.1; race condition</bridgehead> 164 |
|
152 <para>&man.truss.1; appears to contain a race condition during the 153 start-up of debugging, which can result in &man.truss.1; failing 154 to attach to the process before it exists. The symptom is that 155 &man.truss.1; reports that it cannot open the &man.procfs.5; 156 node supporting the process being debugged. A bug also appears 157 to exist wherein &man.truss.1; will hang if &man.execve.2; 158 returns <literal>ENOENT</literal> A further race appears to 159 exist in which &man.truss.1; will return <errorname>PIOCWAIT: 160 Input/output error</errorname> occasionally on startup. The fix 161 for this sufficiently changes process execution handling that it 162 has been deferred until after 5.0.</para> 163 | 165 <para>&man.truss.1; appears to contain a race condition during the 166 start-up of debugging, which can result in &man.truss.1; failing 167 to attach to the process before it exists. The symptom is that 168 &man.truss.1; reports that it cannot open the &man.procfs.5; 169 node supporting the process being debugged. A bug also appears 170 to exist wherein &man.truss.1; will hang if &man.execve.2; 171 returns <literal>ENOENT</literal> A further race appears to 172 exist in which &man.truss.1; will return <errorname>PIOCWAIT: 173 Input/output error</errorname> occasionally on startup. The fix 174 for this sufficiently changes process execution handling that it 175 has been deferred until after 5.0.</para> 176 |
177 <bridgehead renderas="sect3">Disk Partitioning in Installer</bridgehead> 178 |
|
164 <para>Some bugs have been reported in &man.sysinstall.8; disk 165 partitioning. One observed problem on the i386 is that 166 &man.sysinstall.8; cannot recalculate the free space left on a 167 disk after changing the type of an FDISK-type partition.</para> 168 | 179 <para>Some bugs have been reported in &man.sysinstall.8; disk 180 partitioning. One observed problem on the i386 is that 181 &man.sysinstall.8; cannot recalculate the free space left on a 182 disk after changing the type of an FDISK-type partition.</para> 183 |
184 <bridgehead renderas="sect3">Stale Documentation</bridgehead> 185 |
|
169 <para>In some case, documentation (such as the FAQ or Handbook) 170 has not been updated to take into account &os; &release.prev; 171 features. Examples of areas where documentation is still 172 needed include &man.gbde.8; and the new <quote>fast 173 IPsec</quote> implementation.</para> 174 | 186 <para>In some case, documentation (such as the FAQ or Handbook) 187 has not been updated to take into account &os; &release.prev; 188 features. Examples of areas where documentation is still 189 needed include &man.gbde.8; and the new <quote>fast 190 IPsec</quote> implementation.</para> 191 |
192 <bridgehead renderas="sect3">SMB File System</bridgehead> 193 |
|
175 <para>Attempting to unmount smbfs shares may fail with 176 <errorname>Device busy</errorname> errors even when the 177 mount-point is not really busy. A workaround is to keep trying 178 to unmount the share until it eventually succeeds. This bug has 179 been fixed in &release.current;.</para> 180 181 <para>Forcefully unmounting (<command>umount -f</command>) smbfs 182 shares may cause a kernel panic. This bug has been fixed in 183 &release.current;.</para> 184 | 194 <para>Attempting to unmount smbfs shares may fail with 195 <errorname>Device busy</errorname> errors even when the 196 mount-point is not really busy. A workaround is to keep trying 197 to unmount the share until it eventually succeeds. This bug has 198 been fixed in &release.current;.</para> 199 200 <para>Forcefully unmounting (<command>umount -f</command>) smbfs 201 shares may cause a kernel panic. This bug has been fixed in 202 &release.current;.</para> 203 |
204 <bridgehead renderas="sect3">&man.fstat.2;</bridgehead> 205 |
|
185 <para>When called on a connected socket file descriptor, 186 &man.fstat.2; is supposed to return the number of bytes 187 available to read in the <varname>st_size</varname> member of 188 <varname>struct stat</varname>. However, 189 <varname>st_size</varname> is always erroneously reported as 190 <literal>0</literal> on TCP sockets. This bug has been fixed in 191 &release.current;.</para> 192 | 206 <para>When called on a connected socket file descriptor, 207 &man.fstat.2; is supposed to return the number of bytes 208 available to read in the <varname>st_size</varname> member of 209 <varname>struct stat</varname>. However, 210 <varname>st_size</varname> is always erroneously reported as 211 <literal>0</literal> on TCP sockets. This bug has been fixed in 212 &release.current;.</para> 213 |
214 <bridgehead renderas="sect3">Kernel Event Queues</bridgehead> 215 |
|
193 <para>The &man.kqueue.2; <literal>EVFILT_READ</literal> filter 194 erroneously indicates that <literal>0</literal> bytes are 195 available to be read on TCP sockets, regardless of the number of 196 bytes that are actually available. The 197 <literal>NOTE_LOWAT</literal> flag for 198 <literal>EVFILT_READ</literal> is also broken on TCP sockets. 199 This bug has been fixed in &release.current;.</para> 200 | 216 <para>The &man.kqueue.2; <literal>EVFILT_READ</literal> filter 217 erroneously indicates that <literal>0</literal> bytes are 218 available to be read on TCP sockets, regardless of the number of 219 bytes that are actually available. The 220 <literal>NOTE_LOWAT</literal> flag for 221 <literal>EVFILT_READ</literal> is also broken on TCP sockets. 222 This bug has been fixed in &release.current;.</para> 223 |
224 <bridgehead renderas="sect3">POSIX Named Semaphores</bridgehead> 225 |
|
201 <para>&os; &release.prev; introduced support for POSIX named semaphores 202 but the implementation contains a critical bug that causes 203 &man.sem.open.3; to incorrectly handle the opening of the same 204 semaphore multiple times by the same process, and that causes 205 &man.sem.close.3; to crash calling programs. This bug has been 206 fixed in &release.current;.</para> 207 | 226 <para>&os; &release.prev; introduced support for POSIX named semaphores 227 but the implementation contains a critical bug that causes 228 &man.sem.open.3; to incorrectly handle the opening of the same 229 semaphore multiple times by the same process, and that causes 230 &man.sem.close.3; to crash calling programs. This bug has been 231 fixed in &release.current;.</para> 232 |
233 <bridgehead renderas="sect3"><filename>/dev/tty</filename> 234 Permissions</bridgehead> 235 |
|
208 <para>&os; &release.prev; has a minor bug in how the permissions of 209 <filename>/dev/tty</filename> are handled. This can be 210 triggered by logging in as a non-<username>root</username>, 211 non-<groupname>tty</groupname> group user, and using &man.su.1; 212 to switch to a second non-<username>root</username>, 213 non-<groupname>tty</groupname> group user. &man.ssh.1; will 214 fail because it cannot open <filename>/dev/tty</filename>. This 215 bug has been fixed in &release.current;.</para> 216 | 236 <para>&os; &release.prev; has a minor bug in how the permissions of 237 <filename>/dev/tty</filename> are handled. This can be 238 triggered by logging in as a non-<username>root</username>, 239 non-<groupname>tty</groupname> group user, and using &man.su.1; 240 to switch to a second non-<username>root</username>, 241 non-<groupname>tty</groupname> group user. &man.ssh.1; will 242 fail because it cannot open <filename>/dev/tty</filename>. This 243 bug has been fixed in &release.current;.</para> 244 |
245 <bridgehead renderas="sect3">&man.growfs.8;</bridgehead> 246 |
|
217 <para>&man.growfs.8; no longer works on &man.vinum.4; volumes (and 218 presumably, on &man.geom.4; entities) since these subsystems no 219 longer fake disklabels, but &man.growfs.8; insists on examining 220 a label.</para> 221 222 </sect1> 223</article> | 247 <para>&man.growfs.8; no longer works on &man.vinum.4; volumes (and 248 presumably, on &man.geom.4; entities) since these subsystems no 249 longer fake disklabels, but &man.growfs.8; insists on examining 250 a label.</para> 251 252 </sect1> 253</article> |