|
|
Post by rustleg on Nov 6, 2011 14:35:09 GMT -5
I have a USB stick "ISISBACK" permanently mounted in my PC. When I start KNOS from another USB stick it succeeds to mount ISISBACK on bootup (although it gives an error message that it won't mount). I can use it to read and write files ok. When I try to unmount it doesn't with a message:
Cannot unmount volume. Details: Cannot open /media/.hal-mtab
Another thing, when I wrote the prefs to this USB stick the tar.gz file didn't show up in Gnome's Nautilus, but after trying to unmount it (and it failed to unmount), the file did show up! It will continue to accept files written to it.
The mount command shows this:
/dev/msdosfs/ISISBACK on /media/ISISBACK (msdosfs, local, nosuid)
If I force unmount it with
# umount -f /media/ISISBACK/
It unmounts then immediately remounts with name ISISBACK_
|
|
|
|
Post by Kevin McAleavey on Nov 6, 2011 17:31:06 GMT -5
I have a USB stick "ISISBACK" permanently mounted in my PC. When I start KNOS from another USB stick it succeeds to mount ISISBACK on bootup (although it gives an error message that it won't mount). I can use it to read and write files ok. When I try to unmount it doesn't with a message: Cannot unmount volume. Details: Cannot open /media/.hal-mtab Another thing, when I wrote the prefs to this USB stick the tar.gz file didn't show up in Gnome's Nautilus, but after trying to unmount it (and it failed to unmount), the file did show up! It will continue to accept files written to it. The mount command shows this: /dev/msdosfs/ISISBACK on /media/ISISBACK (msdosfs, local, nosuid) If I force unmount it with # umount -f /media/ISISBACK/ It unmounts then immediately remounts with name ISISBACK_ I know this one!  OK ... first I'll do the technical thing since we have lots of geeks who drop by to see if I'm perhaps bs'ing anyone, so I'll lay out the technicals first and then down below, "plain english." Heh. Thanks for the diagnostics, it pinpoints what's going on. I'll get back to that in the human readable part down below. From the diagnostics with respect to that particular USB stick: Nov 4 09:39:02 KNOS-64bit kernel: GEOM: da1: partition 1 does not start on a track boundary. Nov 4 09:39:02 KNOS-64bit kernel: GEOM: da1: partition 1 does not end on a track boundary. The "GEOM" is BSD's kernel driver for drives and sticks that goes way back to 4.3 BSD. Unfortunately, it depends upon a device that is properly formatted and the "partition 1" stuff says that the device isn't perfectly formatted with each track on the correct boundaries. In the upcoming 9 version of BSD's kernel, they've finally gotten rid of GEOM altogether and have replaced it with ATA_CAM which is forgiving of media that isn't perfectly formatted and is able to "punt" on such a discrepancy. Of course since we're still at 8, we're currently stuck with GEOM's insistence that the formatting be perfect and it almost always is. Now to the plain English: It's likely that this USB stick is one of several out there which has a fake CD-like head partition - vendors do this to allow encryption, or software drivers for the USB device. Ironkey is one of those and there are others out there. So natch, you've got me curious as to who the manufacturer is since we've seen a handful of these before. Reformatting the stick in Windows (which means of course destroying everything that's on it) usually solves the problem and presents our GEOM with a happily formatted drive whereupon it won't complain about that and fail to mount it. What's happened is that the kernel went ahead and mounted the drive to begin with, and gnome came along, saw the error and by design won't mount a defective drive normally in order to prevent potential damage to it as a result. Since the first mount was left pending, the device actually WAS busy and thus the error. When you UNmounted it, gnome saw a mounted drive and REmounted it and in doing so settled out the offsets and added the _ at the end because it was as far as it could determine ANOTHER drive with the same name as the first (which is why the _ got added). And of course, it worked then because the offsets were taken into account and that "stuck" drive which was gumming up the works was now cleared out of the way. Since it didn't mount, "hal-mtab" (which is the database for gnome for the drives it supervises in and out) didn't exist since it hadn't mounted and thus those complaints as well. Don't ya just love it? Not. But the bottom line, that drive is formatted a bit squirrely and that's why the mayhem. Another drive would work famously for the GEOM media detect, but didn't here. When I've encountered squirrely drives in the past, I fed them to Windows, had it reformat (complete drive) either in the disk manager thing or with a manufacturer's USB formatting tool. Once done, all was well thereafter. Once we get 9 out the door with the new ATA_CAM instead of the old GEOM, it's willing to offset bad sector numbering in the kernel. Alas, BSD was designed for servers and geeks and those types insist on perfect and so BSD went along with the assumption that it wouldn't be plugged in if it wasn't perfect and the geeks would want to know if it wasn't. That's apparently the thinking in the world of BSD. Nowadays, they're discovering the "real world" and that won't happen with KNOS 9 ... sorry about all that ... |
|
|
|
Post by rustleg on Nov 9, 2011 11:22:34 GMT -5
Thanks for the explanation. Think I'll fire up Windows and sanitise all my USB sticks.
|
|
|
|
Post by Kevin McAleavey on Nov 10, 2011 3:18:04 GMT -5
Thanks for the explanation. Think I'll fire up Windows and sanitise all my USB sticks. Here's hoping that'll do it for now ... apparently since we're seeing some similar in the KNOS 9 code from BSD, there have been a few wrigglies for years in the HAL and GVFS code that nobody's noticed until recently. We've gotten pretty much everything else happy for the beta process except for automount. Last thing that needs fixing before we can start our own beta cycle here. |
|
|
|
Post by rustleg on Nov 16, 2011 5:30:14 GMT -5
Sorry for the delay in coming back here. I have several USB sticks some of which work properly some don't.
The one which gave problems last time still isn't all ok, but it does now unmount, the icon disappears from the desktop (briefly) but then immediately remounts with icon reappearing, this time without the extra underline. After that it behaves "normally" (except for this umounting problem) and will accept files written to it.
I don't know whether to trust if it clears the buffers, so presumably to be safe I should issue a sync command? If I physically pull it out the icon stays there.
Another USB stick of the same make does the same thing, but I have other USB sticks of different make which behave themselves.
I'm not asking for a reply to this, I'm happy to accept how things are.
(... all USB sticks are born equal, but some are more equal than others ...)
|
|
|
|
Post by Kevin McAleavey on Nov 17, 2011 1:23:32 GMT -5
Sorry for the delay in coming back here. I have several USB sticks some of which work properly some don't. The one which gave problems last time still isn't all ok, but it does now unmount, the icon disappears from the desktop (briefly) but then immediately remounts with icon reappearing, this time without the extra underline. After that it behaves "normally" (except for this umounting problem) and will accept files written to it. I don't know whether to trust if it clears the buffers, so presumably to be safe I should issue a sync command? If I physically pull it out the icon stays there. Another USB stick of the same make does the same thing, but I have other USB sticks of different make which behave themselves. I'm not asking for a reply to this, I'm happy to accept how things are. (... all USB sticks are born equal, but some are more equal than others ...) Yeah, as I was telling you in email, there's a few sticks in my own collection that behave strangely and as of BSD 9, there are some bugs in gnome's automounting code that appear to have been there for a few versions of theirs that are showing up now. Any chance of going through a full cycle of madness with each of them and then squirting me diagnostics from each? I'm yelling at the gnome people now and having that to back up the "huh?" I'm getting out of them and the denials that there's any problem would be VERY helpful to my cause and yours. |
|
|
|
Post by rustleg on Nov 17, 2011 16:31:39 GMT -5
OK no problem, will do but might take a couple of days since I'm a bit tied up at the moment. Would it be best to reboot between each?
|
|
|
|
Post by Kevin McAleavey on Nov 17, 2011 22:07:33 GMT -5
OK no problem, will do but might take a couple of days since I'm a bit tied up at the moment. Would it be best to reboot between each? No problem on this end either. There's a lot of mayhem still to be sorted which was handed us with this latest gnome code. I don't see it solved quickly owing to the sheer volume of it all so there's plenty of time ... we're not letting the 9 version out for testing until it works properly for us first. And for the reboot, no need actually ... what I'm looking for is device ID information as each one goes in and out of the system, I can sort the various from one continuous diagnostics file. I'm looking to see what the quirks are in each as listed when they are attached and detached. |
|
