When I want to mount my fat32 filesystem on my primery slave hard drive I get the following message:

# mount /dev/hdb1 /mnt/fat32/
mount: /dev/hdb1 already mounted or /mnt/fat32/ busy

Of course I entered this command from a different directory than /mnt/fat32 so the directory shouldn't be busy. On the other hand this hard drive is not mounted at all to anywhere else. The /etc/fstab includes neither this partition. Or if I added the proper line for this partition into the /etc/fstab the drive was not mounted after boot-up.
The /mnt/fat32 is not mount point for any other partition or device so I don't try to mount my /dev/hdb1 partition to a previously mounted one.
If I check the partitions with fdisk the /dev/hdb1 seemes to be OK. I can even run fsck on /dev/hdb1 and it works fine.


I'm using debian unstable dist. with 2.6.5 kernel.

I also tried it with another vfat filesystem but I got the same error and the same result


Any suggestion?

Try running this:

# mount -t vfat /dev/hdb1 /mnt/fat32

Sometimes a program or one of your open shells will have a lock on a directory or file in the directory.

You can list all of the file locks with the command 'lsof'
So 'lsof' | grep '/mnt/fat32' | grep -v grep will list all locks on the /mnt/fat32 mountpoint.

I got the solution for my problem.

1. The mount -t vfat /dev/hdb1 /mnt/fat32 didn't work out.

2. Nor was the /mnt/fat32 locked (lsof and fuser showed that the partition and the mount point are not in use).


The final intuition: I had some strange errors when I booted:

"kernel: device-mapper: dm-linear: Device lookup failed
kernel: device-mapper: error adding target to table"

So after some seeking it turned out that completely removing the evms package solves the problem: no more error massage as above in kern.log and mounting can be done without sweat!


Thank you guys for helping me! Your suggestions helped me a lot!

I had the same error. When I had created my new /dev/sda entries, I had created all of them with the same Major and Minor number. Ooops. For those not familiar with /dev file properties, the disk nodes created with mknod must have the same Major number, but unique Minor numbers.

Another random fact:
Installing GRUB from a rescue disk with Grub version 0.97 will not work for a system with GRUB 0.93.

Well, the strange thing is that I thought that this is some type of "unstable" issue. It turned out that it is not. When I posted the original message "etch" was not released at all. However now I have "etch" installed on a server and I faced the exact same problem (i.e. could not mount other device) when evms happaned to be installed. Evms and evms-ncurses are installed usually automatically when I install ncurses packages for kernel compiling. So still the best workaround for this installing ncurses packages then apt-get --purge remove evms evms-ncurses. This fixed the problem even in the case of "etch".

Zahoo

The root cause of this problem is because of an orphaned dmraid array.

I just ran the following commands-
/etc/init.d/dmraid stop
dmraid -r -E


^^^
RUN THE ABOVE COMAMNDS ONLY IF YOU ARE NOT USING RAID AND YOU HDD IS PART OF AN OLD RAID ARRAY

Thanks the

dmraid -r -E
command was questionable to me as it sked to delete the pcb hda device and the nvidia device data

although, I had never used ether devices before hand I susspect that these were initialy installed. This is when I was playing aroung with my knoppix system settings for server controls and embeded systems using a PXE or DHCP server.

lol I just was reading up on how to manualy install these on a server, and I think I should stick with the step by step approach as I didnt se what was going on when suddenly by magic a nvidia controlled appeared as by magic in my fdisk -l and I suddenly no longer had access to my sdb hard scsi drive. lol

The first command worked for me however with the -stop switch

THANKS