On Oct 19, 2010, at 2:21 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 10/19/10 08:49, Marcel Moolenaar wrote: >> >> On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote: >> >>> On 19.10.2010 09:03, Andrey V. Elsukov wrote: >>>>> 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. >>>> >>>> Yes, i have the same problem. >>> >>> I fixed it with attached patch. >> >> 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. > > 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/. 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_at_mac.comReceived on Tue Oct 19 2010 - 20:49:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:08 UTC