Daemon News 199904 : A Floppy Disk and a Stiff Upper Lip

A Floppy Disk and a Stiff Upper Lip

Copyright © 1999 Sue Blake

Pssst! This month's column is not really about floppies. It's about the learning process, learning to learn, and dealing with the little frustrations that can turn a normally studious and successful newbie into a screaming pile of hopelessness that can't bear to look at itself in the morning.

Last time we started with the familiar, at least for those coming from other environments, using zip archives and mtools from the packages collection to transfer files to other types of systems on floppy disks. We used MS-DOS (FAT) filesystems but did not consider what is actually involved in formatting these diskettes.

This month we'll continue via the task of formatting a DOS floppy to show how the online documentation can be dredged for information, whether deliberately or out of desperation. You'll see your fearless columnist fall into the traps that we don't normally confess to, and bounce back smelling like a web page.

A bold beginning

The way to DOS-format a floppy with mtools is to put an "m" before the command as usual, giving

# mformat a:

That should work. If it does work, fine, end of story. The first time I tried that it came back with an error message that didn't even make sense, followed by a helpful hint that would make Sherlock chew the end off his pipe.

[Note: Some of the following might be related to the particular versions of mtools and/or FreeBSD I was using, but it helps to illustrate the kind of tangles that newbies can get into]

The sad thing about error messages and warnings is that they try their hardest to tell us what's going on, but sometimes we need to put in a fair bit of effort to work out what they're really trying to say. If you know a small child who is learning to talk, you will have noticed them using the words they know best, and applying them to anything they like with great conviction, leaving it to the adult familiars to work out the child's intention. Over time, parents become quite good at this, just as you will become good at interpreting error messages.

So what would you make of this one?

mformat: Non-removable media is not supported (You must tell the complete geometry of the disk, either in /etc/mtools or on the command line)

Non-removable media? Is that what it thinks the floppy disk is? Or is this what mtools says whenever it isn't real sure what sort of media it's dealing with? It goes on to suggest stating the geometry, so let's give that a go after consulting the man page (man mformat, info mformat, info mtools).

# mformat -t 80 -s 18 a:

Drats, still the same error message. OK, maybe there'll be some quick clues in that file it mentions, /etc/mtools, which is probably the mtools configuration file.

# more /etc/mtools
/etc/mtools: No such file or directory

Hmph! OK, that's it, I can't do this alone.

Don't give up yet!

At this point you might feel like writing to the support mailing list, or searching its archives, in case someone knows what's going on. Persevere just a little longer and something might come to light. This is where the best opportunities for learning can spring up. Ideally you get to learn what you need to finish the task, learning it exactly when you're in the mood to find out, you pick up a few other miscellaneous facts by osmosis along the way, find some words that make no sense at all but will look more familiar next time, and you notice where there's more interesting stuff to come back and look at later on.

It seems that there might be answers in a configuration file for mtools which should exist somewhere on the system. Configuration files often come with valuable information in the comments that is not found elsewhere or doesn't make as much sense anywhere else. If there is a config file for mtools on the system, there's three ways to find it:

Look in the obvious place
Use locate
Use find

Looking in the obvious place is the quickest, but when you're new to the system nothing is obvious. (Do try 'man hier' some time. It explains a lot.) Using find sounds like a good idea. The trouble with find is that it can do so much that its man page is long and hard for novices to follow, and to use it efficiently you need at least a vague idea of where to start looking. The best method would be to use locate. What's locate? Usually it's the quickest way to locate a file. Yes, there's a man page, but first a little background for anyone running a brand new *BSD system.

Get a head start with locate

Once each week (in the wee hours of Saturday on my system) a script called "weekly" is run automatically (cron takes care of this). You'll find it either as /etc/weekly or /etc/periodic/weekly. It is the periodic (weekly, daily, etc) scripts that generate the cryptic emails to root that you might have noticed appearing out of thin air around 2am after a flurry of disk activity.

Until you are familiar with what's going on, just hang on to these emails and watch for any changes that look more alarming than prior messages. When you get a chance, have a look at what the script is doing (you don't have to understand it completely to get the general idea) and see if you can relate that to the output that is mailed to root. Any commands in there will have man pages you can look at, unless the commands are part of the bourne shell (/bin/sh) script commands, in which case "man sh" will keep you discovering for many pleasant hours.

One of the weekly script's tasks is to update (or create) the locate database. The location of every file on the system is indexed so that later you can find files quickly even if you only know part of the filename. If you have never had your machine running right through a Friday night the locate database won't have been created yet. You can start your locate database manually (check the man pages) but you might as well just run the /etc/weekly or /etc/periodic/weekly script, which is likely to do some other useful tasks like create the "whatis database" for apropos(1) and do a bit of tidying up. Run this as root, of course.

Hunt, capture...

Now, back to the original problem. I predict that if I'm lucky there will be a file somewhere called mtools.config or mtools.conf or mtools.cf or... so let's try throwing the common part of those filenames at locate first, rather than just "mtools" which might give an enormous list to sift through.

# locate mtools.c
/usr/local/etc/mtools.conf

Success! There it is! This turns out to be a bigger find than I'd hoped for. Not only is the file full of comments and hints, it even gives instructions for the other way of formatting floppies without mtools. That's a learning bonus.

In my case, it turned out that my floppy drive was defined in the mtools configuration file as

drive a: file="/dev/rfd0"

but needed to be

drive a: file="/dev/rfd0" 1.44m

and after that mformat worked fine.

...and devour

Look what else is in the config file comments:

# Example: To prepare drive A: for use as a 1.44M floppy on FreeBSD:
#   [1] low level format with ......... fdformat /dev/rfd0.1440
#   [2] write a file system with ...... mkdosfs -f 1440 /dev/rfd0
#   [3] then use mcopy/mdir etc. in the usual way.
#
# The mformat command could also be used to build the DOS file system
# in place of mkdosfs.

Right, here's two commands that will have man pages. You don't need the man page if you've been shown exactly what to type, but if you're happy to do what you're told without asking why you'll stay clueless forever. Knowing what to type is valuable though. It will help to make sense of the man page.

fdformat(1) is pretty straightforward. The example above will do for most purposes, but the man page shows why the predigested commandline was given the way it was, and gives information about what else it could be asked to do in different situations later on. Any known bugs or limitations are documented here, and there's various bits of other information that you can pick up, including a plain English explanation of what's going on:

Note that fdformat does only perform low-level formatting.  In case you
wish to create a file system on the medium, see the commands newfs(8) for
an ufs file system, or mkdosfs(1) for an MS-DOS (FAT) file system.

So that's why formatting uses two commands! There's also a free hint about how to format a Unix flavoured floppy by using newfs(8) instead of mkdosfs(1).

It's a good idea to look at the SEE ALSO section of man pages for related commands. Reading about these often helps to understand the command you're primarily interested in, and sometimes it will lead you to a better way to achieve what you're aiming for. If you don't believe me, Have a look at what interesting stuff cat(1) and ls(1) will lead you to dip your toes into if you let them, and how cron(8) will save you from being the hundredth newbie to read the wrong man page if you examine its SEE ALSO section carefully.

OK, next step is to take a look at the man page for mkdosfs(1).

Besides the expected explanation of the basic workings and the options, this man page offers a few paragraphs describing the file system structure that I found interesting to read.

Then it reminds me that the volume label, which I usually ignore, will be written as 4.4BSD by default. Some of the systems that I send floppies to are likely to use the volume label to identify the diskette in some way. Oops, I've been less than helpful in the past, but in future I can use either mkdosfs or mtools to do a better job.

Under DIAGNOSTICS it talks about different kinds of exit status. I know that if I were to use mkdosfs in a script for some reason, I could pick up on this exit status so that the script would behave appropriately if anything ever went wrong.

Under SEE ALSO it lists fdformat(1) which we've seen is the first step, mount_msdos(8) for mounting the floppy after formatting (instead of just using mtools), and newfs(8) which we've already seen could be used to create a UFS filesystem instead.

There's a reminder under BUGS that mkdosfs can't handle media defects. Maybe that's why the ancient diskette I sent Robert which formatted fine here turned out to be damaged. Oops, I didn't read closely enough first time round. I'd better apologise to the postie.

Floppy freedom

Are you getting thoroughly sick of having to su to root before using a floppy disk? Have you wondered why everyone puts up with it, or suspected that there must be an easier way that nobody ever mentions? You're right, there is a much easier way, but if you're running mtools you would have read about it already in the config file when you installed the package. :-)

You could make the floppy drive accessible to all users, but that's not a very good idea, even for a home computer. A better plan is to make it accessible to a particular group. That group could be wheel, since you're probably already a member of that group and anyone else in that group is unlikely to be someone you wouldn't trust with a floppy disk. But I'd prefer to make a new group, called "floppy" for example, and add myself and some other on site users to that group. There is a section in mtools.conf explaining this, and it even gives you the commands to type in. You'll see a lot of words that are also the names of man pages, all of which have "SEE ALSO" sections, so this could become a new starting point for some more liberating discoveries based on what you already know and feel comfortable with. Here's more free lessons, easy and fun, from the best teacher in the world (you!), any time you want to dig them out.

But is this really learning?

Man pages are not ideal for learning from. They were only intended for reference. Books, online tutorials, classes, etc. are much better, but sometimes you need to just have a go at doing something right now that you haven't learned about yet. If you can survive on the minimum of background info, the man pages are always right there.

With a bit of other information, such as related man pages, configuration files, source code (even if you can't understand it all yet), other documentation (such as mtools's "info" documents or "Readme" files etc. that come with packages you install) you can end up delivering yourself an effective tutorial tailored exactly to your own needs, at zero cost, and without feeling that somebody is standing over you passing judgement.

I call this learning by discovery. Some people call it having problems. It all depends on your attitude, whether you're willing to exploit the situation for what you can get out of it, and knowing how far you can afford to explore before stopping and asking for help becomes the most sensible next step.

Learning by discovery does not mean typing commands you don't fully understand and making a mess of your system! That's called learning by negligence, and is not a real good idea. Oh yes, we all have pretty good memories for the details of disasters, but people who call this a learning technique are kidding themselves. If you've really been learning you'll know exactly what you're doing before typing anything, which is a lot safer than simply following someone else's meaningless command recipe.

Learn by discovery and the learning will stick much better than being told what to learn and when to learn it. You pick up the information exactly when your brain is primed to accept it, and all learning is based on what you already know so it sticks. Those two points are critical for fast, solid learning, and they are almost impossible to achieve in a classroom or a book. Tap into it and support it with deliberate study of the fundamental concepts, and you'll be streaking ahead. Besides, it's much more fun to learn as the information hunter, rather than as a helpless victim.

	A Floppy Disk and a Stiff Upper Lip Copyright © 1999 Sue Blake Pssst! This month's column is not really about floppies. It's about the learning process, learning to learn, and dealing with the little frustrations that can turn a normally studious and successful newbie into a screaming pile of hopelessness that can't bear to look at itself in the morning. Last time we started with the familiar, at least for those coming from other environments, using zip archives and mtools from the packages collection to transfer files to other types of systems on floppy disks. We used MS-DOS (FAT) filesystems but did not consider what is actually involved in formatting these diskettes. This month we'll continue via the task of formatting a DOS floppy to show how the online documentation can be dredged for information, whether deliberately or out of desperation. You'll see your fearless columnist fall into the traps that we don't normally confess to, and bounce back smelling like a web page. A bold beginning The way to DOS-format a floppy with mtools is to put an "m" before the command as usual, giving `#` `mformat a:` That should work. If it does work, fine, end of story. The first time I tried that it came back with an error message that didn't even make sense, followed by a helpful hint that would make Sherlock chew the end off his pipe. [Note: Some of the following might be related to the particular versions of mtools and/or FreeBSD I was using, but it helps to illustrate the kind of tangles that newbies can get into] The sad thing about error messages and warnings is that they try their hardest to tell us what's going on, but sometimes we need to put in a fair bit of effort to work out what they're really trying to say. If you know a small child who is learning to talk, you will have noticed them using the words they know best, and applying them to anything they like with great conviction, leaving it to the adult familiars to work out the child's intention. Over time, parents become quite good at this, just as you will become good at interpreting error messages. So what would you make of this one? `mformat: Non-removable media is not supported (You must tell the complete geometry of the disk, either in /etc/mtools or on the command line)` Non-removable media? Is that what it thinks the floppy disk is? Or is this what mtools says whenever it isn't real sure what sort of media it's dealing with? It goes on to suggest stating the geometry, so let's give that a go after consulting the man page (man mformat, info mformat, info mtools). `#` `mformat -t 80 -s 18 a:` Drats, still the same error message. OK, maybe there'll be some quick clues in that file it mentions, /etc/mtools, which is probably the mtools configuration file. `#` `more /etc/mtools` `/etc/mtools: No such file or directory` Hmph! OK, that's it, I can't do this alone. Don't give up yet! At this point you might feel like writing to the support mailing list, or searching its archives, in case someone knows what's going on. Persevere just a little longer and something might come to light. This is where the best opportunities for learning can spring up. Ideally you get to learn what you need to finish the task, learning it exactly when you're in the mood to find out, you pick up a few other miscellaneous facts by osmosis along the way, find some words that make no sense at all but will look more familiar next time, and you notice where there's more interesting stuff to come back and look at later on. It seems that there might be answers in a configuration file for mtools which should exist somewhere on the system. Configuration files often come with valuable information in the comments that is not found elsewhere or doesn't make as much sense anywhere else. If there is a config file for mtools on the system, there's three ways to find it: Look in the obvious place Use locate Use find Looking in the obvious place is the quickest, but when you're new to the system nothing is obvious. (Do try 'man hier' some time. It explains a lot.) Using find sounds like a good idea. The trouble with find is that it can do so much that its man page is long and hard for novices to follow, and to use it efficiently you need at least a vague idea of where to start looking. The best method would be to use locate. What's locate? Usually it's the quickest way to locate a file. Yes, there's a man page, but first a little background for anyone running a brand new *BSD system. Get a head start with locate Once each week (in the wee hours of Saturday on my system) a script called "weekly" is run automatically (cron takes care of this). You'll find it either as /etc/weekly or /etc/periodic/weekly. It is the periodic (weekly, daily, etc) scripts that generate the cryptic emails to root that you might have noticed appearing out of thin air around 2am after a flurry of disk activity. Until you are familiar with what's going on, just hang on to these emails and watch for any changes that look more alarming than prior messages. When you get a chance, have a look at what the script is doing (you don't have to understand it completely to get the general idea) and see if you can relate that to the output that is mailed to root. Any commands in there will have man pages you can look at, unless the commands are part of the bourne shell (/bin/sh) script commands, in which case "man sh" will keep you discovering for many pleasant hours. One of the weekly script's tasks is to update (or create) the locate database. The location of every file on the system is indexed so that later you can find files quickly even if you only know part of the filename. If you have never had your machine running right through a Friday night the locate database won't have been created yet. You can start your locate database manually (check the man pages) but you might as well just run the /etc/weekly or /etc/periodic/weekly script, which is likely to do some other useful tasks like create the "whatis database" for apropos(1) and do a bit of tidying up. Run this as root, of course. Hunt, capture... Now, back to the original problem. I predict that if I'm lucky there will be a file somewhere called mtools.config or mtools.conf or mtools.cf or... so let's try throwing the common part of those filenames at locate first, rather than just "mtools" which might give an enormous list to sift through. `#` `locate mtools.c` `/usr/local/etc/mtools.conf` Success! There it is! This turns out to be a bigger find than I'd hoped for. Not only is the file full of comments and hints, it even gives instructions for the other way of formatting floppies without mtools. That's a learning bonus. In my case, it turned out that my floppy drive was defined in the mtools configuration file as `drive a: file="/dev/rfd0"` but needed to be `drive a: file="/dev/rfd0" 1.44m` and after that mformat worked fine. ...and devour Look what else is in the config file comments: # Example: To prepare drive A: for use as a 1.44M floppy on FreeBSD: # [1] low level format with ......... fdformat /dev/rfd0.1440 # [2] write a file system with ...... mkdosfs -f 1440 /dev/rfd0 # [3] then use mcopy/mdir etc. in the usual way. # # The mformat command could also be used to build the DOS file system # in place of mkdosfs. Right, here's two commands that will have man pages. You don't need the man page if you've been shown exactly what to type, but if you're happy to do what you're told without asking why you'll stay clueless forever. Knowing what to type is valuable though. It will help to make sense of the man page. fdformat(1) is pretty straightforward. The example above will do for most purposes, but the man page shows why the predigested commandline was given the way it was, and gives information about what else it could be asked to do in different situations later on. Any known bugs or limitations are documented here, and there's various bits of other information that you can pick up, including a plain English explanation of what's going on: Note that fdformat does only perform low-level formatting. In case you wish to create a file system on the medium, see the commands newfs(8) for an ufs file system, or mkdosfs(1) for an MS-DOS (FAT) file system. So that's why formatting uses two commands! There's also a free hint about how to format a Unix flavoured floppy by using newfs(8) instead of mkdosfs(1). It's a good idea to look at the SEE ALSO section of man pages for related commands. Reading about these often helps to understand the command you're primarily interested in, and sometimes it will lead you to a better way to achieve what you're aiming for. If you don't believe me, Have a look at what interesting stuff cat(1) and ls(1) will lead you to dip your toes into if you let them, and how cron(8) will save you from being the hundredth newbie to read the wrong man page if you examine its SEE ALSO section carefully. OK, next step is to take a look at the man page for mkdosfs(1). Besides the expected explanation of the basic workings and the options, this man page offers a few paragraphs describing the file system structure that I found interesting to read. Then it reminds me that the volume label, which I usually ignore, will be written as 4.4BSD by default. Some of the systems that I send floppies to are likely to use the volume label to identify the diskette in some way. Oops, I've been less than helpful in the past, but in future I can use either mkdosfs or mtools to do a better job. Under DIAGNOSTICS it talks about different kinds of exit status. I know that if I were to use mkdosfs in a script for some reason, I could pick up on this exit status so that the script would behave appropriately if anything ever went wrong. Under SEE ALSO it lists fdformat(1) which we've seen is the first step, mount_msdos(8) for mounting the floppy after formatting (instead of just using mtools), and newfs(8) which we've already seen could be used to create a UFS filesystem instead. There's a reminder under BUGS that mkdosfs can't handle media defects. Maybe that's why the ancient diskette I sent Robert which formatted fine here turned out to be damaged. Oops, I didn't read closely enough first time round. I'd better apologise to the postie. Floppy freedom Are you getting thoroughly sick of having to su to root before using a floppy disk? Have you wondered why everyone puts up with it, or suspected that there must be an easier way that nobody ever mentions? You're right, there is a much easier way, but if you're running mtools you would have read about it already in the config file when you installed the package. :-) You could make the floppy drive accessible to all users, but that's not a very good idea, even for a home computer. A better plan is to make it accessible to a particular group. That group could be wheel, since you're probably already a member of that group and anyone else in that group is unlikely to be someone you wouldn't trust with a floppy disk. But I'd prefer to make a new group, called "floppy" for example, and add myself and some other on site users to that group. There is a section in mtools.conf explaining this, and it even gives you the commands to type in. You'll see a lot of words that are also the names of man pages, all of which have "SEE ALSO" sections, so this could become a new starting point for some more liberating discoveries based on what you already know and feel comfortable with. Here's more free lessons, easy and fun, from the best teacher in the world (you!), any time you want to dig them out. But is this really learning? Man pages are not ideal for learning from. They were only intended for reference. Books, online tutorials, classes, etc. are much better, but sometimes you need to just have a go at doing something right now that you haven't learned about yet. If you can survive on the minimum of background info, the man pages are always right there. With a bit of other information, such as related man pages, configuration files, source code (even if you can't understand it all yet), other documentation (such as mtools's "info" documents or "Readme" files etc. that come with packages you install) you can end up delivering yourself an effective tutorial tailored exactly to your own needs, at zero cost, and without feeling that somebody is standing over you passing judgement. I call this learning by discovery. Some people call it having problems. It all depends on your attitude, whether you're willing to exploit the situation for what you can get out of it, and knowing how far you can afford to explore before stopping and asking for help becomes the most sensible next step. Learning by discovery does not mean typing commands you don't fully understand and making a mess of your system! That's called learning by negligence, and is not a real good idea. Oh yes, we all have pretty good memories for the details of disasters, but people who call this a learning technique are kidding themselves. If you've really been learning you'll know exactly what you're doing before typing anything, which is a lot safer than simply following someone else's meaningless command recipe. Learn by discovery and the learning will stick much better than being told what to learn and when to learn it. You pick up the information exactly when your brain is primed to accept it, and all learning is based on what you already know so it sticks. Those two points are critical for fast, solid learning, and they are almost impossible to achieve in a classroom or a book. Tap into it and support it with deliberate study of the fundamental concepts, and you'll be streaking ahead. Besides, it's much more fun to learn as the information hunter, rather than as a helpless victim. Sue Blake, sue@welearn.com.au