From sacadmin Mon Mar 24 14:05:44 2008 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 m2OL5iqN013350; Mon, 24 Mar 2008 14:05:44 -0700 (PDT) Received: from tethys.sfbay.sun.com (localhost [127.0.0.1]) by tethys.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2OL2nlB003909; Mon, 24 Mar 2008 14:02:49 -0700 (PDT) Received: (from jg@localhost) by tethys.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m2OL2nD9003905; Mon, 24 Mar 2008 14:02:49 -0700 (PDT) Date: Mon, 24 Mar 2008 14:02:49 -0700 (PDT) From: Jerry Gilliam Message-Id: <200803242102.m2OL2nD9003905@tethys.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Bootadm: managing a diskless client [PSARC/2008/213 Self Review] Status: RO Content-Length: 570 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Bootadm: managing a diskless client 1.2. Name of Document Author/Supplier: Author: Jerry Gilliam 1.3 Date of This Document: 24 March, 2008 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: Automatic 6.6. ARC Exposure: open From jg@jurassic.sfbay.Sun.COM Mon Mar 24 14:13:37 2008 Received: from jurassic.eng.sun.com (jurassic-226-b.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2OLDbQb014387 for ; Mon, 24 Mar 2008 14:13:37 -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 m2OLDamK787300; Mon, 24 Mar 2008 14:13:36 -0700 (PDT) Message-Id: <200803242113.m2OLDamK787300@jurassic.eng.sun.com> Date: Mon, 24 Mar 2008 14:10:41 -0700 (PDT) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: Bootadm: managing a diskless client [PSARC/2008/213] To: psarc-ext@sac.sfbay.sun.com, jerry.gilliam@sun.com Cc: mary.ding@sun.com, jan-setje-eilers@sun.com, vikram.hegde@sun.com, jk@tools.de MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2fxksIOEmqK9vdKbu/MUyw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 sun4u sparc Status: RO Content-Length: 10140 I am sponsoring this case for myself. I believe it qualifies for self-review with automatic approval and I've marked it as such, but if anyone disagrees, it can be promoted to a fast-track. I am requesting minor/patch binding for this change. Background ---------- The boot architecture introduced by PSARC 2004/454 was originally only implemented on x86, with bootadm(1M) hard-wired to manage only x86 platforms, either natively or as a diskless client on a server. PSARC 2006/525 introduced the same boot architecture on sparc, modifying bootadm(1M) to manage boot administration on either sparc or x86. Problem ------- With the sparc introduction of the new boot architecture, bootadm can no longer be used to manage a diskless client of a platform implementation other than the server. Bootadm(1M) presently assumes the client is of the same platform implementation as the server. The platform implementation needs to be made explicit as a client's implementation cannot be intuited from a client's root path alone. Proposal ---------- Support a command-line argument to bootadm(1M) to specify the client's platform implementation for boot administration of a client. Analogous updates to the create_ramdisk and extract_boot_filelist utilities, invoked by bootadm, are needed. The diskless administration tools such as smosservice(1M) are aware of a client's platform and can invoke bootadm appropriately. The miniroot construction process uses the root_archive tool and would not be impacted by this change. Minor release/patch binding is requested. Interfaces ---------- ________________________________________________________________________________ | Interfaces Exported | |______________________________|________________|______________________________| |Interface | Classification| Comments | |______________________________|________________|______________________________| | | | | |bootadm(1M) | Stable | | | -p platform | Stable | diskless client management | | | | | |create_ramdisk: | Cons. Priv. | | | -p platform | Cons. Priv. | diskless client management | | | | | |extract_boot_filelist: | Cons. Priv. | | | -p platform | Cons. Priv. | diskless client management | |______________________________|________________|______________________________| References ---------- PSARC 2005/198 Install Interface Changes Under New Boot PSARC 2004/454 Solaris Boot Architecture Documentation ------------- System Administration Commands bootadm(1M) NAME bootadm - manage bootability of GRUB-enabled operating sys- tem SYNOPSIS - /sbin/bootadm update-archive [-vn] [-R altroot] + /sbin/bootadm update-archive [-vn] [-R altroot] [-p platform] - /sbin/bootadm list-archive [-vn] [-R altroot] + /sbin/bootadm list-archive [-vn] [-R altroot] [-p platform] x86 only - /sbin/bootadm set-menu [-R altroot] key=value + /sbin/bootadm set-menu [-R altroot] [-p platform] key=value - /sbin/bootadm list-menu [-R altroot] + /sbin/bootadm list-menu [-R altroot] [-p platform] DESCRIPTION The bootadm command manages the boot archive and, with x86 boot environments, the GRUB (GRand Unified Bootloader) menu. The update-archive option provides a way for user to update the boot archive as a preventative measure or as part of a recovery procedure. The set-menu subcommand allows you to switch the auto-boot timeout and default boot entry in the GRUB menu. The list-menu subcommand displays the location of the GRUB menu and the current GRUB menu entries. While the typical location of the GRUB menu is /boot/grub/menu.lst, depending on the install method used the active GRUB menu might be located somewhere else. Use the list-menu subcommand to locate the active GRUB menu. For example, if a system was installed using Live Upgrade, the GRUB menu might not be located in the current boot environment. See the EXAMPLES section for typical output from the list-menu option. Note that OpenBoot PROM (OBP)-based machines, such as SPARC systems, do not use GRUB and have no boot menu manageable by bootadm. The bootadm command determines dynamically the options sup- ported by the image to be managed, so that bootadm invoked on one platform can be used to manage diskless clients of a different platform type. SUBCOMMANDS The bootadm command has the following subcommands: update-archive Updates current boot archive if required. Applies to both SPARC and x86 platforms. list-archive Lists the files and directories to be included in the boot archive. Applies to both SPARC and x86 platforms. set-menu Maintain the GRUB menu. The current GRUB menu is boot/grub/menu.lst, relative to root. Do not depend on this location, because it is subject to change. Applies to x86 platforms only. list-menu Lists the location of the active GRUB menu, as well as the current GRUB menu entries. This includes the autoboot-timeout, the default entry number, and the title of each entry. Applies to x86 platforms only. OPTIONS The bootadm command has the following options: -v In an update-archive operation, stale files are displayed on stderr. -n In an update-archive operation, archive content is checked but not updated. -R altroot Operation is applied to an alternate root path. Note - The root file system of any non-global zones must not be referenced with the -R option. Doing so might dam- age the global zone's file system, might compromise the security of the global zone, and might damage the non-global zone's file system. See zones(5). + + -p platform + + The platform, or machine hardware class, of the client. + The platform type can only be specified together with + -R, and is designed for use when managing a diskless + client where the client is of a different platform + hardware class than the server. Currently supported + platform classes are i86pc, sun4u and sun4v. + key=value Possible values are: default=entrynum The item number (for example, 0, 1, or 2) in the GRUB menu designating the operating system to boot when the timer expires. timeout=seconds The number of seconds before the operating system designated by the default item number is booted. If the value is -1, auto boot is disabled. EXAMPLES Example 1 Updating the Current Boot Archive The following command updates the current boot archive: # bootadm update-archive Example 2 Updating the Boot Archive on an Alternate Root The following command updates the boot archive on an alter- nate root: # bootadm update-archive -R /a Example 3 Listing Installed OS Instances The following command lists the installed operating system instances in a GRUB menu: # bootadm list-menu default=0 timeout=10 (0) Solaris10 (1) Solaris10 Failsafe (2) Linux Example 4 Switching Default Boot Entry The following command refers to the menu displayed in the previous example. The user selects Linux (item 2). # bootadm set-menu default=2 Example 5 Listing GRUB Menu Entries and Location of GRUB Menu The following command lists the GRUB menu entries and the location of the GRUB menu: # bootadm list-menu The location for the active GRUB menu is: /stubboot/boot/grub/menu.lst default 0 timeout 10 0 Solaris10 1 Solaris10 failsafe 2 Linux Example 6 Displaying Location of GRUB Menu The following command displays the location of the GRUB menu: # bootadm list-menu The location for the active GRUB menu is: /dev/dsk/c0t1d0s0 (not mounted) The filesystem type of the menu device is default 2 timeout 10 0 c0t1d0s3 1 c0t1d0s3 failsafe 2 Solaris10 3 Solaris10 failsafe In this example, the active GRUB menu is located on a device which is not mounted. To access the GRUB menu, mount the device and access the GRUB menu at /boot/grub/menu.lst. EXIT STATUS The following exit values are returned: 0 The command completed successfully. 1 The command exited due to an error. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO boot(1M), installgrub(1M), attributes(5) Consult the GRUB home page, under: http://www.gnu.org/ From jg@jurassic.sfbay.Sun.COM Mon Mar 24 14:16:55 2008 Received: from jurassic.eng.sun.com (jurassic-226-a.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2OLGtSH014415 for ; Mon, 24 Mar 2008 14:16:55 -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 m2OLGt3r787391; Mon, 24 Mar 2008 14:16:55 -0700 (PDT) Message-Id: <200803242116.m2OLGt3r787391@jurassic.eng.sun.com> Date: Mon, 24 Mar 2008 14:14:00 -0700 (PDT) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: Bootadm: managing a diskless client [PSARC/2008/213] To: psarc-ext@sac.sfbay.sun.com, jerry.gilliam@sun.com Cc: mary.ding@sun.com, jan.setje-eilers@sun.com, vikram.hegde@sun.com, jk@tools.de MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: H6dm08Ebsml+xFgqcNLoJw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 sun4u sparc Status: RO Content-Length: 10141 I am sponsoring this case for myself. I believe it qualifies for self-review with automatic approval and I've marked it as such, but if anyone disagrees, it can be promoted to a fast-track. I am requesting minor/patch binding for this change. Background ---------- The boot architecture introduced by PSARC 2004/454 was originally only implemented on x86, with bootadm(1M) hard-wired to manage only x86 platforms, either natively or as a diskless client on a server. PSARC 2006/525 introduced the same boot architecture on sparc, modifying bootadm(1M) to manage boot administration on either sparc or x86. Problem ------- With the sparc introduction of the new boot architecture, bootadm can no longer be used to manage a diskless client of a platform implementation other than the server. Bootadm(1M) presently assumes the client is of the same platform implementation as the server. The platform implementation needs to be made explicit as a client's implementation cannot be intuited from a client's root path alone. Proposal ---------- Support a command-line argument to bootadm(1M) to specify the client's platform implementation for boot administration of a client. Analogous updates to the create_ramdisk and extract_boot_filelist utilities, invoked by bootadm, are needed. The diskless administration tools such as smosservice(1M) are aware of a client's platform and can invoke bootadm appropriately. The miniroot construction process uses the root_archive tool and would not be impacted by this change. Minor release/patch binding is requested. Interfaces ---------- ________________________________________________________________________________ | Interfaces Exported | |______________________________|________________|______________________________| |Interface | Classification| Comments | |______________________________|________________|______________________________| | | | | |bootadm(1M) | Stable | | | -p platform | Stable | diskless client management | | | | | |create_ramdisk: | Cons. Priv. | | | -p platform | Cons. Priv. | diskless client management | | | | | |extract_boot_filelist: | Cons. Priv. | | | -p platform | Cons. Priv. | diskless client management | |______________________________|________________|______________________________| References ---------- PSARC 2005/198 Install Interface Changes Under New Boot PSARC 2004/454 Solaris Boot Architecture Documentation ------------- System Administration Commands bootadm(1M) NAME bootadm - manage bootability of GRUB-enabled operating sys- tem SYNOPSIS - /sbin/bootadm update-archive [-vn] [-R altroot] + /sbin/bootadm update-archive [-vn] [-R altroot] [-p platform] - /sbin/bootadm list-archive [-vn] [-R altroot] + /sbin/bootadm list-archive [-vn] [-R altroot] [-p platform] x86 only - /sbin/bootadm set-menu [-R altroot] key=value + /sbin/bootadm set-menu [-R altroot] [-p platform] key=value - /sbin/bootadm list-menu [-R altroot] + /sbin/bootadm list-menu [-R altroot] [-p platform] DESCRIPTION The bootadm command manages the boot archive and, with x86 boot environments, the GRUB (GRand Unified Bootloader) menu. The update-archive option provides a way for user to update the boot archive as a preventative measure or as part of a recovery procedure. The set-menu subcommand allows you to switch the auto-boot timeout and default boot entry in the GRUB menu. The list-menu subcommand displays the location of the GRUB menu and the current GRUB menu entries. While the typical location of the GRUB menu is /boot/grub/menu.lst, depending on the install method used the active GRUB menu might be located somewhere else. Use the list-menu subcommand to locate the active GRUB menu. For example, if a system was installed using Live Upgrade, the GRUB menu might not be located in the current boot environment. See the EXAMPLES section for typical output from the list-menu option. Note that OpenBoot PROM (OBP)-based machines, such as SPARC systems, do not use GRUB and have no boot menu manageable by bootadm. The bootadm command determines dynamically the options sup- ported by the image to be managed, so that bootadm invoked on one platform can be used to manage diskless clients of a different platform type. SUBCOMMANDS The bootadm command has the following subcommands: update-archive Updates current boot archive if required. Applies to both SPARC and x86 platforms. list-archive Lists the files and directories to be included in the boot archive. Applies to both SPARC and x86 platforms. set-menu Maintain the GRUB menu. The current GRUB menu is boot/grub/menu.lst, relative to root. Do not depend on this location, because it is subject to change. Applies to x86 platforms only. list-menu Lists the location of the active GRUB menu, as well as the current GRUB menu entries. This includes the autoboot-timeout, the default entry number, and the title of each entry. Applies to x86 platforms only. OPTIONS The bootadm command has the following options: -v In an update-archive operation, stale files are displayed on stderr. -n In an update-archive operation, archive content is checked but not updated. -R altroot Operation is applied to an alternate root path. Note - The root file system of any non-global zones must not be referenced with the -R option. Doing so might dam- age the global zone's file system, might compromise the security of the global zone, and might damage the non-global zone's file system. See zones(5). + + -p platform + + The platform, or machine hardware class, of the client. + The platform type can only be specified together with + -R, and is designed for use when managing a diskless + client where the client is of a different platform + hardware class than the server. Currently supported + platform classes are i86pc, sun4u and sun4v. + key=value Possible values are: default=entrynum The item number (for example, 0, 1, or 2) in the GRUB menu designating the operating system to boot when the timer expires. timeout=seconds The number of seconds before the operating system designated by the default item number is booted. If the value is -1, auto boot is disabled. EXAMPLES Example 1 Updating the Current Boot Archive The following command updates the current boot archive: # bootadm update-archive Example 2 Updating the Boot Archive on an Alternate Root The following command updates the boot archive on an alter- nate root: # bootadm update-archive -R /a Example 3 Listing Installed OS Instances The following command lists the installed operating system instances in a GRUB menu: # bootadm list-menu default=0 timeout=10 (0) Solaris10 (1) Solaris10 Failsafe (2) Linux Example 4 Switching Default Boot Entry The following command refers to the menu displayed in the previous example. The user selects Linux (item 2). # bootadm set-menu default=2 Example 5 Listing GRUB Menu Entries and Location of GRUB Menu The following command lists the GRUB menu entries and the location of the GRUB menu: # bootadm list-menu The location for the active GRUB menu is: /stubboot/boot/grub/menu.lst default 0 timeout 10 0 Solaris10 1 Solaris10 failsafe 2 Linux Example 6 Displaying Location of GRUB Menu The following command displays the location of the GRUB menu: # bootadm list-menu The location for the active GRUB menu is: /dev/dsk/c0t1d0s0 (not mounted) The filesystem type of the menu device is default 2 timeout 10 0 c0t1d0s3 1 c0t1d0s3 failsafe 2 Solaris10 3 Solaris10 failsafe In this example, the active GRUB menu is located on a device which is not mounted. To access the GRUB menu, mount the device and access the GRUB menu at /boot/grub/menu.lst. EXIT STATUS The following exit values are returned: 0 The command completed successfully. 1 The command exited due to an error. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| SEE ALSO boot(1M), installgrub(1M), attributes(5) Consult the GRUB home page, under: http://www.gnu.org/ From bart.smaalders@Sun.COM Tue Mar 25 13:54:46 2008 Received: from zion.sfbay.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2PKsktp026400 for ; Tue, 25 Mar 2008 13:54:46 -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 m2PKsjFQ735928; Tue, 25 Mar 2008 20:54:45 GMT Message-ID: <47E96695.5030909@Sun.COM> Date: Tue, 25 Mar 2008 13:54:45 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.9 (X11/20080201) MIME-Version: 1.0 To: Jerry Gilliam CC: psarc-ext@sac.sfbay.sun.com, jerry.gilliam@Sun.COM, mary.ding@Sun.COM, jan-setje-eilers@Sun.COM, vikram.hegde@Sun.COM, jk@tools.de Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] References: <200803242113.m2OLDamK787300@jurassic.eng.sun.com> In-Reply-To: <200803242113.m2OLDamK787300@jurassic.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 535 Jerry Gilliam wrote: > I am sponsoring this case for myself. I believe it qualifies > for self-review with automatic approval and I've marked it as > such, but if anyone disagrees, it can be promoted to a fast-track. > I am requesting minor/patch binding for this change. Quick question - why can't bootadm figure this out for itself and do the right thing? - 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 jg@jurassic.sfbay.Sun.COM Tue Mar 25 14:52:32 2008 Received: from jurassic.eng.sun.com (jurassic-226-a.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2PLqW3Y028797 for ; Tue, 25 Mar 2008 14:52:32 -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 m2PLqVvD832853; Tue, 25 Mar 2008 14:52:31 -0700 (PDT) Message-Id: <200803252152.m2PLqVvD832853@jurassic.eng.sun.com> Date: Tue, 25 Mar 2008 14:49:37 -0700 (PDT) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] To: bart.smaalders@sun.com Cc: psarc-ext@sac.sfbay.sun.com, jerry.gilliam@sun.com, mary.ding@sun.com, jan-setje-eilers@sun.com, vikram.hegde@sun.com, jk@tools.de MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: N69eHIb+uGmOp3ozSCc9QQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 sun4u sparc Status: RO Content-Length: 786 > >> I am sponsoring this case for myself. I believe it qualifies >> for self-review with automatic approval and I've marked it as >> such, but if anyone disagrees, it can be promoted to a fast-track. >> I am requesting minor/patch binding for this change. > >Quick question - why can't bootadm figure this out for itself and do >the right thing? > >- Bart > We can't yet communicate with the machine, of course, and there's nothing about the root filesystem layout that tells us the platform implementation (sun4u or sun4v). Bootadm builds per-platform archives as we've found otherwise boot time suffers. The diskless admin tools already know the client's implementation so it's just a matter of communicating that to bootadm during the process of configuring the client. -jg From Matthew.Jacob@Sun.COM Tue Mar 25 16:46:40 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2PNkele004506 for ; Tue, 25 Mar 2008 16:46:40 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2PNkerH013195 for ; Tue, 25 Mar 2008 16:46:40 -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 m2PNkZTD028660 for ; Tue, 25 Mar 2008 16:46:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYB005018LXQQ00@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 25 Mar 2008 16:46:35 -0700 (PDT) Received: from [129.145.154.59] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYB00EY28P6J550@fe-sfbay-10.sun.com>; Tue, 25 Mar 2008 16:46:19 -0700 (PDT) Date: Tue, 25 Mar 2008 16:46:18 -0700 From: Matthew Jacob Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] In-reply-to: <200803252152.m2PLqVvD832853@jurassic.eng.sun.com> Sender: Matthew.Jacob@Sun.COM To: Jerry Gilliam Cc: bart.smaalders@Sun.COM, psarc-ext@sac.sfbay.sun.com, Jerry.Gilliam@Sun.COM, Mary.Ding@Sun.COM, jan-setje-eilers@Sun.COM, Vikram.Hegde@Sun.COM, jk@tools.de Reply-to: Matthew.Jacob@Sun.COM Message-id: <47E98ECA.5060901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200803252152.m2PLqVvD832853@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 393 > > We can't yet communicate with the machine, of course, and there's > nothing about the root filesystem layout that tells us the platform > implementation (sun4u or sun4v). Bootadm builds per-platform archives > as we've found otherwise boot time suffers. Side note: I've noticed that the time you save in boot time you (seem to, at least for OpenSolaris) pay back later in reboot time. From bart.smaalders@Sun.COM Tue Mar 25 18:59:58 2008 Received: from zion.sfbay.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2Q1xw9t008048 for ; Tue, 25 Mar 2008 18:59:58 -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 m2Q1xtAS741416; Wed, 26 Mar 2008 01:59:55 GMT Message-ID: <47E9AE1B.60404@Sun.COM> Date: Tue, 25 Mar 2008 18:59:55 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.9 (X11/20080201) MIME-Version: 1.0 To: Matthew.Jacob@Sun.COM CC: Jerry Gilliam , jk@tools.de, Jerry.Gilliam@Sun.COM, jan-setje-eilers@Sun.COM, Vikram.Hegde@Sun.COM, Mary.Ding@Sun.COM, psarc-ext@sac.sfbay.sun.com Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] References: <200803252152.m2PLqVvD832853@jurassic.eng.sun.com> <47E98ECA.5060901@Sun.COM> In-Reply-To: <47E98ECA.5060901@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 812 Matthew Jacob wrote: >> We can't yet communicate with the machine, of course, and there's >> nothing about the root filesystem layout that tells us the platform >> implementation (sun4u or sun4v). Bootadm builds per-platform archives >> as we've found otherwise boot time suffers. > Side note: I've noticed that the time you save in boot time you (seem > to, at least for OpenSolaris) pay back later in reboot time. > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org This would only be the case if you're rebuilding the boot archive; are you doing so on every reboot? - 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 Darren.Moffat@Sun.COM Wed Mar 26 07:44:20 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QEiKJN025273 for ; Wed, 26 Mar 2008 07:44:20 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2QEiJav041451 for ; Wed, 26 Mar 2008 07:44:19 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2QEiD8F004324 for ; Wed, 26 Mar 2008 14:44:13 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYC00401DB9YI00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 26 Mar 2008 14:44:13 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYC000BHE9G3410@fe-emea-09.sun.com>; Wed, 26 Mar 2008 14:44:04 +0000 (GMT) Date: Wed, 26 Mar 2008 14:44:04 +0000 From: Darren J Moffat Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] In-reply-to: <200803242113.m2OLDamK787300@jurassic.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Jerry Gilliam Cc: psarc-ext@sac.sfbay.sun.com, Jerry.Gilliam@Sun.COM, jk@tools.de, jan-setje-eilers@Sun.COM, Vikram.Hegde@Sun.COM, Mary.Ding@Sun.COM Message-id: <47EA6134.7090900@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200803242113.m2OLDamK787300@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 693 Jerry Gilliam wrote: > Proposal > ---------- > Support a command-line argument to bootadm(1M) to specify the client's > platform implementation for boot administration of a client. > > Analogous updates to the create_ramdisk and extract_boot_filelist > utilities, invoked by bootadm, are needed. > > The diskless administration tools such as smosservice(1M) are > aware of a client's platform and can invoke bootadm appropriately. > The miniroot construction process uses the root_archive tool > and would not be impacted by this change. What are the valid values for platform ? In particular for x86 does this allow making a distinction between "i386" and "amd64" ? -- Darren J Moffat From bart.smaalders@Sun.COM Wed Mar 26 08:40:50 2008 Received: from zion.sfbay.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QFeo5j027777 for ; Wed, 26 Mar 2008 08:40:50 -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 m2QFenaE748342; Wed, 26 Mar 2008 15:40:49 GMT Message-ID: <47EA6E81.3010009@Sun.COM> Date: Wed, 26 Mar 2008 08:40:49 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.9 (X11/20080201) MIME-Version: 1.0 To: Darren J Moffat CC: Jerry Gilliam , jk@tools.de, Jerry.Gilliam@Sun.COM, jan-setje-eilers@Sun.COM, Vikram.Hegde@Sun.COM, Mary.Ding@Sun.COM, psarc-ext@sac.sfbay.sun.com Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] References: <200803242113.m2OLDamK787300@jurassic.eng.sun.com> <47EA6134.7090900@Sun.COM> In-Reply-To: <47EA6134.7090900@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1013 Darren J Moffat wrote: > Jerry Gilliam wrote: >> Proposal >> ---------- >> Support a command-line argument to bootadm(1M) to specify the client's >> platform implementation for boot administration of a client. >> >> Analogous updates to the create_ramdisk and extract_boot_filelist >> utilities, invoked by bootadm, are needed. >> >> The diskless administration tools such as smosservice(1M) are >> aware of a client's platform and can invoke bootadm appropriately. >> The miniroot construction process uses the root_archive tool >> and would not be impacted by this change. > > What are the valid values for platform ? > > In particular for x86 does this allow making a distinction between > "i386" and "amd64" ? > There is no difference between the two; Solaris installs both 32bit and 64 bit binaries when installing Solaris x86. - 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 Darren.Moffat@Sun.COM Wed Mar 26 09:29:16 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QGTGo0029251 for ; Wed, 26 Mar 2008 09:29:16 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2QGTFlV000033 for ; Wed, 26 Mar 2008 09:29:16 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2QGT9Ek021856 for ; Wed, 26 Mar 2008 16:29:10 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYC00F01IUH9Z00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 26 Mar 2008 16:29:09 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYC000TMJ423410@fe-emea-09.sun.com>; Wed, 26 Mar 2008 16:28:52 +0000 (GMT) Date: Wed, 26 Mar 2008 16:28:50 +0000 From: Darren J Moffat Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] In-reply-to: <47EA6E81.3010009@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Bart Smaalders Cc: Jerry Gilliam , jk@tools.de, Jerry.Gilliam@Sun.COM, jan-setje-eilers@Sun.COM, Vikram.Hegde@Sun.COM, Mary.Ding@Sun.COM, psarc-ext@sac.sfbay.sun.com Message-id: <47EA79C2.1020507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200803242113.m2OLDamK787300@jurassic.eng.sun.com> <47EA6134.7090900@Sun.COM> <47EA6E81.3010009@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1078 Bart Smaalders wrote: > Darren J Moffat wrote: >> Jerry Gilliam wrote: >>> Proposal >>> ---------- >>> Support a command-line argument to bootadm(1M) to specify the client's >>> platform implementation for boot administration of a client. >>> >>> Analogous updates to the create_ramdisk and extract_boot_filelist >>> utilities, invoked by bootadm, are needed. >>> >>> The diskless administration tools such as smosservice(1M) are >>> aware of a client's platform and can invoke bootadm appropriately. >>> The miniroot construction process uses the root_archive tool >>> and would not be impacted by this change. >> >> What are the valid values for platform ? >> >> In particular for x86 does this allow making a distinction between >> "i386" and "amd64" ? >> > > There is no difference between the two; Solaris installs both 32bit and > 64 bit binaries > when installing Solaris x86. Yes but you could have a smaller boot archive on systems not capable of running 64 bit (and also likely to have less memory) if a distinction on platform was allowed. -- Darren J Moffat From jk@tools.de Wed Mar 26 09:39:07 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QGd7TZ029337 for ; Wed, 26 Mar 2008 09:39:07 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2QGd7Nw010536 for ; Wed, 26 Mar 2008 09:39:07 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2QGanEH023957 for ; Wed, 26 Mar 2008 16:39:06 GMT Received: from mmp12es.sun.com ([160.41.209.22] [160.41.209.22]) by relay13i.sun.com with ESMTP id BT-MMP-683347 for psarc-ext@sac.sfbay.sun.com; Wed, 26 Mar 2008 16:39:06 Z Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.sun.com with ESMTP id BT-MMP-3049865 for psarc-ext@sac.sfbay.sun.com; Wed, 26 Mar 2008 16:39:06 Z Received: from kurt.TooLs.DE ([192.76.135.70] [192.76.135.70]) by relay1i.sun.com with ESMTP id BT-MMP-6541192 for psarc-ext@sac.sfbay.sun.com; Wed, 26 Mar 2008 16:39:05 Z Received: from imap.tools.intra (homes.tools.intra [172.20.0.4]) by kurt.TooLs.DE (Postfix) with ESMTP id E5C7445816; Wed, 26 Mar 2008 17:39:02 +0100 (MET) Received: from tiger2.tools.intra (tiger2.tools.intra [172.20.0.11]) by imap.tools.intra (Postfix) with SMTP id B94563DF92; Wed, 26 Mar 2008 17:39:02 +0100 (CET) Date: Wed, 26 Mar 2008 17:39:02 +0100 (CET) From: Juergen Keil Reply-To: Juergen Keil Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] To: Darren.Moffat@sun.com Cc: Jerry Gilliam , jk@tools.de, Jerry.Gilliam@sun.com, jan-setje-eilers@sun.com, Vikram.Hegde@sun.com, Mary.Ding@sun.com, psarc-ext@sac.sfbay.sun.com Content-MD5: Mna8isw2YpTDewbf7CSuLQ== X-Brightmail-Tracker: AAAAAA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_72 SunOS 5.11 i86pc i386 Message-Id: <20080326163902.B94563DF92@imap.tools.intra> X-Antispam: No, score=-2.6/5.0, scanned in 0.281sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Status: RO Content-Length: 1721 Darren J Moffat wrote: > Bart Smaalders wrote: > > Darren J Moffat wrote: > >> Jerry Gilliam wrote: > >>> Proposal > >>> ---------- > >>> Support a command-line argument to bootadm(1M) to specify the client's > >>> platform implementation for boot administration of a client. > >>> > >>> Analogous updates to the create_ramdisk and extract_boot_filelist > >>> utilities, invoked by bootadm, are needed. > >>> > >>> The diskless administration tools such as smosservice(1M) are > >>> aware of a client's platform and can invoke bootadm appropriately. > >>> The miniroot construction process uses the root_archive tool > >>> and would not be impacted by this change. > >> > >> What are the valid values for platform ? > >> > >> In particular for x86 does this allow making a distinction between > >> "i386" and "amd64" ? > >> > > > > There is no difference between the two; Solaris installs both 32bit and > > 64 bit binaries > > when installing Solaris x86. > > Yes but you could have a smaller boot archive on systems not capable of > running 64 bit (and also likely to have less memory) if a distinction on > platform was allowed. We already have split 32-bit / 64-bit boot archives on i386: % ls -l /platform/i86pc/boot_archive /platform/i86pc/amd64/boot_archive -rw-r--r-- 1 root root 28719104 Mar 25 19:25 /platform/i86pc/amd64/boot_archive -rw-r--r-- 1 root root 26744832 Mar 25 19:25 /platform/i86pc/boot_archive The i386 boot_archives are compressed; on sparc the boot_archive is uncompressed. So that a sparc archive is much bigger than an i386 boot_archive: % ls -l /platform/sun4u/boot_archive -rw-r--r-- 1 root root 71280640 Mar 20 20:41 /platform/sun4u/boot_archive From bart.smaalders@Sun.COM Wed Mar 26 09:50:05 2008 Received: from zion.sfbay.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QGo56O000489 for ; Wed, 26 Mar 2008 09:50:05 -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 m2QGo4kH749998; Wed, 26 Mar 2008 16:50:04 GMT Message-ID: <47EA7EBC.2030001@Sun.COM> Date: Wed, 26 Mar 2008 09:50:04 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.9 (X11/20080201) MIME-Version: 1.0 To: Darren J Moffat CC: Jerry Gilliam , jk@tools.de, Jerry.Gilliam@Sun.COM, jan-setje-eilers@Sun.COM, Vikram.Hegde@Sun.COM, Mary.Ding@Sun.COM, psarc-ext@sac.sfbay.sun.com Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] References: <200803242113.m2OLDamK787300@jurassic.eng.sun.com> <47EA6134.7090900@Sun.COM> <47EA6E81.3010009@Sun.COM> <47EA79C2.1020507@Sun.COM> In-Reply-To: <47EA79C2.1020507@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1402 Darren J Moffat wrote: > Bart Smaalders wrote: >> Darren J Moffat wrote: >>> Jerry Gilliam wrote: >>>> Proposal >>>> ---------- >>>> Support a command-line argument to bootadm(1M) to specify the client's >>>> platform implementation for boot administration of a client. >>>> >>>> Analogous updates to the create_ramdisk and extract_boot_filelist >>>> utilities, invoked by bootadm, are needed. >>>> >>>> The diskless administration tools such as smosservice(1M) are >>>> aware of a client's platform and can invoke bootadm appropriately. >>>> The miniroot construction process uses the root_archive tool >>>> and would not be impacted by this change. >>> >>> What are the valid values for platform ? >>> >>> In particular for x86 does this allow making a distinction between >>> "i386" and "amd64" ? >>> >> >> There is no difference between the two; Solaris installs both 32bit >> and 64 bit binaries >> when installing Solaris x86. > > Yes but you could have a smaller boot archive on systems not capable of > running 64 bit (and also likely to have less memory) if a distinction on > platform was allowed. > We build two separate boot archives already. /platform/i86pc/amd64/boot_archive /platform/i86pc/boot_archive - 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 jg@jurassic.sfbay.Sun.COM Wed Mar 26 10:20:12 2008 Received: from jurassic.eng.sun.com (jurassic-226-a.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2QHKC2M004424 for ; Wed, 26 Mar 2008 10:20:12 -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 m2QHK5Fu871285; Wed, 26 Mar 2008 10:20:05 -0700 (PDT) Message-Id: <200803261720.m2QHK5Fu871285@jurassic.eng.sun.com> Date: Wed, 26 Mar 2008 10:17:11 -0700 (PDT) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: Re: Bootadm: managing a diskless client [PSARC/2008/213] To: bart.smaalders@sun.com, Darren.Moffat@sun.com Cc: jan.setje-eilers@sun.com, Vikram.Hegde@sun.com, Mary.Ding@sun.com, psarc-ext@sac.sfbay.sun.com, jk@tools.de MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XodWS6I/8WQVOFi4gIcZPA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 sun4u sparc Status: RO Content-Length: 624 >> >> What are the valid values for platform ? >> >> In particular for x86 does this allow making a distinction between >> "i386" and "amd64" ? >> > >There is no difference between the two; Solaris installs both 32bit and >64 bit binaries >when installing Solaris x86. > The valid values for platform are whatever implementations Solaris supports and that bootadm builds archives for, as in /platform/`uname -m`, which uname(1m) calls the 'machine hardware name'. The proposal is that bootadm with -p build archives identical to those produced when bootadm is invoked natively on such a platform. -jg