Date: Wed, 19 Feb 2003 00:07:55 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Arun Sharma <arun@sharma-home.net> Cc: freebsd-ia64@FreeBSD.ORG Subject: Re: FreeBSD ia64 install problems WAS: install on Dell Precision Work Station 730 Message-ID: <20030219080755.GA557@dhcp01.pn.xcllnt.net> In-Reply-To: <20030219075115.GA32605@sharma-home.net> References: <03781128C7B74B4DBC27C55859C9D7380B9DDB5D@es06snlnt.sandia.gov> <20030210203522.GA543@athlon.pn.xcllnt.net> <ur8ab1u5l.fsf@unix-os.sc.intel.com> <20030214024721.GB1573@athlon.pn.xcllnt.net> <ulm0i1gfu.fsf@unix-os.sc.intel.com> <20030215020654.GA1779@athlon.pn.xcllnt.net> <u65rh10qu.fsf@unix-os.sc.intel.com> <20030219022618.GA1081@athlon.pn.xcllnt.net> <20030219075115.GA32605@sharma-home.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 18, 2003 at 11:51:15PM -0800, Arun Sharma wrote: > On Tue, Feb 18, 2003 at 06:26:18PM -0800, Marcel Moolenaar wrote: > > On Tue, Feb 18, 2003 at 06:07:53PM -0800, Arun Sharma wrote: > > > > > > Now if I convert the MBR based partition table into a fake MBR (with a > > > single EFI GPT partition), I can't mount root anymore from ufs:da0s2a. > > > > That's because it'll be ufs:da0s1a. By removing the MBR, you remove > > the MBR based mapping. What happens is that the GPT takes over, which > > has it's own mapping. > > 1. Why da0s1a ? The FreeBSD partition is the second partition in the GPT. You're right. I was mistaken. The GEOM GPT code does not maintain seperate numbers for slices and paritions. > 2. ufs:da0s1a failed to mount root for me. However, it gave me the > option of mounting root from: da0s2, da0p4 etc. > > When I chose to mount root from da0s2 (without the "a"), it dropped > me into single user mode, because the kernel couldn't find /usr and > other partitions. Hmmm... This smells like a GEOM bug. If the disklabel is valid (hence my question about this before), GEOM should automagically create the a, b, etc partition entries. If this appears not to be the case. It may be possible that the disklabel class does not like to work with the gpt class. I have to check that... > 3. I think FreeBSD installer writing to the legacy MBR when using GPT is > a significant issue, because it renders the EFI system partition > (fs0) invisible to firmware. I ended up dd'ing a known good fake MBR > into the first 512 bytes of the disk to recover. Exposure of 5.0-RELEASE has given good feedback. Given the short amount of time we had for 5.0-R, MBRs was the best we could do. Now it's a matter of finding the people and the time to actually create GPT. Patches are appreciated. > So how do I get the kernel to peep into da0s2 and recognize the various > partitions inside it (da0s2a etc) ? I'm using GPT_ENT_TYPE_FREEBSD. Your > successful gpt install seemed to use GPT_ENT_TYPE_FREEBSD_UFS. The difference between the two is exactly the disklabel. The first is used to identify a "legacy" slice with disklabel. The second is a raw UFS partition. Note that gpt(8) can migrate a MBR into a GPT, using raw UFS and swap partitions. One has to patch GEOM to allow opening the disk device for writing. I think this is it: ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030219080755.GA557>