Drive not detected in openSUSE Tumbleweed #31
Comments
|
Hi @taohansen. Thanks for your note. Without being able to reproduce your issue myself, it's hard to conclude with certainly exactly what's going on. However, I've got some pretty good guesses. If you update the ...then you can see exactly what the script is doing behind the scenes. Based on the output you provided, we can say with relative confidence that following is the line being executed by the script: Note how this differs with your control experiment: The script specifies the following parameters, which you omit:
I'm willing to bet that if you tried your control test again, but this time explicitly setting It's important to specify the correct block size for your device because UDF limits your partition size to 2 TiB with a 512 B block size, or 8 TiB with a 2048 B block size. (Essentially, that's a limit of 2^32 blocks for a UDF partition.) Also, the block size you specify may have performance implications on your specific hard drive. Only one value is correct, and using any incorrect value will slow down write operations (perhaps reads as well, depending on drive caching). According to the script output, your disk seems to be 4 TB. This means that defaulting to a block size of 2048 should be fine in your case, except for the performance implications of using a non-matching block size. In many cases, all you need to do is to manually specify the block size when mounting on Linux. For example: If you're interested in learning more about the landscape, here is some additional reading:
Let me know how it goes! In the unlikely case that you're running into #13 and its corresponding Linux bug https://bugzilla.kernel.org/show_bug.cgi?id=102271 (meaning that 4096 actually isn't the correct value for your drive), then you can use format-udf's |
|
Thank you for taking the time to write such a detailed answer. I ran your script again and then So then I combed through older issues and tried again first by running Overcome with joy, I plugged the drive in to my friend's Mac, which resulted in this error: So I now have a drive which I can't immediately test with a Windows machine but which does not mount with Mac defeating my desired use for UDF. So I now have three questions: |
|
Hi again, @taohansen. It looks like you stumbled into the correct line of reasoning. As with any In the same way that you had to specify manual instructions for Linux to mount your 4K-block drive, you'll likely have to do the same on OS X. See #16 for more info. To summarize, this might work for you to manually mount your new UDF drive on OS X: Of course, you'll have to fill in the correct All of this is required because operating systems like openSUSE and OS X don't (usually) perform physical block detection when attempting to auto-mount media. I have to do the same thing for my 4K-block drive as well. It's a small price to pay for a drive (with modern features) that can be used across OS families. Good luck! |
|
FYI, I'm closing this issue with the clarifying text I've just added on the README. Essentially, there's not much that format-udf can do if Linux and OS X have trouble auto-mounting drives with certain block sizes. Please feel free to continue the conversation by commenting below. I'm still happy to assist however I can. |
|
mount_udf: mount_udf: /dev/disk1 failed, Resource busy, Resource busy |
|
is Assuming it's correct, you won't be able to mount a drive that's already mounted. Check the output from |
|
Aha, this is same result of me mounting to /mnt/ in Linux: under macOS, the drive fails to show up in the Finder but I can |
|
There are two requirements mounting (same on Linux as for OS X):
If you do neither, you'll see an empty directory and no listing in the output from If you do 1 but not 2, you'll see an empty directory but it might be listed in the output from You didn't provide enough data for me to know what scenario you're in, but there's nothing special about the Finder ... if you mount it properly at the CLI, then it will show up in the Finder. |
|
I am happy to run whatever commands you specify to help resolve this issue. I have changed the permissions of the folder /Volumes/Morrow I created and replugged the drive but am receiving the same error. I have specified the proper blocksize. I was hopeful for a plug & play universal solution but it is as difficult for me to install the Paragon NTFS driver as it is to mount this drive and a drive formatted under NTFS in tandem with Paragon's driver will automount under these three operating systems. That only UDF 512 blocksize drives will mount at all under Windows is the arrow in the heart for UDF for me. I thank you for your exhaustive help and apologize if I've been at all untoward. |
|
Hi @taohansen. Just to be clear, I'm more than happy to help you with format-udf.sh, but I can't help you change OS X or Windows (correct me if I'm wrong, but that seems to be what you're asking for). Apple and Microsoft are the ones in control of how their OSes (auto)mount UDF drives. Microsoft has no motivation to add robust support for UDF, as they prefer that we use NTFS to begin with. Same with Apple and HFS+. I'm happy to give you explicit commands, but you still haven't shared what your block size is. :) format-udf detected it as 4096, but you never reported back as to whether you could be running into #13 (i.e. the Linux bug that lies about your block size for AF drives). Please see https://bugzilla.kernel.org/show_bug.cgi?id=102271. Have you tried As you can see, this is a complicated landscape. :) There is no "plug & play universal solution", but UDF is the closest we've got in the open source arena. Closed-source formats/drivers present challenges of their own. If you're more comfortable with that path, then I certainly won't be offended. In fact, if you're okay with a proprietary solution, I might recommend that altogether. At the very least, NTFS has a fsck, and UDF doesn't. Many people view that as a non-starter for UDF (I just had a corrupt UDF filesystem last week, and had to format and start over). Let me know how you'd like to proceed. |
GNOME Files doesn't see the resulting drive of format-udf.sh as mountable.
In comparison: running
mkudffs --media-type=hd --vid=Morrow --lvid=Morrow /dev/sdcproduces a drive I can mount and read and write to in Linux.NAME="openSUSE Tumbleweed"
VERSION="20161003"
udftools version is 1.0.0b3-161.4
Here's the result of:
./format-udf.sh sdc MorrowThe text was updated successfully, but these errors were encountered: