Date: Wed, 18 Dec 2013 15:48:37 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Adam McDougall <mcdouga9@egr.msu.edu> Cc: "stable@FreeBSD.org" <stable@FreeBSD.org>, Devin Teske <dteske@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: Re: bsdinstall, zfs booting, gpt partition order suitable for volume expansion Message-ID: <1AD35F39-35EB-4AAD-B4B1-AF21B2B6F6BA@fisglobal.com> In-Reply-To: <20131218135326.GM1728@egr.msu.edu> References: <20131210175323.GB1728@egr.msu.edu> <93C924DB-E760-4830-B5E2-3A20160AD322@fisglobal.com> <2D40298B-39FA-4BA9-9AC2-6006AA0E0C9C@fisglobal.com> <73E28A82-E9FE-4B25-8CE6-8B0543183E7F@fisglobal.com> <20131218135326.GM1728@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 18, 2013, at 5:53 AM, Adam McDougall wrote: > On Mon, Dec 16, 2013 at 08:18:14PM +0000, Teske, Devin wrote: >=20 >=20 > On Dec 14, 2013, at 7:44 PM, Teske, Devin wrote: >=20 >>=20 >> On Dec 10, 2013, at 11:00 AM, Devin Teske wrote: >>=20 >>>=20 >>> On Dec 10, 2013, at 9:53 AM, Adam McDougall wrote: >>>=20 >>>> I was wondering if either the default gpt partition order could become >>>> p1=3Dboot, p2=3Dswap, p3=3Dzpool, or if the installer could be enhance= d at >>>> some point to allow the user to select the order. It seems like it wo= uld >>>> be easier to expand the size of the raw device (VM, iscsi, etc) and ex= pand >>>> the zpool if it is the last partition. I am not in a hurry to get this >>>> solved, but if a change to the default order is worthwhile, it seems l= ike >>>> before 10.0 would be a good time to set precedent. I'm trying to thin= k ahead >>>> where people will be installing 10 to VMs or expandable volumes so the= y can >>>> take advantage of expansion with less hassle. I pinged Allen Jude on = this >>>> briefly, I think he said it used to be that way but it was changed to >>>> accomodate MBR partitioning (I think, apologies for not remembering de= tails). >>>=20 >>> Excellent idea. Let me put that into a patch. I'll let you know when I = have >>> something that tests clean. >>=20 >> GPT proved trivial. >> MBR on the other hand... that proved challenging. >>=20 >> While trying to best that challenge... I uncovered more than a couple na= sty bugs >> while iterating over every possible combination in the installer. >>=20 >> That being said... I'm coming out of the "tunnel" since you sent this e-= mail and >> will soon have something to commit that implements this suggestion while= at >> the same time, plugging a few edge-cases. >=20 > Alrighty-then... time to share... >=20 > Here's the commit that does what you want... >=20 > [snip] > I did my testing in virtualbox with 4 5g disk images. I'm skeptical that 5g is big enough. Without knowing much more about your setup (GPT v MBR; SWAP v No-SWAP; GELI v No-GELI), I'd just like to say that there are a couple combinations that would overflow that... E.g., GPT + GELI + SWAP by default would be better at 6GB per disk. E.g., MBR + SWAP would similarly work better at 6GB per disk. While there is code to make sure you don't use disks that are too small, I can't say whether it catches every edge-case. NB: The nature of the error doesn't look to be based on using disks that are too small; I just thought I would mention it because 5G looks too small to me for some layouts. > Whether or not the > installer continues, it does seem to partition the disks as discussed. >=20 > When I hit F3 I see: > DEBUG: zfs_create_boot: Creating root pool... > DEBUG: zfs_create_boot: zpool create -o altroot=3D/mnt -m none -f "zroot"= ada0p3.nop ada1p3.nopzpool create ada2p3.nop "" > DEBUG: zfs_create_boot: retval=3D1 <output below> > cannot open 'ada1p3.nopzpool': no such GEOM provider If you send me the entire log, I can likely pinpoint the issue. That data displayed on Alt-F3 is saved in /tmp/bsdinstall_log --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1AD35F39-35EB-4AAD-B4B1-AF21B2B6F6BA>