Re: HPE ProLiant MicroServer Gen10 Plus
https://homeservershow.com/forums/forum/217-microserver-gen10-plus/ is a good resource for this server (although I doubt anyone over there has tried OpenBSD on it). It should run fine on OpenBSD, the only issue is it doesn't have a NVME slot, you'll have to boot off a usb stick if you don't want to boot off the disk array. If you're aiming to upgrade the CPU to a better Xeon, get the Pentium model to save money. Do get the optional iLO module too, it comes in handy. Cheers, Noth On 18/01/2022 22:06, readahead wrote: Hello, I'm currently considering purchasing a HPE ProLiant MicroServer Gen10 Plus. The machine is to be used mostly as a home NAS (OpenBSD, softraid(4) encryption and Samba). Is this a right machine to run OpenBSD on? Can you please share any experience, recommend an exact model, etc.? Kind regards, readahead
Re: HPE ProLiant MicroServer Gen10 Plus
readahead [readah...@protonmail.com] wrote: > Hello, > > I'm currently considering purchasing a HPE ProLiant MicroServer Gen10 Plus. > The machine is to be used mostly as a home NAS (OpenBSD, softraid(4) > encryption and Samba). > > Is this a right machine to run OpenBSD on? Can you please share any > experience, recommend an exact model, etc.? > Should be well supported, NVMe to 10GbE, nothing out of the ordinary for OpenBSD...
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote: > On 2022-01-17 18:02:25, Marc Espie wrote: > > > > Lol. > > > > cert.pem only contains public certificates. Insisting on only root being > > able to read it means you are going to run code as root which doesn't > > require > > it. That seems way more unreasonable than your original assumption. > > > > I am not arguing about the access permissions (which I screwed > up), but I wonder why pkg_add run by root failed with EPERM? > Actually root was the only one *permitted* to access this file. > Thats not an error. Because we use this nifty technique called privilege separation to alleviate issues with bugs. Most specifically, pkg_add runs as root, which has wy too many rights, so it doesn't connect to the network directly, it starts ftp(1), which runs as _pkgfetch, which passes its result to signify which can check that the archive is properly signed before decompressing it with the zlib and finally putting the result on your disk. It's not rocket science, privilege separation has been around for over 20 years at this point ;)
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On Tue, Jan 18, 2022 at 04:37:00PM +0100, Harald Dunkel wrote: > On 2022-01-17 18:02:25, Marc Espie wrote: > > > > Lol. > > > > cert.pem only contains public certificates. Insisting on only root being > > able to read it means you are going to run code as root which doesn't > > require > > it. That seems way more unreasonable than your original assumption. > > > > I am not arguing about the access permissions (which I screwed > up), but I wonder why pkg_add run by root failed with EPERM? > Actually root was the only one *permitted* to access this file. > Thats not an error. > > If there was another user account involved, then show me. The user is called _pkgfetch -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: pkg_add -u fails with "failed to open CA file '/etc/ssl/cert.pem': Permission denied"
On 2022-01-17 18:02:25, Marc Espie wrote: Lol. cert.pem only contains public certificates. Insisting on only root being able to read it means you are going to run code as root which doesn't require it. That seems way more unreasonable than your original assumption. I am not arguing about the access permissions (which I screwed up), but I wonder why pkg_add run by root failed with EPERM? Actually root was the only one *permitted* to access this file. Thats not an error. If there was another user account involved, then show me.
Re: ttyflags hangs on Dell PowerEdge R200
On Jan 15 11:03:10, dera...@openbsd.org wrote:
> I think the bug is that com_acpi_match() should call ic/com.c comprobe1(),
> which verifies that an actual chip exists, rather than simply trusting the
> ACPI tables. If attach succeeds, open and ioctl become callable, and at
> that point if real hardware isn't present, the driver reacts very poorly.
On Jan 15 15:48:51, dera...@openbsd.org wrote:
> Does this help?
Yes; dmesg below, the difference being
com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
-com1 at acpi0 COMB addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo
-com1: probed fifo depth: 0 bytes
+"PNP0501" at acpi0 not configured
Thank you!
Jan
> Index: com_acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/com_acpi.c,v
> retrieving revision 1.6
> diff -u -p -u -r1.6 com_acpi.c
> --- com_acpi.c26 Dec 2021 13:55:36 - 1.6
> +++ com_acpi.c15 Jan 2022 22:48:13 -
> @@ -61,14 +61,28 @@ int
> com_acpi_match(struct device *parent, void *match, void *aux)
> {
> struct acpi_attach_args *aaa = aux;
> + bus_space_handle_t ioh;
> + bus_space_tag_t iot;
> struct cfdata *cf = match;
> + int iobase;
> + int rv;
>
> if (aaa->aaa_naddr < 1 || aaa->aaa_nirq < 1)
> return 0;
> if (cf->acpidevcf_addr != aaa->aaa_addr[0] &&
> cf->acpidevcf_addr != ACPIDEVCF_ADDR_UNK)
> return 0;
> - return acpi_matchhids(aaa, com_hids, cf->cf_driver->cd_name);
> + if (acpi_matchhids(aaa, com_hids, cf->cf_driver->cd_name) == 0)
> + return 0;
> +
> + iot = aaa->aaa_bst[0];
> + iobase = aaa->aaa_addr[0];
> +
> + if (bus_space_map(iot, iobase, COM_NPORTS, 0, &ioh))
> + return (0);
> + rv = comprobe1(iot, ioh);
> + bus_space_unmap(iot, ioh, COM_NPORTS);
> + return (rv);
> }
>
> void
>
dmesg with the patch:
OpenBSD 7.0-current (GENERIC.MP) #0: Mon Jan 17 13:19:50 CET 2022
h...@toposym.fit.cvut.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4276822016 (4078MB)
avail mem = 4130021376 (3938MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcff9c000 (46 entries)
bios0: vendor Dell Inc. version "1.4.3" date 05/15/2009
bios0: Dell Inc. PowerEdge R200
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ SSDT
SSDT SSDT
acpi0: wakeup devices PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3120 @ 3.16GHz, 2000.44 MHz, 06-17-0a
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 333MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3120 @ 3.16GHz, 2000.15 MHz, 06-17-0a
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (SBE0)
acpiprt3 at acpi0: bus 3 (SBE4)
acpiprt4 at acpi0: bus 4 (SBE5)
acpiprt5 at acpi0: bus 5 (COMP)
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpicmos0 at acpi0
com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
"PNP0501" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2000 MHz: speeds: 3166, 2667, 2333, 2000 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 3200/3210 Host" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 3200/3210 PCIE" rev 0x01: msi
pci1 at ppb0 bus 1
mpi0 at pci1 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x08: msi
mpi0: SAS6IR, firmware 0.25.47.0
scsibus1 at mpi0: 112 targets
sd0 at scsibus1 targ 0 lun 0:
naa.600508e09ed329b65835f206
sd0: 69376MB, 512 bytes/sector, 142082048 sectors
ppb1 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02
pci3 at ppb2 bus 3
bge0 at pci3 dev 0 function 0 "Broadcom BCM5
Re: Delivery status notification: delayed
Today's mails to misc@ are bouncing back with misc@openbsd.org: Network error on destination MXs Jan On Jan 17 15:49:08, mailer-dae...@stare.cz wrote: > Hi! > > This is the MAILER-DAEMON, please DO NOT REPLY to this email. > > A message is delayed for more than 4 hours for the following > list of recipients: > > misc@openbsd.org: Network error on destination MXs > > Please note that this is only a temporary failure report. > The message is kept in the queue for up to 7 days. > You DO NOT NEED to re-send the message to these recipients. > > Below is a copy of the original message: > Reporting-MTA: dns; stare.cz > > Final-Recipient: rfc822; misc@openbsd.org > Action: delayed > Status: 4.0.0 > Received: from localhost (stare.cz [local]) > by stare.cz (OpenSMTPD) with ESMTPA id 3d1ef9fe > for ; > Mon, 17 Jan 2022 13:02:16 +0100 (CET) > Date: Mon, 17 Jan 2022 13:02:16 +0100 > From: Jan Stary > To: misc@openbsd.org > Subject: Re: ttyflags hangs on Dell PowerEdge R200 > Message-ID: > References: > > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > In-Reply-To: > > On Jan 14 19:10:32, kolip...@exoticsilicon.com wrote: > > On Fri, Jan 14, 2022 at 10:41:52PM +0100, Jan Stary wrote: > > > I suspect it's com1; I have yet to try commenting out just tty01. > > > But commenting out both makes it boot OK. > > > > > > com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > > > com1 at acpi0 COMB addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo > > > > > > Are these known to misbehave under ttyflags? > > > > > > I realize a lot has changed since then, but it's a production machine, > > > and while I would love nothing more than go through the releases one > > > by one, this machine has to run now. > > > > Well there were recently changes to make com attach via acpi, and now > > you have a com port that you didn't have before. > > This is to confirm that the "new" com1 @ acpi is the culprit: > it is enough to comment out tty01 in /etc/ttys > and the boot gets through ttyflags -a > > > My suspicion would be that the new com1 either does not really exist in > > hardware, or that it's mis-configured. > > Please excuse my HW ignorance: does "ti16750" mean then > that some ACPI table _says_ there it a (Texas Instruments?) com, > even if there isn't really? At any rate, there is just one > visible cereal on the PowerEdge's case. > > > Does the BIOS mention it? Can it be disabled there? > > The BIOS only mentions "Serial port 1 ... COM1", > which I suppose is 1-based indexing, so that's com0 aka tty00. > There is no other serial port in the BIOS to be disabled. > > (Got a diff in the meantime, recompiling now.) > > Jan >
Re: ttyflags hangs on Dell PowerEdge R200
On Jan 14 19:10:32, kolip...@exoticsilicon.com wrote: > On Fri, Jan 14, 2022 at 10:41:52PM +0100, Jan Stary wrote: > > I suspect it's com1; I have yet to try commenting out just tty01. > > But commenting out both makes it boot OK. > > > > com0 at acpi0 COMA addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > > com1 at acpi0 COMB addr 0x2f8/0x8 irq 3: ti16750, 64 byte fifo > > > > Are these known to misbehave under ttyflags? > > > > I realize a lot has changed since then, but it's a production machine, > > and while I would love nothing more than go through the releases one > > by one, this machine has to run now. > > Well there were recently changes to make com attach via acpi, and now > you have a com port that you didn't have before. This is to confirm that the "new" com1 @ acpi is the culprit: it is enough to comment out tty01 in /etc/ttys and the boot gets through ttyflags -a > My suspicion would be that the new com1 either does not really exist in > hardware, or that it's mis-configured. Please excuse my HW ignorance: does "ti16750" mean then that some ACPI table _says_ there it a (Texas Instruments?) com, even if there isn't really? At any rate, there is just one visible cereal on the PowerEdge's case. > Does the BIOS mention it? Can it be disabled there? The BIOS only mentions "Serial port 1 ... COM1", which I suppose is 1-based indexing, so that's com0 aka tty00. There is no other serial port in the BIOS to be disabled. (Got a diff in the meantime, recompiling now.) Jan
