From sacadmin Tue May 19 15:22:23 2009 Received: from tethys.sfbay.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 n4JMMMXY026271; Tue, 19 May 2009 15:22:22 -0700 (PDT) Received: from tethys.sfbay.sun.com (localhost [127.0.0.1]) by tethys.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4JMM9FV021459; Tue, 19 May 2009 15:22:09 -0700 (PDT) Received: (from jg@localhost) by tethys.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n4JMM8fu021456; Tue, 19 May 2009 15:22:08 -0700 (PDT) Date: Tue, 19 May 2009 15:22:08 -0700 (PDT) From: Jerry Gilliam Message-Id: <200905192222.n4JMM8fu021456@tethys.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Configurable Boot Archive Updates [PSARC/2009/312 FastTrack timeout 05/26/2009] Status: RO Content-Length: 572 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Configurable Boot Archive Updates 1.2. Name of Document Author/Supplier: Author: Gangadhar Mylapuram 1.3 Date of This Document: 19 May, 2009 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 jg@jurassic.sfbay.Sun.COM Tue May 19 15:37:08 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4JMb8Rw026862 for ; Tue, 19 May 2009 15:37:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4JMb3M3017779; Tue, 19 May 2009 15:37:06 -0700 (PDT) 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 <0KJW00113XHTSE00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 19 May 2009 15:37:05 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJW007X1XHTXEE0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 19 May 2009 15:37:05 -0700 (PDT) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id n4JMasQ1168812; Tue, 19 May 2009 15:36:54 -0700 (PDT) Date: Tue, 19 May 2009 15:36:42 -0700 (PDT) From: Jerry Gilliam Subject: Configurable Boot Archive Updates [2009/312 05/26/2009] To: PSARC-ext@sun.com, Gangadhar.M@sun.com Cc: sherry.moore@sun.com, jan.setje-eilers@sun.com, enrico.perla@sun.com Reply-to: Jerry Gilliam Message-id: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: NNJbrwEtK/p0d21W7sbQyQ== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3358 I am sponsoring this fast-track on behalf of Gangadhar Mylapuram, with a timeout set to May 26, 2009. Patch/micro-release binding is requested. ========== 1. Introduction 1.1. Project/Component Working Name: Configurable Boot-archive Updates with uadmin(2) 1.2. Name of Document Author/Supplier: Author: Gangadhar Mylapuram 1.3. Date of This Document: 04/27/2009 1.3.1. Date this project was conceived: 04/06/2009 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. Solaris PAC 1.4.2. PSARC 1.4.3. Chris Armes 1.4.4. Solaris Sustaining 1.5. Email Aliases: 1.5.1. Responsible Manager: Narayana.Kadoor@sun.com 1.5.2. Responsible Engineer: Gangadhar.M@sun.com 1.5.3. Marketing Manager: 1.5.4. Interest List: Todd.Miller@sun.com, Robert.Dipietro@Sun.COM 2. Project Summary 2.1. Project Description: Provides a new attribute in Boot configuration service to permit boot-archive updates during uadmin(2) operations. Patch/micro-release binding requested. 3. Business Summary 3.1. Problem Area: Some customers require the use of uadmin(2) to reboot which can result in boot archive inconsistency on reboot since uadmin(2) does not update the boot archive, Other applications such as clustering require that uadmin(2) NOT update the archive, so always updating the archive cannot be made the default. 3.2. Market/Requester: Lucent Technologies 4. Technical Description: 4.1. Details: Introduce a new property, 'uadmin_boot_archive_sync', to config group in svc:/system/boot-config:default service. The default value of this property is config/uadmin_boot_archive_sync boolean false uadmin(2) system call will respect this property setting when determining whether to update boot-archive before rebooting. Customer may set this value to true if they want to reboot/halt/shutdown the system using uadmin interface and ensure that the boot archive remains in sync. 4.2. Bug/RFE Number(s): 6795430 newboot needs a fully supported way to automatically recover when boot archive is out of date 4.6. Doc Impact: Some additions required to Basic Administration guide, uadmin (2) and uadmin(1M) man pages to describe the new property introduced and how to make use of this property to update the boot-archive. 4.6.1 Man page of uadmin(2) and uadmin(1M) Shutting down or rebooting or halting the system by means of uadmin does not update the boot archive by default. To update the boot archive during these operations, set the uadmin_boot_archive_sync property of boot-config service to true. # svccfg -s svc:/system/boot-config:default setprop \ config/uadmin_boot_archive_sync="true" 4.8 Interfaces: svc:/system/boot-config committed per PSARC/2008/760 config/uadmin_boot_archive_sync committed boolean property 4.12. Dependencies: PSARC/2008/760 Boot configuration Service. Solaris 10 doesn't have this project integrated. This project introduces the boot-config service (but not fast reboot itself) portion of PSARC/2008/760. 5. Reference Documents: CR 6795430 http://monaco.sfbay/detail.jsf?cr=6795430 PSARC/2008/760 http://sac.sfbay/PSARC/2008/760/ 6. Resources and Schedule: Prototype is ready 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Wed May 20 01:10:37 2009 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 n4K8AaCT029346 for ; Wed, 20 May 2009 01:10:36 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4K8AYil021241 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 20 May 2009 01:10: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 <0KJX0060FO1N2C00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 02:10:35 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJX004WNO1MRL10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 02:10:34 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4K8AXnN022957 for ; Wed, 20 May 2009 08:10:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJX00F00NNDQ800@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 09:10:33 +0100 (BST) Received: from [10.0.216.167] (sxeuwww2.eu.sun.com [192.18.3.4]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJX00IM7O1KG200@fe-emea-09.sun.com>; Wed, 20 May 2009 09:10:32 +0100 (BST) Date: Wed, 20 May 2009 09:10:31 +0100 From: Darren J Moffat Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> Sender: Darren.Moffat@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Gangadhar.M@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com Message-id: <4A13BAF7.9030904@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 726 I really think this case is solving the wrong problem. The problem is that we depend on the boot archive at all and that we allow it to get out of date and even worse allow a system to stop very early in boot because of that. I would much rather see we solve the root cause and rethink the whole boot-archive issues - particularly in light of the fact that GRUB and OBP can actually read ZFS. For network boot the boot-archive approach is still desirable but the boot server can deal with the archive updates in that case. However I see that this case is providing value as is so even given the above I'm happy with the proposal and the release binding including the intent to backport to S10. -- Darren J Moffat From Gangadhar.M@sun.com Wed May 20 02:37:10 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4K9b9uJ000531 for ; Wed, 20 May 2009 02:37:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4K9ahfk020600 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 20 May 2009 17:37:08 +0800 (SGT) 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 <0KJX00E23S1TS800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 03:37:05 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJX0046FS1SRLE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 03:37:05 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4K9b3Lt027830 for ; Wed, 20 May 2009 09:37:03 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJX00000ROUAV00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 17:37:03 +0800 (SGT) Received: from [10.6.6.100] ([unknown] [59.92.166.244]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJX0013XS1QRTF0@mail-apac.sun.com>; Wed, 20 May 2009 17:37:03 +0800 (SGT) Date: Wed, 20 May 2009 15:07:03 +0530 From: Gangadhar Mylapuram Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A13BAF7.9030904@Sun.COM> Sender: Gangadhar.M@sun.com To: Darren J Moffat Cc: Jerry Gilliam , PSARC-ext@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com Message-id: <4A13CF3F.9020909@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 935 Darren J Moffat wrote: > I really think this case is solving the wrong problem. > > The problem is that we depend on the boot archive at all and that we > allow it to get out of date and even worse allow a system to stop very > early in boot because of that. > > I would much rather see we solve the root cause and rethink the whole > boot-archive issues - particularly in light of the fact that GRUB and > OBP can actually read ZFS. For network boot the boot-archive approach > is still desirable but the boot server can deal with the archive updates > in that case. As per Jan (Jan.Setje-Eilers@Sun.COM), this is going to be the long term approach (at least for now). Jan, Could you comment on this? > > However I see that this case is providing value as is so even given the > above I'm happy with the proposal and the release binding including the > intent to backport to S10. > > -- > Darren J Moffat Thanks, Gangadhar From carlsonj@phorcys.east.sun.com Wed May 20 09:47:42 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KGlfFG003933 for ; Wed, 20 May 2009 09:47:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KGlO74006272 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 20 May 2009 17:47:40 +0100 (BST) 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 <0KJY00B29BZF1O00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 20 May 2009 10:47:39 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY00J8WBZELGD0@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 20 May 2009 10:47:38 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KGlXEE049720; Wed, 20 May 2009 12:47:33 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4KGkZxa002830; Wed, 20 May 2009 12:46:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4KGkZnu002827; Wed, 20 May 2009 12:46:35 -0400 (EDT) Date: Wed, 20 May 2009 12:46:35 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A13CF3F.9020909@sun.com> To: Gangadhar Mylapuram Cc: Darren J Moffat , PSARC-ext@sun.com, Jerry Gilliam , Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, Enrico.Perla@sun.com Message-id: <18964.13291.214750.171507@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> Status: RO Content-Length: 2183 Gangadhar Mylapuram writes: > Darren J Moffat wrote: > > I really think this case is solving the wrong problem. > > > > The problem is that we depend on the boot archive at all and that we > > allow it to get out of date and even worse allow a system to stop very > > early in boot because of that. > > > > I would much rather see we solve the root cause and rethink the whole > > boot-archive issues - particularly in light of the fact that GRUB and > > OBP can actually read ZFS. For network boot the boot-archive approach > > is still desirable but the boot server can deal with the archive updates > > in that case. > > As per Jan (Jan.Setje-Eilers@Sun.COM), this is going to be the long term > approach (at least for now). The project as proposed doesn't actually fix the problem. If the system panics or power is removed, the very same issue occurs, and uadmin is not involved, so no enhancement of uadmin will work for those cases. The CR cited correctly describes archive failure as the problem, not uadmin. Worse still, having these odd parameters as "Committed" interfaces to satisfy the usage model of just one or a few customers sounds very likely to result in useless folklore about Solaris being "unreliable" and needing "special configuration" in order to make it usable in an enterprise environment. That situation is very much against everything we're trying to design. Solaris needs to work right straight out of the box. I'll go further than Darren: I think adding this sort of functionality to uadmin is the wrong thing to do and just promotes confusion. The underlying problem needs to be fixed; the system needs to recover coherently when the boot archive is found to be out of date at boot time. If the user can see this service fail, log into the system console, remount root as read/write, update the archive, and reboot into a working system, why can't the system itself just do this simply mechanical chore on its own? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Neal.Pollack@sun.com Wed May 20 09:59:42 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KGxfDp005611 for ; Wed, 20 May 2009 09:59:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KGxdl9014873 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 20 May 2009 17:59:40 +0100 (BST) 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 <0KJY00301CJGYR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 20 May 2009 09:59:40 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY002R9CJF4V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 20 May 2009 09:59:39 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4KGxdZE001666 for ; Wed, 20 May 2009 09:59:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJY00I00AE7T700@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 20 May 2009 09:59:39 -0700 (PDT) Received: from [10.1.48.130] ([unknown] [10.1.48.130]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJY00N16CJ24O70@fe-sfbay-10.sun.com>; Wed, 20 May 2009 09:59:27 -0700 (PDT) Date: Wed, 20 May 2009 09:59:13 -0700 From: Neal Pollack Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <18964.13291.214750.171507@gargle.gargle.HOWL> Sender: Neal.Pollack@sun.com To: James Carlson Cc: Gangadhar Mylapuram , Darren J Moffat , PSARC-ext@sun.com, Jerry Gilliam , Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, Enrico.Perla@sun.com Message-id: <4A1436E1.3000203@Sun.Com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dIQx0r5Ncb9zpplFaJbfPQ)" X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 5025 This is a multi-part message in MIME format. --Boundary_(ID_dIQx0r5Ncb9zpplFaJbfPQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 05/20/09 09:46 AM, James Carlson wrote: > Gangadhar Mylapuram writes: > >> Darren J Moffat wrote: >> >>> I really think this case is solving the wrong problem. >>> >>> The problem is that we depend on the boot archive at all and that we >>> allow it to get out of date and even worse allow a system to stop very >>> early in boot because of that. >>> >>> I would much rather see we solve the root cause and rethink the whole >>> boot-archive issues - particularly in light of the fact that GRUB and >>> OBP can actually read ZFS. For network boot the boot-archive approach >>> is still desirable but the boot server can deal with the archive updates >>> in that case. >>> >> As per Jan (Jan.Setje-Eilers@Sun.COM), this is going to be the long term >> approach (at least for now). >> > > The project as proposed doesn't actually fix the problem. If the > system panics or power is removed, the very same issue occurs, and > uadmin is not involved, so no enhancement of uadmin will work for > those cases. The CR cited correctly describes archive failure as the > problem, not uadmin. > > Worse still, having these odd parameters as "Committed" interfaces to > satisfy the usage model of just one or a few customers sounds very > likely to result in useless folklore about Solaris being "unreliable" > and needing "special configuration" in order to make it usable in an > enterprise environment. That situation is very much against > everything we're trying to design. Solaris needs to work right > straight out of the box. > > I'll go further than Darren: I think adding this sort of functionality > to uadmin is the wrong thing to do and just promotes confusion. The > underlying problem needs to be fixed; the system needs to recover > coherently when the boot archive is found to be out of date at boot > time. > > If the user can see this service fail, log into the system console, > remount root as read/write, update the archive, and reboot into a > working system, why can't the system itself just do this simply > mechanical chore on its own? > +1 --Boundary_(ID_dIQx0r5Ncb9zpplFaJbfPQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 05/20/09 09:46 AM, James Carlson wrote: 
Gangadhar Mylapuram writes:
  
Darren J Moffat wrote:
    
I really think this case is solving the wrong problem.

The problem is that we depend on the boot archive at all and that we
allow it to get out of date and even worse allow a system to stop very
early in boot because of that.

I would much rather see we solve the root cause and rethink the whole
boot-archive issues - particularly in light of the fact that GRUB and
OBP can actually read ZFS.  For network boot the boot-archive approach
is still desirable but the boot server can deal with the archive updates
in that case.
      
As per Jan (Jan.Setje-Eilers@Sun.COM), this is going to be the long term
approach (at least for now).
    

The project as proposed doesn't actually fix the problem.  If the
system panics or power is removed, the very same issue occurs, and
uadmin is not involved, so no enhancement of uadmin will work for
those cases.  The CR cited correctly describes archive failure as the
problem, not uadmin.

Worse still, having these odd parameters as "Committed" interfaces to
satisfy the usage model of just one or a few customers sounds very
likely to result in useless folklore about Solaris being "unreliable"
and needing "special configuration" in order to make it usable in an
enterprise environment.  That situation is very much against
everything we're trying to design.  Solaris needs to work right
straight out of the box.

I'll go further than Darren: I think adding this sort of functionality
to uadmin is the wrong thing to do and just promotes confusion.  The
underlying problem needs to be fixed; the system needs to recover
coherently when the boot archive is found to be out of date at boot
time.

If the user can see this service fail, log into the system console,
remount root as read/write, update the archive, and reboot into a
working system, why can't the system itself just do this simply
mechanical chore on its own?

+1



--Boundary_(ID_dIQx0r5Ncb9zpplFaJbfPQ)-- From casper@holland.sun.com Wed May 20 10:06:46 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KH6kF0006207 for ; Wed, 20 May 2009 10:06:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4KH6jFk029044 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 20 May 2009 10:06:46 -0700 (PDT) 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 <0KJY00501CV92G00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 20 May 2009 10:06:45 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY002HJCV74N10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 20 May 2009 10:06:44 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KH6bZS047781; Wed, 20 May 2009 18:06:37 +0100 (BST) Date: Wed, 20 May 2009 19:06:37 +0200 From: Casper.Dik@sun.com Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <18964.13291.214750.171507@gargle.gargle.HOWL> Sender: casper@holland.sun.com To: James Carlson Cc: Gangadhar Mylapuram , Darren J Moffat , PSARC-ext@sun.com, Jerry Gilliam , Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, Enrico.Perla@sun.com Message-id: <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> Status: RO Content-Length: 350 >If the user can see this service fail, log into the system console, >remount root as read/write, update the archive, and reboot into a >working system, why can't the system itself just do this simply >mechanical chore on its own? +1. (I will also need to reproduce a similar problem with smf which also needs to be fixed by the system) Casper From setje@sun.com Wed May 20 11:46:43 2009 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 n4KIkhtM008773 for ; Wed, 20 May 2009 11:46:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4KIkdHO025440; Wed, 20 May 2009 11:46:40 -0700 (PDT) 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 <0KJY00A1PHHR4B00@nwk-avmta-2.sfbay.sun.com>; Wed, 20 May 2009 11:46:39 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY00875HHRYZ30@nwk-avmta-2.sfbay.sun.com>; Wed, 20 May 2009 11:46:39 -0700 (PDT) Received: from [129.146.226.114] (smack.SFBay.Sun.COM [129.146.226.114]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4KIkcx9446153; Wed, 20 May 2009 11:46:38 -0700 (PDT) Date: Wed, 20 May 2009 11:46:38 -0700 From: Jan Setje-Eilers Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A13BAF7.9030904@Sun.COM> To: Darren J Moffat Cc: Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com Message-id: <4A14500E.3070103@sun.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 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1538 Is there any chance we can separate this case from a general archive recovery discussion? In particular this case attempts to provide a method to configure the archive update behavior n uadmin invocation in light of very different requirements depending on deployment. This configuration is needed regardless of the level to which the system can recover itself. Some background to help clarify the motivation for this particular case: The previous users of uadmin(3c) that we had encountered were clustering applications that require the ability to tear down a node as quickly as possible. The current customer as an update/configuration deployment framework that calls uadmin(3c) after applying the changes to the system. -jan Darren J Moffat wrote: > I really think this case is solving the wrong problem. > > The problem is that we depend on the boot archive at all and that we > allow it to get out of date and even worse allow a system to stop very > early in boot because of that. > > I would much rather see we solve the root cause and rethink the whole > boot-archive issues - particularly in light of the fact that GRUB and > OBP can actually read ZFS. For network boot the boot-archive approach > is still desirable but the boot server can deal with the archive updates > in that case. > > However I see that this case is providing value as is so even given the > above I'm happy with the proposal and the release binding including the > intent to backport to S10. > > -- > Darren J Moffat From setje@sun.com Wed May 20 11:47:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KIlYoh008806 for ; Wed, 20 May 2009 11:47:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KIlJoe027844; Wed, 20 May 2009 19:47:29 +0100 (BST) 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 <0KJY00M07HJ3CI00@brm-avmta-1.central.sun.com>; Wed, 20 May 2009 12:47:27 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY00F6RHJ2H750@brm-avmta-1.central.sun.com>; Wed, 20 May 2009 12:47:26 -0600 (MDT) Received: from [129.146.226.114] (smack.SFBay.Sun.COM [129.146.226.114]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4KIlPOj447343; Wed, 20 May 2009 11:47:26 -0700 (PDT) Date: Wed, 20 May 2009 11:47:25 -0700 From: Jan Setje-Eilers Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: James Carlson , Gangadhar Mylapuram , Darren J Moffat , PSARC-ext@sun.com, Jerry Gilliam , Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, Enrico.Perla@sun.com Message-id: <4A14503D.5010309@sun.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 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 832 Casper.Dik@Sun.COM wrote: >> If the user can see this service fail, log into the system console, >> remount root as read/write, update the archive, and reboot into a >> working system, why can't the system itself just do this simply >> mechanical chore on its own? > > > +1. (I will also need to reproduce a similar problem with smf which also > needs to be fixed by the system) > > Casper The risk there is that the system just identified itself as potentially unstable. Prior to zfs root we were very careful to perform this check before any fs is mounted rw, in order to avoid the possibility of corrupting data if the system were to run into issues with incompatible modules. If you all don't see a problem with this, I'm happy to implement the automated re-build during boot, it's not like it's much code. -jan From Scott.Rotondo@sun.com Wed May 20 12:00:23 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KJ0M4o012223 for ; Wed, 20 May 2009 12:00:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KJ0Kq9006072 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 20 May 2009 20:00:22 +0100 (BST) 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 <0KJY00A1LI4KY400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 12:00:20 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY008WUI4JZ540@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 12:00:20 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4KJ0Jk5010013 for ; Wed, 20 May 2009 19:00:19 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJY00200I3AFI00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 20 May 2009 13:00:19 -0600 (MDT) Received: from [129.146.108.62] ([unknown] [129.146.108.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJY00ECPI3PEQ30@mail-amer.sun.com>; Wed, 20 May 2009 12:59:49 -0600 (MDT) Date: Wed, 20 May 2009 11:58:50 -0700 From: Scott Rotondo Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A14500E.3070103@sun.com> Sender: Scott.Rotondo@sun.com To: Jan Setje-Eilers Cc: Darren J Moffat , Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com Message-id: <4A1452EA.7050004@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A14500E.3070103@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1336 Jan Setje-Eilers wrote: > > Is there any chance we can separate this case from a general archive > recovery discussion? > > In particular this case attempts to provide a method to configure the > archive update behavior n uadmin invocation in light of very different > requirements depending on deployment. This configuration is needed > regardless of the level to which the system can recover itself. > > Some background to help clarify the motivation for this particular case: > > The previous users of uadmin(3c) that we had encountered were > clustering applications that require the ability to tear down a node as > quickly as possible. The current customer as an update/configuration > deployment framework that calls uadmin(3c) after applying the changes to > the system. > > -jan If this view ultimately prevails, I think you should consider reversing the default so that the more robust behavior occurs unless you specifically disable it (e.g. for a clustered system). Besides optimizing for the common case, I think Jim Carlson makes a good point that you don't want to spread folklore that Solaris needs special tuning to be enterprise-worthy. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From carlsonj@phorcys.east.sun.com Wed May 20 12:01:18 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KJ1HW3020090 for ; Wed, 20 May 2009 12:01:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KJ1CD6006689; Wed, 20 May 2009 20:01:15 +0100 (BST) 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 <0KJY0000FI62NA00@brm-avmta-1.central.sun.com>; Wed, 20 May 2009 13:01:14 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY00FSII60H750@brm-avmta-1.central.sun.com>; Wed, 20 May 2009 13:01:12 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KJ13JO007420; Wed, 20 May 2009 15:01:03 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4KJ05n3003657; Wed, 20 May 2009 15:00:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4KJ05gg003654; Wed, 20 May 2009 15:00:05 -0400 (EDT) Date: Wed, 20 May 2009 15:00:05 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A14500E.3070103@sun.com> To: Jan Setje-Eilers Cc: Darren J Moffat , Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com, Casper.Dik@sun.com Message-id: <18964.21301.716433.81290@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> <4A14503D.5010309@sun.com> <4A14500E.3070103@sun.com> Status: RO Content-Length: 2146 Jan Setje-Eilers writes: > The previous users of uadmin(3c) that we had encountered were > clustering applications that require the ability to tear down a node as > quickly as possible. The current customer as an update/configuration > deployment framework that calls uadmin(3c) after applying the changes to > the system. Haven't we always documented uadmin(2) as the wrong way to do that? The current man page seems to be pretty clear that you're not supposed to call it unless you really know what you're doing (which would preclude calling it when the system is unstable). Jan Setje-Eilers writes: > > +1. (I will also need to reproduce a similar problem with smf which also > > needs to be fixed by the system) > > > > Casper > > The risk there is that the system just identified itself as > potentially unstable. Prior to zfs root we were very careful to perform > this check before any fs is mounted rw, in order to avoid the > possibility of corrupting data if the system were to run into issues > with incompatible modules. > > If you all don't see a problem with this, I'm happy to implement the > automated re-build during boot, it's not like it's much code. At least to me, one of the basic questions is: what the heck can the administrator realistically do when the archive is out of date? It is it at all plausible that someone might fix this problem by some means that do not include just "bootadm update-archive"? If so, then what exactly is that scenario? Or is it ever possible that someone might want to continue running despite the obvious problem? Again, if so, why? If there are no realistic cases where the user can do anything but update the archive based on the current disk contents, then this looks to me like the same sort of "please hang up and dial 1" annoyance features that we ought to be avoiding. Especially so given the annoying regularity of the problem ... -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@Sun.COM Wed May 20 12:10:35 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KJAX2m008121 for ; Wed, 20 May 2009 12:10:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4KJAIEm024062; Thu, 21 May 2009 03:10:23 +0800 (SGT) 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 <0KJY0043PILA8100@nwk-avmta-1.sfbay.Sun.COM>; Wed, 20 May 2009 12:10:22 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY002EKIL84R90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 20 May 2009 12:10:20 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4KJ80kP006315; Wed, 20 May 2009 14:08:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4KJ80fW006314; Wed, 20 May 2009 14:08:00 -0500 (CDT) Date: Wed, 20 May 2009 14:08:00 -0500 From: Nicolas Williams Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <18964.21301.716433.81290@gargle.gargle.HOWL> To: James Carlson Cc: Jan Setje-Eilers , Darren J Moffat , Jerry Gilliam , PSARC-ext@Sun.COM, Gangadhar.M@Sun.COM, Sherry.Moore@Sun.COM, Jan.Setje-Eilers@Sun.COM, Enrico.Perla@Sun.COM, Casper.Dik@Sun.COM Message-id: <20090520190759.GQ29258@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> <4A14503D.5010309@sun.com> <4A14500E.3070103@sun.com> <18964.21301.716433.81290@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1445 On Wed, May 20, 2009 at 03:00:05PM -0400, James Carlson wrote: > At least to me, one of the basic questions is: what the heck can the > administrator realistically do when the archive is out of date? > > It is it at all plausible that someone might fix this problem by some > means that do not include just "bootadm update-archive"? If so, then > what exactly is that scenario? Or is it ever possible that someone > might want to continue running despite the obvious problem? Again, if > so, why? > > If there are no realistic cases where the user can do anything but > update the archive based on the current disk contents, then this looks > to me like the same sort of "please hang up and dial 1" annoyance > features that we ought to be avoiding. > > Especially so given the annoying regularity of the problem ... > +1 There could be times where updating the archive won't be feasible because, say, a driver needed for mounting / needs to be updated to match a firmware update, and a panic occurs before the archive update -- if the driver and firmware have to be updated together then you have a brick. To fix this should require using a recovery CD or net boot. More complex cases might involve heavy hacking on /etc/system vis-a-vis the root filesystem. You'd be on your own then though. So if boot archive update can complete at boot time then that's the thing to do. The system should probably then reboot again. Nico -- From carlsonj@phorcys.east.sun.com Wed May 20 12:19:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KJJjxP006859 for ; Wed, 20 May 2009 12:19:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4KJJYVc028883; Thu, 21 May 2009 03:19:41 +0800 (SGT) 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 <0KJY00209J0RDX00@brm-avmta-1.central.sun.com>; Wed, 20 May 2009 13:19:39 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY00FGOJ0QH070@brm-avmta-1.central.sun.com>; Wed, 20 May 2009 13:19:38 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4KJJWgx064958; Wed, 20 May 2009 15:19:32 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4KJIYUE004127; Wed, 20 May 2009 15:18:34 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4KJIYea004124; Wed, 20 May 2009 15:18:34 -0400 (EDT) Date: Wed, 20 May 2009 15:18:34 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <20090520190759.GQ29258@Sun.COM> To: Nicolas Williams Cc: Jan Setje-Eilers , Darren J Moffat , Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com, Casper.Dik@sun.com Message-id: <18964.22410.586010.828413@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> <4A14503D.5010309@sun.com> <4A14500E.3070103@sun.com> <18964.21301.716433.81290@gargle.gargle.HOWL> <20090520190759.GQ29258@Sun.COM> Status: RO Content-Length: 1176 Nicolas Williams writes: > There could be times where updating the archive won't be feasible > because, say, a driver needed for mounting / needs to be updated to > match a firmware update, and a panic occurs before the archive update -- > if the driver and firmware have to be updated together then you have a > brick. To fix this should require using a recovery CD or net boot. > > More complex cases might involve heavy hacking on /etc/system vis-a-vis > the root filesystem. You'd be on your own then though. If so, then that argues for having either a flag that keeps the system from going into a potentially 'bad' rebuild / reboot / panic loop. (Whether the system sticks in the completely unusable maintenance mode or skips the update and runs crippled for this one corner seems like a coin toss to me.) I've rebuilt more archives than I care to count, and I can't say I've ever encountered such a problem, but I guess anything's possible. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Wed May 20 12:24:08 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KJO70Z007034 for ; Wed, 20 May 2009 12:24:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4KJNoVO001251; Thu, 21 May 2009 03:23:57 +0800 (SGT) 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 <0KJY00201J7WV600@brm-avmta-1.central.sun.com>; Wed, 20 May 2009 13:23:56 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY00FDSJ7VH270@brm-avmta-1.central.sun.com>; Wed, 20 May 2009 13:23:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4KJLdno006329; Wed, 20 May 2009 14:21:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4KJLdpK006328; Wed, 20 May 2009 14:21:39 -0500 (CDT) Date: Wed, 20 May 2009 14:21:39 -0500 From: Nicolas Williams Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <18964.22410.586010.828413@gargle.gargle.HOWL> To: James Carlson Cc: Jan Setje-Eilers , Darren J Moffat , Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com, Casper.Dik@sun.com Message-id: <20090520192138.GS29258@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> <4A14503D.5010309@sun.com> <4A14500E.3070103@sun.com> <18964.21301.716433.81290@gargle.gargle.HOWL> <20090520190759.GQ29258@Sun.COM> <18964.22410.586010.828413@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1618 On Wed, May 20, 2009 at 03:18:34PM -0400, James Carlson wrote: > Nicolas Williams writes: > > There could be times where updating the archive won't be feasible > > because, say, a driver needed for mounting / needs to be updated to > > match a firmware update, and a panic occurs before the archive update -- > > if the driver and firmware have to be updated together then you have a > > brick. To fix this should require using a recovery CD or net boot. > > > > More complex cases might involve heavy hacking on /etc/system vis-a-vis > > the root filesystem. You'd be on your own then though. > > If so, then that argues for having either a flag that keeps the system > from going into a potentially 'bad' rebuild / reboot / panic loop. Bad rebuild should cause a sulogin or a hang, not reboot. > (Whether the system sticks in the completely unusable maintenance mode > or skips the update and runs crippled for this one corner seems like a > coin toss to me.) If it can mount / rw (and /usr, if it's separate) then the boot archive can be rebuilt, otherwise the best you can do is give the user a sulogin/shell, or maybe not even (in which case rebooting won't help, so better just spew on console and wait for user input). > I've rebuilt more archives than I care to count, and I can't say I've > ever encountered such a problem, but I guess anything's possible. Me too -- I was just imagining what cases could fail to rebuild boot archives. All such cases would be the result of something bad having happened that is so rare that forcing fallback on a recovery CD or net boot seems reasonable. Nico -- From setje@sun.com Wed May 20 14:57:38 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4KLvcfK012370 for ; Wed, 20 May 2009 14:57:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4KLvVob001714; Wed, 20 May 2009 14:57:33 -0700 (PDT) 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 <0KJY00L0HQBWI400@nwk-avmta-2.sfbay.sun.com>; Wed, 20 May 2009 14:57:32 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJY00H28QBUH930@nwk-avmta-2.sfbay.sun.com>; Wed, 20 May 2009 14:57:30 -0700 (PDT) Received: from [129.146.226.114] (smack.SFBay.Sun.COM [129.146.226.114]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4KLvTtS627943; Wed, 20 May 2009 14:57:29 -0700 (PDT) Date: Wed, 20 May 2009 14:57:29 -0700 From: Jan Setje-Eilers Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <18964.21301.716433.81290@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com, Casper.Dik@sun.com Message-id: <4A147CC9.8000904@sun.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 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> <4A14503D.5010309@sun.com> <4A14500E.3070103@sun.com> <18964.21301.716433.81290@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3257 James Carlson wrote: > Jan Setje-Eilers writes: >> The previous users of uadmin(3c) that we had encountered were ^^ correction: uadmin(2), the syscall >> clustering applications that require the ability to tear down a node as >> quickly as possible. The current customer as an update/configuration >> deployment framework that calls uadmin(3c) after applying the changes to >> the system. > > Haven't we always documented uadmin(2) as the wrong way to do that? I suspect you looked at the page, but for the record, the language is: "This function is tightly coupled to the system administrative procedures and is not intended for general use." > The current man page seems to be pretty clear that you're not supposed > to call it unless you really know what you're doing (which would > preclude calling it when the system is unstable). I did quote that to the customer and then explained it to them further. They did understand, and weren't opposed to changing their tools, but had no method to roll out updated tools company wide. Interestingly they do have rather tight controls on system configuration, making configurable behavior a viable solution. The ability to configure this behavior does not as far as I can tell violate the definition of the uadmin interface, and may benefit more than just this one customer. > Jan Setje-Eilers writes: >>> +1. (I will also need to reproduce a similar problem with smf which also >>> needs to be fixed by the system) >>> >>> Casper >> The risk there is that the system just identified itself as >> potentially unstable. Prior to zfs root we were very careful to perform >> this check before any fs is mounted rw, in order to avoid the >> possibility of corrupting data if the system were to run into issues >> with incompatible modules. >> >> If you all don't see a problem with this, I'm happy to implement the >> automated re-build during boot, it's not like it's much code. > > At least to me, one of the basic questions is: what the heck can the > administrator realistically do when the archive is out of date? > > It is it at all plausible that someone might fix this problem by some > means that do not include just "bootadm update-archive"? If so, then > what exactly is that scenario? Or is it ever possible that someone > might want to continue running despite the obvious problem? Again, if > so, why? If the administrator knows why the archive is out of date and is for instance willing to move forward using the older driver (if it has already been loaded) they can simply clear the service and drive on. If whatever files that are out of sync were not used yet (say a driver that's not part of the boot path), then it's safe to drive on and the fact that the test failed is really a bug. > If there are no realistic cases where the user can do anything but > update the archive based on the current disk contents, then this looks > to me like the same sort of "please hang up and dial 1" annoyance > features that we ought to be avoiding. > > Especially so given the annoying regularity of the problem ... We have some plans to address these issues from multiple directions, but that is a separate case. -jan From carlsonj@phorcys.east.sun.com Thu May 21 05:39:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4LCdOaj015936 for ; Thu, 21 May 2009 05:39:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4LCdKvo008853; Thu, 21 May 2009 20:39:21 +0800 (SGT) 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 <0KJZ00A0PV5K5600@nwk-avmta-2.sfbay.sun.com>; Thu, 21 May 2009 05:39:20 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJZ00JHSV5JGSB0@nwk-avmta-2.sfbay.sun.com>; Thu, 21 May 2009 05:39:20 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4LCdEux001836; Thu, 21 May 2009 08:39:14 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4LCcF3p005957; Thu, 21 May 2009 08:38:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4LCcFIu005954; Thu, 21 May 2009 08:38:15 -0400 (EDT) Date: Thu, 21 May 2009 08:38:15 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A147CC9.8000904@sun.com> To: Jan Setje-Eilers Cc: Darren J Moffat , Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Sherry.Moore@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com, Casper.Dik@sun.com Message-id: <18965.19255.713929.778665@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> <4A14503D.5010309@sun.com> <4A14500E.3070103@sun.com> <18964.21301.716433.81290@gargle.gargle.HOWL> <4A147CC9.8000904@sun.com> Status: RO Content-Length: 5214 Jan Setje-Eilers writes: > James Carlson wrote: > > The current man page seems to be pretty clear that you're not supposed > > to call it unless you really know what you're doing (which would > > preclude calling it when the system is unstable). > > I did quote that to the customer and then explained it to them > further. They did understand, and weren't opposed to changing their > tools, but had no method to roll out updated tools company wide. > Interestingly they do have rather tight controls on system > configuration, making configurable behavior a viable solution. The > ability to configure this behavior does not as far as I can tell violate > the definition of the uadmin interface, and may benefit more than just > this one customer. As it doesn't cover the other boot-time issues, and it currently is just for one customer, I still think it's a hack. And I'm very much concerned that providing a tunable here will drive customers in exactly the wrong direction. If you wanted a private interface for this (say, an undocumented /etc file or /etc/default entry or /etc/system variable that is written up in an infodoc article and explained to this one customer), then I'd be more supportive of the change. I'd still think that you're putting _way_ too many moving parts into the uadmin(2) system call interface (how exactly does a syscall invoke a user-space archive rebuild anyway? or did you mean uadmin(1M)?), but making that one customer happy sounds like a good trade-off. However, you're proposing it as a public interface, and as something we're committing to for the long term. Given that it doesn't actually solve the underlying problem, and that it mistakenly tells customers that Solaris isn't safe to use, and that the default is to be "unsafe," I can't agree with that. > > It is it at all plausible that someone might fix this problem by some > > means that do not include just "bootadm update-archive"? If so, then > > what exactly is that scenario? Or is it ever possible that someone > > might want to continue running despite the obvious problem? Again, if > > so, why? > > If the administrator knows why the archive is out of date and is for > instance willing to move forward using the older driver (if it has > already been loaded) they can simply clear the service and drive on. It may have already been loaded, but the fact that it's out of sync with the one on disk means: - If it happens to unload, then the next load will cause a *different* copy of the driver to be loaded, with possibly unexpected results. It's all timing dependent and hard to predict. - The fact that it's out of date with respect to the disk is a likely indication that this isn't the only problem. There may well be applications that depend on that driver (drivers usually aren't too interesting without at least some applications that use them), and the fact that the driver has been updated on disk likely indicates that the non-archive-resident applications have *also* been updated by the same patching process. For the normal administrator -- one who hasn't yet memorized the source code for the drivers -- I suspect that the behavior is just unpredictable. I can't see how anyone would accept that as a reasonable risk for running the system, when the alternative is to spend a couple of minutes rebuilding the archive and rebooting to get a stable and predictable system. Perhaps more importantly: if someone actually did this, and then later ran into a problem, what would our support people say when they got the call? > If > whatever files that are out of sync were not used yet (say a driver > that's not part of the boot path), then it's safe to drive on and the > fact that the test failed is really a bug. Can we fix that bug? At the point when the real root is mounted, is it possible to remember the files that have been used, so that when we later check the archive, we know whether the out-of-date files have been used by accident? In any event, this is just a hard-to-predict corner case. As with the other one, rebuilding is safer and easier. It's possible that driver developers and others hacking around in the kernel may know when skipping an archive rebuild is ok, but I'm not seeing a good argument for providing that sort of functionality to regular system administrators. > > If there are no realistic cases where the user can do anything but > > update the archive based on the current disk contents, then this looks > > to me like the same sort of "please hang up and dial 1" annoyance > > features that we ought to be avoiding. > > > > Especially so given the annoying regularity of the problem ... > > We have some plans to address these issues from multiple directions, > but that is a separate case. I don't agree that it's a separate case as long as we're talking about a committed interface and a higher-level statement of direction regarding uadmin. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Fri May 22 02:33:25 2009 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 n4M9XOtX028148 for ; Fri, 22 May 2009 02:33:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4M9XNJj010277 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 22 May 2009 02:33:24 -0700 (PDT) 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 <0KK100H11H7N0100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 May 2009 02:33:23 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK100C5CH7L9E20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 May 2009 02:33:22 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4M9XLQI025355 for ; Fri, 22 May 2009 09:33:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK100C00GSUON00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 May 2009 10:33:21 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK100LBXH78OBD0@fe-emea-10.sun.com>; Fri, 22 May 2009 10:33:08 +0100 (BST) Date: Fri, 22 May 2009 10:33:06 +0100 From: Darren J Moffat Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> Sender: Darren.Moffat@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Gangadhar.M@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com, Sherry.Moore@sun.com Message-id: <4A167152.3000809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1276 I'm derailing this case there appears to be a very strong consensus from those that have commented on the case that: a) it doesn't solve the root causes of the problem b) it could actually make it worse in some cases c) makes Solaris look like it needs tuning for enterprise use. While the case technical content is obvious it is highly controversial. I've thought about this more and I now feel so strongly about this case that I would actually vote against it despite my previous comments. We need to stop "patching" and "hacking" around this issue and solve the issue with the boot archive inconsistency once and for all. Either by removing the use of the boot archive completely when booting from disk (assuming doing so doesn't introduce a boot time regression) or by ensuring that it is never out of date. The solution to this should assume that at the time of uadmin we can't write to the root filesystem. I have rebuilt many many boot archives and not once have I ever been in a situation where anything other than "svcadm clear boot-archive" or boot from the failsafe and update it were the correct solution. Sure this is a kernel developers view but an admin has even less chance of knowing if there is another solution. -- Darren J Moffat From bart.smaalders@sun.com Fri May 22 11:12:34 2009 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 n4MICXks002337 for ; Fri, 22 May 2009 11:12:33 -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.2) with ESMTP id n4MICQNa006651; Fri, 22 May 2009 12:12:28 -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 <0KK20000Z58RQC00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 22 May 2009 11:12:27 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK2008C458Q70F0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 22 May 2009 11:12:26 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id n4MICQFv007153; Fri, 22 May 2009 18:12:26 +0000 (GMT) Date: Fri, 22 May 2009 11:12:20 -0700 From: Bart Smaalders Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A167152.3000809@Sun.COM> To: Darren J Moffat Cc: Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com, Sherry.Moore@sun.com Message-id: <4A16EB04.9060504@Sun.COM> Organization: Sun Microsystems 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 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A167152.3000809@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1874 Darren J Moffat wrote: > We need to stop "patching" and "hacking" around this issue and solve the > issue with the boot archive inconsistency once and for all. Either by > removing the use of the boot archive completely when booting from disk > (assuming doing so doesn't introduce a boot time regression) or by > ensuring that it is never out of date. The solution to this should > assume that at the time of uadmin we can't write to the root filesystem. This means either we cannot use a boot archive, or that we need to eliminate the existence of the uadmin command. The former means we need to invent and maintain two separate ways of booting (one for network boot, one for disk based boot), and the later means a rather incompatible change, and still it doesn't take care of the panic during patching problem we have in S10 today. The problem with the boot archive being out of date is inevitable if you allow in-situ modification of any components needed for booting on the live system; this is the way most of our customers patch their S10 systems and there is an unavoidable window of vulnerability here. Note that the "panic during patching problem" isn't solved by getting rid of boot archives, since the components in the filesystem may not form a coherent bootable set anyway. The boot archive merely expands the WoV, and according to Roger, such windows are either open or closed. If you're going to stand on architectural principle, then fix the entire underlying problem, rather than going off on boot archives. Otherwise you're just arguing about what constitutes a more serious problem for the customer - interesting and useful perhaps, but not really architectural. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From setje@sun.com Fri May 22 11:20:34 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MIKYNr002460 for ; Fri, 22 May 2009 11:20:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4MIKUMO009263; Fri, 22 May 2009 11:20:30 -0700 (PDT) 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 <0KK20050D5M6BG00@nwk-avmta-2.sfbay.sun.com>; Fri, 22 May 2009 11:20:30 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK2004AL5M59W20@nwk-avmta-2.sfbay.sun.com>; Fri, 22 May 2009 11:20:29 -0700 (PDT) Received: from [129.146.226.114] (smack.SFBay.Sun.COM [129.146.226.114]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4MIKSnk212613; Fri, 22 May 2009 11:20:29 -0700 (PDT) Date: Fri, 22 May 2009 11:20:28 -0700 From: Jan Setje-Eilers Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A167152.3000809@Sun.COM> To: Darren J Moffat Cc: Jerry Gilliam , PSARC-ext@sun.com, Gangadhar.M@sun.com, Jan.Setje-Eilers@sun.com, Enrico.Perla@sun.com, sherry.moore@sun.com Message-id: <4A16ECEC.5010902@sun.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 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A167152.3000809@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2423 Darren J Moffat wrote: > I'm derailing this case there appears to be a very strong consensus from > those that have commented on the case that: > a) it doesn't solve the root causes of the problem > b) it could actually make it worse in some cases > c) makes Solaris look like it needs tuning for enterprise use. This sounds like you're simply opposed to this case, I'm not sure I understand what you hope to achieve by derailing it. I actually agree with much that James has brought up and have been considering ways to make this a non-public interface that will work to get this customer out of their current situation. > While the case technical content is obvious it is highly controversial. > > I've thought about this more and I now feel so strongly about this case > that I would actually vote against it despite my previous comments. > > We need to stop "patching" and "hacking" around this issue and solve the > issue with the boot archive inconsistency once and for all. Either by > removing the use of the boot archive completely when booting from disk > (assuming doing so doesn't introduce a boot time regression) or by > ensuring that it is never out of date. The solution to this should > assume that at the time of uadmin we can't write to the root filesystem. That doesn't explain why it's wrong to attempt to update the archive if we can though. This is all an attempt to provide a self-consistent view of the world at the time the system shuts down. When the live system is anything but read-only, there are no hard guarantees surrounding this without the archive either, so perhaps your real complaint is the existence of the check. > I have rebuilt many many boot archives and not once have I ever been in > a situation where anything other than "svcadm clear boot-archive" or > boot from the failsafe and update it were the correct solution. Sure > this is a kernel developers view but an admin has even less chance of > knowing if there is another solution. There is work both to perform automated recovery, as well as to further refine the check (to automatically drive on whenever "clear" was the right solution) under way. However I don't see how that has anything to do with whether or not it is correct to update the archives on udamin when we can (ie the administrator has declared it reasonable to perform work at that point). -jan From carlsonj@phorcys.east.sun.com Fri May 22 11:56:54 2009 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 n4MIusqM003748 for ; Fri, 22 May 2009 11:56:54 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4MIub4w015988; Fri, 22 May 2009 11:56:54 -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 <0KK2002037ATNB00@brm-avmta-1.central.sun.com>; Fri, 22 May 2009 12:56:53 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK200D067ASCHA0@brm-avmta-1.central.sun.com>; Fri, 22 May 2009 12:56:53 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4MIulRc032134; Fri, 22 May 2009 14:56:47 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4MItiq5010735; Fri, 22 May 2009 14:55:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4MItiNN010732; Fri, 22 May 2009 14:55:44 -0400 (EDT) Date: Fri, 22 May 2009 14:55:44 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A16ECEC.5010902@sun.com> To: Jan Setje-Eilers Cc: Darren J Moffat , Enrico.Perla@sun.com, Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, PSARC-ext@sun.com, Jerry Gilliam , Gangadhar.M@sun.com Message-id: <18966.62768.633111.438019@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A167152.3000809@Sun.COM> <4A16ECEC.5010902@sun.com> Status: RO Content-Length: 1951 Jan Setje-Eilers writes: > Darren J Moffat wrote: > > I'm derailing this case there appears to be a very strong consensus from > > those that have commented on the case that: > > a) it doesn't solve the root causes of the problem > > b) it could actually make it worse in some cases > > c) makes Solaris look like it needs tuning for enterprise use. > > This sounds like you're simply opposed to this case, I'm not sure I > understand what you hope to achieve by derailing it. The main thing it'd achieve would be the creation of a written opinion and a vote on the project, rather than just letting it get approved. That doesn't seem like a bad thing, especially since we'd effectively be reversing a decision we made in PSARC 2004/454. I agree with you that it doesn't seem like there's a great deal more to discuss at a meeting, other than perhaps user documentation, but I suppose I could be missing something. > There is work both to perform automated recovery, as well as to > further refine the check (to automatically drive on whenever "clear" was > the right solution) under way. However I don't see how that has anything > to do with whether or not it is correct to update the archives on udamin > when we can (ie the administrator has declared it reasonable to perform > work at that point). I'd still like to know if we're talking about uadmin(1M) or uadmin(2). If it's the latter, then I'm really curious about how this will actually work. Does libc's syscall wrapper check for the flag and fork/exec the archive update? Is it some magic in the kernel? Or something else entirely? If it's the former, then are we sure the customer doesn't just use uadmin(2) from his application? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Gangadhar.M@sun.com Fri May 22 12:50:27 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MJoQZY002002 for ; Fri, 22 May 2009 12:50:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4MJoP6h019847 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 22 May 2009 20:50:25 +0100 (BST) 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 <0KK200K059S13B00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 May 2009 12:50:25 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK200HKP9RZW040@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 May 2009 12:50:24 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4MJoNTT018495 for ; Fri, 22 May 2009 19:50:23 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK2003009RQL400@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 23 May 2009 03:50:23 +0800 (SGT) Received: from [10.6.6.100] ([unknown] [59.92.223.174]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK2008SO9RVL040@mail-apac.sun.com>; Sat, 23 May 2009 03:50:23 +0800 (SGT) Date: Sat, 23 May 2009 01:20:21 +0530 From: Gangadhar Mylapuram Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <18966.62768.633111.438019@gargle.gargle.HOWL> Sender: Gangadhar.M@sun.com To: James Carlson Cc: Jan Setje-Eilers , Darren J Moffat , Enrico.Perla@sun.com, Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, PSARC-ext@sun.com, Jerry Gilliam Message-id: <4A1701FD.3070002@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A167152.3000809@Sun.COM> <4A16ECEC.5010902@sun.com> <18966.62768.633111.438019@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2034 James Carlson wrote: > Jan Setje-Eilers writes: >> Darren J Moffat wrote: >>> I'm derailing this case there appears to be a very strong consensus from >>> those that have commented on the case that: >>> a) it doesn't solve the root causes of the problem >>> b) it could actually make it worse in some cases >>> c) makes Solaris look like it needs tuning for enterprise use. >> This sounds like you're simply opposed to this case, I'm not sure I >> understand what you hope to achieve by derailing it. > > The main thing it'd achieve would be the creation of a written opinion > and a vote on the project, rather than just letting it get approved. > That doesn't seem like a bad thing, especially since we'd effectively > be reversing a decision we made in PSARC 2004/454. > > I agree with you that it doesn't seem like there's a great deal more > to discuss at a meeting, other than perhaps user documentation, but I > suppose I could be missing something. > >> There is work both to perform automated recovery, as well as to >> further refine the check (to automatically drive on whenever "clear" was >> the right solution) under way. However I don't see how that has anything >> to do with whether or not it is correct to update the archives on udamin >> when we can (ie the administrator has declared it reasonable to perform >> work at that point). > > I'd still like to know if we're talking about uadmin(1M) or > uadmin(2). If it's the latter, then I'm really curious about how this > will actually work. Does libc's syscall wrapper check for the flag > and fork/exec the archive update? Is it some magic in the kernel? Or > something else entirely? If it's the former, then are we sure the > customer doesn't just use uadmin(2) from his application? > It is uadmin(2) that we are modifying : Snv webrev: http://jurassic.eng/net/ssaesrv.eng/export/users/gm149974/scratch/bootadm/webrev/ S10 webrev: http://jurassic.eng/net/on10-public.sfbay/builds/gm149974/s10sust/webrev/ Thanks, Gangadhar From carlsonj@phorcys.east.sun.com Fri May 22 15:27:12 2009 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 n4MMRCAT007884 for ; Fri, 22 May 2009 15:27:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4MMRBiu006437 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Fri, 22 May 2009 15:27:12 -0700 (PDT) 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 <0KK200L4BH1CCO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 22 May 2009 15:27:12 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK200C5SH1AHX60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 22 May 2009 15:27:11 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4MMR49o005332; Fri, 22 May 2009 18:27:04 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4MMQ5RS011788; Fri, 22 May 2009 18:26:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4MMQ5AX011785; Fri, 22 May 2009 18:26:05 -0400 (EDT) Date: Fri, 22 May 2009 18:26:05 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A16EB04.9060504@Sun.COM> To: Bart Smaalders Cc: Darren J Moffat , Enrico.Perla@sun.com, Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, PSARC-ext@sun.com, Jerry Gilliam , Gangadhar.M@sun.com Message-id: <18967.9853.697839.824497@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A167152.3000809@Sun.COM> <4A16EB04.9060504@Sun.COM> Status: RO Content-Length: 2261 Bart Smaalders writes: > This means either we cannot use a boot archive, or that we need to > eliminate the existence of the uadmin command. The former means we need I'd be willing to go for a middle ground: just make it so that the user doesn't have to know that the archive exists. It rebuilds when it needs to, and doesn't when it doesn't. > systems and there is an unavoidable window of vulnerability here. Note > that the "panic during patching problem" isn't solved by getting rid of > boot archives, since the components in the filesystem may not form > a coherent bootable set anyway. The boot archive merely expands the > WoV, and according to Roger, such windows are either open or closed. Yep; understood. If the system happens to go down with inconsistent bits on disk, then you're in a very sad place. I hope you either backed the system first, or you take it as an object lesson in the goodness of tools such as Live Upgrade, so that at least some good comes of it. In the other cases, though, the current behavior is just plain annoying. It doesn't help, and it hurts in all the cases where the bits on the disk are "right" but just don't happen to match what was last stored in the archive. > If you're going to stand on architectural principle, then fix the entire > underlying problem, rather than going off on boot archives. Otherwise > you're just arguing about what constitutes a more serious problem > for the customer - interesting and useful perhaps, but not really > architectural. The architectural matters here are that (a) the bits natively on the disk [not in the archive] are the real ones and (b) nothing but inconsistency or corruption in the *real* bits should stop the system from coming up. The boot archive is just supposed to be a cache. If it's inconsistent, that shouldn't turn the system into a warm brick as it does today. It should cause the system to come up more slowly. Stopping the system because archive doesn't match disk just seems like confusing map for terrain to me. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Mon May 25 07:21:00 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4PEKxvp008149 for ; Mon, 25 May 2009 07:21:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4PEKoCb015894 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 25 May 2009 15:20:58 +0100 (BST) 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 <0KK700F1PEIVRQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 May 2009 07:20:55 -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 <0KK700MAKEIV9GB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 May 2009 07:20:55 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4PEIUDh024923 for ; Mon, 25 May 2009 14:20:54 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-4655074 for PSARC-ext@sun.com; Mon, 25 May 2009 14:20:54 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-29819196 for PSARC-ext@sun.com; Mon, 25 May 2009 14:20:52 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay4i.sun.com with ESMTP id BT-MMP-1768305 for PSARC-ext@sun.com; Mon, 25 May 2009 14:19:29 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id C0EFE6F054A; Mon, 25 May 2009 16:18:50 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 0B5956F053C; Mon, 25 May 2009 16:18:50 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.13.7) with SMTP id n4PEInXg006607; Mon, 25 May 2009 16:18:49 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 May 2009 16:18:49 +0200 Date: Mon, 25 May 2009 16:18:45 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A147CC9.8000904@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: setje@sun.com, james.d.carlson@sun.com Cc: Sherry.Moore@sun.com, PSARC-ext@sun.com, jg@jurassic.sfbay.Sun.COM, Jan.Setje-Eilers@sun.com, Gangadhar.M@sun.com, Enrico.Perla@sun.com, Casper.Dik@sun.com Message-id: <4a1aa8c5.M3BjG9KMN78VW5Ub%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.069sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> <4A14503D.5010309@sun.com> <4A14500E.3070103@sun.com> <18964.21301.716433.81290@gargle.gargle.HOWL> <4A147CC9.8000904@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 25 May 2009 14:18:49.0271 (UTC) FILETIME=[B8FA0470:01C9DD43] Status: RO Content-Length: 678 Jan Setje-Eilers wrote: > > Haven't we always documented uadmin(2) as the wrong way to do that? > > I suspect you looked at the page, but for the record, the language is: > > "This function is tightly coupled to the system > administrative procedures and is not intended for > general use." Souldn't this be updated since uadmin now supports suspend/resume? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From setje@sun.com Tue May 26 11:04:23 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QI4Mq9018928 for ; Tue, 26 May 2009 11:04:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QI4BuR009291; Tue, 26 May 2009 19:04:16 +0100 (BST) 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 <0KK900D05JJ1B500@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 May 2009 11:04:13 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK900CFZJJ1TK20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 May 2009 11:04:13 -0700 (PDT) Received: from [129.146.226.114] (smack.SFBay.Sun.COM [129.146.226.114]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4QI4Cih725211; Tue, 26 May 2009 11:04:12 -0700 (PDT) Date: Tue, 26 May 2009 11:04:12 -0700 From: Jan Setje-Eilers Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4a1aa8c5.M3BjG9KMN78VW5Ub%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling Cc: james.d.carlson@sun.com, sherry.moore@sun.com, PSARC-ext@sun.com, jg@jurassic.sfbay.Sun.COM, Jan.Setje-Eilers@sun.com, Gangadhar.M@sun.com, Enrico.Perla@sun.com, Casper.Dik@sun.com Message-id: <4A1C2F1C.4040208@sun.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 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A13BAF7.9030904@Sun.COM> <4A13CF3F.9020909@sun.com> <18964.13291.214750.171507@gargle.gargle.HOWL> <200905201706.n4KH6bZS047781@dm-holland-02.uk.sun.com> <4A14503D.5010309@sun.com> <4A14500E.3070103@sun.com> <18964.21301.716433.81290@gargle.gargle.HOWL> <4A147CC9.8000904@sun.com> <4a1aa8c5.M3BjG9KMN78VW5Ub%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 501 Joerg Schilling wrote: > Jan Setje-Eilers wrote: > >>> Haven't we always documented uadmin(2) as the wrong way to do that? >> I suspect you looked at the page, but for the record, the language is: >> >> "This function is tightly coupled to the system >> administrative procedures and is not intended for >> general use." > > Souldn't this be updated since uadmin now supports suspend/resume? I'd consider that to still hold. sys-suspend(1) is the general entry-point. -jan From gww@eng.sun.com Tue May 26 11:34:09 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QIY9eJ019484 for ; Tue, 26 May 2009 11:34:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QIY3lG027814; Tue, 26 May 2009 19:34:07 +0100 (BST) 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 <0KK900E1JKWTDQ00@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 12:34:05 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK9005ACKWS85F0@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 12:34:04 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QIY0BL029479; Tue, 26 May 2009 11:34:01 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n4QIWcao010876; Tue, 26 May 2009 11:32:38 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n4QIWciV010875; Tue, 26 May 2009 11:32:38 -0700 (PDT) Date: Tue, 26 May 2009 11:32:38 -0700 (PDT) From: Gary Winiger Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] To: Joerg.Schilling@fokus.fraunhofer.de, setje@sun.com Cc: james.d.carlson@sun.com, sherry.moore@sun.com, PSARC-ext@sun.com, jg@jurassic.sfbay.sun.com, Jan.Setje-Eilers@sun.com, Gangadhar.M@sun.com, Enrico.Perla@sun.com, Casper.Dik@sun.com Message-id: <200905261832.n4QIWciV010875@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 980 > >>> Haven't we always documented uadmin(2) as the wrong way to do that? > >> I suspect you looked at the page, but for the record, the language is: > >> > >> "This function is tightly coupled to the system > >> administrative procedures and is not intended for > >> general use." > > > > Souldn't this be updated since uadmin now supports suspend/resume? No. As I've said before uadmin(1m) should be used. uadmin(1m) will appropriately shutdown services as needed across reboot and suspend/resume. > I'd consider that to still hold. sys-suspend(1) is the general > entry-point. If this is the PSARC/2009/112 sys-suspend(1), that's fine also. Though it does have some unresolved bugs. It is an interface that also will appropriately shutdown services. There are still issues going forward that the powermanagement team needs to resolve before there is a fully functional result. Fortunately this are below the uadmin(1m)/sys-suspend(1) layer. Gary.. From Scott.Rotondo@sun.com Tue May 26 11:57:12 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QIvBYM020386 for ; Tue, 26 May 2009 11:57:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4QIv3jr017703 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 27 May 2009 02:57:10 +0800 (SGT) 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 <0KK900G29LZ8RB00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 May 2009 12:57:08 -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 <0KK900EFSLZ7H910@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 May 2009 12:57:07 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QIv7bF013615 for ; Tue, 26 May 2009 18:57:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK900G00LQ0I900@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 May 2009 12:57:07 -0600 (MDT) Received: from [129.146.108.62] ([unknown] [129.146.108.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK9003KALYYR9D0@mail-amer.sun.com>; Tue, 26 May 2009 12:56:58 -0600 (MDT) Date: Tue, 26 May 2009 11:55:59 -0700 From: Scott Rotondo Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <18967.9853.697839.824497@gargle.gargle.HOWL> Sender: Scott.Rotondo@sun.com To: James Carlson Cc: Bart Smaalders , Darren J Moffat , Enrico.Perla@sun.com, Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, PSARC-ext@sun.com, Jerry Gilliam , Gangadhar.M@sun.com Message-id: <4A1C3B3F.5000205@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A167152.3000809@Sun.COM> <4A16EB04.9060504@Sun.COM> <18967.9853.697839.824497@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2248 James Carlson wrote: > The architectural matters here are that (a) the bits natively on the > disk [not in the archive] are the real ones and (b) nothing but > inconsistency or corruption in the *real* bits should stop the system > from coming up. The boot archive is just supposed to be a cache. If > it's inconsistent, that shouldn't turn the system into a warm brick as > it does today. It should cause the system to come up more slowly. If you accept the idea that the boot archive is just a cache for the filesystem contents, that seems to have two consequences: 1. If the boot archive and the filesystem ever disagree, the boot archive is wrong. The right (unconditional) action is to rebuild the boot archive and boot again. This can only fail if the filesystem contents themselves are incorrect. [1] Does everyone agree with the paragraph above, or are there additional complications? 2. The mechanism proposed by this case is never needed for consistency (since we can always rebuild the boot archive on the next boot), but it may be a useful optimization to make the boot-time consistency check pass more often. It seems like we could achieve the same optimization without affecting uadmin(2) and without having to disable the optimization for clustered systems. A background service could periodically check the boot archive for consistency and rebuild if necessary. [2] Nothing special is needed in uadmin(2), and the current reboot check would generally succeed without stopping to rebuild the archive. Perhaps this idea has been considered before and rejected, but I don't know why. Can anyone enlighten me? Scott [1] If booting fails a second time, after rebuilding the boot archive, then the archive and filesystem are no longer inconsistent. At that point, it's reasonable to boot the failsafe archive and leave it to the user to (somehow) repair the damage. [2] We'd probably want to allow for settling time (e.g. make sure at least a minute has passed since the last file was updated) to avoid rebuilding in the middle of a patch/package install. -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From carlsonj@phorcys.east.sun.com Tue May 26 12:27:34 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QJRXnp018574 for ; Tue, 26 May 2009 12:27:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4QJRXOx028149 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Tue, 26 May 2009 12:27:33 -0700 (PDT) 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 <0KK900901NDXAI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 26 May 2009 12:27:33 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK9002OLNDWRQ80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 26 May 2009 12:27:33 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QJRQtS057214; Tue, 26 May 2009 15:27:26 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4QJQPc8016503; Tue, 26 May 2009 15:26:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4QJQPWO016500; Tue, 26 May 2009 15:26:25 -0400 (EDT) Date: Tue, 26 May 2009 15:26:25 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A1C3B3F.5000205@sun.com> To: Scott Rotondo Cc: Bart Smaalders , Darren J Moffat , Enrico.Perla@sun.com, Jan.Setje-Eilers@sun.com, Sherry.Moore@sun.com, PSARC-ext@sun.com, Jerry Gilliam , Gangadhar.M@sun.com Message-id: <18972.16993.162111.817542@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A167152.3000809@Sun.COM> <4A16EB04.9060504@Sun.COM> <18967.9853.697839.824497@gargle.gargle.HOWL> <4A1C3B3F.5000205@sun.com> Status: RO Content-Length: 1403 Scott Rotondo writes: > 1. If the boot archive and the filesystem ever disagree, the boot > archive is wrong. The right (unconditional) action is to rebuild the > boot archive and boot again. This can only fail if the filesystem > contents themselves are incorrect. [1] > > Does everyone agree with the paragraph above, or are there additional > complications? I do. It's unclear whether _everyone_ does. > Perhaps this idea has been considered before and rejected, but I don't > know why. Can anyone enlighten me? The periodic rebuild was considered during the original newboot case, and rejected because it was too hackish -- we should know when things change and rebuild only when necessary. > [2] We'd probably want to allow for settling time (e.g. make sure at > least a minute has passed since the last file was updated) to avoid > rebuilding in the middle of a patch/package install. It might not be feasible in general to avoid smacking into an update of some sort, but the idea of making sure that the newest changed file is not newer than some benchmark time is an interesting one ... more so if we didn't set the last modification time during unpacking. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From setje@sun.com Fri Jun 5 17:45:04 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n560j32b022603 for ; Fri, 5 Jun 2009 17:45:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n560itn0013429; Sat, 6 Jun 2009 08:44:59 +0800 (SGT) 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 <0KKS00D03KQXC800@brm-avmta-1.central.sun.com>; Fri, 05 Jun 2009 18:44:57 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKS00EH6KQWSO70@brm-avmta-1.central.sun.com>; Fri, 05 Jun 2009 18:44:57 -0600 (MDT) Received: from [129.146.226.114] (smack.SFBay.Sun.COM [129.146.226.114]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n560iuL4266517; Fri, 05 Jun 2009 17:44:56 -0700 (PDT) Date: Fri, 05 Jun 2009 17:44:56 -0700 From: Jan Setje-Eilers Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> To: Jerry Gilliam Cc: PSARC-ext@sun.com, Gangadhar.M@sun.com, sherry.moore@sun.com, jan.setje-eilers@sun.com, enrico.perla@sun.com Message-id: <4A29BC08.1020807@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 477 Since this proposal is not a desirable final state, we'd like to propose updating the interface table making the interface as well as the behavior it controls non-public: 4.8 Interfaces: svc:/system/boot-config Contracted Project Private per PSARC/2008/760 config/uadmin_boot_archive_sync Contracted Project Private boolean property This will allow the impacted customer to use it until the behavior is obsoleted by automatic seamless recovery. -jan From carlsonj@phorcys.east.sun.com Mon Jun 8 05:47:19 2009 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 n58ClJ6u010921 for ; Mon, 8 Jun 2009 05:47:19 -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.2) with ESMTP id n58ClIft043384; Mon, 8 Jun 2009 06:47:18 -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 <0KKX00F0T7ISDV00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 08 Jun 2009 05:47:16 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKX000NS7IQM580@nwk-avmta-1.sfbay.Sun.COM>; Mon, 08 Jun 2009 05:47:15 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n58Cl7Ws032132; Mon, 08 Jun 2009 08:47:07 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n58CjuER012647; Mon, 08 Jun 2009 08:45:56 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n58Cjumi012644; Mon, 08 Jun 2009 08:45:56 -0400 (EDT) Date: Mon, 08 Jun 2009 08:45:56 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A29BC08.1020807@sun.com> To: Jan Setje-Eilers Cc: Jerry Gilliam , PSARC-ext@sun.com, Jan.Setje-Eilers@sun.com, Gangadhar.M@sun.com, Enrico.Perla@sun.com, Sherry.Moore@sun.com Message-id: <18989.2052.310255.363033@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A29BC08.1020807@sun.com> Status: RO Content-Length: 506 Jan Setje-Eilers writes: > svc:/system/boot-config I'm a little baffled that we need to define a third service for this one feature: online Jun_03 svc:/system/boot-archive:default online Jun_03 svc:/system/boot-archive-update:default ... but otherwise +1. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From setje@sun.com Mon Jun 8 08:55:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n58FtK4j013684 for ; Mon, 8 Jun 2009 08:55:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n58Ft87v017828; Mon, 8 Jun 2009 16:55:14 +0100 (BST) 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 <0KKX00M1TG7VUI00@nwk-avmta-2.sfbay.sun.com>; Mon, 08 Jun 2009 08:55:07 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKX00GICG7T6NB0@nwk-avmta-2.sfbay.sun.com>; Mon, 08 Jun 2009 08:55:05 -0700 (PDT) Received: from [10.7.251.212] (punchin-setje.SFBay.Sun.COM [10.7.251.212]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n58Ft4OL548320; Mon, 08 Jun 2009 08:55:04 -0700 (PDT) Date: Mon, 08 Jun 2009 08:55:09 -0700 From: Jan Setje-Eilers Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <18989.2052.310255.363033@gargle.gargle.HOWL> To: James Carlson Cc: Jerry Gilliam , PSARC-ext@sun.com, Jan.Setje-Eilers@sun.com, Gangadhar.M@sun.com, Enrico.Perla@sun.com, Sherry.Moore@sun.com Message-id: <4A2D345D.6040206@sun.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 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A29BC08.1020807@sun.com> <18989.2052.310255.363033@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 607 James Carlson wrote: > Jan Setje-Eilers writes: >> svc:/system/boot-config That service is not new with this case. It came into existence to provide a home for the fast reboot state (go through POST or not). It is where properties that define how the system with (re)boot are going. This will however be the first thing to back-port it (with just this one property) to 10. > > online Jun_03 svc:/system/boot-archive:default > online Jun_03 svc:/system/boot-archive-update:default Those are both services that do work during boot. > ... but otherwise +1. Thanks. -jan From carlsonj@phorcys.east.sun.com Mon Jun 8 09:10:17 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n58GAGgn014181 for ; Mon, 8 Jun 2009 09:10:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n58G9xiS004911; Tue, 9 Jun 2009 00:10:13 +0800 (SGT) 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 <0KKX0032HGX1XV00@brm-avmta-1.central.sun.com>; Mon, 08 Jun 2009 10:10:13 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKX00DQ2GWZQMD0@brm-avmta-1.central.sun.com>; Mon, 08 Jun 2009 10:10:11 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n58GA4fP011922; Mon, 08 Jun 2009 12:10:04 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n58G8p9t013463; Mon, 08 Jun 2009 12:08:51 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n58G8pG1013460; Mon, 08 Jun 2009 12:08:51 -0400 (EDT) Date: Mon, 08 Jun 2009 12:08:51 -0400 From: James Carlson Subject: Re: Configurable Boot Archive Updates [2009/312 05/26/2009] In-reply-to: <4A2D345D.6040206@sun.com> To: Jan Setje-Eilers Cc: Jerry Gilliam , PSARC-ext@sun.com, Jan.Setje-Eilers@sun.com, Gangadhar.M@sun.com, Enrico.Perla@sun.com, Sherry.Moore@sun.com Message-id: <18989.14227.889954.154975@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905192236.n4JMasQ1168812@jurassic.eng.sun.com> <4A29BC08.1020807@sun.com> <18989.2052.310255.363033@gargle.gargle.HOWL> <4A2D345D.6040206@sun.com> Status: RO Content-Length: 927 Jan Setje-Eilers writes: > James Carlson wrote: > > Jan Setje-Eilers writes: > >> svc:/system/boot-config > > That service is not new with this case. It came into existence to > provide a home for the fast reboot state (go through POST or not). It is > where properties that define how the system with (re)boot are going. > This will however be the first thing to back-port it (with just this one > property) to 10. Ah, ok. I somehow missed it when grepping around. :-< > > online Jun_03 svc:/system/boot-archive:default > > online Jun_03 svc:/system/boot-archive-update:default > > Those are both services that do work during boot. Third service's the charm. ;-} -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677