svn commit: r259479 - head/usr.sbin/bsdinstall/scripts

Teske, Devin Devin.Teske at fisglobal.com
Thu Dec 19 06:08:21 UTC 2013


On Dec 16, 2013, at 2:03 PM, Nathan Whitehorn wrote:

> On 12/16/13 15:55, Teske, Devin wrote:
>> On Dec 16, 2013, at 1:50 PM, Nathan Whitehorn wrote:
>> 
>>> On 12/16/13 15:48, Teske, Devin wrote:
>>>> On Dec 16, 2013, at 1:40 PM, Teske, Devin wrote:
>>>> 
>>>>> On Dec 16, 2013, at 1:26 PM, Nathan Whitehorn wrote:
>>>>> 
>>>>>> On 12/16/13 13:47, Devin Teske wrote:
>>>>>>> Author: dteske
>>>>>>> Date: Mon Dec 16 19:47:04 2013
>>>>>>> New Revision: 259479
>>>>>>> URL: http://svnweb.freebsd.org/changeset/base/259479
>>>>>>> 
>>>>>>> Log:
>>>>>>>  Add kern.geom.label.disk_ident.enable="0" to loader.conf(5).
>>>>>>>     Discussed on:	-current, -stable
>>>>>>>  MFC after:	3 days
>>>>>>> 
>>>>>>> Modified:
>>>>>>>  head/usr.sbin/bsdinstall/scripts/zfsboot
>>>>>>> 
>>>>>>> Modified: head/usr.sbin/bsdinstall/scripts/zfsboot
>>>>>>> ==============================================================================
>>>>>>> --- head/usr.sbin/bsdinstall/scripts/zfsboot	Mon Dec 16 19:44:45 2013	(r259478)
>>>>>>> +++ head/usr.sbin/bsdinstall/scripts/zfsboot	Mon Dec 16 19:47:04 2013	(r259479)
>>>>>>> @@ -1159,6 +1159,9 @@ zfs_create_boot()
>>>>>>> 	             $BSDINSTALL_TMPETC/rc.conf.zfs || return $FAILURE
>>>>>>> 	f_eval_catch $funcname echo "$ECHO_APPEND" 'zfs_load=\"YES\"' \
>>>>>>> 	             $BSDINSTALL_TMPBOOT/loader.conf.zfs || return $FAILURE
>>>>>>> +	f_eval_catch $funcname echo "$ECHO_APPEND" \
>>>>>>> +	             'kern.geom.label.disk_ident.enable=\"0\"' \
>>>>>>> +	             $BSDINSTALL_TMPBOOT/loader.conf.zfs || return $FAILURE
>>>>>>>   	# We're all done unless we should go on for boot pool
>>>>>>> 	[ "$ZFSBOOT_BOOT_POOL" ] || return $SUCCESS
>>>>>> Uh -- what is all of this? Why are we disabling kernel functions depending on what the root filesystem is? Please don't MFC this.
>>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076365.html&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=WCmXzB4036KuOzNScbJsBQLKdo%2BAo15QWLYq4A7DKis%3D%0A&s=4f16f0d6399e3a3c5e105a7869c580884327a8721c2f44c1711b319212a23db7
>>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076471.html&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=WCmXzB4036KuOzNScbJsBQLKdo%2BAo15QWLYq4A7DKis%3D%0A&s=17882f97e3633c1e3ebd45f332e62d2212dc53d1f0577acc4ae15d8234d09c7f
>>>>> 
>>>>> NB: Happy to rip it out... but want something in-reply to those threads (pretty please).
>>>> Basically... the logic is...
>>>> 
>>>> The ZFS pool is built on vdevs of a specific name. The names that are used
>>>> should remain the same. Adding this to the loader.conf ensures that the names
>>>> that the pool(s) was/were built upon do not change.
>>>> 
>>>> This goes beyond just a swap partition I imagine. For example... copying the
>>>> data to a new drive using a duplicator. I'm sure there are other cases too.
>>> Thanks for the explanation! I wonder if we should just turn off the disk ident stuff by default globally -- it was causing problems for me as well without ZFS root.
>> As I was making the commit to zfsboot... the very thought had occurred to me.
>> 
>> I'm happy to rip this out in favor of a new global default. The end-result is that
>> what Johan experienced won't be repeated.
>> 
>> I think there's an urgency to get something to solve this into 10.
> 
> Yeah, I can see that. Let me bring this up on -CURRENT, with a short timeout, and see what the options are.

Any updates on this?
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.


More information about the svn-src-all mailing list