From sacadmin Thu May 20 12:53:31 2010 Received: from tethys.Eng.Sun.COM (tethys.SFBay.Sun.COM [129.146.226.92]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KJrVtj027493; Thu, 20 May 2010 12:53:31 -0700 (PDT) Received: from tethys.Eng.Sun.COM (localhost [127.0.0.1]) by tethys.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o4KJctjo012696; Thu, 20 May 2010 12:38:55 -0700 (PDT) Received: (from jg@localhost) by tethys.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o4KJct54012694; Thu, 20 May 2010 12:38:55 -0700 (PDT) Date: Thu, 20 May 2010 12:38:55 -0700 (PDT) From: Jerry Gilliam Message-Id: <201005201938.o4KJct54012694@tethys.Eng.Sun.COM> To: PSARC-record@sac.sfbay.sun.com Subject: Automated Boot Archive Recovery [PSARC/2010/187 FastTrack timeout 05/27/2010] Status: RO Content-Length: 606 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Automated Boot Archive Recovery 1.2. Name of Document Author/Supplier: Author: Jan Setje-Eilers 1.3 Date of This Document: 20 May, 2010 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From jerry.gilliam@oracle.com Thu May 20 12:57:04 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KJv3Ho027802 for ; Thu, 20 May 2010 12:57:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4KJv1Wi037828; Thu, 20 May 2010 13:57:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00507I31YF00@nwk-avmta-2.sfbay.sun.com>; Thu, 20 May 2010 12:57:01 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00LB3I30YT90@nwk-avmta-2.sfbay.sun.com>; Thu, 20 May 2010 12:57:00 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KJv0Bb015610; Thu, 20 May 2010 19:57:00 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KJurYM018397; Thu, 20 May 2010 19:56:54 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 285751131274385328; Thu, 20 May 2010 12:55:28 -0700 Received: from 133.sub-75-229-25.myvzw.com (/10.7.250.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 12:55:28 -0700 Date: Thu, 20 May 2010 12:55:00 -0700 From: Jerry Gilliam Subject: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] To: PSARC-ext@sun.com Cc: Jan Setje-Eilers , Gangadhar Mylapuram Message-id: <4BF59394.8080901@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BF5940B.0193:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Status: RO Content-Length: 8090 I'm submitting the following fast-track on behalf of Jan Setje-Eilers with time-out set to 05/27/2010. Minor/patch binding is requested. ----- 1) Summary While automated recovery from an out of sync boot archive is possible, it does require rebooting the world with the updated archive. With both OBP and fast-reboot this can be reliably initiated from the previously running system. However BIOS based x86 systems lack any way to ensure that the system will boot from a specific device when coming out of reset, but can be (and often are) configured to boot from a specific device or ordered list of devices by the administrator. If a system is configured in that way it is highly desirable to allow it to participate in the fully automated recovery just like OBP based or fast-reboot capable systems. The bulk of text in this case described the implementation of the automated recovery. The interface described is however just the service fmri and the property name that allow a BIOS based system to be flagged as safe to automatically reboot. 2) Technical Details 2.0) Automated recovery 2.1.1) Background: The boot_archive verification was designed to catch a problem that has little to do with the boot_archive. The concern is that the boot_archive may have been generated before some kernel components were updated. This would allow a random match of older components, which were loaded from the boot_archive and newer components, which were loaded from the filesystem to interact in an unpredictable manner leading to potential data corruption. This scenario represents an unclean shutdown during or after updating kernel components without the use of install/upgrade or patch tools which will complete their transaction by updating the boot_archive. Given that such components need to be updated as a grouped transaction and updating the archive simply represents closing the transaction, this issue exists with and without the boot_archive. 2.1.2) Problem: There are other files in the archive that are updated out of band that cause the archive to become out of sync causing the check to keep the system from recovering unattended after a crash or power failure. The majority of these have been addressed with the fixes for 6256649 and 6803974. 2.1.3) Remaining problem: We will never be able to account for things like third party subsystems modifying binaries contained in the archive. Such unknown scenarios need to be handled via an automated archive re-build followed by (re)booting with the new archive. 2.1.4) Solution: As long as kernel components are upgraded using a supported install/upgrade/patch mechanism it is reasonable to trust the running kernel to be sufficiently self-consistent to not be dangerous at that point. In fact a system that has been subject to power failure or panic after non-matched kernel components were copied into place simply needs to be assumed to be trust-worthy by the the check as that is exactly what would happen without the archive or check if the panic/power failure had occurred during the update. This means it is reasonable to re-build the archive and reboot the system. Alternatively it's also possible to provide an automated failsafe, reboot to it, rebuild the archive and then reboot again, but based on the above premise that is not necessary. Since the point is to provide unattended recovery, the system must reboot to the same root fs with the same options. On x86, where the OS does not have control over the firmware's boot device selection this requires fast reboot which allows a running kernel to boot another directly without returning control to the firmware (this also bypasses POST which is significant performance win, but in this case that is secondary). On SPARC, where we have sufficient control over OBP, it is reasonable to simply reboot passing through the firmware. The lack of ability to reboot to an explicit device/root fs prior to fast reboot is what has been blocking this work since the initial introduction of the check. Since we now have fast reboot, this work can be put in place as well. The actual implementation is rather simple. The boot_archive service already blocks the system from reaching multi-user, so all it needs to do is explicitly rebuild the archive (the ufs case would also need to mount -o rw /) and then reboot with the exact options used for the current boot. Since SPARC does not require fast reboot to reliable reboot to a specific device/fs the s10 back-port retains full value for SPARC customers. x86 customer still get the option of setting up their systems to boot from the proper device and conveying this by setting trust-bios-boot-device to true. 3) Public Interfaces The interface is expected to be documented and used by system administrators. 3.1) svc:/system/boot-config:default svc fmri to store the property. While the service was introduced in PSARC 2008/760, this case extends the binding for the service to micro/patch. 3.1) trust-bios-boot-device A boolean property associated with the system/boot-config service called trust-bios-boot-device that is set to false by default. The property can be set via to true by an administrator to convey that they have configured both the BIOS and the default GRUB menu entry to boot from an appropriate device or list of devices in order to allow for an automated reboot in case an recovery is performed. Typically most systems are configured that way however in isolated situations the consequences of automatically rebooting to an unknown OS or OS configuration may be unpredictable, hence explicit confirmation from the administrator is required. Like other service properties, trust-bios-boot-device can be set and queried via svccfg(1). For example: svccfg -s svc:/system/boot-config:default \ listprop config/trust-bios-boot-device Will list the state, while: svccfg -s svc:/system/boot-config:default \ setprop config/trust-bios-boot-device = true Will set it to true. 4) Man page addition 4.1) boot(1m) The service svc:/system/boot-config:default contains the boolean property trust-bios-boot-device which is set to false by default. Setting it to true communicates that both the system's BIOS and default GRUB menu entry are set to boot from the current boot device. This allows the system to automatically reboot in order to recover from conditions such as an out of date boot-archive. The value of this property can be changed using svccfg(1M) and svcadm(1M). Typically most systems are configured that way however in isolated situations the consequences of automatically rebooting to an unknown OS or OS configuration may be unpredictable, hence explicit confirmation from the administrator is required. Example setting trust-bios-boot-device to allow for automated reboots. example# svccfg -s svc:/system/boot-config:default \ setprop config/trust-bios-boot-device = true From seth.goldberg@oracle.com Thu May 20 13:54:16 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KKsGpL028603 for ; Thu, 20 May 2010 13:54:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KKsEov021671; Thu, 20 May 2010 13:54:14 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00E01KQET200@brm-avmta-1.central.sun.com>; Thu, 20 May 2010 14:54:14 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q003ULKQE3X70@brm-avmta-1.central.sun.com>; Thu, 20 May 2010 14:54:14 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4KKsDML014666; Thu, 20 May 2010 20:54:13 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4K4WuKt012960; Thu, 20 May 2010 20:54:10 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 255377431274388733; Thu, 20 May 2010 13:52:13 -0700 Received: from kasha (/10.1.48.74) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 13:52:12 -0700 Date: Thu, 20 May 2010 13:51:32 -0700 (PDT) From: Seth Goldberg Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: <4BF59394.8080901@oracle.com> X-X-Sender: sethg@bergsoft.local To: Jerry Gilliam Cc: PSARC-ext@sun.com, Jan Setje-Eilers , Gangadhar Mylapuram Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BF5A174.0180:SCFMA4539814,ss=1,fgs=0 References: <4BF59394.8080901@oracle.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) Status: RO Content-Length: 8939 Hi, Instead of "trust-bios-boot-device", can we name it something like "automatic-boot-archive-recovery"? Future firmware support will not use the bios-boot-device property, and the property name should reflect its actual use instead of its implementation detail. Also: the text: > set to false by default. Setting it to true > communicates that both the system's BIOS and default > GRUB menu entry are set to boot from the current boot > device. is misleading -- we don't specify a boot "device" in GRUB anymore. We use the findroot/bootfs commands to search for the root pool or (in updates) the appropriate UFS filesystem. --S Quoting Jerry Gilliam, who wrote the following on Thu, 20 May 2010: > > I'm submitting the following fast-track on behalf of Jan Setje-Eilers > with time-out set to 05/27/2010. Minor/patch binding is requested. > > ----- > > 1) Summary > > While automated recovery from an out of sync boot archive is > possible, it does require rebooting the world with the updated > archive. With both OBP and fast-reboot this can be reliably > initiated from the previously running system. However BIOS > based x86 systems lack any way to ensure that the system will > boot from a specific device when coming out of reset, but can > be (and often are) configured to boot from a specific device > or ordered list of devices by the administrator. If a system is > configured in that way it is highly desirable to allow it to > participate in the fully automated recovery just like OBP > based or fast-reboot capable systems. > > The bulk of text in this case described the implementation of > the automated recovery. > > The interface described is however just the service fmri and > the property name that allow a BIOS based system to be flagged > as safe to automatically reboot. > > 2) Technical Details > > 2.0) Automated recovery > > 2.1.1) Background: > > The boot_archive verification was designed to catch a problem > that has little to do with the boot_archive. > > The concern is that the boot_archive may have been generated > before some kernel components were updated. This would > allow a random match of older components, which were loaded > from the boot_archive and newer components, which were loaded > from the filesystem to interact in an unpredictable manner > leading to potential data corruption. > > This scenario represents an unclean shutdown during or after > updating kernel components without the use of install/upgrade > or patch tools which will complete their transaction by > updating the boot_archive. Given that such components need to > be updated as a grouped transaction and updating the archive > simply represents closing the transaction, this issue exists > with and without the boot_archive. > > > 2.1.2) Problem: > > There are other files in the archive that are updated out of > band that cause the archive to become out of sync causing the > check to keep the system from recovering unattended after a > crash or power failure. > > The majority of these have been addressed with the fixes for > 6256649 and 6803974. > > > 2.1.3) Remaining problem: > > We will never be able to account for things like third party > subsystems modifying binaries contained in the archive. > > Such unknown scenarios need to be handled via an automated > archive re-build followed by (re)booting with the new > archive. > > > 2.1.4) Solution: > > As long as kernel components are upgraded using a supported > install/upgrade/patch mechanism it is reasonable to trust the > running kernel to be sufficiently self-consistent to not be > dangerous at that point. In fact a system that has been > subject to power failure or panic after non-matched kernel > components were copied into place simply needs to be assumed > to be trust-worthy by the the check as that is exactly what > would happen without the archive or check if the panic/power > failure had occurred during the update. > > This means it is reasonable to re-build the archive and reboot > the system. Alternatively it's also possible to provide an > automated failsafe, reboot to it, rebuild the archive and then > reboot again, but based on the above premise that is not > necessary. > > Since the point is to provide unattended recovery, the system > must reboot to the same root fs with the same options. On x86, > where the OS does not have control over the firmware's boot > device selection this requires fast reboot which allows a > running kernel to boot another directly without returning > control to the firmware (this also bypasses POST which is > significant performance win, but in this case that is > secondary). On SPARC, where we have sufficient control over > OBP, it is reasonable to simply reboot passing through the > firmware. > > The lack of ability to reboot to an explicit device/root fs > prior to fast reboot is what has been blocking this work since > the initial introduction of the check. Since we now have fast > reboot, this work can be put in place as well. > > The actual implementation is rather simple. The boot_archive > service already blocks the system from reaching multi-user, so > all it needs to do is explicitly rebuild the archive (the ufs > case would also need to mount -o rw /) and then reboot with > the exact options used for the current boot. > > Since SPARC does not require fast reboot to reliable reboot to > a specific device/fs the s10 back-port retains full value for > SPARC customers. x86 customer still get the option of > setting up their systems to boot from the proper device and > conveying this by setting trust-bios-boot-device to true. > > 3) Public Interfaces > > The interface is expected to be documented and used by system > administrators. > > 3.1) svc:/system/boot-config:default > > svc fmri to store the property. While the service was > introduced in PSARC 2008/760, this case extends the > binding for the service to micro/patch. > > 3.1) trust-bios-boot-device > > A boolean property associated with the > system/boot-config service called > trust-bios-boot-device that is set to false by > default. The property can be set via to true by an > administrator to convey that they have > configured both the BIOS and the default GRUB menu > entry to boot from an appropriate device > or list of devices in order to allow for an automated > reboot in case an recovery is performed. > > Typically most systems are configured that way however > in isolated situations the consequences of > automatically rebooting to an unknown OS or OS > configuration may be unpredictable, hence explicit > confirmation from the administrator is required. > > Like other service properties, trust-bios-boot-device > can be set and queried via svccfg(1). For example: > > svccfg -s svc:/system/boot-config:default \ > listprop config/trust-bios-boot-device > > Will list the state, while: > > svccfg -s svc:/system/boot-config:default \ > setprop config/trust-bios-boot-device = true > > Will set it to true. > > 4) Man page addition > > 4.1) boot(1m) > > The service svc:/system/boot-config:default contains > the boolean property trust-bios-boot-device which is > set to false by default. Setting it to true > communicates that both the system's BIOS and default > GRUB menu entry are set to boot from the current boot > device. > > This allows the system to automatically reboot in > order to recover from conditions such as an out of > date boot-archive. The value of this property can be > changed using svccfg(1M) and svcadm(1M). > > Typically most systems are configured that way however > in isolated situations the consequences of > automatically rebooting to an unknown OS or OS > configuration may be unpredictable, hence explicit > confirmation from the administrator is required. > > Example setting trust-bios-boot-device to allow for > automated reboots. > > example# svccfg -s svc:/system/boot-config:default \ > setprop config/trust-bios-boot-device = true > > > > > From scott.rotondo@oracle.com Thu May 20 14:19:32 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KLJWIe029145 for ; Thu, 20 May 2010 14:19:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4KLJTYN014640; Thu, 20 May 2010 15:19:30 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q0041DLWICW00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 20 May 2010 14:19:30 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00BKKLWGNH50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 20 May 2010 14:19:28 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4KLJSpQ006282; Thu, 20 May 2010 21:19:28 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KLJQA8030086; Thu, 20 May 2010 21:19:26 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 285966381274390299; Thu, 20 May 2010 14:18:19 -0700 Received: from [129.146.108.62] (/129.146.108.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 14:18:19 -0700 Date: Thu, 20 May 2010 14:18:24 -0700 From: Scott Rotondo Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: To: PSARC-ext@sun.com Cc: Jerry Gilliam , Jan Setje-Eilers , Gangadhar Mylapuram Message-id: <4BF5A720.9070007@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BF5A75F.014B:SCFMA4539814,ss=1,fgs=0 References: <4BF59394.8080901@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 587 On 05/20/10 01:51 PM, Seth Goldberg wrote: > Hi, > > Instead of "trust-bios-boot-device", can we name it something like > "automatic-boot-archive-recovery"? Future firmware support will not use > the bios-boot-device property, and the property name should reflect its > actual use instead of its implementation detail. Similarly, please avoid using the term "trust" where the meaning is unrelated to security/integrity. Thanks, Scott -- Scott Rotondo Senior Principal Engineer, Solaris Core OS Engineering President, Trusted Computing Group Phone: +1 650 786 6309 (Internal x86309) From jan.setjeeilers@oracle.com Thu May 20 14:49:03 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KLn31t029497 for ; Thu, 20 May 2010 14:49:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KLn099020745; Thu, 20 May 2010 16:49:01 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00C0TN9OCY00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 20 May 2010 14:49:00 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00B37N9ONI80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 20 May 2010 14:49:00 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4KLn0Ue002221; Thu, 20 May 2010 21:49:00 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KBKPpg016634; Thu, 20 May 2010 21:48:59 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 255515591274392064; Thu, 20 May 2010 14:47:44 -0700 Received: from [129.146.226.114] (/129.146.226.114) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 14:47:44 -0700 Date: Thu, 20 May 2010 14:47:43 -0700 From: Jan Setje-Eilers Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: <4BF5A720.9070007@oracle.com> To: Scott Rotondo Cc: PSARC-ext@sun.com, Jerry Gilliam , Gangadhar Mylapuram Message-id: <4BF5ADFF.9050903@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BF5AE4B.0133:SCFMA4539814,ss=1,fgs=0 References: <4BF59394.8080901@oracle.com> <4BF5A720.9070007@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 978 On 05/20/10 14:18, Scott Rotondo wrote: > On 05/20/10 01:51 PM, Seth Goldberg wrote: >> Hi, >> >> Instead of "trust-bios-boot-device", can we name it something like >> "automatic-boot-archive-recovery"? Future firmware support will not use >> the bios-boot-device property, and the property name should reflect its >> actual use instead of its implementation detail. I'm happy to drop the term BIOS in favor of firmware (though with EFI I'm hopeful that we'll actually be able to control this). But I do want to keep the property generic, so that other things that may need to rely on it can. > Similarly, please avoid using the term "trust" where the meaning is > unrelated to security/integrity. It is related to integrity. It implies that the administrator has allowed us to assume more integrity on part of the BIOS than we usually would. OK, with these restrictions I'm having a hard time coming up with something short. How about "auto-reboot-safe"? -jan From jan.setjeeilers@oracle.com Thu May 20 14:52:36 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KLqZK7029532 for ; Thu, 20 May 2010 14:52:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4KLqWQi030212; Thu, 20 May 2010 15:52:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Q00D15NFK8G00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 20 May 2010 14:52:32 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Q00B3YNFKNL80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 20 May 2010 14:52:32 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4KLqVTv003285; Thu, 20 May 2010 21:52:31 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KL1lC7012482; Thu, 20 May 2010 21:52:30 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 286045051274392274; Thu, 20 May 2010 14:51:14 -0700 Received: from [129.146.226.114] (/129.146.226.114) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 14:51:14 -0700 Date: Thu, 20 May 2010 14:51:13 -0700 From: Jan Setje-Eilers Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: To: Seth Goldberg Cc: Jerry Gilliam , PSARC-ext@sun.com, Gangadhar Mylapuram Message-id: <4BF5AED1.7060404@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BF5AF1E.0157:SCFMA4539814,ss=1,fgs=0 References: <4BF59394.8080901@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 713 On 05/20/10 13:51, Seth Goldberg wrote: > Also: the text: >> set to false by default. Setting it to true >> communicates that both the system's BIOS and default >> GRUB menu entry are set to boot from the current boot >> device. > > is misleading -- we don't specify a boot "device" in GRUB anymore. We > use the findroot/bootfs commands to search for the root pool or (in > updates) the appropriate UFS filesystem. Unless someone did set the device by hand. Setting the property is largely a promise that they didn't futz with those configs in a way that will sabotage our attempt to automatically reboot back to the same bits. Do you want me to try to rephrase or simple delete the reference? -jan From scott.rotondo@oracle.com Tue May 25 16:21:01 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4PNL09N025490 for ; Tue, 25 May 2010 16:21:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4PNKwKm032765; Tue, 25 May 2010 17:20:58 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3000K130UYMY00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 25 May 2010 16:20:58 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L300015J0UY4QB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 25 May 2010 16:20:58 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4PNKvhQ012818; Tue, 25 May 2010 23:20:57 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PNCY3N008276; Tue, 25 May 2010 23:20:57 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 297820961274829628; Tue, 25 May 2010 16:20:28 -0700 Received: from [129.146.108.62] (/129.146.108.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 16:20:28 -0700 Date: Tue, 25 May 2010 16:20:33 -0700 From: Scott Rotondo Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: <4BF5ADFF.9050903@oracle.com> To: Jan Setje-Eilers Cc: PSARC-ext@sun.com, Jerry Gilliam , Gangadhar Mylapuram Message-id: <4BFC5B41.7060909@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BFC5B59.00EC:SCFMA4539814,ss=1,fgs=0 References: <4BF59394.8080901@oracle.com> <4BF5A720.9070007@oracle.com> <4BF5ADFF.9050903@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1243 On 05/20/10 02:47 PM, Jan Setje-Eilers wrote: > On 05/20/10 14:18, Scott Rotondo wrote: >> On 05/20/10 01:51 PM, Seth Goldberg wrote: >>> Hi, >>> >>> Instead of "trust-bios-boot-device", can we name it something like >>> "automatic-boot-archive-recovery"? Future firmware support will not use >>> the bios-boot-device property, and the property name should reflect its >>> actual use instead of its implementation detail. > > I'm happy to drop the term BIOS in favor of firmware (though with EFI > I'm hopeful that we'll actually be able to control this). But I do want > to keep the property generic, so that other things that may need to rely > on it can. > >> Similarly, please avoid using the term "trust" where the meaning is >> unrelated to security/integrity. > > It is related to integrity. It implies that the administrator has > allowed us to assume more integrity on part of the BIOS than we usually > would. > > OK, with these restrictions I'm having a hard time coming up with > something short. How about "auto-reboot-safe"? > > -jan "auto-reboot-safe" is fine with me. Scott -- Scott Rotondo Senior Principal Engineer, Solaris Core OS Engineering President, Trusted Computing Group Phone: +1 650 786 6309 (Internal x86309) From seth.goldberg@oracle.com Tue May 25 16:39:38 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4PNdcBO025679 for ; Tue, 25 May 2010 16:39:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4PNdZGQ018692; Tue, 25 May 2010 16:39:36 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3000A071Q0JY00@brm-avmta-1.central.sun.com>; Tue, 25 May 2010 17:39:36 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3000ELF1PVEQA0@brm-avmta-1.central.sun.com>; Tue, 25 May 2010 17:39:35 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4PNdV9t020268; Tue, 25 May 2010 23:39:31 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PMfwZN032239; Tue, 25 May 2010 23:39:29 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 297855901274830748; Tue, 25 May 2010 16:39:08 -0700 Received: from [192.168.5.207] (/64.134.224.138) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 16:39:07 -0700 Date: Tue, 25 May 2010 16:39:02 -0700 From: "seth.goldberg@oracle.com" Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: <4BFC5B41.7060909@oracle.com> To: Scott Rotondo Cc: Jan Setje-Eilers , "PSARC-ext@sun.com" , Jerry Gilliam , Gangadhar Mylapuram Message-id: MIME-version: 1.0 X-Mailer: iPhone Mail (7D11) Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BFC5FB1.0129:SCFMA4539814,ss=1,fgs=0 References: <4BF59394.8080901@oracle.com> <4BF5A720.9070007@oracle.com> <4BF5ADFF.9050903@oracle.com> <4BFC5B41.7060909@oracle.com> Status: RO Content-Length: 1250 On May 25, 2010, at 4:20 PM, Scott Rotondo wrote: > On 05/20/10 02:47 PM, Jan Setje-Eilers wrote: >> On 05/20/10 14:18, Scott Rotondo wrote: >>> On 05/20/10 01:51 PM, Seth Goldberg wrote: >>>> Hi, >>>> >>>> Instead of "trust-bios-boot-device", can we name it something like >>>> "automatic-boot-archive-recovery"? Future firmware support will >>>> not use >>>> the bios-boot-device property, and the property name should >>>> reflect its >>>> actual use instead of its implementation detail. >> >> I'm happy to drop the term BIOS in favor of firmware (though with EFI >> I'm hopeful that we'll actually be able to control this). But I do >> want >> to keep the property generic, so that other things that may need to >> rely >> on it can. >> >>> Similarly, please avoid using the term "trust" where the meaning is >>> unrelated to security/integrity. >> >> It is related to integrity. It implies that the administrator has >> allowed us to assume more integrity on part of the BIOS than we >> usually >> would. >> >> OK, with these restrictions I'm having a hard time coming up with >> something short. How about "auto-reboot-safe"? >> >> -jan > > "auto-reboot-safe" is fine with me. Same here. --S From garrett@damore.org Tue May 25 16:58:37 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4PNwbGX026181 for ; Tue, 25 May 2010 16:58:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4PNwaps048692 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 25 May 2010 17:58:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L30007052LPLH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 25 May 2010 16:58:37 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L30006AF2LO8210@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 25 May 2010 16:58:36 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4PNuYXR001285 for ; Tue, 25 May 2010 23:58:36 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-1185041 for PSARC-ext@sun.com; Tue, 25 May 2010 23:58:36 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-230587775 for PSARC-ext@sun.com; Tue, 25 May 2010 23:58:35 +0000 (Z) Received: from outbound-mail-359.bluehost.com ([66.147.249.253] [66.147.249.253]) by relay1i.sun.com id BT-MMP-3787771 for PSARC-ext@sun.com; Tue, 25 May 2010 23:58:35 +0000 (Z) Received: (qmail 5624 invoked by uid 0); Tue, 25 May 2010 23:58:34 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy1.bluehost.com.bluehost.com with SMTP; Tue, 25 May 2010 23:58:34 +0000 Received: from 65.sub-72-105-109.myvzw.com ([72.105.109.65] helo=localhost) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OH414-0006ur-Cw; Tue, 25 May 2010 17:58:34 -0600 Date: Tue, 25 May 2010 16:58:46 -0700 From: "Garrett D'Amore" Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] To: "seth.goldberg@oracle.com" , Scott Rotondo Cc: Jerry Gilliam , " PSARC-ext@sun.com" , Gangadhar Mylapuram Message-id: Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Date:Subject:Message-ID:From:To:Cc:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=mSceAg1NlfeI4XLaV//l1RxOa/wRXmWqnT/tYgtF/N+SamNmnPSiTWoCebLqoWuvfbWY9hvTa5XtoJ1s6DJoDtG3TF9E4IoVrvR41gyXaPiKityXaO5j12K9O7ZbQzs4; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 72.105.109.65 authed with garrett+damore.org} X-Antispam: No, score=0.0/5.0, scanned in 0.306sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Status: RO Content-Length: 2080 U28gKzEgb24gdGhlIGNhc2UsIHNpbmNlIHRoZSBpc3N1ZXMgc2VlbSBzZXR0bGVkIG5vdy4KCiAg IC0tIEdhcnJldHQKCiJzZXRoLmdvbGRiZXJnQG9yYWNsZS5jb20iIDxzZXRoLmdvbGRiZXJnQG9y YWNsZS5jb20+IHdyb3RlOgoKPgo+Cj5PbiBNYXkgMjUsIDIwMTAsIGF0IDQ6MjAgUE0sIFNjb3R0 IFJvdG9uZG8gPHNjb3R0LnJvdG9uZG9Ab3JhY2xlLmNvbT4gIAo+d3JvdGU6Cj4KPj4gT24gMDUv MjAvMTAgMDI6NDcgUE0sIEphbiBTZXRqZS1FaWxlcnMgd3JvdGU6Cj4+PiBPbiAwNS8yMC8xMCAx NDoxOCwgU2NvdHQgUm90b25kbyB3cm90ZToKPj4+PiBPbiAwNS8yMC8xMCAwMTo1MSBQTSwgU2V0 aCBHb2xkYmVyZyB3cm90ZToKPj4+Pj4gSGksCj4+Pj4+Cj4+Pj4+IEluc3RlYWQgb2YgInRydXN0 LWJpb3MtYm9vdC1kZXZpY2UiLCBjYW4gd2UgbmFtZSBpdCBzb21ldGhpbmcgbGlrZQo+Pj4+PiAi YXV0b21hdGljLWJvb3QtYXJjaGl2ZS1yZWNvdmVyeSI/IEZ1dHVyZSBmaXJtd2FyZSBzdXBwb3J0 IHdpbGwgIAo+Pj4+PiBub3QgdXNlCj4+Pj4+IHRoZSBiaW9zLWJvb3QtZGV2aWNlIHByb3BlcnR5 LCBhbmQgdGhlIHByb3BlcnR5IG5hbWUgc2hvdWxkICAKPj4+Pj4gcmVmbGVjdCBpdHMKPj4+Pj4g YWN0dWFsIHVzZSBpbnN0ZWFkIG9mIGl0cyBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuCj4+Pgo+Pj4g SSdtIGhhcHB5IHRvIGRyb3AgdGhlIHRlcm0gQklPUyBpbiBmYXZvciBvZiBmaXJtd2FyZSAodGhv dWdoIHdpdGggRUZJCj4+PiBJJ20gaG9wZWZ1bCB0aGF0IHdlJ2xsIGFjdHVhbGx5IGJlIGFibGUg dG8gY29udHJvbCB0aGlzKS4gQnV0IEkgZG8gIAo+Pj4gd2FudAo+Pj4gdG8ga2VlcCB0aGUgcHJv cGVydHkgZ2VuZXJpYywgc28gdGhhdCBvdGhlciB0aGluZ3MgdGhhdCBtYXkgbmVlZCB0byAgCj4+ PiByZWx5Cj4+PiBvbiBpdCBjYW4uCj4+Pgo+Pj4+IFNpbWlsYXJseSwgcGxlYXNlIGF2b2lkIHVz aW5nIHRoZSB0ZXJtICJ0cnVzdCIgd2hlcmUgdGhlIG1lYW5pbmcgaXMKPj4+PiB1bnJlbGF0ZWQg dG8gc2VjdXJpdHkvaW50ZWdyaXR5Lgo+Pj4KPj4+IEl0IGlzIHJlbGF0ZWQgdG8gaW50ZWdyaXR5 LiBJdCBpbXBsaWVzIHRoYXQgdGhlIGFkbWluaXN0cmF0b3IgaGFzCj4+PiBhbGxvd2VkIHVzIHRv IGFzc3VtZSBtb3JlIGludGVncml0eSBvbiBwYXJ0IG9mIHRoZSBCSU9TIHRoYW4gd2UgIAo+Pj4g dXN1YWxseQo+Pj4gd291bGQuCj4+Pgo+Pj4gT0ssIHdpdGggdGhlc2UgcmVzdHJpY3Rpb25zIEkn bSBoYXZpbmcgYSBoYXJkIHRpbWUgY29taW5nIHVwIHdpdGgKPj4+IHNvbWV0aGluZyBzaG9ydC4g SG93IGFib3V0ICJhdXRvLXJlYm9vdC1zYWZlIj8KPj4+Cj4+PiAtamFuCj4+Cj4+ICJhdXRvLXJl Ym9vdC1zYWZlIiBpcyBmaW5lIHdpdGggbWUuCj4KPiAgIFNhbWUgaGVyZS4KPgo+ICAgLS1TCj4K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5vcGVuc29s YXJpcy1hcmMgbWFpbGluZyBsaXN0Cj5vcGVuc29sYXJpcy1hcmNAb3BlbnNvbGFyaXMub3JnCg== From jan.setjeeilers@oracle.com Tue May 25 17:19:06 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4Q0J6dL026340 for ; Tue, 25 May 2010 17:19:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4Q0J2V4058234; Tue, 25 May 2010 18:19:04 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3000K053JSSV00@nwk-avmta-2.sfbay.sun.com>; Tue, 25 May 2010 17:19:04 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3000BD73JR7880@nwk-avmta-2.sfbay.sun.com>; Tue, 25 May 2010 17:19:03 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4Q0J37e009623; Wed, 26 May 2010 00:19:03 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4Q0Ixcw020460; Wed, 26 May 2010 00:18:59 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 268066791274833022; Tue, 25 May 2010 17:17:02 -0700 Received: from [10.7.251.212] (/10.7.251.212) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 17:17:02 -0700 Date: Tue, 25 May 2010 17:17:00 -0700 From: Jan Setje-Eilers Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: To: "Garrett D'Amore" Cc: "seth.goldberg@oracle.com" , Scott Rotondo , Jerry Gilliam , "PSARC-ext@sun.com" , Gangadhar Mylapuram Reply-to: jan.setjeeilers@oracle.com Message-id: <4BFC687C.6020408@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BFC68F3.01A5:SCFMA4539814,ss=1,fgs=0 References: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 196 On 05/25/10 16:58, Garrett D'Amore wrote: Which decodes too: > > So +1 on the case, since the issues seem settled now. > > -- Garrett > -jan From garrett@damore.org Tue May 25 21:12:38 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4Q4Cb5G029355 for ; Tue, 25 May 2010 21:12:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4Q4Cbqo021886 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 25 May 2010 22:12:37 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3000D03ED1JN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 25 May 2010 22:12:37 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3000MWHECZRS30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 25 May 2010 22:12:35 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4Q4CYfU028440 for ; Wed, 26 May 2010 04:12:35 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-38721 for PSARC-ext@sun.com; Wed, 26 May 2010 04:11:21 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-172718979 for PSARC-ext@sun.com; Wed, 26 May 2010 04:11:20 +0000 (Z) Received: from outbound-mail-360.bluehost.com ([67.222.39.60] [67.222.39.60]) by relay4i.sun.com id BT-MMP-4437175 for PSARC-ext@sun.com; Wed, 26 May 2010 04:11:20 +0000 (Z) Received: (qmail 25601 invoked by uid 0); Wed, 26 May 2010 04:11:19 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy2.bluehost.com with SMTP; Wed, 26 May 2010 04:11:19 +0000 Received: from cpe-76-93-15-33.socal.res.rr.com ([76.93.15.33] helo=[192.168.251.110]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OH7xf-0003rW-Jz; Tue, 25 May 2010 22:11:19 -0600 Date: Tue, 25 May 2010 21:11:19 -0700 From: "Garrett D'Amore" Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: <4BFC687C.6020408@oracle.com> To: jan.setjeeilers@oracle.com Cc: "seth.goldberg@oracle.com" , Scott Rotondo , Jerry Gilliam , "PSARC-ext@sun.com" , Gangadhar Mylapuram Message-id: <4BFC9F67.30900@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=uegeYz39HiiJLXmOpfW8GMOw5M9lmcKa3WpEEd4d0FQZFh9OgEtTMCby7pBLwAN0WZjGsTHrNF4KwS8KCkh22bNCP02e7l3/m/EUDrbMKT7HlxK/2WQsdTgC4J1kuI5o; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 76.93.15.33 authed with garrett+damore.org} X-Antispam: No, score=0.0/5.0, scanned in 0.309sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BFC687C.6020408@oracle.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Status: RO Content-Length: 692 Thanks Jan. I used the mail client on my Android phone, to reply -- not sure why it garbled it into base 64. Interestingly enough, even the encoding client couldn't read the resulting message when it came back from the e-mail list. I suspect there may have been some bad interaction between the mailing list software and the base 64 encoding. (As to why it chose to encode it in base 64... that is a mystery.) - Garrett On 5/25/2010 5:17 PM, Jan Setje-Eilers wrote: > On 05/25/10 16:58, Garrett D'Amore wrote: > > > > Which decodes too: > > > > So +1 on the case, since the issues seem settled now. > > > > -- Garrett > > > > > -jan From jerry.gilliam@oracle.com Tue Jun 1 10:58:45 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o51Hwjmw018755 for ; Tue, 1 Jun 2010 10:58:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o51HwgGU050674; Tue, 1 Jun 2010 11:58:43 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3C00G0BKLVFI00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 01 Jun 2010 10:58:43 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3C00L4TKLUQ0D0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 01 Jun 2010 10:58:42 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o51Hwgm2004367; Tue, 01 Jun 2010 17:58:42 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o51GWgh2005074; Tue, 01 Jun 2010 17:58:35 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 287074791275415019; Tue, 01 Jun 2010 10:56:59 -0700 Received: from 136.sub-75-210-35.myvzw.com (/10.7.250.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 10:56:58 -0700 Date: Tue, 01 Jun 2010 10:56:38 -0700 From: Jerry Gilliam Subject: Re: Automated Boot Archive Recovery [PSARC/2010/187 fast-track 05/27/2010] In-reply-to: To: "Garrett D'Amore" Cc: "seth.goldberg@oracle.com" , Scott Rotondo , "PSARC-ext@sun.com" , Gangadhar Mylapuram Message-id: <4C0549D6.4040105@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C054A4D.001D:SCFMA4539814,ss=1,fgs=0 References: User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Status: RO Content-Length: 289 On 5/25/10 4:58 PM, Garrett D'Amore wrote: > So +1 on the case, since the issues seem settled now. > > -- Garrett > > Thanks all; I've now marked this case as closed approved, with final materials providing the original proposal plus updates as discussed and agreed upon. -jg