zfs mount : invalid argument

[MukiEX]

I'm well in aware that this might fall outside of the scope here. I've gone from Open Solaris to ZFS-Fuse and now to KQ Infotech's ZFS port. Most of my zfs filesystems mount just fine. However, a few give me a simple error: cannot mount 'zpool/filesystem': Invalid argument

Strace is as follows:

execve("/usr/bin/sudo", ["sudo", "zfs", "mount", "zpool/filesystem"], [/* 19 vars */]) = 0 brk(0) = 0x1d2e000 fcntl(0, F_GETFD) = 0 fcntl(1, F_GETFD) = 0 fcntl(2, F_GETFD) = 0 access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb8a942e000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=51087, ...}) = 0 mmap(NULL, 51087, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb8a9421000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libpam.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\"\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=51712, ...}) = 0 mmap(NULL, 2146808, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb8a9003000 mprotect(0x7fb8a900f000, 2093056, PROT_NONE) = 0 mmap(0x7fb8a920e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7fb8a920e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=14696, ...}) = 0 mmap(NULL, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb8a8dff000 mprotect(0x7fb8a8e01000, 2097152, PROT_NONE) = 0 mmap(0x7fb8a9001000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fb8a9001000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\356\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1572232, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb8a9420000 mmap(NULL, 3680296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb8a8a7c000 mprotect(0x7fb8a8bf6000, 2093056, PROT_NONE) = 0 mmap(0x7fb8a8df5000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x179000) = 0x7fb8a8df5000 mmap(0x7fb8a8dfa000, 18472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb8a8dfa000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libcrypt.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\n\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=43296, ...}) = 0 mmap(NULL, 2326976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb8a8843000 mprotect(0x7fb8a884c000, 2097152, PROT_NONE) = 0 mmap(0x7fb8a8a4c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9000) = 0x7fb8a8a4c000 mmap(0x7fb8a8a4e000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb8a8a4e000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb8a941f000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb8a941e000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb8a941d000 arch_prctl(ARCH_SET_FS, 0x7fb8a941e700) = 0 mprotect(0x7fb8a8a4c000, 4096, PROT_READ) = 0 mprotect(0x7fb8a8df5000, 16384, PROT_READ) = 0 mprotect(0x7fb8a9001000, 4096, PROT_READ) = 0 mprotect(0x7fb8a920e000, 4096, PROT_READ) = 0 mprotect(0x621000, 4096, PROT_READ) = 0 mprotect(0x7fb8a9430000, 4096, PROT_READ) = 0 munmap(0x7fb8a9421000, 51087) = 0 brk(0) = 0x1d2e000 brk(0x1d4f000) = 0x1d4f000 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=5205824, ...}) = 0 mmap(NULL, 5205824, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb8a834c000 close(3) = 0 geteuid() = 1000 write(2, "sudo", 4sudo) = 4 write(2, ": ", 2: ) = 2 write(2, "must be setuid root", 19must be setuid root) = 19 write(2, "\n", 1 ) = 1 exit_group(1) = ?

[nkhare]

You mentioned few gave you errors. So, is it not always the case?

Can you give us following information ti further debug the issue:- a. The OS you are running (Fedora/ Ubuntu/ RHEL) b. The kernel version c. Steps to re-produce the problem.

[MukiEX]

Using Ubuntu 10.10, kernel 2.6.35-22-generic, architecture x86_64

Ran as root (real root, sudo su). I ran "strace zfs mount pls/media". I got this: http://www.pasteall.org/18375/bash

Perhaps there's an existing attribute that's breaking the code? The problem is that I can't even unmount this thing (if, for instance, I wanted to try loading the pool under zfs-fuse instead). If there's anything I can run to extract more info about why this particular zfs fs isn't loading, I'll gladly do it.

[nkhare]

As per my understanding you imported the pool which was earlier with zfs-fuse. Please correct me if I am wrong.

Right now we don't recommend to import any pools which were created on Solaris or via zfs-fuse to our bits but we will try to debug the problem you are facing.

If you used zfs-fuse than can tell us the the version of zfs-fuse, which you used to create the pools.

I am not sure about that unmount thing. Can you please give us more info on that?

[MukiEX]

It was originally created in OpenSolaris 2009.06 (111b). Then it was upgraded to pool version 14 in build 128a. After that it was opened in ZFS-Fuse 0.6.9.

I did some "get all" functions, and here are my results: http://www.pasteall.org/18393

Keep in mind that pls/home/mukiex mounts just fine, while pls/media gives me that error. Could it be an ACL thing, or an extended attributes thing? If there's a way to have zfs completely ignore that info, I'd be glad to set whatever flags I need for it.

Also, I edited my comment about the strace for clarity.

Edit note: I still have access to boot under OpenSolaris, so if there's anything I can run under there to remove ANY unsupported attributes that OpenSolaris leaves in a ZFS filesystem (or anything else that might cause bugs), I will be glad to.

[nkhare]

Thank you for providing the information.

We tried to re-produce the problem by creating a pool on Open Solaris, then imported the pool with zfs-fuse and then after exporting, importing it with our bits. But we were not able to re-produce it.

You mentioned that "pls/home/mukiex" mounts fine but you face the problem with "pls/media". "sharenfs", "sharesmb" and "net.mukiex:sharellink" properties differ in them. May be you want to try after setting the same properties on "/pls/media", as on "pls/home/mukiex"

[MukiEX]

Solved! And unlike every other "closed" I've seen, here's what I did:

I followed your advice, nkhare, and did: zfs set sharenfs=off pls/media

I also turned off sharesmb, but that's neither here nor there.

However, I tried that in Ubuntu and it hung on me (command never finished). After that, I booted into an OpenSolaris live CD, did a "zpool import -f pls", then I disabled sharenfs there. After that I did "zpool export pls", installed Fedora, imported the pool, and media showed up just fine!

A few notes: Okay, obviously, this is a really crappy way to "verify", as Fedora isn't the same environment as Ubuntu. I probably shouldn't have done that but Ubuntu 64-bit wasn't installing Samba without hanging so I decided to move to the "official" distro for KQStor.

In addition, I'm not sure if this place is run or helped by KQ Infotech, but if it is, I'd just like to point out that requiring, specifically, kernel 2.6.35.6-48 is insane. NOBODY has that kernel version. I found ONE mirror that still had it, and downloaded the RPM's for that and the same version of kernel-devel. Given that they'd be separate downloads, I don't think you're out of line to provide those RPM's ;-)

[MukiEX]

With that, we're closed =3

[nkhare]

Its good to know that the issue is resolved.

Yes, this place is run by KQ Infotech. We will be building the packages for the latest version of kernel available on Fedora 14 and will upload them on KQ Stor website (kqstor.com).

You can also contact us at support@kqinfotech.com.