Re: Disk partition not recognized
Crystal Kolipe wrote: > On Tue, Dec 21, 2021 at 06:04:28PM -0500, Rob Whitlock wrote: > > A problem seems to be that there is no disklabel entry for the ExFAT > > partition. > > You probably wrote a BSD disklabel to the disk before creating the ExFAT > partition. > > If there is no on-disk disklabel, the kernel will create one in memory based > on information from other partitioning schemes, (MBR, GPT). So in this case, > as you change those MBR or GPT partitions, those changes will be reflected in > the disklabel that the kernel sees. > > Once you actually write a disklabel to the disk, that on-disk disklabel is > then used in place of calculating one each time the disk is attached, and the > automatic parsing of MBR and GPT partition information stops. > > To solve your problem, you need to add the details of the ExFAT partition to > the BSD disklabel. You can either do that manually with the disklabel > command, or since you do not have any OpenBSD partitions on the disk, you > could overwrite the on-disk disklabel, allow the kernel to generate one > automatically with the correct information, then optionally force it to be > written to the disk by running disklabel and entering 'w' at the interactive > prompt. This can be investigated with disklabel -d (BTW, when the disklabel is constructed from other information on the disk, we call it a "spoofed label")
PHP 7.4: SSL routines:CONNECT_CR_CERT:certificate verify failed
Hey friends, i have a OpenBSD 7.0 server with all syspatches applied. On that server i have setup httpd and PHP 7.4 running via PHP-FPM. I followed the readme provided by the package and everything seams to be fine. There is only one issue when i try to establish a secure connection from PHP to another server. (sending an email in this case via SMTP). I get the following error: PHP Warning: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed I followed the readme to the point and populated /var/www/etc/ssl/ with all the recommended files (cert.pem and openssl.cnf). In the config file /etc/php-7.4.ini i added the folowing lines to point PHP-FPM to those files (the chroot /var/www gets appended by php): [curl] curl.cainfo = /etc/ssl/cert.pem [openssl] openssl.cafile = /etc/ssl/cert.pem The files are read by PHP, because when i remove then i get an error (as expected, just a verification that they are read as intended). But PHP is still unable to connect to that server. I ssh'ed into that server and did the openssl s_client manually. Just to verify that everything works as expected and it does: openssl s_client -tls1_2 -connect mail.foobar.com:587 openssl s_client -tls1_3 -connect mail.foobar.com:587 (both 1.2 and 1.3 work) Here is the successful response: CONNECTED(0003) 3143473289712:error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version:/usr/src/lib/libssl/tls13_lib.c:151: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 201 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: Start Time: 1640216653 Timeout : 7200 (sec) Verify return code: 0 (ok) --- Do you have any ideas on what might be wrong here? The error message sadly is not that helpful and as far as i know there is not that much i can do to get more detailed logs. Thanks in advance Leo OpenBSD 7.0 (GENERIC.MP) #3: Wed Dec 15 13:14:26 MST 2021 r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33537511424 (31983MB) avail mem = 32505069568 (30999MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6a30 (11 entries) bios0: vendor Hetzner version "2017" date 11/11/2017 bios0: Hetzner vServer acpi0 at bios0: ACPI 1.0 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel Xeon Processor (Skylake, IBRS), 2294.85 MHz, 06-55-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLWB,AVX512CD,AVX512BW,AVX512VL,MD_CLEAR,IBRS,IBPB,SSBD,ARAT,XSAVEOPT,XSAVEC,XGETBV1,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 999MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel Xeon Processor (Skylake, IBRS), 2294.59 MHz, 06-55-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLWB,AVX512CD,AVX512BW,AVX512VL,MD_CLEAR,IBRS,IBPB,SSBD,ARAT,XSAVEOPT,XSAVEC,XGETBV1,MELTDOWN cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel Xeon Processor (Skylake, IBRS), 2294.60 MHz, 06-55-04 cpu2:
Re: Disk partition not recognized
I am not sure you can find someone who knows (almost) everything about disks and partitions even on OpenBSD area. There are so many "standards" and "methods" that the utilities got their names in time: fdisk - %#@& disk dd - destroy disk disklabel - diskbabel But maybe I am mistaken.
Re: Disk partition not recognized
On Wed, Dec 22, 2021 at 05:29:34PM +0100, Tilo Stritzky wrote:
> (With an MBR disk you could force feed a handcrafted disklabel but
> that won't work here because on a GPT disk without OpenBSD partition
> the disklabel and the primary GPT share a physical sector and that
> won't work.)
That is incorrect.
At one time, the disklabel program would try to write it to the second block,
I.E. the sector after the MBR. This would indeed fail if a GPT was already
there.
However, if you test this on OpenBSD 7.0-release, you will see that the
disklabel will happily be written elsewhere:
# dd if=/dev/zero of=/tmp/vd bs=1m count=512
# vnconfig vnd0 /tmp/vd
# fdisk -e vnd0 # Create a non-OpenBSD GPT partition
# disklabel -E vnd0 # Write the disklabel to the media
# hexdump -C /tmp/vd
ea 05 00 c0 07 8c c8 8e d0 bc fc ff 8e d8 b8 a0 ||
0010 07 8e c0 31 f6 31 ff b9 00 02 fc f3 a4 ea 22 00 |...1.1".|
0020 a0 07 1e 07 0e 1f b4 02 cd 16 a8 03 74 0d b0 07 |t...|
0030 e8 de 00 67 80 0d b4 01 00 00 01 f6 c2 80 75 08 |...g..u.|
0040 be 49 01 e8 bf 00 b2 80 be be 01 b9 04 00 8a 04 |.I..|
0050 3c 80 74 0f 83 c6 10 e2 f5 be 7d 01 e8 a6 00 fb |<.t...}.|
0060 f4 eb fc 88 d0 24 0f 04 30 a2 3a 01 b0 34 28 c8 |.$..0.:..4(.|
0070 a2 47 01 56 be 2d 01 67 f6 05 b4 01 00 00 01 75 |.G.V.-.g...u|
0080 01 46 e8 80 00 5e 26 67 c7 05 fe 01 00 00 00 00 |.F...^|
0090 67 f6 05 b4 01 00 00 01 75 34 88 14 bb aa 55 b4 |g...u4U.|
00a0 41 cd 13 8a 14 72 27 81 fb 55 aa 75 21 f6 c1 01 |Ar'..U.u!...|
00b0 74 1c b0 2e e8 5a 00 66 8b 4c 08 67 66 89 0d 25 |tZ.f.L.gf..%|
00c0 01 00 00 56 b4 42 be 1d 01 cd 13 5e 73 1a b0 3b |...V.B.^s..;|
00d0 e8 3e 00 8a 74 01 8b 4c 02 b8 01 02 31 db cd 13 |.>..t..L1...|
00e0 73 06 be 65 01 e9 74 ff be 90 01 e8 17 00 26 67 |s..e..t...|
00f0 81 3d fe 01 00 00 55 aa 75 05 ea 00 7c 00 00 be |.=U.u...|...|
0100 74 01 e9 57 ff 50 fc ac 84 c0 74 0f e8 02 00 eb |t..W.Pt.|
0110 f6 50 53 b4 0e bb 01 00 cd 10 5b 58 c3 10 00 01 |.PS...[X|
0120 00 00 00 c0 07 00 00 00 00 00 00 00 00 21 55 73 |.!Us|
0130 69 6e 67 20 64 72 69 76 65 20 58 2c 20 70 61 72 |ing drive X, par|
0140 74 69 74 69 6f 6e 20 59 00 4d 42 52 20 6f 6e 20 |tition Y.MBR on |
0150 66 6c 6f 70 70 79 20 6f 72 20 6f 6c 64 20 42 49 |floppy or old BI|
0160 4f 53 0d 0a 00 0d 0a 52 65 61 64 20 65 72 72 6f |OS.Read erro|
0170 72 0d 0a 00 4e 6f 20 4f 2f 53 0d 0a 00 4e 6f 20 |r...No O/S...No |
0180 61 63 74 69 76 65 20 70 61 72 74 69 74 69 6f 6e |active partition|
0190 0d 0a 00 90 00 00 00 00 00 00 00 00 00 00 00 00 ||
01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
01b0 00 00 00 00 00 00 4f 78 00 00 00 00 00 00 00 ff |..Ox|
01c0 ff ff ee ff ff ff 01 00 00 00 ff ff ff ff 00 00 ||
01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.|
0200 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART\...|
0210 65 43 91 cc 00 00 00 00 01 00 00 00 00 00 00 00 |eC..|
0220 ff ff 0f 00 00 00 00 00 22 00 00 00 00 00 00 00 |"...|
0230 de ff 0f 00 00 00 00 00 f2 63 79 02 b9 99 39 48 |.cy...9H|
0240 99 97 2e 77 79 98 35 f5 02 00 00 00 00 00 00 00 |...wy.5.|
0250 80 00 00 00 80 00 00 00 a7 be 55 7f 00 00 00 00 |..U.|
0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
0400 a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 |..3D..h..&..|
0410 41 60 b8 b5 2b 54 10 41 ba 44 ee f8 3e 55 7b 50 |A`..+T.A.D..>U{P|
0420 22 00 00 00 00 00 00 00 de ff 0f 00 00 00 00 00 |"...|
0430 00 00 00 00 00 00 00 00 66 00 6f 00 6f 00 00 00 |f.o.o...|
0440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
vvv BSD disklabel here vvv
4600 57 45 56 82 0c 00 00 00 76 6e 64 20 64 65 76 69 |WEV.vnd devi|
4610 63 65 00 00 00 00 00 00 66 69 63 74 69 74 69 6f |ce..fictitio|
4620 75 73 00 00 00 00 00 00 00 02 00 00 64 00 00 00 |us..d...|
4630 01 00 00 00 f5 28 00 00 64 00 00 00 00 00 10 00 |.(..d...|
4640 38 88 61 0e cf 69 90 5f 00 00 00 00 00 00 00 00 |8.a..i._|
4650 22 00 00 00 df ff 0f 00 00 00 00 00 00 00 00 00 |"...|
4660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
4670 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
4680 00 00 00 00 57 45 56 82 97 e8 10 00 00 20 00 00 |WEV.. ..|
4690 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
Re: Disk partition not recognized
On Wed, Dec 22, 2021 at 5:23 AM Crystal Kolipe wrote: > On Tue, Dec 21, 2021 at 06:04:28PM -0500, Rob Whitlock wrote: > > A problem seems to be that there is no disklabel entry for the ExFAT > > partition. > > You probably wrote a BSD disklabel to the disk before creating the ExFAT > partition. > I formatted the disk on a MacOS system, so I'm pretty sure there is no disklabel on the disk. > If there is no on-disk disklabel, the kernel will create one in memory > based on information from other partitioning schemes, (MBR, GPT). So in > this case, as you change those MBR or GPT partitions, those changes will be > reflected in the disklabel that the kernel sees. > > Once you actually write a disklabel to the disk, that on-disk disklabel is > then used in place of calculating one each time the disk is attached, and > the automatic parsing of MBR and GPT partition information stops. > > To solve your problem, you need to add the details of the ExFAT partition > to the BSD disklabel. You can either do that manually with the disklabel > command, or since you do not have any OpenBSD partitions on the disk, you > could overwrite the on-disk disklabel, allow the kernel to generate one > automatically with the correct information, then optionally force it to be > written to the disk by running disklabel and entering 'w' at the > interactive prompt. > I would like to not modify the on-disk contents. Is there a way to get OpenBSD to recognize the partition without writing things to the disk?
Re: Recommendations on Buffer Space for Busy Unbound Resolver Service for a network
Thanks Stuart, A year or two ago I set the following sysctl which did help, fdns1# cat /etc/sysctl.conf net.inet.udp.recvspace=262144 net.inet.udp.sendspace=262144 Thanks for the tip re diagnosing the UDP buffers output of the command you suggested looks good from a buffer perspective... The server has been running a few hours fdns1# netstat -s -p udp udp: 32820423 datagrams received 0 with incomplete header 0 with bad data length field 7 with bad checksum 133788 with no checksum 32686635 input packets software-checksummed 0 output packets software-checksummed 40699 dropped due to no socket 13873 broadcast/multicast datagrams dropped due to no socket 0 dropped due to missing IPsec protection 0 dropped due to full socket buffers 32765844 delivered 32913599 datagrams output 24008710 missed PCB cache Thanks again, Really appreciate your Tom Smyth On Wed, 22 Dec 2021 at 11:26, Stuart Henderson wrote: > On 2021-12-22, Dirk Coetzee wrote: > > Hi Tom, > > > > I would recommend debugging using "unbound-control stats_noreset" and > referencing the unbound configuration documentation at > https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ > > Also check for "dropped due to full socket buffers" in netstat -s -p udp, > some have reported needing to raise net.inet.udp.*space sysctls. > > You might also consider front-ending with dnsdist. As well as answering hot > requests very quickly, that could also simplify things for maintenance. > > > On Tue, 21 Dec 2021 at 21:15, Tom Smyth > > wrote: > > > >> Recommendations on Buffer Space for Busy Unbound Resolver Service for > >> a network serving a 3000, customers > > > -- > Please keep replies on the mailing list. > > -- Kindest regards, Tom Smyth.
Re: Disk partition not recognized
On 22/12/21 13:35 Tilo Stritzky wrote: Um, well.. What I was going to say is, for some reason the default disklabel doesn't pick up your partitions (it should also show the EFI, but doesn't). As a quick-and-dirty fix you cold try and change the partition ID to something that's picked up by the default label. 3f929abc-650c-4237-af34-2027ddc585e5 should work. For a proper fix, find where the partition IDs are kept and add yours. (With an MBR disk you could force feed a handcrafted disklabel but that won't work here because on a GPT disk without OpenBSD partition the disklabel and the primary GPT share a physical sector and that won't work.) > On 21/12/21 18:04 Rob Whitlock wrote: > > I have two disks, one an MBR partitioned 1TB external SSD, and the other a > > GPT partitioned 5TB external HDD. Both have a single ExFAT partition on > > them and both have the same contents. Both show up as sd1 under "sysctl > > hw.disknames" (when plugged in one at a time, that is). I am able to mount > > the MBR partitioned SSD with the command > > > > mount.exfat-fuse /dev/sd1i /mnt > > > > however when I try the same command with the GPT partitioned HDD I get the > > error > > > > FUSE exfat 1.2.8 > > ERROR: failed to open '/dev/sd1i': Device not configured. > > > > I checked that the /dev/sd1i block device exists. I am running OpenBSD 6.9. > > Here's the output of disklabel sd1 > > > > # /dev/rsd1c: > > type: SCSI > > disk: SCSI disk > > label: Expansion Desk > > duid: > > flags: > > bytes/sector: 512 > > sectors/track: 63 > > tracks/cylinder: 255 > > sectors/cylinder: 16065 > > cylinders: 608001 > > total sectors: 9767541167 > > boundstart: 0 > > boundend: 9767541167 > > drivedata: 0 > > > > 16 partitions: > > #size offset fstype [fsize bsize cpg] > > c: 97675411670 unused > > > > > > Here's the output of fdisk -v sd1 > > Primary GPT: > > Disk: sd1 Usable LBA: 34 to 9767541133 [9767541167 Sectors] > > GUID: 570ab069-1869-44ed-911b-a568af1275ff > >#: type [ start: size ] > > guid name > > > >0: EFI Sys [ 40: 409600 ] > > a4bd4c86-177d-4e02-a9f9-afc51ade8d87 EFI System Partition > > > >1: FAT12[ 411648: 9767129088 ] > > 7157c7e5-978f-4a43-96af-fa6648710488 > > > > > > Secondary GPT: > > Disk: sd1 Usable LBA: 34 to 9767541133 [9767541167 Sectors] > > GUID: 570ab069-1869-44ed-911b-a568af1275ff > >#: type [ start: size ] > > guid name > > > >0: EFI Sys [ 40: 409600 ] > > a4bd4c86-177d-4e02-a9f9-afc51ade8d87 EFI System Partition > > > >1: FAT12[ 411648: 9767129088 ] > > 7157c7e5-978f-4a43-96af-fa6648710488 > > > > > > MBR: > > Disk: sd1 geometry: 267349/255/63 [4294961685 Sectors] > > Offset: 0 Signature: 0xAA55 > > Starting Ending LBA Info: > > #: id C H S - C H S [ start:size ] > > --- > > 0: EE 0 0 2 - 267349 89 3 [ 1: 4294967294 ] EFI GPT > > > > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > > 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > > > > A problem seems to be that there is no disklabel entry for the ExFAT > > partition. Additionally, xxd successfully reads the first few sectors of > > /dev/sd1c so I don't think the hardware is the issue. > > > > How can I mount the HDD ExFAT partition? > > > > Thanks! > > > > Rob >
Re: Disk partition not recognized
James Cook wrote: > I thought the disklabel lives at the start of the OpenBSD partition. That is incorrect.
Re: Disk partition not recognized
On Wed, Dec 22, 2021 at 07:21:41AM -0300, Crystal Kolipe wrote: > On Tue, Dec 21, 2021 at 06:04:28PM -0500, Rob Whitlock wrote: > > A problem seems to be that there is no disklabel entry for the ExFAT > > partition. > > You probably wrote a BSD disklabel to the disk before creating the ExFAT > partition. > > If there is no on-disk disklabel, the kernel will create one in memory based > on information from other partitioning schemes, (MBR, GPT). So in this case, > as you change those MBR or GPT partitions, those changes will be reflected in > the disklabel that the kernel sees. > > Once you actually write a disklabel to the disk, that on-disk disklabel is > then used in place of calculating one each time the disk is attached, and the > automatic parsing of MBR and GPT partition information stops. > > To solve your problem, you need to add the details of the ExFAT partition to > the BSD disklabel. You can either do that manually with the disklabel > command, or since you do not have any OpenBSD partitions on the disk, you > could overwrite the on-disk disklabel, allow the kernel to generate one > automatically with the correct information, then optionally force it to be > written to the disk by running disklabel and entering 'w' at the interactive > prompt. I thought the disklabel lives at the start of the OpenBSD partition. Since that disk has no OpenBSD partition, it can't have a disklabel, right? Could the in-memory disklabel be out of sync? Does the problem persist if you reboot, or detach/re-attach the disk? -- James
Re: Disk partition not recognized
On 21/12/21 18:04 Rob Whitlock wrote: > I have two disks, one an MBR partitioned 1TB external SSD, and the other a > GPT partitioned 5TB external HDD. Both have a single ExFAT partition on > them and both have the same contents. Both show up as sd1 under "sysctl > hw.disknames" (when plugged in one at a time, that is). I am able to mount > the MBR partitioned SSD with the command > > mount.exfat-fuse /dev/sd1i /mnt > > however when I try the same command with the GPT partitioned HDD I get the > error > > FUSE exfat 1.2.8 > ERROR: failed to open '/dev/sd1i': Device not configured. > > I checked that the /dev/sd1i block device exists. I am running OpenBSD 6.9. > Here's the output of disklabel sd1 > > # /dev/rsd1c: > type: SCSI > disk: SCSI disk > label: Expansion Desk > duid: > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 608001 > total sectors: 9767541167 > boundstart: 0 > boundend: 9767541167 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] > c: 97675411670 unused > > > Here's the output of fdisk -v sd1 > Primary GPT: > Disk: sd1 Usable LBA: 34 to 9767541133 [9767541167 Sectors] > GUID: 570ab069-1869-44ed-911b-a568af1275ff >#: type [ start: size ] > guid name > >0: EFI Sys [ 40: 409600 ] > a4bd4c86-177d-4e02-a9f9-afc51ade8d87 EFI System Partition > >1: FAT12[ 411648: 9767129088 ] > 7157c7e5-978f-4a43-96af-fa6648710488 > > > Secondary GPT: > Disk: sd1 Usable LBA: 34 to 9767541133 [9767541167 Sectors] > GUID: 570ab069-1869-44ed-911b-a568af1275ff >#: type [ start: size ] > guid name > >0: EFI Sys [ 40: 409600 ] > a4bd4c86-177d-4e02-a9f9-afc51ade8d87 EFI System Partition > >1: FAT12[ 411648: 9767129088 ] > 7157c7e5-978f-4a43-96af-fa6648710488 > > > MBR: > Disk: sd1 geometry: 267349/255/63 [4294961685 Sectors] > Offset: 0 Signature: 0xAA55 > Starting Ending LBA Info: > #: id C H S - C H S [ start:size ] > --- > 0: EE 0 0 2 - 267349 89 3 [ 1: 4294967294 ] EFI GPT > > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > A problem seems to be that there is no disklabel entry for the ExFAT > partition. Additionally, xxd successfully reads the first few sectors of > /dev/sd1c so I don't think the hardware is the issue. > > How can I mount the HDD ExFAT partition? > > Thanks! > > Rob
Re: Recommendations on Buffer Space for Busy Unbound Resolver Service for a network
On 2021-12-22, Dirk Coetzee wrote: > Hi Tom, > > I would recommend debugging using "unbound-control stats_noreset" and > referencing the unbound configuration documentation at > https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ Also check for "dropped due to full socket buffers" in netstat -s -p udp, some have reported needing to raise net.inet.udp.*space sysctls. You might also consider front-ending with dnsdist. As well as answering hot requests very quickly, that could also simplify things for maintenance. > On Tue, 21 Dec 2021 at 21:15, Tom Smyth > wrote: > >> Recommendations on Buffer Space for Busy Unbound Resolver Service for >> a network serving a 3000, customers -- Please keep replies on the mailing list.
Re: I had to change NIC I’m still having issues.
Rather than sentences like "finagled a Google router/modem to give me back the same local reserved address" and "some kinda round-robin with god knows what but it was messing with my internet" it would be better to show exactly what you are doing/typing/seeing, I think nobody can help without accurate information. On 2021-12-22, Luke Small wrote: > I have a Ethernet westmere-ep Supermicro server I use for a local dns > server which I have local devices vpn connected into. > > I started with em0 and I finagled a Google router/modem to give me back the > same local reserved address for em3 for the new Intel i350-t2 card. > > I was watching “tcpdump -aetvvipflog0” and I found a pf match rewrite a wg0 > state with a never before seen address like 206.xxx.xxx.xxx > > The rule was something like: > “pass out log quick on $ext_if inet modulate state nat-to ($ext_if) tagged > wireguard”, > and ext_if=em3 > > running “pfctl -srules” > > Showed it as some kinda round-robin with god knows what but it was messing > with my internet! > > I just changed it to: > pass out log quick on em3 inet modulate state tagged wireguard nat-to > > > Am I missing something? I disabled resolvd and made the name server > 127.0.0.1 in resolv.conf and other stuff. > > Why would it do that? > > > -- Please keep replies on the mailing list.
Re: Disk partition not recognized
On Tue, Dec 21, 2021 at 06:04:28PM -0500, Rob Whitlock wrote: > A problem seems to be that there is no disklabel entry for the ExFAT > partition. You probably wrote a BSD disklabel to the disk before creating the ExFAT partition. If there is no on-disk disklabel, the kernel will create one in memory based on information from other partitioning schemes, (MBR, GPT). So in this case, as you change those MBR or GPT partitions, those changes will be reflected in the disklabel that the kernel sees. Once you actually write a disklabel to the disk, that on-disk disklabel is then used in place of calculating one each time the disk is attached, and the automatic parsing of MBR and GPT partition information stops. To solve your problem, you need to add the details of the ExFAT partition to the BSD disklabel. You can either do that manually with the disklabel command, or since you do not have any OpenBSD partitions on the disk, you could overwrite the on-disk disklabel, allow the kernel to generate one automatically with the correct information, then optionally force it to be written to the disk by running disklabel and entering 'w' at the interactive prompt.
I had to change NIC I’m still having issues.
I have a Ethernet westmere-ep Supermicro server I use for a local dns server which I have local devices vpn connected into. I started with em0 and I finagled a Google router/modem to give me back the same local reserved address for em3 for the new Intel i350-t2 card. I was watching “tcpdump -aetvvipflog0” and I found a pf match rewrite a wg0 state with a never before seen address like 206.xxx.xxx.xxx The rule was something like: “pass out log quick on $ext_if inet modulate state nat-to ($ext_if) tagged wireguard”, and ext_if=em3 running “pfctl -srules” Showed it as some kinda round-robin with god knows what but it was messing with my internet! I just changed it to: pass out log quick on em3 inet modulate state tagged wireguard nat-to Am I missing something? I disabled resolvd and made the name server 127.0.0.1 in resolv.conf and other stuff. Why would it do that? -- -Luke
