From sacadmin Mon Mar 17 15:07:06 2008 Received: from tethys.sfbay.sun.com (tethys [129.146.226.92]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2HM76Sq000448; Mon, 17 Mar 2008 15:07:06 -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 m2HM4GFi004971; Mon, 17 Mar 2008 15:04:16 -0700 (PDT) Received: (from jg@localhost) by tethys.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m2HM4Ft7004967; Mon, 17 Mar 2008 15:04:15 -0700 (PDT) Date: Mon, 17 Mar 2008 15:04:15 -0700 (PDT) From: Jerry Gilliam Message-Id: <200803172204.m2HM4Ft7004967@tethys.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Grub Findroot [PSARC/2008/201 FastTrack timeout 03/24/2008] Status: RO Content-Length: 547 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: Grub Findroot 1.2. Name of Document Author/Supplier: Author: Vikram Hegde 1.3 Date of This Document: 17 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: FastTrack 6.6. ARC Exposure: open From jg@jurassic.sfbay.sun.com Mon Mar 17 15:17:24 2008 Received: from jurassic.eng.sun.com (jurassic-226-b [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2HMHOqM000744 for ; Mon, 17 Mar 2008 15:17:24 -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 m2HMHNoP405954; Mon, 17 Mar 2008 15:17:24 -0700 (PDT) Message-Id: <200803172217.m2HMHNoP405954@jurassic.eng.sun.com> Date: Mon, 17 Mar 2008 15:14:34 -0700 (PDT) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: Grub Findroot [PSARC 2008/201 fasttrack timeout 03/24/2008] To: psarc-ext@sac.sfbay.sun.com Cc: shidokht.yadegari@sun.com, jan.setje-eilers@sun.com, lori.alt@sun.com, jerry.gilliam@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SN9loDHsDGvAQgrFvkgVgA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 sun4u sparc Status: RO Content-Length: 9877 I am sponsoring the following case on behalf of Vikram Hegde as a fast-track with timeout set to 03/24/2008. The project requests minor/patch binding. findroot - biosdev replacement ============================== BACKGROUND ============ biosdev is a private utility that was introduced by the Newboot x86 project (PSARC/2004/454). It's primary purpose is to map BIOS disk IDs (i.e. identifiers generated by the BIOS for hard disks) into Solaris device paths. BIOS disk IDs range from 0x80 to 0x87. Solaris typically does not use BIOS disk IDs. The need for this mapping arose because of the GRUB bootloader. GRUB uses a menu based approach to allow users to load different OSes. One of the components that goes into making a menu entry is the GRUB "root" command. The "root" command is of the form: root (hdX, Y, Z) where X is a number from 0 to 7, Y is a number from 0 to 3 and Z is a letter starting with 'a'. X is the hard disk number which is derived from the BIOS disk ID for a hard disk. Thus if BIOS disk ID is 0x80, then X is 0 making the first component hd0. Similarly for 0x81, it is hd1 and so on. Y is the fdisk partition number and Z is the slice letter. Thus a root filesystem that exists on BIOS disk ID 82, fdisk partition 2 (fdisk partitions start with 1 but are represented by GRUB starting with 0) and slice c will be represented as root (hd2, 1, c) While the second and third components of the root component are easily derived (Y via fdisk and Z is directly mappable into a Solaris slice), determining X is a real problem. biosdev was initially created to solve this problem. However, it has since proved to be unreliable, doesn't work at all on some systems and the source of numerous bugs. This proposal outlines a solution that replaces biosdev with a better and more reliable mechanism. THE PROBLEM ============ The assignment of BIOS disk IDs to disks are entirely determined by the BIOS which varies from one BIOS to another. In addition and more importantly, BIOS disk IDs are very sensitive to the boot disk. If the boot disk changes, the BIOS disk ID assignment can change in a completely unpredictable fashion. The only way to determine what the disk assignment is for a particular boot device is to actually boot from that device and then ask the BIOS. This has important consequences for Solaris (more on that later). Thus if we are to use GRUB's root command, we are forced to use something like biosdev. biosdev uses two mechanisms to determine the mapping: 1. INT13 fn 48 BIOS call- INT13 fn 48 is a BIOS service that when invoked on a particular disk, reports various disk parameters including device path information such as as "Host bus type", "interface type", "interface path" and "device path". For example for a SCSI disk we may see the following information: Host Bus type: PCI Interface type: SCSI Interface Path: PCI Bus number, Slot number, Function number Device Path: SCSI Target ID. Early during bootup, we issue this BIOS call against all accessible disks and store the reported information in properties named biosdev-0x8n. When biosdev is subsequently invoked (post-boot), a devinfo snapshot is taken and we attempt to match a Solaris disk via the data stored in the biosdev-0x8N properties. 2. First sector match - Early boot code reads the first sector of each disk and creates a property that is called biosdev-x8N that includes among other things the contents of the first sector of that disk. Once Solaris is booted and when biosdev is invoked, it reads the first sector of a disk and compares the data found with the data in the properties to find the correct mapping. biosdev has a large number of problems with no practical or viable solutions 1. The INT13 fn 48 BIOS "device path" information appears not be used by other major OSes so bugs in it's BIOS implementation are common. In addition, there appears to be confusion among BIOS developers on what information to report for SATA disks. Some BIOSes report these disks as ATA whereas some report them as SATA. In addition with the integration of the nv_sata project, it may be possible to run a disk as either PATA (ATA) or SATA. All of this creates signifcant problems for biosdev with SATA disks. Many BIOSes (including many of Sun's x86 platforms) are buggy as far as "device path" information reported by this BIOS service is concerned and some BIOSes don't provide device path information at all. 2. If there is no INT13 fn 48 support for device path information, biosdev resorts to first sector match. This can fail if the two (or more) disks on the system have the same bits on the 1st sector of the disk. Identical first sectors are quite common on systems with multiple disks. 3. If the GRUB menu is generated while booted off one disk and the customer changes boot disk order to boot from another, the GRUB menu won't be present on the new boot disk or even if it is, it is no longer correct, since the BIOS may have renumbered 0x80, 0x81 etc. to point at different disks. This problem is particularly acute with Live Upgrade. Changing the BIOS disk boot order on a system with Live Upgrade will result in unbootable BEs. 4. biosdev does not work with Xen dom0 because no BIOS services are available in dom0. This currently makes it impossible to support Live Upgrade with Xen. 5. If the user or some utility changes the Master Boot Record (MBR) via fdisk, then the content of the first sector will change and will no longer match first sector data maintained in the biosdev properties resulting in failed matches. 6. biosdev does not work correctly if vold is running. To run biosdev, vold has to be killed. This is a major problem when running Live Upgrade on older releases. 7. Live Upgrade currently uses a single GRUB menu which is located on the boot disk. Even if we want to, we cannot have multiple redundant GRUB menus on other disks on the system, because we have no way of knowing what the BIOS disk mapping is when booted off other disks. We only have information via biosdev (if it works) for the current boot disk. This is obviously an issue of serious concern, since if the boot disk fails, the system will be unbootable even if bootable instances of Solaris exist on other disks in the system. This has in fact happened on the Nevada Gate machine and it took engineers with knowledge of Live Upgrade and boot internals several hours to recover. This problem if it occurs is not something customers can fix on their own. THE SOLUTION ============ The solution is twofold. 1. Enhance GRUB to provide a new "findroot" command. There is precedence for such enhancements - the Xen project enhanced the kernel and module GRUB commands giving us the "kernel$" and "module$" commands. In addition, the ZFS boot project will enhance GRUB to provide the "bootfs" command. The findroot command is generic (meaning it can be used by other OSes as well) and we plan to contribute this command back to the mainstream GRUB tree. The operand for the findroot command will be the following: findroot (, Y, Z) where signature is a unique filename in /boot/grub/bootsign on the root filesystem of interest. Y and Z are the same as that for the "root" command. An alternative form with slightly reduced performance will also be made available. It will have the form: findroot where signature is a file in /boot/grub/bootsign. This is for those who do not want to or cannot determine Y and Z. The format of the signature will vary depending on the install method and filesystem. The name space is intentionally carved out into subspaces: For Live Upgrade ------------------ findroot (BE_, Y, Z) For fresh install and standard upgrade on ufs filesystems --------------------------------------------------------- findroot (rootfs, Y, Z) where N is a unique number For fresh install and standard upgrade on ZFS filesystems --------------------------------------------------------- findroot (pool_, Y, Z) Fresh install, standard upgrade and live upgrade will be modified to generate the signature file. Fresh install and standard upgrade will use bootadm to generate the signature file. Live Upgrade will not use bootadm - it will generate this signature file itself. Since the namespace for Live Upgrade is separate, this will not result in duplicated code. 2. Step 1 alone does not allow us to get rid of biosdev. Live Upgrade still needs biosdev to know where to put the GRUB menu since only the GRUB menu on the boot disk is used to boot the system. The solution for this is simple. We install GRUB and the GRUB menu on every boot environment (BE) in the system. This has the very important benefit of providing redundancy. We are no longer hostage to the boot disk. If it fails, we can boot off any other disk on the system, provided it has a bootable Solaris instance on it. There is another benefit to this approach. Live Upgrade currently has the notion of the "GRUB slice" i.e. the slice on the boot disk where the (sole) menu.lst in the system resides. Much of the code in the GRUB based implementation of Live Upgrade is devoted to maintaining this GRUB slice. If GRUB is installed on every Solaris instance, then this code can be removed, vastly simplifying the current Live Upgrade implementation CONCLUSION =========== This proposed solution allows us to replace the unreliable biosdev utility while at the same time allowing us to keep redundant copies of the GRUB menu on every Solaris instance. Because of the findroot command, we are no longer tied to BIOS disk identifiers and the menu is guaranteed to work irrespective of which disk is used to boot and irrespective of what the BIOS disk ID is. Another plus - using this proposed solution would vastly simplify the current Live Upgrade code on x86 From mws@zion.sfbay.sun.com Tue Mar 18 14:38:34 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2ILcYUV020515 for ; Tue, 18 Mar 2008 14:38:34 -0700 (PDT) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2ILcXrS626209; Tue, 18 Mar 2008 21:38:33 GMT Received: (from mws@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m2ILcXop626208; Tue, 18 Mar 2008 14:38:33 -0700 (PDT) From: Michael Shapiro Message-Id: <200803182138.m2ILcXop626208@zion.sfbay.sun.com> Subject: Re: Grub Findroot [PSARC 2008/201 fasttrack timeout 03/24/2008] In-Reply-To: <200803172217.m2HMHNoP405954@jurassic.eng.sun.com> from Jerry Gilliam at "Mar 17, 2008 03:14:34 pm" To: jg@jurassic.sfbay.sun.com Date: Tue, 18 Mar 2008 14:38:32 -0700 (PDT) Cc: psarc-ext@sac.sfbay.sun.com, shidokht.yadegari@sun.com, jan.setje-eilers@sun.com, lori.alt@sun.com, jerry.gilliam@sun.com, mws@sun.com X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2333 > > findroot - biosdev replacement > ============================== > > BACKGROUND > ============ > > biosdev is a private utility that was introduced by the Newboot x86 project > (PSARC/2004/454). It's primary purpose is to map BIOS disk IDs (i.e. > identifiers generated by the BIOS for hard disks) into Solaris device paths. > > ... > > biosdev has a large number of problems with no practical or viable solutions The findroot description here sounds fine to me, and I agree that it has usefulness for the problems described. But I do not believe deleting biosdev is ok, nor do I believe what you've described addresses all of what biosdev does. There is a fundamental booting problem which is that the BIOS setup menu is in control of what devices are configured for initial boot attempts. Let's say my hardware supports four possible internal boot devices. Let's say my BIOS menu has two of those four disabled. Let's say my installer then runs and wants to know which two disks it should use as the thing to install onto. The only way to do that is to ask the BIOS as to its boot device list in the way that biosdev does, i.e. grab the BIOS boot disks and then match them through the EDD to devices. Particularly if the devices are yet to be installed and just got unpacked in the factory, there is no magic boot signature or whatever on them. The completely broken part of biosdev is that it ever even had code to fall back to the block content -- it never should have done that. And I do agree that some BIOSes don't do this stuff correctly (what a surprise). But there is no reason we can't require Sun platforms to test this on Solaris and make it work properly (particularly if we limit that to only internal devices that can be probed out by the BIOS). If you're not solving that problem somehow, then that part of biosdev needs to be left alone. There's also no reason that can't be trivially made to work under Xen. biosdev doesn't talk to the BIOS at all -- it just reads the properties we create from EDD in the kernel. The Xen kernel could simply forge up the same property from the one boot device it wants to expose and install an appropriate bios-boot-disk property in the device tree and biosdev will run just fine. -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/ From Vikram.Hegde@sun.com Tue Mar 18 14:58:31 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2ILwUHJ021309 for ; Tue, 18 Mar 2008 14:58:30 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2ILwUVG008512 for ; Tue, 18 Mar 2008 14:58:30 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2ILwP2t014327 for ; Tue, 18 Mar 2008 14:58:25 -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 <0JXY00K014UPED00@fe-sfbay-10.sun.com> (original mail from Vikram.Hegde@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 18 Mar 2008 14:58:25 -0700 (PDT) Received: from [129.146.224.150] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXY008V85155D60@fe-sfbay-10.sun.com>; Tue, 18 Mar 2008 14:58:18 -0700 (PDT) Date: Tue, 18 Mar 2008 14:50:38 -0700 From: Vikram Hegde Subject: Re: Grub Findroot [PSARC 2008/201 fasttrack timeout 03/24/2008] In-reply-to: <200803182143.m2ILhY3b501062@jurassic.eng.sun.com> Sender: Vikram.Hegde@sun.com To: mws@zion.sfbay.sun.com, jg@jurassic.sfbay.sun.com Cc: Jerry Gilliam , Vikram.Hegde@sun.com, psarc-ext@sac.sfbay.sun.com, Shidokht.Yadegari@sun.com, Jan.Setje-Eilers@sun.com, Lori.Alt@sun.com Message-id: <47E0392E.10402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200803182143.m2ILhY3b501062@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0a1 (X11/20060807) Status: RO Content-Length: 3476 Hi, I should have mentioned this in the case materials but there are two classes of problems for which biosdev can be used 1. Populating the GRUB menu.lst with root(?) entries 2. Determining the boot disk or determining the accessibility (to BIOS) of various disks. The intent of the proposal is to replace the use of biosdev for 1. Biosdev will not be deleted and will continue to be present in Solaris, but it will be used solely for problems mentioned in 2. Any use that install makes of biosdev for "2" will stay intact after this fix integrates. Does that address your concern ? Vikram Jerry Gilliam wrote: > ------------- Begin Forwarded Message ------------- > > Date: Tue, 18 Mar 2008 14:38:32 -0700 (PDT) > From: Michael Shapiro > Subject: Re: Grub Findroot [PSARC 2008/201 fasttrack timeout 03/24/2008] > To: jg@jurassic.sfbay.sun.com > Cc: psarc-ext@sac.sfbay.sun.com, shidokht.yadegari@sun.com, > jan.setje-eilers@sun.com, lori.alt@sun.com, jerry.gilliam@sun.com, mws@sun.com > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.4.1.325704 > > >> findroot - biosdev replacement >> ============================== >> >> BACKGROUND >> ============ >> >> biosdev is a private utility that was introduced by the Newboot x86 project >> (PSARC/2004/454). It's primary purpose is to map BIOS disk IDs (i.e. >> identifiers generated by the BIOS for hard disks) into Solaris device paths. >> >> ... >> >> biosdev has a large number of problems with no practical or viable solutions >> > > The findroot description here sounds fine to me, and I agree that it > has usefulness for the problems described. But I do not believe deleting > biosdev is ok, nor do I believe what you've described addresses all of > what biosdev does. > > There is a fundamental booting problem which is that the BIOS setup > menu is in control of what devices are configured for initial boot attempts. > Let's say my hardware supports four possible internal boot devices. > Let's say my BIOS menu has two of those four disabled. > Let's say my installer then runs and wants to know which two disks > it should use as the thing to install onto. > > The only way to do that is to ask the BIOS as to its boot device list > in the way that biosdev does, i.e. grab the BIOS boot disks and then > match them through the EDD to devices. Particularly if the devices > are yet to be installed and just got unpacked in the factory, there is > no magic boot signature or whatever on them. > > The completely broken part of biosdev is that it ever even had code to > fall back to the block content -- it never should have done that. > And I do agree that some BIOSes don't do this stuff correctly (what a > surprise). But there is no reason we can't require Sun platforms to > test this on Solaris and make it work properly (particularly if we limit > that to only internal devices that can be probed out by the BIOS). > > If you're not solving that problem somehow, then that part of > biosdev needs to be left alone. > > There's also no reason that can't be trivially made to work under Xen. > biosdev doesn't talk to the BIOS at all -- it just reads the properties > we create from EDD in the kernel. The Xen kernel could simply forge up > the same property from the one boot device it wants to expose and install > an appropriate bios-boot-disk property in the device tree and biosdev > will run just fine. > > -Mike > > From mws@zion.sfbay.sun.com Tue Mar 18 15:00:25 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2IM0PtG021422 for ; Tue, 18 Mar 2008 15:00:25 -0700 (PDT) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2IM0LRi627244; Tue, 18 Mar 2008 22:00:21 GMT Received: (from mws@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m2IM0Kbs627243; Tue, 18 Mar 2008 15:00:20 -0700 (PDT) Date: Tue, 18 Mar 2008 15:00:20 -0700 From: Mike Shapiro To: Vikram Hegde Cc: mws@zion.sfbay.sun.com, jg@jurassic.sfbay.sun.com, psarc-ext@sac.sfbay.sun.com, Shidokht.Yadegari@sun.com, Jan.Setje-Eilers@sun.com, Lori.Alt@sun.com Subject: Re: Grub Findroot [PSARC 2008/201 fasttrack timeout 03/24/2008] Message-ID: <20080318220020.GB627190@sun.com> References: <200803182143.m2ILhY3b501062@jurassic.eng.sun.com> <47E0392E.10402@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E0392E.10402@sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 867 On Tue, Mar 18, 2008 at 02:50:38PM -0700, Vikram Hegde wrote: > Hi, > > I should have mentioned this in the case materials but there are two > classes of problems for which biosdev can be used > > 1. Populating the GRUB menu.lst with root(?) entries > > 2. Determining the boot disk or determining the accessibility (to BIOS) > of various disks. > > The intent of the proposal is to replace the use of biosdev for 1. > Biosdev will not be deleted and will continue to be present in Solaris, > but it will be used solely for problems mentioned in 2. Any use that > install makes of biosdev for "2" will stay intact after this fix integrates. > > Does that address your concern ? > > Vikram Yes, but please modify the final copy of your proposal to reflect what you are saying above. -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/ From johnlev@barman.uk.sun.com Tue Mar 18 15:03:50 2008 Received: from dm-uk-02.uk.sun.com (dm-uk-02.UK.Sun.COM [129.156.101.196]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2IM3nbK021519 for ; Tue, 18 Mar 2008 15:03:50 -0700 (PDT) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2IM3htB007950; Tue, 18 Mar 2008 22:03:43 GMT Received: from johnlev by barman.uk.sun.com with local (Exim 4.42) id 1Jbjtw-00079h-J9; Tue, 18 Mar 2008 22:03:20 +0000 Date: Tue, 18 Mar 2008 22:03:20 +0000 From: John Levon To: Michael Shapiro Cc: jg@jurassic.sfbay.sun.com, jerry.gilliam@sun.com, lori.alt@sun.com, jan.setje-eilers@sun.com, mws@sun.com, shidokht.yadegari@sun.com, psarc-ext@sac.sfbay.sun.com Subject: Re: Grub Findroot [PSARC 2008/201 fasttrack timeout 03/24/2008] Message-ID: <20080318220320.GA26839@barman.uk.sun.com> References: <200803172217.m2HMHNoP405954@jurassic.eng.sun.com> <200803182138.m2ILcXop626208@zion.sfbay.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803182138.m2ILcXop626208@zion.sfbay.sun.com> X-Url: http://jurassic.eng/~johnlev/ User-Agent: Mutt/1.5.6i Sender: John Levon Status: RO Content-Length: 1209 On Tue, Mar 18, 2008 at 02:38:32PM -0700, Michael Shapiro wrote: > Let's say my installer then runs and wants to know which two disks > it should use as the thing to install onto. > > The only way to do that is to ask the BIOS as to its boot device list > in the way that biosdev does, i.e. grab the BIOS boot disks and then This is specific to one case though, right? That is, initial install onto a fresh system. Is there another case where asking the BIOS this list is the right thing to do? > There's also no reason that can't be trivially made to work under Xen. > biosdev doesn't talk to the BIOS at all -- it just reads the properties > we create from EDD in the kernel. The Xen kernel could simply forge up > the same property from the one boot device it wants to expose and install > an appropriate bios-boot-disk property in the device tree and biosdev > will run just fine. We could fake things up I'm sure. But we want to get away from the idea of knowing about boot device paths altogether (for making v2v less miserable if nothing else), so something that avoids the issue, and can also fix the particular dom0 and domU cases without special hacks, seems like the way to go. regards john From mws@zion.sfbay.sun.com Tue Mar 18 15:08:40 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2IM8eA0021556 for ; Tue, 18 Mar 2008 15:08:40 -0700 (PDT) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2IM8dkH627535; Tue, 18 Mar 2008 22:08:39 GMT Received: (from mws@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m2IM8cLL627534; Tue, 18 Mar 2008 15:08:38 -0700 (PDT) Date: Tue, 18 Mar 2008 15:08:38 -0700 From: Mike Shapiro To: John Levon Cc: Michael Shapiro , jg@jurassic.sfbay.sun.com, jerry.gilliam@sun.com, lori.alt@sun.com, jan.setje-eilers@sun.com, shidokht.yadegari@sun.com, psarc-ext@sac.sfbay.sun.com Subject: Re: Grub Findroot [PSARC 2008/201 fasttrack timeout 03/24/2008] Message-ID: <20080318220838.GE627190@sun.com> References: <200803172217.m2HMHNoP405954@jurassic.eng.sun.com> <200803182138.m2ILcXop626208@zion.sfbay.sun.com> <20080318220320.GA26839@barman.uk.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080318220320.GA26839@barman.uk.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1680 On Tue, Mar 18, 2008 at 10:03:20PM +0000, John Levon wrote: > On Tue, Mar 18, 2008 at 02:38:32PM -0700, Michael Shapiro wrote: > > > Let's say my installer then runs and wants to know which two disks > > it should use as the thing to install onto. > > > > The only way to do that is to ask the BIOS as to its boot device list > > in the way that biosdev does, i.e. grab the BIOS boot disks and then > > This is specific to one case though, right? That is, initial install > onto a fresh system. Is there another case where asking the BIOS this > list is the right thing to do? Asking the BIOS is just asking the BIOS. It's useful when that's the question you're trying to answer. > > There's also no reason that can't be trivially made to work under Xen. > > biosdev doesn't talk to the BIOS at all -- it just reads the properties > > we create from EDD in the kernel. The Xen kernel could simply forge up > > the same property from the one boot device it wants to expose and install > > an appropriate bios-boot-disk property in the device tree and biosdev > > will run just fine. > > We could fake things up I'm sure. But we want to get away from the idea > of knowing about boot device paths altogether (for making v2v less > miserable if nothing else), so something that avoids the issue, and can > also fix the particular dom0 and domU cases without special hacks, seems > like the way to go. I'm certainly not suggesting Xen boot or install depend on this. I'm just noting that it's trivial to support biosdev under Xen and the description of that issue in the case materials isn't correct. -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/ From jg@jurassic.sfbay.Sun.COM Tue Mar 25 16:29:00 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 m2PNT0wP003770 for ; Tue, 25 Mar 2008 16:29:00 -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 m2PNT0d3836121; Tue, 25 Mar 2008 16:29:00 -0700 (PDT) Message-Id: <200803252329.m2PNT0d3836121@jurassic.eng.sun.com> Date: Tue, 25 Mar 2008 16:26:06 -0700 (PDT) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: Re: Grub Findroot [PSARC 2008/201 fasttrack timeout 03/24/2008] To: psarc-ext@sac.sfbay.sun.com, vikram.hedge@sun.com Cc: shidokht.yadegari@sun.com, jan.setje-eilers@sun.com, lori.alt@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gwTa8MXRbQMqeBbgwhfKkA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_78 SunOS 5.11 sun4u sparc Status: RO Content-Length: 119 I've marked this case as closed approved with the updated materials as discussed in the materials directory. -jg