-----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"
Yes, i have the same problem. -- WBR, Andrey V. Elsukov
I fixed it with attached patch. -- WBR, Andrey V. Elsukov
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"
On my sparc64 system with today kernel I also got this problem. With old kernel system boots properly. boot -sv log attached. -- MATPOCKuH
-----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-----
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"
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
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"
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"
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
Can you explain why you think it should be strncmp() please. -- Peter Jeremy
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"
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"
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"
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"
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"
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
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"
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian | [RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set |
| Junio C Hamano | Re: Rss produced by git is not valid xml? |
| Linux Kernel Mailing List | iSeries: fix section mismatch in iseries_veth |
| Linux Kernel Mailing List | ixbge: remove TX lock and redo TX accounting. |
| Linux Kernel Mailing List | ixgbe: fix several counter register errata |
| Linux Kernel Mailing List | b43: fix build with CONFIG_SSB_PC |
