Date: Wed, 9 Oct 2013 18:14:48 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Allan Jude <freebsd@allanjude.com> Cc: "<freebsd-current@freebsd.org>" <freebsd-current@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Message-ID: <13CA24D6AB415D428143D44749F57D720FC4B907@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <525596A7.2090701@allanjude.com> References: <52531295.7090700@allanjude.com> <5254D231.5070803@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC4B3F2@LTCFISWMSGMB21.FNFIS.com> <525596A7.2090701@allanjude.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 9, 2013, at 10:47 AM, Allan Jude wrote: > On 2013-10-09 13:21, Teske, Devin wrote: >> On Oct 8, 2013, at 8:49 PM, Allan Jude wrote: >>=20 >>> On 2013-10-07 15:59, Allan Jude wrote: >>>> Devin Teske and I have been working on a big patch to bsdinstall to >>>> implement installing on a ZFS pool. It supports both GPT and MBR, the = 4k >>>> sector gnop trick, and optional GELI encryption. We would like to comm= it >>>> this in time for 10.0-BETA1 so it needs some testing to work out any >>>> obvious bugs before we send it off to re@ to get it committed. >>>>=20 >>>> It includes a single configuration menu that allows you to select all = of >>>> the required details, including which drives to use (gets details from >>>> camcontrol, also includes an inspection utility that presents the >>>> detailed output of camcontrol inquiry/identify, and gpart show), what >>>> ZFS RAID level to use (taking in to consideration the selected number = of >>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. >>>>=20 >>>>=20 >>>> Additional, it includes some other changes to bsdinstall: >>>> 1. Change the default to the 'non-standard keyboard mapping' prompt to= no >>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with ju= st 1 >>>> 3. Remove the dialog asking if you wish to enable crash dumps, this >>>> feature has been combined into the regular 'services to enable' dialog >>>> and enabled by default >>>>=20 >>>>=20 >>>> You can browse the patches here: >>>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://druidbsd.cvs.sf.ne= t/viewvc/druidbsd/bsdinstall_zfs/&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r= =3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3DoPEdrpFUFqEutq%2= B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=3D32f69a33d9c98c63ecf3962b89eea0af6= 31f5a2fd6e82b55afb6ec139f3f803d >>>>=20 >>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, >>>> available compressed (48 MB) or uncompressed (211 MB): >>>>=20 >>>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://www.allanjude.com/= bsd/zfsbootonly_2013-10-06.iso.xz&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r= =3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3DoPEdrpFUFqEutq%2= B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=3Dfd0f3ed623f12c8cb5eee607cf8212252= 3a0800ab9f5624cb3f77ae2646e1b1b >>>>=20 >>>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://www.allanjude.com/= bsd/zfsbootonly_2013-10-06.iso&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3D= LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3DoPEdrpFUFqEutq%2B7D= HGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0A&s=3Dfa49aaa528513a591ac40a2f0c5666abae2d= 7269bd66ac70d7100475a9574300 >>>>=20 >>>>=20 >>>> We look forward to your feedback >>>>=20 >>> We've made more improvements, including corporating most all of the >>> feedback we've gotten so far >>>=20 >>>=20 >>> Outstanding items: >>> 1. Apply the changes to ipv6 config the way we did ipv4 >>> 2. improve disk identification (model info and serial # instead of one >>> or the other) >>> 3. Include a helpful message before the GELI step where you have to >>> enter your password many times, the user will be less confused if it is >>> explained why they have to enter their password 3 * number of disks tim= es >> I'm hopeful that we can script the application of a password that we >> first prompt for. >>=20 >> What tool is prompting for a password? Can we not just provide an answer >> on stdin? (e.g., echo "$pass" | tool_that_needs_pass) >>=20 > It is 'geli create' and 'geli attach'. I am not sure if we want to have > the password show up in the process list (obviously in the installer > this is less of an issue, but) >=20 It won't. echo is a shell built-in. If we're uber paranoid... we prefix the word "builtin"; e.g.,... builtin echo "$pass" | tool_that_needs_pass You'll see the tool in ps, but you won't see the echo (that's part of the shell invocation -- all you see in ps is an instance of sh). >>=20 >>> 4. Validate vdev type choice inside the vdev type menu, and warn the >>> user if they have made an invalid selection, so they can add more disks >>> or chance their selection, without having to try to start the >>> installation first >> This will be done with fanciness ;D (read: ... --and-widget --infobox ..= . and >> sundry smartness; retaining as much as possible the ability to do things >> out of order but never arise at a point of astonishment). >>=20 >=20 > I don't think we need --and-widget, just in the function where we apply > the results of the menu selection, The purpose of --and-widget with an --infobox is to let the user know that validation is occurring each/every time they make a selection. Seeing the infobox before being returned to the previous menu (in the case of selecting a valid vdev_type) is to cement in the mind of the user that t= heir selection was validated. Of course, in the case of an invalid selection, th= ey get a message box. What the message box says depends on: 1. Are they trying to select a vdev_type for which they don't have enough devices? Tell them that they don't have enough devices, and bring them back to the vdev_type menu (to select a different [valid] vdev type *or* cancel and go back to the ZFS menu where they can optionally Rescan for more devices -- allowing that vdev_type to be selected without issue). In the prompt that tells them that they don't have enough disks in their system to select that vdev_type, we sould hint that they can choose cancel and go back to use the "Rescan" option to scan for more devices. 2. Are they trying to select a vdev_type for which they have enough devices but have not yet made enough selections? Drop them back to the ZFS menu so they can go select the appropriate number of devices. Good? > we can add a regular --msgbox telling > them that their config won't work, and they need to either select more > drives or a different vdev type >=20 I agree on the msgbox -- and I still think the temporaneous infobox injected via --and-widget would be value-add. Question is what to do after the msgbox. I posit that if the vdev_type is valid but they don't have enough disks currently selected, that they be tossed back at the ZFS menu. However, if they instead select a vdev_type which couldn't possible be satisfied given the number of devices available to the hardware... keep them in the vdev_type menu.=20 >>> 5. Whatever else you guys find wrong tonight >>>=20 >>> I generated new test images, and attached the patch (which got REALLY >>> big when Devin Teske decided to fix "all of the things": >>>=20 >> And then I merged "all of the things" into HEAD, so the patch-set shrunk >> back to its normal size. Now we have global exit codes which will make >> merging of code that is based off of Thomas Dickey's samples easier. >=20 > I am glad to see all of the good ideas, and plans to make everything > wonderful, but my biggest concern is getting this over to re@ so it can > get in to 10.0-BETA1, the deadline for which is looming (like, tomorrow > I think). >=20 I hate to say it... but it was the netconfig and keymap changes that put us out of our way. If anything, I'd like to see those get dropped and have us focus on ZFS. > As such, I have rolled back the patches to netconfig and netconfig_ipv4 > (my stuff to reduce the number of dialogs to configure ipv4, it posed > some problems with the possible usage of xdialog, and didn't actually > offer an option to 'cancel'). I kept Warren's netconfig wireless patch >=20 Cool. We're thinking along the same lines. > This leaves the only real outstanding problem the keymap thing. I > propose changing it from a yes/no/other to a --menu, and hopefully we > can find the bug with the display name, or just make it show the keymap > name instead. >=20 Last night I started doing what I knew "had to be done". Just as was the case with "bsdconfig timezone" ... I literally went into tzsetup(8) and converted the C code line-by-line to shell. (don't take that *too* literally... swaths of optimization were applied int he process; point being that the shell quite-ably reads the ISO3166 tables and zone files in the same *exact* manner as tzetup). I've gone into kbdmap and looked at how it parses things. No biggie... looks like INDEX.keymaps (whose suffix matches the directory he lives in) is nothing more than a colon-delimited 3-field syntax with lea= ding whitespace chopped and a comment-character of "#". Nothing a trival awk(1) script couldn't handle. To make things cute... I've got the code parsing into a shell structs (the = same way I parse dhclient.leases and other file formats). By having an awk script read the file and generate shell statements that in-turn load the data into= the exigent namespace. I'll see what I can get in ASAP. --=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?13CA24D6AB415D428143D44749F57D720FC4B907>