Date: Thu, 24 Oct 2013 23:26:56 +0200 From: Polytropon <freebsd@edvax.de> To: <leeoliveshackelford@surewest.net> Cc: freebsd-questions@freebsd.org Subject: Re: click-click in floppy disk drive Message-ID: <20131024232656.4c6c36bb.freebsd@edvax.de> In-Reply-To: <20131024112256.DTF88722@ms5.mc.surewest.net> References: <20131024112256.DTF88722@ms5.mc.surewest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Oct 2013 11:22:56 -0700 (PDT), leeoliveshackelford@surewest.net wrote:
> As was suggested to me, I ran the lsof utility. It created a
> very long text file, which unfortunately, I was unable to
> interpret.
I would suggest to grep the output for something that is
in relation to the mountpoint the floppy drive is associated
to. A hint could be present in /etc/fstab. For example, if
the default mountpoint would be /mnt/floppy,
# lsof | grep "floppy"
would probably get rid of anything not related.
> I ran the "mount -v" command. It did not indicate that a
> floppy drive was mounted.
This is good. So one of the assumptions ("something is still
expecting a floppy disk in the drive because there's an umount
pending") could be removed.
> I inserted a diskette into the drive, and mounted it. The
> mount was successful. The clicking continued, but each
> click was then followed by rotation of the diskette.
That is to be expected: The drive seems to perform a real I/O
operation on the media (instead of just querying _if_ a floppy
is inserted).
> I ran ls command on the floppy disk, which resulted in a
> correct display of the directory. However, when I ran the
> umount command, the system responded that the device was
> busy, and therefore could not be unmounted.
Ha! You got the right direction. This is the point where you
repeat the
# lsof | grep "floppy"
command - of course adjusted to a grep pattern that somehow
matches the place where the floppy is mounted; "mount -v" will
tell you this, "df -h" also would.
> I ran the command "camcontrol devlist" followed by "camcontrol
> reset n:0:0". The floppy drive kept on clicking.
This shows that the clicking is not caused by some "hidden"
software mechanism (like the device driver), but instead is
probably caused by something like HAL, a program that keeps
polling the drive status. And after stopping and resetting
the drive, HAL will continue doing this, so the clicking
will continue.
> Polytropon's comment on Oct. 22 at 15:42 P.D.T. that I had
> in fact successfully installed the operating system is
> technically true. However, my idea of a fully functioning
> workstation includes the addition of applications that will
> allow me to get work done.
Yes, that's a common definition, but the task of the OS is
to help you getting things done, and if only by providing a
means of installing the "productivity software" you need. :-)
> I would like my system include the installation of X-windows,
> Gnome, and Open Office.
THe FreeBSD Handbook covers this in detail.
http://www.freebsd.org/doc/handbook/x11-wm.html
> My problems in this area are described in another thread,
> "Gnome green screen of death" on September 26 19:34 P.D.T.
Sadly I'm not familiar enough with that so I can't provide
more help, sorry.
> That installation effort was based on the incorrectly
> informed notion that if I entered the command "pkg_add gnome2"
> that the system would take care of loading and configuring
> all other packages on which gnome depends.
That should have been the case. Of course, a _configuration_
cannot be done this way because the binary packages installed
by pkg_add have been compiled with the default options. If
those are fine for you - no problem. If they are not, you
need to install from source, using the Ports Collection. A
command like
# cd /usr/ports/x11/gnome2
# make config-recursive
# make install clean
should do the right thing. Be aware of the fact that you will
have to make _lots_ of decisions. :-)
Also note the configuration details explained in the handbook,
as provided by the link above.
> After that fiasco, I uninstalled gnome, and have ever since
> been trying to install and then configure each underlying
> package in my idea of the order of dependency.
Such a task should never be required. It simply sounds wrong.
There are infrastructures and tools that take care of all that.
You might be interested in learning "portmaster" as a good tool
to deal with ports.
> All of my printers are Hewlett-Packard lasers. First, I
> installed cups. I was flummoxed because the instructions to
> configure cups requi
> r!
> e the use of a web browser, which I do not yet have.
You can always install a text web browser like lynx, links or
w3m, and then access http://localhost:631 (which I admit is
a quite stupid method of configuring a printer). But CUPS also
has tools like lpadmin to perform printer installations without
needing the trouble of a web interface.
Depending on what your printer "speaks", you maybe don't even
need CUPS for printing. HP laser printers are good buddies.
They usually speak PS or PCL. If they speak PS - the story
ends here, because PS is the default output of _all_ the
applications that print something; an entry to /etc/printcap
is sufficient to make the printer work. And for PCL, there's
gs (ghostscript) that translates PS to PCL without trouble,
and a custom printer filter is quickly done.
Here's some relevant documentation about printing:
http://www.freebsd.org/doc/handbook/printing.html
http://www.wonkity.com/~wblock/docs/html/lpdprinting.html
> Then I installed hplip, which I could not configure because
> cups was not configured.
I have to be honest and admit: I never fully understood the
"logic" of all the different printer spoolers, filters, trans-
lators and driver collections. There's also foomatic, gimp-print,
hpijs, of course CUPS, then apsfilter, gs, zjs, and probably
many more. If you have a printer capable of PS, _use that_ and
get rid of all that overcomplicated stuff. :-)
> Subsequently, I have been trying to install xorg. It does
> not work because I have two video drivers, but only one
> monitor.
No problem. I have one graphics card, but two monitors. :-)
Getting X installed is easy. It should automatically get the
correct card (the one with the monitor attached) and initialize
that. If it really doesn't, you can always create a xorg.conf
file and explicitely tell X which card and monitor to use.
Again, this might help you:
http://www.wonkity.com/~wblock/docs/html/aei.html
This article especially discusses the troubles with HAL which,
regarding your clicking floppy problem, would something you
probably are interested in getting rid of. I'm running a HAL-free
system for many years and never missed any significant feature.
Additionally, centralized means of configuration, such as the
mentioned /etc/X11/xorg.conf, work _again_ as intended.
If you are interested in a system that comes with a preinstalled
and preconfigured (!) X environment, have a look at PC-BSD. If
I remember correctly, they offer KDE instead of Gnome, but if
this isn't a problem for you, give it a try. It also has packages
for OpenOffice / LibreOffice and many other things.
You can find it here:
http://www.pcbsd.org/
> I have found in the archives several questions about this state
> of affairs, but the responses were too general for me to follow,
> that is, to implement the instructions given would require skill
> and experience that I do not yet have to be able to fill in all
> of the little details that were missing but assumed to be
> understood.
If you stick to the handbook and try to follow the instructions
as near as you can, and _still_ encounter problems, the mailing
list is the correct place to ask questions. Please keep in mind
that only few members own a crystal ball and magic wand, so try
to provide:
1. the source you've been following
2. the command you've tried
3. their results
This will encourage people to provide more help, _precise_ help.
> Returning to the floppy disk drive, when I ran "camcontrol stop
> n:0:0", the system responded by erasing the command, and moving
> the cursor leftward to the prompt.
That is _really_ strange! The expected behaviour should be like
this:
# camcontrol reset 0,0,0
Reset of bus 0 was successful
# _
In case an error occured, an error message will be printed. Also
have a look at VT #0 (Alt+PF1) if any suspicious kernel messages
(bright white) are printed.
> It is possible that the system redisplayed the list of parameters
> to this command, and then redisplayed the prompt, and that by
> chance the new prompt was at the exact location of the old prompt.
That doesn't sound right.
> It is also possible that I did not see the screen re-write due to
> the behavior of the graphics accelerator, even though the screen
> is written in character mode.
The text mode should not be plagued with graphics card problems
as it might happen in X.
> As I was falling asleep the other night, I remembered that the
> problem with the floppy drive began after I had modified the
> file /etc/rc.conf. The instructions for installation of xorg
> say to add the following two lines to this file: "hald_enable="YES",
> and "dbus_enable="YES". The clicking begins as soon as the
> login prompt appears.
And _here_ you have the cause of your trouble: HAL. It keeps
polling the drive status. There is a configuration file for
that, but I can't remember it anymore; as I said, I don't use
HAL for anything, so I got rid of it.
The HAL FAQ mentions the problem and a solution:
http://www.freebsd.org/gnome/docs/halfaq.html
If I remember correctly, there's another one, maybe easier:
HAL does _not_ access devices that have an entry in /etc/fstab.
For example, if you have an entry for your DVD drive in that
file, HAL won't work with it. Likewise, if you could _add_ an
entry for the floppy drive, maybe that prevents HAL from clicking
the drive?
It would be something like this:
/dev/da3 /media/floppy msdosfs rw,noauto,noatime 0 0
You need to adjust this according to your actual device name and
designated mountpoint.
> The last several lines that are written to the screen preceding
> the login prompt are as follows:
>
> [...]
> Starting hald.
> Starting dbus.
Those two prove my assumption. :-)
> After logging-in as toor, I entered the following commands.
> The comments describe the result.
>
> service hald stop [enter]
> # The clicking stops.
> service hald start [enter]
> # The clicking resumes.
> service dbus stop [enter]
> # The clicking stops.
> service dbus start [enter]
> # The floppy disk drive remains silent.
You can derive that HAL is a very strange piece of software. :-)
> Based on this discovery, I realize that my problem could be
> sidestepped by writing a login script that stops, and then
> restarts dbus, but I wish I could have a little clearer
> understanding of what is going on here.
I'd suggest removing the floppy disk drive from the list of
devices to poll. Simple solution. Period.
> Also, at this point in time, I have no training in writing sh
> or bash scripts.
That's not required for this particular task, but it doesn't do
you any harm by acquiring basic interaction and scripting skills.
Keep in mind that FreeBSD's default dialog shell is tcsh (C shell).
Of course you can always install bash and make that your shell.
> What are hald and dbus supposed to do?
Oh, that's a very good question. :-)
HAL is a "hardware abstraction layer", an invention from Linux-land,
that has, if I remember correctly, already been deprecated "over
there". It aims to remove certain "hardware-related" access methods
in favour of an uniform abstracted method. It's goal is to allow
vertain GUIs to do what they can already to for decades: Notify
the user about new media being present and cause certain actions
(open file manager, burning utility, or whatever is "in fashion"
at the moment).
DBUS is related to "inter-application" communication and employed
in the mentioned goal.
> Are they being started with incorrect parameters?
No. They are started with _default_ parameters which might not be
suitable for your actual setting. One of those configurational
aspects includes to poll existing devices continuously to determine
when a medium is present.
> Are they being started in an incorrect order relative to other
> daemons that are started by the system?
No. The system makes sure things are started in the correct order.
Keywords in the start scripts provide that information, and
rcorder (see "man rcorder" for details) makes sure the correct
order will be used.
> There was no change in behavior when I interchanged the order
> of hald_enable and dbus_enable in the /etc/rc.conf file.
The order of statements does not matter. The rc.conf file is
just a (partial) shell script that is being sourced by other
files. It just contains variables that are assigned a value.
Thing of it as an "include file" that holds all those settings.
Note: "Last value wins", so if you have, for example,
hal_enable="YES"
and several lines later on
hal_enable="NO"
then "NO" will be the final value that's being used.
> In which order are /etc/rc.conf, /etc/defaults/rc.conf, and
> other possible startup files executed?
The default settings are loaded first. They only consider the OS.
Then rc.conf is sourced, and it "overwrites" any settings from
defaults/rc.conf that have a new definition. Finally rc.conf.local
is sourced (not often used, but I wanted to mention it anyway).
As I said, "last value wins".
The /etc/defaults/rc.conf file does _not_ contain settings for
3rd party software, such as HAL or DBUS. It only configures the
defaults for the operating system.
> Which file contains the instruction to write the login prompt?
It's configured in /etc/gettytab, the "default" entry, and more
specifically, the im= attribute.
There are other files to "enhance" things here, for example /etc/motd
and /etc/issue, or even /etc/rc (you can, but _should not_ add
things here).
> As before, any and all comments are most appreciated.
You found the solution to your problem. Now it's time to find out
how to _implement_ it properly. :-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131024232656.4c6c36bb.freebsd>