Installer login broken (ncurse?)

[Bill Hacker]

ader.dragonflybsd.org> <abc5f50ffd30cbc6567899ca23f25882 at xxxxxxxxx> <423f2b87$0$718$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4b6e963267b965600d8081f12b08a030 at xxxxxxxxx> <423f46bc$0$719$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <cdaafa0765c9da334dd73de434a78ceb at xxxxxxxxx>
In-Reply-To: <cdaafa0765c9da334dd73de434a78ceb at xxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 104
Message-ID: <423fa083$0$717$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 218.253.82.16
X-Trace: 1111466115 crater_reader.dragonflybsd.org 717 218.253.82.16
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:3934

Jasse Jansson wrote:

> 
> On Mar 21, 2005, at 11:11 PM, Bill Hacker wrote:
> 
>> Jasse Jansson wrote:

>> I ain't gonna touch that!
> 
> Does a mirror setup really cover anything else that if a drive
> suddenly dies?

Believe me - covering an unexpected HDD failure with
a near-as-dammit 100% near-real-time mirror that can
be immediately in-service, or never even out of service,
is no small thing...

> Slow corruption gets propagated to the mirror disk, doesn't it?
> 

'Slow corruption', other than WINCrobe-generated, is unusual
with decent hardware.  A good reason for trashing CMD-640 IDE
controllers, or having to hand-select SCSI controllers to live
with a 386 DX-16 overclocked to 40 MHz (though keeping
the isopranol coolant from catching fire was a bigger worry.. ;-)

Not generally a problem in *BSD-land.

>>
>> But it will reach out and touch you someday. ;-)
> 
> There's nothing the system can do to me that I haven't done
> much more efficiently already ;-)
> 

We all have *that* tee-shirt.. the one with bullet-holes,
powder-burns, and matching undershorts with the seat
chewed out by management or customers... ;-0

But the sophisticated controller is the biggest chunk of the
cost of RAID, so why not?

>> Balanced channels usually give the best speed though,
> 
> I leave the U160 disks on one channel.
> My future u320 disks will occupy the other one.

You should see very good performance from one
of each LVD 160, LVD 320 on each channel.

If you want max performance, throw in a commodity
LVD 160 controller when you get the 'faster' drives,
and use the better controller ONLY for the fast devices.

Independent controllers and PCI slots will help more
than the alleged speedup by itself.

>>>> > but DFly attaches them to mpt1, not mpt0.
>>>
>>> That was because I had connected them to channel B.
>>> Dunno why.

>> You have changed that since?
> 
> Moved the cable to channel A, where it should been in the
> first place. Shouldn't matter if I boot ftom mpt0 ot mpt1.
>

'Shouldn't matter' is notoriously mendacious.
'bout as bad as 'they say...'

> Changed a setting in the controller BIOS to disable RAID.
>
Was enabled, did not work.  Disabled did work.

> Have changed that back and reinstalling DFly.
> 
Re-enabled, still works.

So it is now RAID, or ?

> Just rebooted, works fine.
> 
>> Good news!  ... but had you *also* re-arranged the
>> drives and/or altered BIOS settings?
> 
> And changed them back. It still works.

. .Either way, then?

> Want me to test some more settings (as long as it's not any RAID stuff) ?
> 
> 
> J^2
> 
Sounds like you have covered it, whether MDs patch or the move to
Channel A (0), or both in combination.

Either way, if it ain't broke (any longer....), be happy.

Bill

NNNN