Re: NetBSD on a wireless router?

[Jason Thorpe]

> On Aug 15, 2019, at 8:15 PM, John Franklin  wrote:
> 
> because I usually use the Ubiquiti APs for WiFi.  For WiFi performance and 
> management on a budget, they’re hard to beat.

+1. I use Ubiquiti to cover the 3 levels of my house + back yard, and it works 
flawlessly (total of 4 APs to do the job).

-- thorpej

Re: NetBSD on a wireless router?

[John Franklin]

On Aug 15, 2019, at 14:57, r...@reedmedia.net wrote:
> 
> On Wed, 14 Aug 2019, John Franklin wrote:
> 
>> Are you absolutely committed to NetBSD? pfSense is an excellent 
>> router/firewall distribution built on top of FreeBSD, with support for 
>> whatever WiFi and hardware FreeBSD supports. I love NetBSD, but when I 
>> need to set up a router, I just grab pfSense.
> 
> :)
> 
> https://duckduckgo.com/?q=pfsense+essentials+book+jeremy+c.+reed
> 
> From its preface:
> [snip]

Oh, so you’ve heard of it!  :)

> I have probably used around eight different wireless cards on a few 
> different hardwares running a few different versions of pfSense. While 
> it works for me, I haven't had great reliability or performance with the 
> wireless devices I've used there.

None of my pfSense routers have WiFi built-in, even though it’s an option.  The 
WiFi module my preferred hardware vendor offers is only b/g/n — no 802.11ac at 
all.  I don’t know if I would bother even if they did support AC, because I 
usually use the Ubiquiti APs for WiFi.  For WiFi performance and management on 
a budget, they’re hard to beat.  On occasion, I’ll use an old home router set 
to AP mode, until I get around to upgrading.

jf
-- 
John Franklin
frank...@elfie.org

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/bin/pax/Makefile
cvs update: `src/distrib/notes/common/list-portmasters.pl' is no longer in the 
repository
P src/distrib/sets/lists/comp/mi
P src/doc/CHANGES
P src/doc/CHANGES.prev
P src/external/bsd/compiler_rt/lib/clang/include/sanitizer/Makefile
P src/external/gpl3/gcc/usr.bin/include/sanitizer/Makefile
P src/sbin/fsck_ext2fs/main.c
P src/sbin/fsck_ffs/main.c
P src/sbin/fsck_lfs/main.c
P src/share/man/man9/kmem.9
P src/share/man/man9/usbnet.9
P src/share/mk/bsd.prog.mk
P src/sys/arch/aarch64/aarch64/pmap.c
P src/sys/arch/aarch64/include/pte.h
P src/sys/arch/macppc/dev/ki2c.c
P src/sys/arch/mips/mips/pmap_machdep.c
P src/sys/dev/ata/satafis_subr.c
P src/sys/dev/usb/files.usb
P src/sys/dev/usb/if_axe.c
P src/sys/dev/usb/if_axen.c
P src/sys/dev/usb/if_cdce.c
P src/sys/dev/usb/if_cue.c
P src/sys/dev/usb/if_cuereg.h
P src/sys/dev/usb/if_mue.c
P src/sys/dev/usb/if_muereg.h
P src/sys/dev/usb/if_muevar.h
P src/sys/dev/usb/if_smsc.c
P src/sys/dev/usb/if_udav.c
P src/sys/dev/usb/if_ure.c
P src/sys/dev/usb/if_url.c
P src/sys/dev/usb/if_urlreg.h
P src/sys/dev/usb/if_urndis.c
P src/sys/dev/usb/usbnet.c
P src/sys/dev/usb/usbnet.h
P src/sys/kern/files.kern
P src/sys/kern/subr_extent.c
P src/sys/kern/subr_kmem.c
P src/sys/net/if.c
P src/sys/sys/param.h
P src/tests/bin/df/Makefile
P src/tests/fs/nfs/nfsservice/Makefile
P src/tests/kernel/Makefile
P src/tests/lib/libc/misc/Makefile
P src/tests/net/if/t_ifconfig.sh
P src/tests/usr.bin/id/Makefile
P src/usr.sbin/installboot/Makefile
P src/usr.sbin/installboot/installboot.h
P src/usr.sbin/installboot/machines.c
P src/usr.sbin/makemandb/apropos-utils.c
P src/usr.sbin/rpc.bootparamd/bootparamd.c
P src/usr.sbin/rpc.lockd/lockd.c
P src/usr.sbin/rpc.statd/statd.c
P src/usr.sbin/ypserv/ypserv/Makefile

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  43065165 Aug 16 03:04 ls-lRA.gz

Re: building and testing 9.99

[Riccardo Mottola]

Hi all!

On 8/7/19 7:18 AM, m...@netbsd.org wrote:

On Wed, Aug 07, 2019 at 12:40:08AM +0200, Riccardo Mottola wrote:

Hi All,

I want to rebuild all userland.
Is there now a recommended way to skip all the llvm stuff which is extremely
big.. and as far as I know, not needed for my Intel graphic card?

Riccardo

-V MKLLVMRT=no (or in mk.conf)



thanks. This  worked fine! kernel, modules and userland built. I 
installed it and X11 works, wireless works, at a first glance, nothing 
"worse" than 8.99 (which I build with llvm and took a week)


I did not remove, though, I don't know if install "cleans" the old llvm 
and X stuff built with it... I wonder thus if something is missing.


Still, good news. Further tests and upgrades of pkgsrc in a fortnight, 
after some holidays!



Riccardo

Re: NetBSD on a wireless router?

[John Franklin]

On Wed, Aug 14, 2019 at 10:51 AM, r...@reedmedia.net wrote:

I want to replace a wifi router with a NetBSD solution.

The posting at

links to a spreadsheet of hardward, but I don't know from that yet 
what

has wireless and how well supported.

Ideas include Microtik Routerboard, OpenBlocks,  LinkIt Smart 7688,
Orange Pi.

Is anyone using NetBSD for wireless routers?

Jeremy C. Reed


Are you absolutely committed to /Net/BSD?  pfSense is an excellent 
router/firewall distribution built on top of FreeBSD, with support for 
whatever WiFi and hardware FreeBSD supports.  I love NetBSD, but when I 
need to set up a router, I just grab pfSense.


jf
--
John Franklin
frank...@elfie.org

Automated report: NetBSD-current/i386 build success

[NetBSD Test Fixture]

The NetBSD-current/i386 build is working again.

The following commits were made between the last failed build and the
successful build:

2019.08.15.19.53.01 martin src/usr.sbin/installboot/Makefile,v 1.54
2019.08.15.19.53.01 martin src/usr.sbin/installboot/machines.c,v 1.42

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2019.08.html#2019.08.15.19.53.01

Re: NetBSD on a wireless router?

[Brian Buhrow]

hello.  My Dell Latitude 400 has an Atheros mini-pci wifi card in it
that runs great with NetBSD-5.2 in hostap mode, serving 802.11BG clients.  I
believe it's using the open source HAL code.  While this isn't 802.11N or
802.11AC, I use it regularly in this mode to "tether" devices wishing to
use my USB Verizon Internet modem.
So, if you can find a piece of equipment with a mini-pci slot in it and an
antenna, I believe you can get these cards very cheap.  I bought mine on
Ebay some 11 or 12 years ago.
-thanks
-Brian

Re: NetBSD on a wireless router?

[reed]

On Wed, 14 Aug 2019, John Franklin wrote:

> Are you absolutely committed to NetBSD? pfSense is an excellent 
> router/firewall distribution built on top of FreeBSD, with support for 
> whatever WiFi and hardware FreeBSD supports. I love NetBSD, but when I 
> need to set up a router, I just grab pfSense.

:)

https://duckduckgo.com/?q=pfsense+essentials+book+jeremy+c.+reed

>From its preface:


This book was written using Docbook using NetBSD and vi.
The print-ready book was generated with
Dblatex version 0.3.10 with a custom stylesheet,
pdfTeX 3.14159265-2.6-1.40.19 (Web2C 2018),
and the TeX document production system installed via
Tex Live and Pkgsrc.
...

I have probably used around eight different wireless cards on a few 
different hardwares running a few different versions of pfSense. While 
it works for me, I haven't had great reliability or performance with the 
wireless devices I've used there.

I'd like to use NetBSD. But I have received some great feedback and 
shared experiences about using a non-NetBSD wireless gear. I will 
probably use NetBSD as my gateway/firewall and bridge to a dedicated 
wifi device. Unless I can find a "a suitable wireless card that performs 
well in hostap mode on NetBSD" (quoting from someone else in this 
thread).

Automated report: NetBSD-current/i386 build failure

[NetBSD Test Fixture]

This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2019.08.15.16.01.27.

An extract from the build.sh output follows:

--- gpt_make ---
--- create.d ---
#create  gpt/create.d

CC=/tmp/bracket/build/2019.08.15.16.01.27-i386/tools/bin/i486--netbsdelf-gcc 
/tmp/bracket/build/2019.08.15.16.01.27-i386/tools/bin/nbmkdep -f create.d.tmp  
--   -std=gnu99   --sysroot=/tmp/bracket/build/2019.08.15.16.01.27-i386/destdir 
/tmp/bracket/build/2019.08.15.16.01.27-i386/src/sbin/gpt/create.c &&  mv -f 
create.d.tmp create.d
--- installboot_make ---

/tmp/bracket/build/2019.08.15.16.01.27-i386/src/usr.sbin/installboot/machines.c:46:22:
 error: 'ib_mach_1' undeclared here (not in a function); did you mean 'ib_mach'?
 #define IB_PREFIX(X) ib_mach_##X
  ^

/tmp/bracket/build/2019.08.15.16.01.27-i386/src/usr.sbin/installboot/machines.c:47:20:
 note: in expansion of macro 'IB_PREFIX'
 #define MY_ARCH(X) IB_PREFIX(X)
^

/tmp/bracket/build/2019.08.15.16.01.27-i386/src/usr.sbin/installboot/machines.c:48:6:
 note: in expansion of macro 'MY_ARCH'
 _ARCH(SINGLE_ARCH),
  ^~~
--- lfs_cleanerd_make ---
A failure has been detected in another branch of the parallel make
nbmake[7]: stopped in 
/tmp/bracket/build/2019.08.15.16.01.27-i386/obj/distrib/i386/ramdisks/ramdisk-big/lfs_cleanerd
*** [lfs_cleanerd_make] Error code 2
nbmake[6]: stopped in 
/tmp/bracket/build/2019.08.15.16.01.27-i386/obj/distrib/i386/ramdisks/ramdisk-big
--- fsck_ffs_make ---

The following commits were made between the last successful build and
the failed build:

2019.08.15.14.06.40 martin src/usr.sbin/installboot/Makefile,v 1.53
2019.08.15.14.06.40 martin src/usr.sbin/installboot/machines.c,v 1.41
2019.08.15.16.01.27 kamil src/distrib/sets/lists/comp/mi,v 1.2281
2019.08.15.16.01.27 kamil 
src/external/gpl3/gcc/usr.bin/include/sanitizer/Makefile,v 1.4

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2019.08.html#2019.08.15.16.01.27

Re: kern/54289 hosed my RAID. Recovery possible?

[John D. Baker]

For the gorey details, see the latest addenda to PR kern/54289.  At
least in my case, this PR bit me on this host adapter, but for some it
works fine with the same host adapter.

Thanks Brian and Greg for the confirmation of my supposition.  The case
was that the components were "sort-of" there, but not accessible at RAID
configuration time (under netbsd-9), so the raid didn't configure and
the devices (raid0, dk0) it represented likewise were not available.
Back under netbsd-8, using the original config file with 'raidctl -C'
got it sorted out.

Thanks again.

-- 
|/"\ John D. Baker, KN5UKS   NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSDFreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Re: kern/54289 hosed my RAID. Recovery possible?

[John D. Baker]

On Thu, 15 Aug 2019, jdba...@consolidated.net wrote:

> An 'fsck -f' run is in progress.

This showed no errors.  The RAID is back in service.  Whew!

-- 
|/"\ John D. Baker, KN5UKS   NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSDFreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Re: build.sh flag "-u"

[Martin Husemann]

On Thu, Aug 15, 2019 at 04:52:09PM +0100, Arthur Barlow wrote:
> I have some uncertainty about the application of the "-u" flag in
> build.sh.  The docs say it prevents "make clean."  But without it will
> rebuild everything, including tools.  I've used the flag before
> without problems, but recently I've had the build break on a couple of
> occasions.  I'm not doing any cross compile and I'm building amd64.

It "usually just works". There are sometimes hickups when things get moved
around big time and old *.d files in the object directory confuse make.

I mostly use -u untill it fails, and when it fails I check src/UPDATING
for recent hints.

Martin

build.sh flag "-u"

[Arthur Barlow]

I have some uncertainty about the application of the "-u" flag in
build.sh.  The docs say it prevents "make clean."  But without it will
rebuild everything, including tools.  I've used the flag before
without problems, but recently I've had the build break on a couple of
occasions.  I'm not doing any cross compile and I'm building amd64.

When I delete all the files in /usr/obj, (my obj directory), and don't
use the "-u" flag, everything seems to build fine.  Can anyone provide
any wisdom on whether to use or not use this flag?

Re: kern/54289 hosed my RAID. Recovery possible?

[Greg Oster]

On Thu, 15 Aug 2019 09:07:46 -0500
jdba...@consolidated.net wrote:

> On 2019-08-15 00:03, jdba...@consolidated.net wrote:
> > The SiI3214 SATALink card suffers from the identify problem in
> > netbsd-9 and -current (PR kern/54289).
> > 
> > Booting a netbsd-9 kernel, the drives failed to identify which
> > caused RAIDframe to mark the 4 drives on that card (of 8) in my
> > RAID as FAILED.
> > Rebooting netbsd-8, the drives identify properly, but are still
> > marked as
> > FAILED.
> > 
> > Is there any way to unmark them so the raid will configure and
> > recover? Normally 'raidctl -C' is used during first time
> > configuration. Could it be used to force configuration, ignoring
> > the FAILED status?  Would the RAID
> > be recoverable with parity rebuild afterwards?  
> 
> This seems to have worked.  The disks not being correctly 
> identified/attached
> under netbsd-9 apparently had them recorded as failed on the
> components that
> did attach (on the machine's on-board intel ahcisata ports).
> Rebooting netbsd-8, although the drives identified and attached
> properly, they were
> still considered failed components.
> 
> Being a multiple-disk failure is usually fatal to a RAID, but the 
> components
> weren't actually failed.  Un-configuring with 'raidctl -u' then
> forcing a
> config with 'raidctl -C /path/to/config' did not show any fatal
> errors and
> subsequent 'raidctl -s' showed all component labels (w/serial number) 
> intact.
> Parity rewrite took a long time.
> 
> Afterwards, 'gpt show raid0d' and 'dkctl raid0d listwedges' showed 
> things to
> be intact that far.  Rebooting the machine, the RAID properly 
> autoconfigured.
> 'fsck' reported the filesystem as clean (since it never got mounted 
> after the
> failed reboot into netbsd-9).  An 'fsck -f' run is in progress.

In general, with this sort of 'larger' set of failed components, you
should be OK.  There are a couple of scenarios for the different RAID
sets you might have configured:
 1) The components that 'failed' were not sufficient to fail the RAID
 set (i.e. it was just 'degraded').  In this case, the surviving
 components still have your data, but in degraded mode.  Rebuild the
 'failed' component, and you're good-to-go.

 2) The components that 'failed' were enough to completely fail the RAID
 set upon configuration.  In this case, the RAID set would not
 configure, and no data would be written to any of the components (save
 for the updating of the component labels).  In this case you can use
 'raidctl -C' to reconstruct the RAID set and be comfortable that your
 data is still intact (given that there wasn't actually a real failure,
 and no data was written to the RAID set).  Yes, a parity rebuild will
 be needed, and it will be a NOP (but it doesn't know that :) ).

The only place this gets tricky is if the RAID set does get configured
and mounted -- in that case you don't want to use 'raidctl -C', as data
on the surviving components will be out-of-sync with the failed
components.  In this case you're better off rebuilding in-place.

Later...

Greg Oster

Re: kern/54289 hosed my RAID. Recovery possible?

[Brian Buhrow]

hello.  Yes, raidctl -C with the original config file that created the
raid, or one you faked up for the occasion, should get you going again.
Once you  configure the raid with raidctl -C, you can then run parity
checks and filesystem checks without a problem.  I've done this sort of
thing many times over the years.
-Brian

On Aug 15, 12:03am, jdba...@consolidated.net wrote:
} Subject: kern/54289 hosed my RAID.  Recovery =?UTF-8?Q?possible=3F?=
} The SiI3214 SATALink card suffers from the identify problem in netbsd-9
} and -current (PR kern/54289).
} 
} Booting a netbsd-9 kernel, the drives failed to identify which caused
} RAIDframe to mark the 4 drives on that card (of 8) in my RAID as FAILED.
} Rebooting netbsd-8, the drives identify properly, but are still marked 
} as
} FAILED.
} 
} Is there any way to unmark them so the raid will configure and recover?
} Normally 'raidctl -C' is used during first time configuration. Could it
} be used to force configuration, ignoring the FAILED status?  Would the 
} RAID
} be recoverable with parity rebuild afterwards?
} 
} Thanks.
} 
} John D. Baker
} 
} Sorry for the poor (or lack of) formatting.  I've had to evacuate to my
} ISP's web mail until this is sorted out (or I get my "oil lamps" in 
} place).
>-- End of excerpt from jdba...@consolidated.net

Re: Another exciting error building lang/mono...

[Chavdar Ivanov]

On Thu, 15 Aug 2019 at 15:12,  wrote:
>
> On Thu, Aug 15, 2019 at 02:50:52PM +0100, Chavdar Ivanov wrote:
> > BTW I just noticed there are no gnome packages in
> > /usr/pkgsrc/meta-packages any more, while there are still some in x11
> > directory - was there any announce that it has been phased out?
>
> It was GNOME2, I am under the impression GNOME2 doesn't build with
> updated libraries, and someone had considered removing it.
>
> An alternative is "MATE" which tries to continue the GNOME 2 spirit.

Yes, I am aware, I already have mate running on a few machines. At
some stage I had problems with it with respect to using different
keyboard layouts, so I reverted to gnome2 for a while; later I found
the problem.

I guess we have enough desktop environments even without gnome,
although it would be nice if cinnamon gets into pkgsrc proper; as I
mentioned above, it builds for me, but doesn't run very well - or at
all in a virtual machine.




-- 

Re: Another exciting error building lang/mono...

[maya]

On Thu, Aug 15, 2019 at 02:50:52PM +0100, Chavdar Ivanov wrote:
> BTW I just noticed there are no gnome packages in
> /usr/pkgsrc/meta-packages any more, while there are still some in x11
> directory - was there any announce that it has been phased out?

It was GNOME2, I am under the impression GNOME2 doesn't build with
updated libraries, and someone had considered removing it.

An alternative is "MATE" which tries to continue the GNOME 2 spirit.

Re: kern/54289 hosed my RAID. Recovery possible?

[jdbaker]

On 2019-08-15 00:03, jdba...@consolidated.net wrote:

The SiI3214 SATALink card suffers from the identify problem in netbsd-9
and -current (PR kern/54289).

Booting a netbsd-9 kernel, the drives failed to identify which caused
RAIDframe to mark the 4 drives on that card (of 8) in my RAID as 
FAILED.
Rebooting netbsd-8, the drives identify properly, but are still marked 
as

FAILED.

Is there any way to unmark them so the raid will configure and recover?
Normally 'raidctl -C' is used during first time configuration. Could it
be used to force configuration, ignoring the FAILED status?  Would the 
RAID

be recoverable with parity rebuild afterwards?


This seems to have worked.  The disks not being correctly 
identified/attached
under netbsd-9 apparently had them recorded as failed on the components 
that

did attach (on the machine's on-board intel ahcisata ports).  Rebooting
netbsd-8, although the drives identified and attached properly, they 
were

still considered failed components.

Being a multiple-disk failure is usually fatal to a RAID, but the 
components
weren't actually failed.  Un-configuring with 'raidctl -u' then forcing 
a
config with 'raidctl -C /path/to/config' did not show any fatal errors 
and
subsequent 'raidctl -s' showed all component labels (w/serial number) 
intact.

Parity rewrite took a long time.

Afterwards, 'gpt show raid0d' and 'dkctl raid0d listwedges' showed 
things to
be intact that far.  Rebooting the machine, the RAID properly 
autoconfigured.
'fsck' reported the filesystem as clean (since it never got mounted 
after the

failed reboot into netbsd-9).  An 'fsck -f' run is in progress.


John D. Baker

Re: Another exciting error building lang/mono...

[Chavdar Ivanov]

BTW I just noticed there are no gnome packages in
/usr/pkgsrc/meta-packages any more, while there are still some in x11
directory - was there any announce that it has been phased out?

On Thu, 15 Aug 2019 at 13:09, Chavdar Ivanov  wrote:
>
> It actually is a part of the package:
> $ export MONO_CONFIG=/usr/pkg/share/examples/mono/config
>  $ csharp
> Mono C# Shell, type "help;" for help
>
> Enter statements below.
> csharp>
>
> The bug is actually elsewhere - ktrace shows:
> 22455  1 mono-sgen open("/usr/pkg/etc/mono/mono/config", 0,
> 0xff8295b8) Err#2 ENOENT
>
> so there is the directory name twice, in reality the installation
> places the file in /usr/pkg/etc/mono/config.
>
> # cd /usr/pkg/etc/mono ; ln -s . mono
>
> sorts it.
>
>
>
>
> On Wed, 14 Aug 2019 at 20:14,  wrote:
> >
> > On Tue, Aug 13, 2019 at 12:00:31PM +0100, Chavdar Ivanov wrote:
> > > wip/mono6 built OK, but I get:
> > > 
> > > ~ csharp
> > >
> > > Unhandled Exception:
> > > System.TypeInitializationException: The type initializer for
> > > 'System.Console' threw an exception. --->
> > > System.TypeInitializationException: The type initializer for
> > > 'System.ConsoleDriver' threw an exception. --->
> > > System.DllNotFoundException: System.Native
> >
> > I kept seeing this. I finally have the answer.
> >
> > There's a file in the Mono build directory, data/config.
> > This maps the upstream (Microsoft) DLL names to the ones used by Mono.
> >
> > Run it as:
> >
> > env MONO_CONFIG=./data/config csharp
>
>
>
> --
> 



-- 

Re: Another exciting error building lang/mono...

[Chavdar Ivanov]

It actually is a part of the package:
$ export MONO_CONFIG=/usr/pkg/share/examples/mono/config
 $ csharp
Mono C# Shell, type "help;" for help

Enter statements below.
csharp>

The bug is actually elsewhere - ktrace shows:
22455  1 mono-sgen open("/usr/pkg/etc/mono/mono/config", 0,
0xff8295b8) Err#2 ENOENT

so there is the directory name twice, in reality the installation
places the file in /usr/pkg/etc/mono/config.

# cd /usr/pkg/etc/mono ; ln -s . mono

sorts it.




On Wed, 14 Aug 2019 at 20:14,  wrote:
>
> On Tue, Aug 13, 2019 at 12:00:31PM +0100, Chavdar Ivanov wrote:
> > wip/mono6 built OK, but I get:
> > 
> > ~ csharp
> >
> > Unhandled Exception:
> > System.TypeInitializationException: The type initializer for
> > 'System.Console' threw an exception. --->
> > System.TypeInitializationException: The type initializer for
> > 'System.ConsoleDriver' threw an exception. --->
> > System.DllNotFoundException: System.Native
>
> I kept seeing this. I finally have the answer.
>
> There's a file in the Mono build directory, data/config.
> This maps the upstream (Microsoft) DLL names to the ones used by Mono.
>
> Run it as:
>
> env MONO_CONFIG=./data/config csharp



-- 

Re: kern/54289 hosed my RAID. Recovery possible?

[Michael van Elst]

jdba...@consolidated.net writes:

>Is there any way to unmark them so the raid will configure and recover?
>Normally 'raidctl -C' is used during first time configuration. Could it
>be used to force configuration, ignoring the FAILED status?  Would the 
>RAID
>be recoverable with parity rebuild afterwards?


raidctl(8) documents that you need to use -C to manually configure the RAID
_without_ the component that failed first (named as "absent" in the config).
Then initialize the RAID set with -I to force consistent labels and finally
add the absent disk with -a and recover with -F.

Never tried this.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

kern/54289 hosed my RAID. Recovery possible?

[jdbaker]

The SiI3214 SATALink card suffers from the identify problem in netbsd-9
and -current (PR kern/54289).

Booting a netbsd-9 kernel, the drives failed to identify which caused
RAIDframe to mark the 4 drives on that card (of 8) in my RAID as FAILED.
Rebooting netbsd-8, the drives identify properly, but are still marked 
as

FAILED.

Is there any way to unmark them so the raid will configure and recover?
Normally 'raidctl -C' is used during first time configuration. Could it
be used to force configuration, ignoring the FAILED status?  Would the 
RAID

be recoverable with parity rebuild afterwards?

Thanks.

John D. Baker

Sorry for the poor (or lack of) formatting.  I've had to evacuate to my
ISP's web mail until this is sorted out (or I get my "oil lamps" in 
place).