Date: Sat, 8 Apr 95 00:06 CDT From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: freebsd-bugs@FreeBSD.org Cc: uhclem@nemesis.lonestar.org Subject: Bugs in snap 032295 Message-ID: <m0rxSio-0004vsC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
Here are some problem reports on SNAP-032295: ------------------------------ FDIV001 SYSTEM INSTALL (While downloading rest of system) Date: 20-Feb-95 in SNAP-021095, but still occurs in 032295 Impact: Medium Problem: When you specify that you want to do your own FTP commands and have specified more than one distribution (bin, src, etc), FTP is invoked repeatedly to download each module separately, but nothing is displayed to indicate which module the install expects you to download now. I determined (the hard way) that it doesn't want them all downloaded at once when it came back from processing just bin and started FTP again, apparently wanting more files. But which? Even if I pretended they were there already, it would fail due to filename conflicts (see below). It is possible to guess what it wants, but if you download the wrong thing in the wrong order (I did this several times), it sometimes it does not catch the error and goes on its merry way with unknown results. Once I determined it was asking for stuff in the order that the checked boxes were listed, I wrote that order down and on the next install attempt I was able to supply things in the expected order. Suggestion: Before invoking FTP each time in this manual mode, display a prompt such as "Now download all files in the 'src' distribution" so the user will know exactly what to get. When wanting compat1x (as an example), the prompt would say: "Now download all files in the 'compat1x' distribution" etc. I also suggest putting a prefix of some sort on files with common names, such as CKSUMS (src.CKSUMS) so that it the user elects to keep the files around (you do offer that choice), the conflicting names won't render the downloaded files useless. Right now, the CKSUMS for bin are lost after downloading the next thing, and you never have the opportunity to make separate directories to put the different distributions in. That might be a better solution than changing the names: creating a %s/src, %s/bin, %s/compat1x, etc where %s is /usr/tmp or whatever the user specifies. ------------------------------ FDIV002 SYSTEM INSTALL (While downloading rest of system) Date: 20-Feb-95 in SNAP-021095, but still occurs in 032295 Impact: Medium Problem: When you specify that you want to do your own FTP commands and have specified more than one distribution (bin, src, etc), FTP is invoked repeatedly to download each module separately. After processing each module, it asks if you want to delete the files in /usr/tmp. If you answer this "yes", it apparently does a rm -rf /usr/tmp and when it moves on to load the next module, but /usr/tmp is now deleted and it cannot proceed. You get the message "No such file or directory for /usr/tmp, sorry! Please fix this and try" The rest of the message is cut off and the box and shading gets messed-up, probably because the message is too long. Of course, there is no way to fix this, since you can't get a shell, a ^Z causes the installation process to panic and reboot as does ^C. If there is a way to get to a shell to fix this, it isn't obvious. This did not happen in 2.0, and I suspect it has to do with the new ability to select multiple modules and something is not re-creating the directory if you answer the above question "yes". In this case, the test system was tight on disk space and could not afford to have the packed distribution hanging around. I was able to get around this on a tight disk space system by answering "No", and once in FTP, get a shell and remove the files in /usr/tmp manually, then resume FTP and download the next batch of files. But this is clumsy, and would not have been possible until after the "bin" distribution was loaded. Solution: Verify that /usr/tmp either does not get deleted or make sure it gets recreated with the same permissions after each module is downloaded. It is possible to guess what it wants, but if you download the wrong thing (I did this several times), it sometimes it does not catch the error and goes on its merry way with unknown results. Once I determined it was asking for stuff in the order the checked boxes were listed, I wrote that order down and was able to supply things in the expected order. ------------------------------ FDIV003 SYSTEM INSTALL (While downloading rest of system) Date: 20-Feb-95 in SNAP-021095, but still occurs in 032295 Impact: Medium Problem: When you specify that you want to do your own FTP commands and have specified more than one distribution (bin, src, etc), FTP is invoked repeatedly to download each module separately. You are offered a chance to specify a directory other than /usr/tmp. I attempted to specify /usr/src/tmp, so that the files would be placed on a different partition with more space. This failed with errors, including "no such file or directory". Note: This may be related to FDIV002, so investigate that problem first. Either the install procedure failed to create the directory before trying to use it, or it was created and then later accidentally deleted by the install procedure. ------------------------------ FDIV004 SYSTEM INSTALL (While downloading rest of system) Date: 20-Feb-95 in SNAP-021095, but still occurs in 032295 Impact: Medium Problem: When you specify that you want to do your own FTP commands if you abort a mget or other FTP operation with interrupt (Control-C), FTP does not receive the interrupt, but the install shell/program does, that pops up partially on the screen with "Installation Aborted", but FTP is still running, asking questions. In my case, I forgot to turn PROMPTing off before I started a mget, and did a Control-C to start the process over. I was expecting a "Continue with mget?" prompt to answer "no" to, but instead FTP never got the Control-C signal as it had been intercepted upstairs somewhere. Suggestion: When letting the user do his own FTP commands, allow all signals to pass to FTP, and do not abort or otherwise respond to the interrupt signal while FTP is running. ------------------------------ FDIV005 appears fixed in SNAP-032295 FDIV006 appears fixed in SNAP-032295 ------------------------------ FDIV007 Non-RAW serial I/O. Date: SNAP-032295 Impact: Medium (Emotionally it should be HIGH - made me consider switching to Linux!) Problem: The backspace character/key situation is nuts in this release. During installation, neither BACKSPACE nor DELETE produces an ERASE operation. As soon as you touch a shell the BACKSPACE key now produces 0x7f, not 0x08. This makes connecting to other systems via telnet or cu a major hassle since most accept BACKSPACE as 0x08 and some accept it as 0x7f. Locally, even if you stty erase ^?, vi still only accepts the BACKSPACE key as a ERASE operation in Insert mode. The BACKSPACE key no longer can be used for cursor motion, something that has worked for over a decade. CTRL-BACKSPACE produces 0x08 which is accepted a cursor motion, but this is a poor substitute. Other editing tools (like prompts in tin) have the same dual-personality problem that they did not have before. Suggestion: PLEASE make BACKSPACE produce an 0x08! In the drawn-out religious war some weeks ago, I thought this was the outcome. Or are we deliberately trying to be incompatible with the other operating systems that run on PCs where BACKSPACE==0x08 and make it difficult to TELNET/CU to NON-FREEBSD systems? I can't fix every program and system that this broke! ------------------------------ FDIV008 SYSTEM INSTALL (While downloading rest of system) Date: SNAP-032295 Impact: Medium Problem: During installation, if you press CTRL-Z, the installation aborts, reports something about abnormal child termination and immediately reboots the system. Suggestion: This signal should either deliver a shell (when possible) or be trapped and ignored. ------------------------------ FDIV009 Normal operation Date: SNAP-032295 Impact: High Problem: SNAP-032295 is less stable than the previous SNAP. I get system lockups during kernel builds, ls -alR | more, even grep commnds. This same system ran SNAP-021095 for a month without problems. The system also ran 2.0 and 1.1.5.1 without problems. When I rebuild the kernel, typically three to six drivers get recompiled. During this process, the system will lockup an average of one time per build. I have had to restart the same build three times to make it all the way through, and then ten minutes later a recompile of the same files goes through without incident. The system is a 486DX-33 EISA system with one WD 528Meg IDE drive, OAK SVGA, SMC 8013 network adapter, Soundblaster 16 with two Matsushita CD-ROM drives. 8 Meg of RAM. The hard disk was completely wiped during multiple installations. I have removed and reseated RAM, processor all cards, and finally replaced all the RAM and the problem doesn't go away. I finally moved the hard disk to a similar system (almost identical configuration that has been running SNAP-021095 since it was available with no problems) and now the other system randomly lockups. I assume it is either a memory management problem or a problem with the wd disk driver. It will not lockup if the system isn't doing anything. It has to be crunching to cause the problem to show itself. In fact, I wrote this report by telneting from a SNAP-032295 system to a 1.1.5.1 system that was otherwise idle. While typing this note, cron ran /etc/daily and locked the system up. Nothing else was running and there are no other users. ------------------------------ FDIV010 Installation Date: SNAP-032295 Impact: High Problem: The boot block looks for a kernel named 386bsd (or 386bsd.old) rather than kernel*. At first I thought I had downloaded the wrong floppy images, but a second download of the files in SNAP-032295/floppies resulted in the same problems. SNAP-021095 did not have this problem and searched for "kernel". ------------------------------ FDIV011 Installation README Date: SNAP-032295 Impact: Medium Problem: The installation README says that the Creative CD-ROM cannot be used for installation, but this should be possible in SNAP-032295 and later. ------------------------------ FDIV012 Installation Kernel Date: SNAP-032295 Impact: High Problem: The kernel on the boot floppy does not have the matcd driver present. I have been told (but have not personally checked) that the fixit disk also doesn't have matcd. This should be fixed on at least the fixit disk so that files can be recovered from the distribution CD-ROM if needed. ------------------------------ FDIV013 Installation Date: SNAP-032295 Impact: Low Problem: When doing FTP download, it asks for the machines fully-qualified domain name. I typed: dalek.lonestar.org The next question asked what my domain name was, and it filled the box in with: dalek.lonestar.org| with the cursor on the right. Why didn't it at least delete the left-most field off the fully-qualified domain name and offer that as a prompt? ------------------------------ FDIV014 Installation Date: SNAP-032295 Impact: Medium Problem: When doing FTP download, it asks for the machines domain name, system name, IP number and other information prior to downloading modules. After downloads are complete, it offers to finish configuring TCP/IP settings. If you select this, it asks the same questions again and has discarded the answers from the previous questions. ------------------------------ FDIV015 Installation Date: SNAP-032295 Impact: Medium Problem: When doing FTP download, it asks for the machines domain name, system name, IP number and other information prior to downloading modules. After extracting modules you may also specify details of your domain, system name and IP information. When you reboot, your system name is still "myname.mydomain" instead of being set based on the information given during the installation. Suggestion: The hosts and sysconfig files should be updated with the information provided during the installation. ------------------------------ FDIV016 Installation Date: SNAP-032295 Impact: Medium Problem: When doing FTP download, if the connection fails as in 421 Service not available, remote server has close connection 98304 bytes received in 8.4e+02 seconds (0.11 kbytes/sec) Continue with mget? Or course you can't answer the question. If you press CTRL-C, you get: User interrupted Aborting installation and the system immediately reboots. Suggestion: There needs to be a way to restart an entire download if something goes wrong without having to restart the entire installation process. ------------------------------ FDIV017 fsck Date: SNAP-032295 Impact: Medium Problem: The first time FSCK runs after an installation and finds an unreferenced file or directory, it creates lost+found. This is OK. However, fsck then reports: LINK COUNT INCREASING (duh) UNEXPECTED INCONSISTENCY; RUN FSCK MANUALLY Suggestion: Fsck should consider the inode it used to create lost+found to not be an inconsistency. ------------------------------ FDIV018 installation /usr/include/sys Date: SNAP-032295 Impact: Medium Problem: Everybody knows this by now - /usr/include/sys ends up as a link to /usr/sys/sys which is a link to /usr/sys/sys. Make world cannot be done with the links like this and the contents of /usr/include/sys appear to be erased. If you correct this, "make world" will try to change it near the start of the make "world process" and wlll change it again a second time at the end of the "make world" process. Make sure you fix both attempts to scramble links in the "make world" process. ------------------------------ FDIV019 Boot -s Date: SNAP-032295 Impact: Medium Problem: When you tell the system to boot -s, it comes up and says: Enter pathname of shell or RETURN for sh: If you press RETURN, you get: erase *, kill ^U, intr ^C where * is a symbol that looks like a stick drawing of a house. This is yet-another symptom of erase not being set to ^H and the BACKSPACE key not generating ^H. ------------------------------ FDIV020 Clock management, installation, single & multi-user Date: SNAP-032295 Impact: Medium Problem: The installation procedure seems to be written assuming you are going to set the CMOS clock to GMT, which is the least likely time. This is because people who use the system for MS-DOS on other partitions must keep the clock correct to local time. If you elect to keep the CMOS at local time, the installation will offer you cities (not many in CST by the way), then show you a time with the CST suffix, WITH THE GMT OFFSET ADDED even if you don't want it. If then asks "Is this what you wanted?". The normal user isn't going to realize that all we are asking about at that point is the CST suffix and will answer the question NO because the time is wrong. The user has to answer that question yes and then select 98 (CMOS isn't GMT) later. This is pretty user-unfriendly and needs improvement or at least better instructions. Also note that if you have CMOS set to LOCAL, and boot the system in maint mode, the date shown is wrong (behind by several hours). If you change it to be correct, and then boot multi-user, the date is now ahead of where it should be by several hours. This is pretty confusing. ------------------------------ FDIV021 Weekly cron Date: SNAP-032295 Impact: Medium Problem: When weekly cron runs on a system that has everything except X11 installed, you get mail that says: weekly run output Rotating messages: cat: /var/run/syslog.pid: no such file or directory usage: kill [-l] [-sig] pid... Rotating cron log: /usr/X11R6/man/whatis.tmp no such file or directory ------------------------------ FDIV022 FTP Date: SNAP-032295 Impact: Low Problem: When FTP completes a transfer that runs faster the 99K/sec, it displays the results in scientific notation. Can't we fix this so that it doesn't switch to scientific notation that average people don't understand? ------------------------------ FDIV023 Boot Date: SNAP-032295 Impact: Medium Problem: From time to time during the normal boot process, it will hang immediately after the message: check for kernel -c changes After waiting a minute or so if you press CTRL-C, the system will proceed with: clearing /tmp and continue to boot. This may be related to booting a kernel named something other than /kernel, but it seemed more random than that. *END* Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi" or uhclem%nemesis@trsvax.ast.com (Internet)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!trsvax.fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0rxSio-0004vsC>