Is there really no way to specify that the installer target the default boot disk explicitly in the manifest? There are interfaces available on x86 that the installer can use to try to determine the default boot disk. They're not perfect, but they do work quite often.
--S On Jul 28, 2010, at 3:33 PM, Mary Ding <[email protected]> wrote: > Anna: > > It will depend on the x86 and I suggest you go and try it out and see what > happens. > > > > > On 07/28/10 03:24 PM, [email protected] wrote: >> >> Thanks Mary, >> >> But would #1 boot_disk not pick up the first disk in the BIOS menu? >> >> Anna >> >> On 7/28/2010 3:17 PM, Mary Ding wrote: >>> Anna: >>> >>> I used the following #4 Volume name to target the disk I wanted to install >>> and tag it with volume ai-disk. >>> >>> This had been done for a while: >>> >>> >>> Author: Jan Damborsky <[email protected]> >>> Repository: /hg/caiman/slim_source >>> Latest revision: 2f04e6d1a2353fa00e0a159801aa380e0828f065 >>> Total changesets: 1 >>> Log message: >>> 5451 No way to permanently target specific disk in AI engine manifest >>> 7057 desire for being able to specify boot disk as installation target in >>> AI man >>> ifest >>> 7058 desire for being able to pick up disk as installation target by >>> specifying >>> volume name in AI manifest >>> >>> Files: >>> update: usr/src/cmd/auto-install/ai_manifest.rng >>> update: usr/src/cmd/auto-install/ai_manifest.xml >>> update: usr/src/cmd/auto-install/auto_install.c >>> update: usr/src/cmd/auto-install/auto_install.h >>> update: usr/src/cmd/auto-install/auto_parse.c >>> update: usr/src/cmd/auto-install/auto_td.c >>> update: usr/src/lib/liborchestrator/disk_info.c >>> update: usr/src/lib/liborchestrator/disk_target.c >>> update: usr/src/lib/liborchestrator/disk_util.c >>> update: usr/src/lib/liborchestrator/orchestrator_api.h >>> update: usr/src/lib/liborchestrator/target_discovery.c >>> update: usr/src/lib/libtd/td_api.h >>> update: usr/src/lib/libtd/td_dd.c >>> update: usr/src/lib/libtd/test_td.c >>> update: usr/src/pkgdefs/SUNWauto-install-common/prototype_com >>> update: usr/src/pkgdefs/SUNWauto-install/prototype_com >>> >>> >>> >>> it is now possible to select target disk in AI manifest by >>> following new disk selection criteria: >>> >>> [1] boot disk >>> ------------- >>> >>> Existing tag <target_device_name> has been enhanced to accept >>> 'boot_disk' keyword to select current boot disk as an installation >>> target - snippet of AI manifest: >>> >>> <ai_target_device> >>> <target_device_name> >>> boot_disk >>> </target_device_name> >>> </ai_target_device> >>> >>> known issues/limitations: >>> * Does not work in XEN/PV, as information about boot disk >>> is not available. >>> >>> * some x86 BIOSes don't report boot disk correctly - >>> see following bug for more details: >>> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6831009 >>> >>> * for Sparc case, information about boot disk is not available >>> if diag-switch? OBP property is set to true. Make sure diag-switch? >>> is set to false if you would like to utilize boot disk disk selection >>> criteria on Sparc platform. >>> [2] Device ID >>> ------------- >>> >>> New tag <target_device_select_id> has been introduced which allows >>> to select target disk by Device ID. That information can be obtained >>> for instance by means of iostat(1M): >>> >>> $ iostat -iEn >>> c7d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 >>> Model: ST31000340NS Revision: Device Id: >>> id1,c...@ast31000340ns=____________9qj2lnyy >>> ... >>> >>> Appropriate snippet of AI manifest then would look like: >>> >>> <ai_target_device> >>> <target_device_select_id> >>> id1,c...@ast31000340ns=____________9qj2lnyy >>> </target_device_select_id> >>> </ai_target_device> >>> >>> known issues/limitations: >>> * iostat(1M) doesn't report Device ID on LDOM guest. However, that >>> information is available and can be obtained by Target Discovery >>> test driver which is present in AI image: >>> >>> # /opt/install-test/bin/tdmgtst -dv | grep ddm_disk_dev_id >>> ddm_disk_dev_id=id1,v...@f8498536e4a8ad037000bcb400001 >>> >>> * Does not work in XEN/PV, as Device ID is not available for virtual >>> drive. >>> >>> >>> [3] Physical device path >>> ------------------------ >>> >>> New tag <target_device_select_device_path> has been introduced which allows >>> to select target disk by physical path under /devices directory. >>> That information can be for instance obtained by inspecting related >>> c#t#d#s# symbolic link: >>> >>> $ ls -l /dev/dsk/c7d0s0 >>> lrwxrwxrwx 1 root root 51 2009-04-03 00:20 /dev/dsk/c7d0s0 -> >>> ../../devices/p...@0,0/pci-...@1f,2/i...@0/c...@0,0:a >>> >>> Appropriate snippet of AI manifest then would look like >>> ('/devices' portion is stripped as well as part >>> representing minor node): >>> >>> <ai_target_device> >>> <target_device_select_device_path> >>> /p...@0,0/pci-...@1f,2/i...@0/c...@0,0 >>> </target_device_select_device_path> >>> </ai_target_device> >>> >>> >>> [4] Volume name >>> --------------- >>> >>> New tag <target_device_select_volume_name> has been introduced >>> which allows to select target disk by volume name created by means >>> of format(1M) command, e.g.. >>> >>> format -d c0d0 > /dev/null 2>/dev/null - <<EOF >>> volname >>> "ai-disk" >>> y >>> quit >>> EOF >>> >>> Appropriate snippet of AI manifest then would look like >>> >>> <ai_target_device> >>> <target_device_select_volume_name> >>> ai-disk >>> </target_device_select_volume_name> >>> </ai_target_device> >>> >>> >>> >>> Algorithm for selecting target disk has been modified >>> in following way: >>> >>> All existing disk criteria have been divided into two mutually >>> exclusive groups: >>> >>> G1 - deterministic disk criteria >>> ................................ >>> * iscsi_target_parameters >>> * target_device_name (c#t#d# name or 'boot_disk') >>> * target_device_select_volume_name >>> * target_device_select_id >>> * target_device_select_device_path >>> >>> G2 - rest of disk criteria >>> .......................... >>> * target_device_type >>> * target_device_vendor >>> * target_device_size >>> >>> AI manifest schema ai_manifest.rng has been modified to enforce >>> following policy: >>> >>> * criteria in group G1 are mutually exclusive - only >>> one can be specified at a time >>> >>> * groups G1 and G2 are mutually exclusive - i.e. >>> if criteria from G1 is specified, no criteria >>> from G2 are allowed and vice versa >>> >>> * multiple criteria from G2 can be specified >>> >>> If invalid manifest is provided to the AI client, >>> Automated Installation will abort when validating the manifest. >>> Error messages indicating the cause of the failed syntactic >>> validation will be present in /tmp/install_log file on AI client: >>> >>> # cat /tmp/install_log >>> <AI Jan 7 09:24:05> Syntactic validation of the manifest failed with >>> following >>> errors >>> <AI_E Jan 7 09:24:05> Relax-NG validity error : Extra element >>> ai_target_device >>> in interleave >>> <AI_E Jan 7 09:24:05> /tmp/ai_manifest.xml:2: element ai_target_device: >>> Relax- >>> NG validity error : Element ai_manifest failed to validate content >>> <AI_E Jan 7 09:24:05> /tmp/ai_manifest.xml fails to validate >>> <AI_E Jan 7 09:24:05> xmllint(1M) returned with exit code 3 >>> <AI Jan 7 09:24:05> Auto install failed. Invalid manifest >>> /tmp/ai_combined_mani >>> fest.xml specified >>> >>> On server side, when being added to install service, custom AI manifest >>> is validated against the schema in AI image associated with given >>> install service. >>> That means that the same validation process will apply to manifests added >>> to install service associated with AI image containing this fix >>> (based on build 131 on later). >>> >>> Previously, it was possible to specify <target_device_name> criteria >>> (from G1) along with combination of G2 criteria. This will no longer work. >>> This special case is mentioned here as it was presented in original >>> AI sample manifest [1]. AI sample manifest was modified appropriately >>> to reflect this set of changes - new disk criteria have been added, >>> but commented out, so that AI sample manifest validates. >>> >>> [1] located in /usr/share/auto_install/ai_manifest.xml on AI client >>> >>> >>> >>> >>> On 07/28/10 02:59 PM, [email protected] wrote: >>>> Hi, >>>> >>>> Our pxe server setup is used by users to install on many different x86 >>>> machines. Most of these systems have multiple disks. In our current setup >>>> no target is specified in the manifest file for installation, therefore >>>> the automated installer chooses the first disk it finds. Very often this >>>> is not the first device in the users BIOS boot menu and not the disk on >>>> which the user wants the OS to be installed on. It would also be difficult >>>> to specify the target device by logical device name or MPXIO name in the >>>> manifest file since we would not know what this name would be for >>>> different systems. Is there some other mechanism by which the OS can be >>>> installed on the first disk in BIOS or can a user specify where the >>>> install should take place? >>>> >>>> Thanks >>>> Anna >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> [email protected] >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >>> > > > -- > Sponsor me in the Relay For Life of Mountain View > Sat 10am to Sun 10am, May 22-23, 2010 at Cuesta Park > > All proceeds go to American Cancer Society > > http://main.acsevents.org/goto/Mary.Ding > > _______________________________________________ > caiman-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
