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: >> >>> On 2013-10-21 12:19, Teske, Devin wrote: >>>> On Oct 21, 2013, at 9:06 AM, Allan Jude wrote: >>>> >>>>> On 2013-10-21 12:04, Teske, Devin wrote: >>>>>> On Oct 21, 2013, at 8:50 AM, Allan Jude wrote: >>>>>> >>>>>>> On 2013-10-21 11:45, Johan Broman wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> 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! :) >>>>>>>> >>>>>>>> ( 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. ) >>>>>>>> >>>>>>>> Here's the screenshot: >>>>>>>> >>>>>>>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99 >>>>>>>> >>>>>>>> >>>>>>>> Maybe one should be unable to select drives that are part of a graid >>>>>>>> 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) >>>>>>>> >>>>>>>> >>>>>>>> Cheers >>>>>>>> Johan >>>>>>>> >>>>>>>> >>>>>>>> On 19/10/13 22:20, Teske, Devin wrote: >>>>>>>>> On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: >>>>>>>>> >>>>>>>>>> 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 returned >>>>>>>>>> to the ZFS setup screen if I hit OK. >>>>>>>>>> >>>>>>>>>> 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 like. >>>>>>>>>> I've put the screen shots here: >>>>>>>>>> >>>>>>>>>> https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1 >>>>>>>>> I've added a patch to fix debugging in the zfsboot script... >>>>>>>>> >>>>>>>>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0A&s=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9 >>>>>>>>> >>>>>>>>> Feedback welcome. >>>>>>>>> >>>>>>>>> Johan,... >>>>>>>>> >>>>>>>>> Can you see if the patch sheds some better light as to what's failing? >>>>>>>>> >>>>>>>>> The patch won't fix the problem, but it should give us an accurate error >>>>>>>>> message so that we can learn what precisely is returning an error >>>>>>>>> status. >>>>>>>>> >>>>>>>>> Thanks in advance. >>>>>>>>> >>>>>>> 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, but we >>>>>>> can't always be sure it will do that. >>>>>>> >>>>>> The next patchset will fix that. >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>>> the graid thing is rather hard to detect, especially when it is a >>>>>>> faulted array that doesn't even appear in graid status etc. >>>>>>> >>>>>> I believe the idea behind the script is that whatever you tell it to use will >>>>>> be destroyed. >>>>>> >>>>>> Allan, maybe perhaps we could add some code that attempts to dis- >>>>>> assemble a graid to make the disk usable? >>>>>> >>>>>> Johan, what would you be more apt to expect? That it killed your graid >>>>>> 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. >>>>> >>>>> 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 >>>>> >>>> Well, my concern with going and asking about each/every configuration >>>> before we clear it... >>>> >>>> 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. >>> >>> 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. >>> >> Hmmm... so what does one do in *that* situation? >> >> 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) > Allan, Do we want to add a "graid delete" command to the same place as the pedantic "gpart destroy" commands? -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:43 UTC
