Re: [zfs] Mounting from (...) failed with error 19

Previous thread: c 213323 breaks Sony Vaio P11Z w/o acpi by volker on Monday, October 18, 2010 - 3:31 pm. (9 messages)

Next thread: [head tinderbox] failure on sparc64/sparc64 by FreeBSD Tinderbox on Tuesday, October 19, 2010 - 1:22 am. (1 message)
From: Xin LI
Date: Monday, October 18, 2010 - 4:50 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

With latest kernel I got:

	Mounting from (...) failed with error 19

On boot.  The system is using pure ZFS setup.  It seems that 19 means
ENODEV but according to the dmesg the device do exist.

At the beginning I thought it was because that zpool.cache was destroyed
somehow, so I have tried to use LiveFS and mkdir /boot/zfs, hostid
start, zpool import -f, mount pool/root, and copy /boot/zfs/zpool.cache
over it but unluckily this failed.

Escaping to boot loader prompt, and load old kernel, old opensolaris.ko,
old zfs.ko doesn't work.  However, using LiveFS to restore the whole
kernel back to previous version fixed the problem (mv kernel kernel.bad
&& mv kernel.old kernel).

Looking at the change log, I find that there is no intrusive changes to
ZFS itself but there are some changes against mountroot logic, but I'm
not convinced since loading kernel.old/kernel at boot loader should have
override this :-/

Any idea?

Cheers,
- -- 
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!	       Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMvN06AAoJEATO+BI/yjfBkuAH/0437KphO+sPWv+M0UNEW/Zi
FO6c6TErSl4cZiTyGUSUjjDMAM71E+OXMin5ELjSDQbB05Dd96uLUKiCObEYdz1o
hovpjbGy+ZNIeIBUvrCvdg14o8m9WipWGwVZDXEdHY9GOjcEJdWcmcL6xpsLMN7F
BadVL1c/FunVXjeRwhDwhO7YmFgzfE6rBJjbtPflCj2PeKPsyk7he0hL3iNyBbAx
5IvwHvd0bu3EkGk9slc9ogahJjOdq3SRPiiSnkKIZyRjCeeC+ptSvI9ri1evIpIX
EFoY1oEmNAkmtIBiVxNlRPeJ2kWQxDCkqWsDUgpwXrKKS5FL7cKssb9PYog/mVE=
=Buo+
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Andrey V. Elsukov
Date: Monday, October 18, 2010 - 10:03 pm

Yes, i have the same problem.

-- 
WBR, Andrey V. Elsukov

From: Andrey V. Elsukov
Date: Tuesday, October 19, 2010 - 7:55 am

I fixed it with attached patch.

-- 
WBR, Andrey V. Elsukov
From: Marcel Moolenaar
Date: Tuesday, October 19, 2010 - 8:49 am

Makes sense. "tank" (or its namesake) isn't a real device.
Feel free to commit to unbreak things, but we may want to
rethink this from a generality point of view. Listing
exceptions doesn't scale and we now have 2 (the first was
the empty device name as used by nfs, and now also zfs).

Good catch, BTW.

-- 
Marcel Moolenaar
xcllnt@mac.com



_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: KOT MATPOCKuH
Date: Tuesday, October 19, 2010 - 11:16 am

On my sparc64 system with today kernel I also got this problem.
With old kernel system boots properly.
boot -sv log attached.

-- 
MATPOCKuH
From: Xin LI
Date: Tuesday, October 19, 2010 - 2:21 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Yes good catch, it fixed the problem for me as well.

What about the attached patch?  I'm going to give it a swirl soon.  The
difference is that it tests whether dev begins with /dev/.

Note that I'm not quite convinced with this yet as we may want to wait
for the devices from a zpool be ready, which may also need some yielding
during boot.  A better way of solving this might be to register a
"watchlist" of devices (so that ZFS can register its vdev devices for
example) and have mountroot wait for that list?  Or perhaps a set of
EVENTHANDLER callback?

Cheers,
- -- 
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!	       Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMvgvkAAoJEATO+BI/yjfBX/gIAIRnS4eQVBe/Zh6RrT8BjI91
J1r7wNz1AYXda2t4/RUVnPZYr97GG1quEewtgcxTxW2nkii1ZkftjMg6Ik4Gio6Y
AxNdjEB35tXqhVUV1oS8JS09ejZij2Y43SHxWxOkhUnFEmuhjK4+euM/+obpJ4Kl
AR61E/DYqwv/8bqhofknylroDsveN3Vhd1n7dK4s+e3YcmANnZxTCWcxroD7C2yb
gCH6TDZPDVKVbfyS73QFoyic2Jml5eK/dkmlLMRubP5qs5aIgy0P1zcjhvRrrgOf
bYLM3IUEbVhPSQnO8d2sDhXytgCI/s6p39rMdKPR3jrf2+UnW6IM46NvVkSaOP8=
=cAxC
-----END PGP SIGNATURE-----
From: Marcel Moolenaar
Date: Tuesday, October 19, 2010 - 3:33 pm

Interesting. I've been thinking about this too, but isn't
exactly fool-proof. When devfs is the root file system,
you can use "ufs:da0s1a" to refer to the device special
file. It seems inconsistent to have "ufs:da0s1" fail when
ufs:/dev/da0s1" works (a real scenario with USB based mass
storage devices -- root mount is unheld as soon as umass
is created, but before daX exists for it).

This patch at least covers the problem cases with a single
strstr(), and we may get away with the inconsistency given
above by documenting it properly.

Andrey: any thoughts?

-- 
Marcel Moolenaar
xcllnt@mac.com



_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Andrey V. Elsukov
Date: Tuesday, October 19, 2010 - 9:38 pm

Currently usage information in parse_dir_ask() says that device should
be specified with "/dev/". But conf0 does not use "/dev/". Also,  Marcel,
do you have any plans write some documentation with examples about using
of new features?

-- 
WBR, Andrey V. Elsukov

From: Marcel Moolenaar
Date: Wednesday, October 20, 2010 - 9:23 am

Yes, this will be documented.

-- 
Marcel Moolenaar
xcllnt@mac.com



_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: KOT MATPOCKuH
Date: Tuesday, October 19, 2010 - 11:50 pm

Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs"))?
-- 
MATPOCKuH
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Andrey V. Elsukov
Date: Wednesday, October 20, 2010 - 12:21 am

Just because it is not first access to the fs variable in this function.
And it is already checked with strcmp.

-- 
WBR, Andrey V. Elsukov

From: Peter Jeremy
Date: Wednesday, October 20, 2010 - 12:45 pm

Can you explain why you think it should be strncmp() please.

-- 
Peter Jeremy
From: Garrett Cooper
Date: Wednesday, October 20, 2010 - 1:39 pm

I'd say that strcmp is perfectly fine because zfs is a 3 character (4
if you count NUL) string. The comparison logic is dang near the same:

/*
 * Compare strings.
 */
int
strcmp(const char *s1, const char *s2)
{
        while (*s1 == *s2++)
                if (*s1++ == '\0')
                        return (0);
        return (*(const unsigned char *)s1 - *(const unsigned char *)(s2 - 1));
}

int
strncmp(const char *s1, const char *s2, size_t n)
{

        if (n == 0)
                return (0);
        do {
                if (*s1 != *s2++)
                        return (*(const unsigned char *)s1 -
                                *(const unsigned char *)(s2 - 1));
                if (*s1++ == '\0')
                        break;
        } while (--n != 0);
        return (0);
}

Weird how n == 0 with strcmp returns 0...

-Garrett
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Garrett Cooper
Date: Wednesday, October 20, 2010 - 1:40 pm

s/strcmp/strncmp/

-Garrett
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Matthew Fleming
Date: Wednesday, October 20, 2010 - 3:18 pm

It wouldn't be about the length of the string, but whether you want a
match on other strings like "zfs2", "zfs_foo", and anything else
prefixed with zfs.  That's the difference between strcmp and
strncmp(... strlen()).

Thanks,
matthew
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Garrett Cooper
Date: Wednesday, October 20, 2010 - 3:46 pm

Well, yeah... the because using the above strategy would introduce
parsing bugs as you so elegantly put it :).
-Garrett
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Marcel Moolenaar
Date: Tuesday, October 19, 2010 - 8:43 am

Can you both boot verbose and send me the output.
Also, please boot with -a and show me the console
output, as well as the output of the '?' command.

Thanks,

-- 
Marcel Moolenaar
xcllnt@mac.com



_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From: Andrey V. Elsukov
Date: Tuesday, October 19, 2010 - 9:24 am

It is ZFS-only system and I have this line in /boot/loader.conf:
vfs.root.mountfrom="zfs:zroot"

With "boot -a -v -s" I got the same result that with "boot -s -v"
but when I enter zfs:zroot in mountroot prompt it printed:

Trying to mount root from zfs:zroot []...
mountroot: waiting for device zroot ...
Mounting from zfs:zroot failed with error 19.
Trying to mount root from zfs:zroot []...
mountroot: waiting for device zroot ...
Mounting from zfs:zroot failed with error 19.
panic: mountroot: unable to (re-)mount root.

So, it seems that waiting for device when we are booting from zfs
is not necessary..

-- 
WBR, Andrey V. Elsukov
From: KOT MATPOCKuH
Date: Tuesday, October 19, 2010 - 12:50 pm

I think you forgot to load zpool.cache:
load -t /boot/zfs/zpool.cache /boot/zfs/zpool.cache
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Previous thread: c 213323 breaks Sony Vaio P11Z w/o acpi by volker on Monday, October 18, 2010 - 3:31 pm. (9 messages)

Next thread: [head tinderbox] failure on sparc64/sparc64 by FreeBSD Tinderbox on Tuesday, October 19, 2010 - 1:22 am. (1 message)