Date: Mon, 21 Oct 2013 17:20:50 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Allan Jude <freebsd@allanjude.com> Cc: Johan Broman <johan@bridgenet.se>, Devin Teske <dteske@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com>, "<freebsd-current@freebsd.org> Current" <freebsd-current@freebsd.org> Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Message-ID: <13CA24D6AB415D428143D44749F57D720FC903FC@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <526561E1.3000903@allanjude.com> References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> <5262B304.3090605@allanjude.com> <5262BC56.4050004@bridgenet.se> <13CA24D6AB415D428143D44749F57D720FC7F916@LTCFISWMSGMB21.FNFIS.com> <52654C0C.80702@bridgenet.se> <52654D47.6020106@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC8FE7F@LTCFISWMSGMB21.FNFIS.com> <52655118.6010909@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC90006@LTCFISWMSGMB21.FNFIS.com> <52656095.3070406@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC90392@LTCFISWMSGMB21.FNFIS.com> <526561E1.3000903@allanjude.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 21, 2013, at 10:18 AM, Allan Jude wrote: > On 2013-10-21 13:14, Teske, Devin wrote: >> On Oct 21, 2013, at 10:12 AM, Allan Jude wrote: >>=20 >>> On 2013-10-21 12:19, Teske, Devin wrote: >>>> On Oct 21, 2013, at 9:06 AM, Allan Jude wrote: >>>>=20 >>>>> On 2013-10-21 12:04, Teske, Devin wrote: >>>>>> On Oct 21, 2013, at 8:50 AM, Allan Jude wrote: >>>>>>=20 >>>>>>> On 2013-10-21 11:45, Johan Broman wrote: >>>>>>>> Hi! >>>>>>>>=20 >>>>>>>> Sorry for the delayed answer. I've patched zfsboot and rebuilt the >>>>>>>> release. I now get an error message that ada2 can't be used, which= is >>>>>>>> correct. Good stuff! :) >>>>>>>>=20 >>>>>>>> ( I've recreated the test environment using a KVM guest with four = SATA >>>>>>>> drives instead of the server I was using. I makes it easier to test >>>>>>>> stuff. ) >>>>>>>>=20 >>>>>>>> Here's the screenshot: >>>>>>>>=20 >>>>>>>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://212.181.212.14= 6/bsdinstall/Screenshot_2013-10-21.png&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D= %0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DB6jLX5vSxIfvyks3HH55lYWtfhR= BpGZ3nVA65M%2FgmXM%3D%0A&s=3Df6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dc= f6c66ad91564a8ce99 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Maybe one should be unable to select drives that are part of a gra= id >>>>>>>> in the first place? Or is that out-of-scope for bsdinstall at this >>>>>>>> point? (As I guess that requires too many changes/new lines) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Cheers >>>>>>>> Johan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 19/10/13 22:20, Teske, Devin wrote: >>>>>>>>> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: >>>>>>>>>=20 >>>>>>>>>> I recreated the graid mirror on ada2 and ada3 and reran the >>>>>>>>>> installation. I'm unable to scroll the msgbox using PgDn or arrow >>>>>>>>>> keys. There is no indication that the action failed and I'm retu= rned >>>>>>>>>> to the ZFS setup screen if I hit OK. >>>>>>>>>>=20 >>>>>>>>>> I have screen shots (taken with my phone) of the msgbox and "ps >>>>>>>>>> auxwww" output. Let me know what kind of debug info you would li= ke. >>>>>>>>>> I've put the screen shots here: >>>>>>>>>>=20 >>>>>>>>>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://212.181.212.= 146/bsdinstall&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrjs6vR4%2Faj2Ns= 9%2FssHJjg%3D%3D%0A&m=3DB6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A= &s=3D6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1 >>>>>>>>> I've added a patch to fix debugging in the zfsboot script... >>>>>>>>>=20 >>>>>>>>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://druidbsd.cvs.= sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D= %0A&r=3DMrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DB6jLX5vSxIfvyks3HH55lYWtfhR= BpGZ3nVA65M%2FgmXM%3D%0A&s=3D1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aa= be170bb80e31bca6d9 >>>>>>>>>=20 >>>>>>>>> Feedback welcome. >>>>>>>>>=20 >>>>>>>>> Johan,... >>>>>>>>>=20 >>>>>>>>> Can you see if the patch sheds some better light as to what's fai= ling? >>>>>>>>>=20 >>>>>>>>> The patch won't fix the problem, but it should give us an accurat= e error >>>>>>>>> message so that we can learn what precisely is returning an error >>>>>>>>> status. >>>>>>>>>=20 >>>>>>>>> Thanks in advance. >>>>>>>>>=20 >>>>>>> I do notice that Devin's manually prefixing the error message with = the >>>>>>> tool name, is partially redundancy when the tool does it it self, b= ut we >>>>>>> can't always be sure it will do that. >>>>>>>=20 >>>>>> The next patchset will fix that. >>>>>>=20 >>>>>> I'm dropping the tool name from the msgbox contents and putting it in >>>>>> the title (e.g., '"Error: gpart") that way... even if the tool spits= out its own >>>>>> name (or not), we'll know what exactly what was going on by looking >>>>>> at the title. >>>>>>=20 >>>>>>=20 >>>>>>> the graid thing is rather hard to detect, especially when it is a >>>>>>> faulted array that doesn't even appear in graid status etc. >>>>>>>=20 >>>>>> I believe the idea behind the script is that whatever you tell it to= use will >>>>>> be destroyed. >>>>>>=20 >>>>>> Allan, maybe perhaps we could add some code that attempts to dis- >>>>>> assemble a graid to make the disk usable? >>>>>>=20 >>>>>> Johan, what would you be more apt to expect? That it killed your gra= id >>>>>> or that it gave an error? (/me thinks what the recourse to the error= might >>>>>> entail -- going to partedit?) >>>>> Your recourse would be switching to the shell (control+alt+f4) and >>>>> destroying the graid. >>>>>=20 >>>>> I am a little hesitant to go destroying graids unprompted. If we had = the >>>>> geom.confxml parsing, we might be able to detect it and ask the user >>>>> what to do >>>>>=20 >>>> Well, my concern with going and asking about each/every configuration >>>> before we clear it... >>>>=20 >>>> Hasn't the user already answered a "Last Chance!" dialog giving the go- >>>> ahead to nuke any/all data *and* configurations on a drive? >>> I guess that makes sense, We offer the dialog to allow the user to >>> investigate their disk in detail so they can be sure they picked the >>> correct ones. >>>=20 >>> the graid thing is the biggest gotcha because it picks up metadata >>> written by the motherboard raid system, so you can have a graid >>> configuration even if you have never booted freebsd before. >>>=20 >> Hmmm... so what does one do in *that* situation? >>=20 >> Go into the motherboard BIOS and disable on-board RAID features for >> the controller providing the disks-in-question? > You can destroy the metadata with the graid delete command. I've only > encountered once instance where 'graid status' didn't show any devices, > but graid was blocking zfs from using the device until the graid was > destroyed (the graid part was only discovered after generating an image > out of the geom.confdot sysctl) >=20 Would you know where precisely to add the "graid delete" command if, say, we wanted to see if we could address Johan's issue? --=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?13CA24D6AB415D428143D44749F57D720FC903FC>