This is an update of an article originally written for Minix 1.7 in 1996. Everything I wrote then still holds true if you are trying to write to raw floppy disks to make a Minix boot disk or to transfer large files to a Minix system. In fact, now (2005) the problem has become even worse, because floppy disks are less commonly used. This has two side effects: first everyone who has had a computer for a while has a stock of old floppy disks to recycle and thus is loathe to spend good money to buy high quality new disks. Second, because people use floppy drives less often, the drive itself is likely to have problems. On many systems the slot where you insert a floppy disk is also one of the main places where the cooling fan sucks in air from the outside, and a drive that has not been used for a long time can have a surprising amount of dirt inside, ready to be wiped off on, and thus to damage, the first disk inserted.
So, to the advice below I would add these points:
Finally, if you have difficulties with floppy disks or if you have a system that has no floppy disk drive available consider using a different installation method. These days most systems have CD-ROM drives and are networked; these are two ways data can be introduced into a computer without using floppy disks. Minix 32-bit versions 2.0.3 and later come with the mtools utility which can transfer files from large Windows FAT partitions to a Minix partition, without the limitations of the old dosread program. And there are ways to start a Minix installation without booting from a floppy: at least one bootable Minix CD-ROM to RAM disk scheme is available, and the DOSMinix method allows you to run Minix using a Windows FAT file as a simulated disk. Both of these methods can be used as staging points for a standard Minix installation on a dedicated hard disk partition.
Here is the original version of this page:
On 17 Jan 1996 15:13:36 GMT James Skerritt (email@example.com) wrote in comp.os.minix: : I have minix installed OK, except that the USR.0? disks aren't all : installed, I've only got it to install up to USR.02 the other disks : haven't been used. any ideas? You are probably having a problem with the vol command. I think it will be helpful if I answer the question: How does vol work? A: Vol in write mode accepts a stream of data and writes it to a device, pausing after every n blocks to prompt for insertion of a new disk. In read mode vol generates a stream of data from a series of disks. There is no file system on disks used by vol, and the disks are not mounted; if a file system exists all the file system structures will be overwritten with data. Thus vol can be used to transfer files between operating systems, as long as both operating systems can read raw disk sectors in the same format. But none of the normal file system mechanisms to prevent use of bad sectors are available. Vol cannot detect the end of a file or any errors within a file. In write mode vol will terminate when the process preceding it in the pipeline terminates. In read mode vol receives a SIGPIPE signal when the pipe it is writing to no longer has a process reading from it. In the ftp distribution of Minix 1.7 the USR.* and SRC.* disks contain pieces of a big file -- you can think of it as USR.tar.Z or SRC.tar.Z, although it never appears as a named file. In installing Minix this stream of data is read, decompressed, and then extracted into directories and files by the vol | zcat | tar pipeline. If vol stops asking for disks before you get to the last one it usually means that the data is corrupt and zcat or tar reacted as if the end of the file had been reached. In this case tar is the only program in the pipeline that can actually detect errors in the file, so the zcat | tar pipe will break first when tar terminates, causing zcat to terminate and the vol | zcat pipe to break. The problem is most likely on the last disk accepted, but it is possible it could have been the next-to last one -- sometimes the pipeline will not detect the end of the data before you are asked for one more disk. It can also happen normally that vol in read mode will ask for one more disk than was actually written originally. Just any old disk, including the one previously read, will do in this case. Since vol does a raw write of data to a disk with no file system there are no file system mechanisms to lock out bad sectors. (If you have formatted disks under MS-DOS you have noticed sometimes you get a message saying there are bad sectors, but the disk is still usable. Minix has a mechanism, the badblocks command, to lock out bad sectors on a Minix file system.) With vol you must use perfect disks. If you are not absolutely sure of your disks you should either check them (use readall under Minix) or reformat them with a format program that verifies all sectors are good (format -v under Minix), before you use vol (or any other program that writes raw data to a disk) to write disks to be read by vol. -- Albert S. Woodhull Hampshire College, Amherst, MA firstname.lastname@example.org
|[HOME]||[HINTS/FAQ]||[MINIX DOWNLOADS]||[CONTRIB SOFTWARE]|