Re: CARP misbehaving on RPi2+ / RPI3
Ah, okay -- that makes some sense. Glad to know it's not (just) me. :) Thank you! On Sun, Mar 26, 2023 at 3:56 AM Michael van Elst wrote: > > rela...@gmail.com (Greywolf) writes: > > >Greetings; I have a couple RPi that I will refer to here as 'thing1' > >and 'thing2'. Both are running evbarm-earmv7h, NetBSD 10-BETA. > > The carp driver sent advertising packets through the carp interface > which sets the source MAC address to the CARP virtual MAC address > (computed from the vhid value). > > A normal ethernet switch will then learn that this MAC address > exists on multiple ports and change its forwarding table all > the time, resulting in lots of packet drops. The CARP election > protocol then doesn't work. > > I have comitted a change to send advertisments through the backing > 'carpdev' interface instead. This uses its own distinct MAC > address, and the switch stays happy. > > With the consumer switches here, it still takes up to 20 seconds to notice > when CARP moves the virtual MAC address to the other machine. > -- --*greywolf;
CARP misbehaving on RPi2+ / RPI3
Greetings; I have a couple RPi that I will refer to here as 'thing1' and 'thing2'. Both are running evbarm-earmv7h, NetBSD 10-BETA. thing1: rpi2+ /etc/ifconfig.carp0: create vhid 1 advbase 21 advskew 2 carpdev usmsc0 pass aPassword 172.21.12.2/23 up thing2: rpi3 /etc/ifconfig.carp0: create vhid 1 carpdev usmsc0 pass aPassword 172.21.12.2/23 up thing1 comes up with CARP in BACKUP mode, as expected. thing2 comes up and enables CARP, and all is relatively well except that no other host on the network can ping the VIP. Is this a limitation of the RPi hardware, or am I doing something wrong? My intent was to use these two as a VIP'd nameserver. -- --*greywolf;
Re: tar: Pathname can't be converted from UTF-8 to current locale
make -e EXTRACT_CMD='gtar -zxf $${extract_file}' returned
'{extract_file}: No such file or directory'. Perhaps I needed to
double-quote that string.
EXTRACT_CMD='gtar -zxf $${extract_file}' export EXTRACT_CMD; #I'm old
school -- this is habit.
make -e extract
worked. Thank you.
On Fri, Feb 24, 2023 at 1:22 PM bch wrote:
>
>
>
> On Fri, Feb 24, 2023 at 12:46 Greywolf wrote:
>>
>> Hi there, having a problem more and more building from pkgsrc (see Subject):
>>
>> Output from "locale | awk '/CTYPE|LANG|ALL/' is as follows:
>>
>> LANG="en_US.UTF-8"
>> LC_CTYPE="en_US.UTF-8"
>> LC_ALL="en_US.UTF-8"
>>
>> I cannot seem to force TAR to be /usr/local/bin/gtar when extracting,
>> no matter what I try within my scope of knowledge. I've attempted the
>> full-on brute force method of:
>>
>> TAR=/usr/local/bin/gtar make -e TAR=/usr/local/bin/gtar extract
>>
>> and to no avail -- the value never makes it to the 'extract' script in
>> /usr/src/mk/extract/extract.
>>
>> I would be appreciative of any clues pointing toward a solution.
>
>
> I’ve seen the same (seems esp trigger-able by lang/go test cases, for example)
>
> I’ve pushed through w GNU tar before, but it’d certainly be nice to get
> libarchive (which I believe gets hung-up) working…
>
> You might get traction with:
> EXTRACT_CMD= gtar -xzf $${extract_file}
>
> Good luck,
>
> -bch
>
>>
>>
>> [Note: LANG=C is my usual preferred (interactive) localisation -- I'm
>> only setting it here so I can build a package.]
>> --
>> --*greywolf;
--
--*greywolf;
tar: Pathname can't be converted from UTF-8 to current locale
Hi there, having a problem more and more building from pkgsrc (see Subject): Output from "locale | awk '/CTYPE|LANG|ALL/' is as follows: LANG="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_ALL="en_US.UTF-8" I cannot seem to force TAR to be /usr/local/bin/gtar when extracting, no matter what I try within my scope of knowledge. I've attempted the full-on brute force method of: TAR=/usr/local/bin/gtar make -e TAR=/usr/local/bin/gtar extract and to no avail -- the value never makes it to the 'extract' script in /usr/src/mk/extract/extract. I would be appreciative of any clues pointing toward a solution. [Note: LANG=C is my usual preferred (interactive) localisation -- I'm only setting it here so I can build a package.] -- --*greywolf;
built and installed -current with clang, can't build in /usr/src
Greetings. Built and installed NetBSD-9.99.96 [clang/LLVM] on 16 May and it built everything including X11, which is great, except that I decided to completely blank out my extant system (fresh everything under /bin /sbin /usr/bin /usr/sbin /usr/lib* /lib* /stand; restored /etc). Now I cannot even kick off a build because even if I specify: ./build.sh -c clang tools it fails to build the tools because the build is still looking for gcc. Is clang/LLVM still considered "experimental"? Is this a known issue? Will John and Marsha make it out of the system before it crashes? "Inquiring idiots want to know." -- --*greywolf;
CVS broken/down/changed?
Hi, all! cvs up -AdP in my source tree yields the message cvs [update aborted]: permission denied for src What's up? -- --*greywolf;
Re: RAIDframe question
Thank you all for being so quick to come forth with answers on this! Still not sure why my first set went strange on me but this certainly explains why everything else which seems slightly amiss actually really isn't! The more you think you know... :) On Tue, Jun 16, 2020 at 1:19 PM Brian Buhrow wrote: > > hello. If you reboot again, the raid2 will probably look as you > expect. The general procedure for disk replacement is; > > 1. raidctl -a /dev/newdisk raidset > > 2. raidctl -F /dev/baddisk raidset (fails the bad disk, uses the spare and > reconstructs to it) > > 3. Raid is left with a used_spare, but all is wel. > > 4. Reboot. All components become optimal. > > It has long been my desire that once a spare is used, it get > automatically promoted to optimal without the interveening reboot. I > probably could have made this change with Greg's blessing, but I never did > the work. > > Hope that helps. > -Brian > > On Jun 16, 12:18am, Greywolf wrote: > } Subject: Re: RAIDframe question > } I don't know what I did to get that volume to recover but ripping > } it apart and placing the good component first on reconfiguration > } produced a good volume on a rebuild. As I recall it looked a lot like this: > } > } Components: > } component0: failed > } /dev/wd1c: optimal > } Spares: > } /dev/wd0c: spare > } component0 status is: failed. skipping label > } Component label for /dev/wd1c: > }Row: 0, Column: 1, Num Rows: 1, Num Columns: 2 > }Version: 2, Serial Number: 1984, Mod Counter: 7232 > }Clean: No, Status: 0 > }sectPerSU: 128, SUsPerPU: 4, SUsPerRU: 1 > }Queue size: 120, blocksize: 512, numBlocks: 976772992 > }RAID Level: 1 > }Autoconfig: Yes > }Root partition: No > }Last configured as: raid1 > } /dev/wd0c status is: spare. Skipping label. > } Reconstruction is 100% complete. > } Parity Re-write is 100% complete. > } Copyback is 100% complete. > } > } On the other hand, I have the following showing up after > } a rebuild (different volume, "raid2", mirrored 2TB disks): > } > } Components: > } /dev/dk0: optimal > } component1: spared > } Spares: > } /dev/dk1: used_spare > } Component label for /dev/dk0: > }Row: 0, Column: 0, Num Rows: 1, Num Columns: 2 > }Version: 2, Serial Number: 3337, Mod Counter: 468 > }Clean: No, Status: 0 > }sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1 > }Queue size: 100, blocksize: 512, numBlocks: 3907028992 > }RAID Level: 1 > }Autoconfig: Yes > }Root partition: No > }Last configured as: raid2 > } component1 status is: spared. Skipping label. > } Component label for /dev/dk1: > }Row: 0, Column: 1, Num Rows: 1, Num Columns: 2 > }Version: 2, Serial Number: 3337, Mod Counter: 468 > }Clean: No, Status: 0 > }sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1 > }Queue size: 100, blocksize: 512, numBlocks: 3907028992 > }RAID Level: 1 > }Autoconfig: Yes > }Root partition: No > }Last configured as: raid2 > } Parity status: clean > } Reconstruction is 100% complete. > } Parity Re-write is 100% complete. > } Copyback is 100% complete. > } > } I've been thru enough different results it's hard to tell whether that is > sane; > } I would have expected /dev/dk1 to have shifted up to 'optimal' and > component1 to > } have vanished. > } > } On Sat, Jun 13, 2020 at 11:48 PM Martin Husemann wrote: > } > > } > On Sat, Jun 13, 2020 at 09:44:35PM -0700, Greywolf wrote: > } > > raidctl -a /dev/wd0c raid1 > } > > > } > > raidctl -F component0 raid1 > } > > } > I would have expected that to work. What is the raidctl status output > } > after the -a ? > } > > } > Martin > } > } > } > } -- > } --*greywolf; > >-- End of excerpt from Greywolf > > -- --*greywolf;
Re: RAIDframe question
I don't know what I did to get that volume to recover but ripping it apart and placing the good component first on reconfiguration produced a good volume on a rebuild. As I recall it looked a lot like this: Components: component0: failed /dev/wd1c: optimal Spares: /dev/wd0c: spare component0 status is: failed. skipping label Component label for /dev/wd1c: Row: 0, Column: 1, Num Rows: 1, Num Columns: 2 Version: 2, Serial Number: 1984, Mod Counter: 7232 Clean: No, Status: 0 sectPerSU: 128, SUsPerPU: 4, SUsPerRU: 1 Queue size: 120, blocksize: 512, numBlocks: 976772992 RAID Level: 1 Autoconfig: Yes Root partition: No Last configured as: raid1 /dev/wd0c status is: spare. Skipping label. Reconstruction is 100% complete. Parity Re-write is 100% complete. Copyback is 100% complete. On the other hand, I have the following showing up after a rebuild (different volume, "raid2", mirrored 2TB disks): Components: /dev/dk0: optimal component1: spared Spares: /dev/dk1: used_spare Component label for /dev/dk0: Row: 0, Column: 0, Num Rows: 1, Num Columns: 2 Version: 2, Serial Number: 3337, Mod Counter: 468 Clean: No, Status: 0 sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1 Queue size: 100, blocksize: 512, numBlocks: 3907028992 RAID Level: 1 Autoconfig: Yes Root partition: No Last configured as: raid2 component1 status is: spared. Skipping label. Component label for /dev/dk1: Row: 0, Column: 1, Num Rows: 1, Num Columns: 2 Version: 2, Serial Number: 3337, Mod Counter: 468 Clean: No, Status: 0 sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1 Queue size: 100, blocksize: 512, numBlocks: 3907028992 RAID Level: 1 Autoconfig: Yes Root partition: No Last configured as: raid2 Parity status: clean Reconstruction is 100% complete. Parity Re-write is 100% complete. Copyback is 100% complete. I've been thru enough different results it's hard to tell whether that is sane; I would have expected /dev/dk1 to have shifted up to 'optimal' and component1 to have vanished. On Sat, Jun 13, 2020 at 11:48 PM Martin Husemann wrote: > > On Sat, Jun 13, 2020 at 09:44:35PM -0700, Greywolf wrote: > > raidctl -a /dev/wd0c raid1 > > > > raidctl -F component0 raid1 > > I would have expected that to work. What is the raidctl status output > after the -a ? > > Martin -- --*greywolf;
RAIDframe question
Here's my situation: raid1: a RAID-1 mirror consisting of (usually) /dev/wd0c and /dev/wd1c, each 500G SSD. I recently had to fail out one of the components because I had two different kinds of disk which were performing at different transfer rates, and the slow one was slowing down the volume: raidctl -f /dev/wd0c [power off the machine, install new disk, bring it back up] raid1 now shows (as expected) "component0" and "/dev/wd1c" as components. [partition wd0 with c = d = whole disk, type RAID] raidctl -a /dev/wd0c raid1 raidctl -F component0 raid1 Within short order, the disklabel on raid1 vanishes. If I replace the label I had before, the filesystem checks fail as though everything is garbage. If I unconfigure/reconfigure raid1 with and /dev/wd1c, everything becomes sane again. If I unconfigure/reconfigure raid1 with /dev/wd0c and /dev/wd1c, it's hosed again. What am I doing wrong? -- --*greywolf;
Re: Build failed on fresh sources
On Sat, Sep 28, 2019 at 3:48 AM Christos Zoulas wrote:
> We've chosen not to fix the fallthrough warnings in 3rd party code, but
> we instead have changed the default setting to not produce errors. Have
> you made any changes to the compilation environment that caused those to
> become errors again?
>
> christos
No, sir, I have not -- fresh sources, no environment variables set (I
only set them for full release builds).
Can this be overridden with a subsequent -Wno-{something}, or something similar?
--
--*greywolf;
Build failed on fresh sources
Sources from 2019-09-26, building a kernel, I get this:
###
gcc -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -mno-avx
-msoft-float -mindirect-branch=thunk-inline -mindirect-branch-register
-ffreestanding -fno-zero-initialized-in-bss
-fno-delete-null-pointer-checks -g -O2 -fno-omit-frame-pointer
-fstack-protector -Wstack-protector --param ssp-buffer-size=1
-fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main
-Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes
-Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow
-Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign
-Wno-attributes -Wextra -Wno-unused-parameter -Wold-style-definition
-Wno-sign-compare -Wno-shadow -Damd64 -Dx86_64 -I.
-I../../../../external/bsd/acpica/dist
-I../../../../external/bsd/libnv/dist
-I../../../../../common/lib/libx86emu
-I../../../../../common/lib/libc/misc -I../../../../../common/include
-I../../../../arch -I../../../.. -nostdinc -DCOMPAT_UTILS -DDIAGNOSTIC
-DCOMPAT_44 -D_KERNEL -D_KERNEL_OPT -std=gnu99
-I../../../../lib/libkern/../../../common/lib/libc/quad
-I../../../../lib/libkern/../../../common/lib/libc/string
-I../../../../lib/libkern/../../../common/lib/libc/arch/x86_64/string
-D_FORTIFY_SOURCE=2 -I../../../../external/bsd/common/include
-I../../../../external/bsd/common/include
-I../../../../external/bsd/drm2/include
-I../../../../external/bsd/drm2/include
-I../../../../external/bsd/common/include
-I../../../../external/bsd/drm2/dist/include
-I../../../../external/bsd/drm2/dist/include/drm
-I../../../../external/bsd/drm2/dist/uapi
-I../../../../external/bsd/drm2/dist -D__KERNEL__
-DCONFIG_BACKLIGHT_CLASS_DEVICE=0
-DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0
-DCONFIG_DRM_FBDEV_EMULATION=1 -DCONFIG_FB=0
-I../../../../../common/include -I../../../../external/bsd/libnv/dist
-I../../../../external/bsd/drm2/i915drm
-I../../../../external/bsd/drm2/dist/drm/i915
-DCONFIG_DRM_I915_FBDEV=1 -DCONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=0
-DCONFIG_DRM_FBDEV_EMULATION=1
-I../../../../external/bsd/acpica/dist/include -c
../../../../external/bsd/drm2/dist/drm/i915/intel_ddi.c -o intel_ddi.o
In file included from
../../../../external/bsd/drm2/dist/drm/i915/intel_bios.h:33:0,
from ../../../../external/bsd/drm2/dist/drm/i915/i915_drv.h:50,
from
../../../../external/bsd/drm2/dist/drm/i915/intel_ddi.c:35:
../../../../external/bsd/drm2/dist/drm/i915/intel_ddi.c: In function
'translate_signal_level':
../../../../external/bsd/drm2/dist/include/drm/drmP.h:241:6: error:
this statement may fall through [-Werror=implicit-fallthrough=]
if (unlikely(drm_debug & DRM_UT_KMS)) \
^
../../../../external/bsd/drm2/dist/drm/i915/intel_ddi.c:2229:3: note:
in expansion of macro 'DRM_DEBUG_KMS'
DRM_DEBUG_KMS("Unsupported voltage swing/pre-emphasis level: 0x%x\n",
^
../../../../external/bsd/drm2/dist/drm/i915/intel_ddi.c:2231:2: note: here
case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_0:
^~~~
cc1: all warnings being treated as errors
*** Error code 1
Stop.
###
It's one of a bug, a coding error, or user error. I will accept all
of these answers, but if it's the third one, I'd like to know where
I've gone wrong.
--
--*greywolf;
Build issues (amd64)
Greetings!
I seem to be having some build issues happening. My pertinent
environment/variables are as follows:
MACHINE=
MACHINE_ARCH=<(not set)>
MAKEOBJDIR=
DESTDIR=
RELEASEDIR=
PATH=
MANPATH=
BSDSRCDIR=
BSDOBJDIR=
BUILDROOT=
TOOLDIR=
MACHINE_ARCH is not set because things seem to go horribly wrong when it is
set to x86_64, even though that appears to be the default MACHINE_ARCH for
MACHINE=amd64.
My command line (general) is as such:
./build.sh -m amd64 -D /usr/src/build/arch/amd64/build/ -O
/usr/src/build/arch/amd64/obj -R /usr/src/build/arch/amd64/release/ -T
/usr/src/tools/tools-amd64 -j12 {target}
Doesn't matter what my target is -- that command line works just fine;
UNLESS:
If I add '-u' to that command line, I get failures. Isn't -u supposed to
skip cleandir and the tools rebuild? The tools rebuild fails if the tools
already exist. (This bug has been present for quite some time.)
If I add '-x' (to build X11), I get failures before the toolchain finishes
building. Why there? Does the toolchain contain any weird X11
dependencies?
So right now, I can't do a build-by-stages (tools, build, distribution,
release). I can only pick one target and build to that, as each build
seems to require a total wipeout and restart.
My /etc/mk.conf: https://www.starwolf.com/machines/eddie/mk.conf
Build Logs:
"build release", success:
https://www.starwolf.com/machines/eddie/buildlogs/2019-09-23/1433-build-release.out.gz
"build release with -x", failure:
https://www.starwolf.com/machines/eddie/buildlogs/2019-09-24/0031-build-release-fail.gz
"build tools", success:
https://www.starwolf.com/machines/eddie/buildlogs/2019-09-24/0105-build-tools.out.gz
"build tools with -x", failure:
https://www.starwolf.com/machines/eddie/buildlogs/2019-09-24/0228-build-tools.fail.gz
I do in fact have the X sources at /usr/xsrc, updated yesterday (and
nothing new seems to have come in).
There is so much going on that it is hard for me to find "where's the spark
that's blowing up the bomb"?
--
--*greywolf;
/* relayer @t gmail d0t com */
/* ^ spam decoy ^ */
