Re: EFI boot on Dell PowerEdge R610
Hi,
On Wed, 17 Jun 2020 00:37:48 -0700
Johan Hattne wrote:
> On 2020-05-29 17:01, Johan Hattne wrote:
>>
>>> On May 28, 2020, at 20:38, YASUOKA Masahiko
>>> wrote:
>>>
>>> Hi,
>>>
>>> On Thu, 28 May 2020 09:46:23 -0700
>>> Johan Hattne wrote:
> On May 28, 2020, at 06:42, Nick Holland
> wrote:
>
> On 2020-05-28 05:15, Johan Hattne wrote:
>> On 2020-05-28 00:56, Johan Hattne wrote:
>>> On 2020-05-28 00:43, YASUOKA Masahiko wrote:
Hi,
On Wed, 27 May 2020 22:32:58 -0700
Johan Hattne wrote:
> I've been trying to boot the 6.7 installation media from USB via EFI
> on a Dell PowerEdge R610. The screen goes blank and then the thing
> resets (so no kernel output or anything). I can boot the same stick
> via BIOS.
>
> I've been searching for a while without results. Firmware settings
> look sane to me. Is this something anybody has seen before? Any hint
> on where I could even start looking for problems would be very much
> appreciated!
I'd like you to try the diff attached with the following message.
https://marc.info/?l=openbsd-tech=158280719421562=2
>>>
>>> Thanks a lot, Yasuoka! Is there any chance you could provide a
>>> compiled
>>> BOOTX64.EFI? I don't have an amd64 build environment at the moment.
>>
>> After a bit of off-list discussion, Yasuoka concluded that above diff
>> won't help here. To clarify the issue: there is no output at all
>> before
>> the machine resets, in particular there is no prompt from the EFI boot
>> program.
>>
>> // Johan
>>
>
> Have you tried firmware updates?
> That machine is many years old, I'd not be the slightest bit surprised
> if
> the firmware was buggy and didn't boot much of anything in EFI mode
> other
> than Windows and maybe Linux.
Thanks, Nick! The firmware is up to date. And the machine does boot
e.g. NetBSD through EFI.
>>>
>>> Probing serial devices is one of the differences from NetBSD efiboot.
>>>
>>> diff --git a/sys/arch/amd64/stand/efiboot/conf.c
>>> b/sys/arch/amd64/stand/efiboot/conf.c
>>> index 3eb745d808d..8d385a4f198 100644
>>> --- a/sys/arch/amd64/stand/efiboot/conf.c
>>> +++ b/sys/arch/amd64/stand/efiboot/conf.c
>>> @@ -89,7 +89,7 @@ int ndevs = nitems(devsw);
>>>
>>> struct consdev constab[] = {
>>> { efi_cons_probe, efi_cons_init, efi_cons_getc, efi_cons_putc },
>>> - { efi_com_probe, efi_com_init, efi_com_getc, efi_com_putc },
>>> + //{ efi_com_probe, efi_com_init, efi_com_getc, efi_com_putc },
>>> { NULL }
>>> };
>>> struct consdev *cn_tab = constab;
>>>
>>> I put a compiled binary on https://yasuoka.net/~yasuoka/BOOTX64.EFI
>> Thanks a lot, Yasuoka! The binary you compiled still exhibits the
>> same problem (it immediately resets the machine).
>
> Another difference to NetBSD's efiboot is the way the heap is
> allocated: OpenBSD does AllocateMaxAddress, whereas NetBSD does
> AllocateAnyPages. Turns out the EFI on this machine fails with
> AllocateMaxAddress (so I guess Nick was right). For what it's worth,
> the patch below allowed me to eventually boot the kernel through EFI.
Nice finding.
I remember that HEAP_LIMIT was for some machines.
https://marc.info/?t=14425410003=1=2
Do you have or can you take the result of "machine memory" on efiboot?
> Index: Makefile.common
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efi64/Makefile.common,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile.common
> --- Makefile.common 5 Mar 2020 16:36:30 - 1.5
> +++ Makefile.common 17 Jun 2020 04:20:16 -
> @@ -7,8 +7,6 @@ EFIDIR= ${S}/stand/efi
> OBJCOPY?= objcopy
> OBJDUMP?= objdump
>
> -EFI_HEAP_LIMIT=0xc0
> -
> LDFLAGS+= -nostdlib -T${.CURDIR}/../${LDSCRIPT} -Bsymbolic -shared
>
> COPTS+= -DEFIBOOT -DFWRANDOM -DNEEDS_HEAP_H -I${.CURDIR}/..
> @@ -69,7 +67,7 @@ ${PROG}: ${PROG.so}
> .include
> CFLAGS+= -Wno-pointer-sign
> CPPFLAGS+= -DSMALL -DSLOW -DNOBYFOUR -D__INTERNAL_LIBSA_CREAD
> -CPPFLAGS+= -DHEAP_LIMIT=${EFI_HEAP_LIMIT} -DHIBERNATE
> +CPPFLAGS+= -DHIBERNATE
>
> ${PROG.so}: ${OBJS}
> ${LD} ${LDFLAGS} -o ${.TARGET}.tmp ${OBJS} ${LDADD}
> Index: efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efi64/efiboot.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 efiboot.c
> --- efiboot.c 11 May 2019 19:14:41 - 1.2
> +++ efiboot.c 17 Jun 2020 04:20:16 -
> @@ -275,8 +275,7 @@ efi_heap_init(void)
> {
> EFI_STATUS status;
>
> - heap = HEAP_LIMIT;
> - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
> - EfiLoaderData,
> + status = EFI_CALL(BS->AllocatePages, AllocateAnyPages,
>
Re: hostname.pppoe0, !/bin/sh when reconnecting
On 2020-06-17, Christian Weisgerber wrote: > On 2020-06-17, Lévai, Dániel wrote: > >> I'm trying to run a script whenever I get a new IP address from my ISP over >> pppoe0. They disconnect me occasionally and the router reconnects then, eg.: >> /bsd: pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated >> /bsd: pppoe0: received unexpected PADO >> last message repeated 2 times This "GENERIC ERROR" is sent by your ISP. Their pppoe server process is dying for some reason, if you can reach a sysadmin or somebody useful in their technical support then they might be interested in looking into that.. >> I have this as the last line in /etc/hostname.pppoe0: >> !/bin/sh /etc/hostname.pppoe0.script pppoe0 0.0.0.1 >> >> It doesn't seem to be executed when this happens, only when I reboot the >> router. > > /etc/hostname.* is only executed once when the system starts. > > The PPP disconnect/reconnect is handled entirely by pppoe(4)--well, > sppp(4) really--in the kernel. There is no callout to the userland > available. > > It may be possible to use ifstated(8) for this. I haven't tried > that, but it's where I would start looking. > >> Is the culprit here something along the lines of not (re)configuring the >> interface with ifconfig up/down (in which case the script would run), > > Note that ifconfig down/up will not run /etc/hostname.* either. If you don't get anywhere with ifstated, you could always run a script from cron that checks "ifconfig pppoe0" for changes to the address..
Re: New tool to (quickly) check for available package upgrades
On 2020-06-17, Jeremy O'Brien wrote: >> What if a new batch of amd64/i386 files appears while one of the ongoing >> syncs run, do you restart over and hope yet another new one doesn't appear >> while that one is running? > > Is this something that actually happens? These 4 arches all take <3 days or so for a package build: 39.9G i386 46.4G amd64 34.5G aarch64 25.4G sparc64 146Gtotal Then there are files from base plus the other slower package arches, and stable packages and releases every now and again. Not particularly carefully calculated but if a mirror can't sustain an average of somewhere around 6Mb/s for fetches (bearing in mind for many mirrors these are fairly high latency links and the tuning of OpenBSD's tcp stack isn't the best in the world for coping with this) they aren't going to keep up. And of course even if they normally cope then a network problem somewhere can drop it below the speed needed to keep in sync.
Re: Sysupgrade fails with "cannot create SHA256.sig: Permission denied"
Bingo! You are right on, as /home is an nfs mount. Unmounting it allows sysupgrade to work. Thanks! Dave Raymond On 6/17/20, Florian Obser wrote: > Wild guess, /home is an nfs mount or mounted read-only? That's not going to > work unfortunately. > > > On 17 June 2020 22:23:13 CEST, "Raymond, David" > wrote: >>I am trying to upgrade a bunch of machines from 6.6 to 6.7 using >>sysupgrade and I get the message >> >>/usr/sbin/sysupgrade[136]: cannot create SHA256.sig: Permission denied >> >>These are AMD64 machines on wired internet at my university. >>Sysupgrade worked fine on a laptop and on an AMD desktop using my home >>internet provider. >> >>Any hints? Might there be some protocol that is blocked by the >>university network? When I boot bsd.rd directly (after having been >>locally verified), the upgrade works fine. >> >>Dave Raymond > > -- > Sent from a mobile device. Please excuse poor formating. > -- David J. Raymond david.raym...@nmt.edu http://kestrel.nmt.edu/~raymond
Re: New tool to (quickly) check for available package upgrades
On 2020-06-17, Marc Espie wrote: > The only way you end up with broken installations is when porters don't do > their jobs, that is they fail to bump a shared library or something like > that. They do still break in some cases: libA depends on libB someapp depends on libA, libB libB has a major bump. libA gets updated but someapp is missed due to a mirror with an incomplete update. Now someapp wants old libB, but libA wants new libB, resulting in breakage. (There are also situations where some installed packages are broken for part of a pkg_add -u run, though they do sort themselves out later - I forget the details but I think it was something to do with the timing of ldconfig runs, updates to things like glib2/pango often do this). >> Even with snapshot shearing though, having this index file could provide a >> substantial speed upgrade. Instead of having to check *all* installed >> package's header for updates, you could use the index to know the subset of >> packages that you expect to have actually changed, and only download *those* >> packages' headers. If the expected "combined" sha of a given package doesn't >> match the index's version, then the mirror is clearly out of sync and we >> could abort an update as usual. > > > The problem is the multiple RTT...! if you manage to keep one single > connection open, you get a substantial speed upgrade. > > Generating a single index is more problematic than it would seem at first o > glance. This is already a problem when pkg_add fetches the directory listing (though a smaller one because the filenames don't change as often). Firstly the contents of the mirror can change during the pkg_add run so the listing becomes invalid, that can happen on any mirror. Secondly if the mirror involves a cache (CDNs) they will often cache the directory listing as an object - the other files in the directory can be out of sync with regard to the served index page. As the index is not too big and is hit on every pkg_add run against that mirror, it's highly likely to be cached, more so than probably anything else in the directory except the quirks package. > When everything goes fine, you're happy. > > If anything is out-of-synch, you're in deep shit. Sometimes things get in a state where a mirror can't get a complete sync at all, we've had times where it's been many days / week+ on fanout->L2s so nobody gets updates. One question is what to do in that situation. When it's like that, depending on what changed, updating any packages at all can cause quite bad breakage. > This would mean having several possible modes to cope with that, we don't > have enough resources to do that. > >
Re: IKEv2 difference with 6.7
Hi Tobias, > So the error message is probably in the other side's logs but here is > a guess: 5.6 doesn't know curve25519. > > Try adding the following to your iked.conf: > > ikesa group modp2048 Many thanks!!! That was the issue and you saved me from pulling what I have left of hairs. Thank you! Daniel
Re: New tool to (quickly) check for available package upgrades
Jeremy O'Brien wrote: > > What if a new batch of amd64/i386 files appears while one of the > > ongoing syncs run, do you restart over and hope yet another new one > > doesn't appear while that one is running? > > Is this something that actually happens? Yes. Apparently you don't like reading.
Re: New tool to (quickly) check for available package upgrades
On Wed, Jun 17, 2020, at 13:45, Janne Johansson wrote: > Do think of what you call "the index file" in terms of "I check/replace some > 100+G of snapshots and packages every 24h", at which point do you replace > that single file, before, under or after none,most,all packages for your arch > are replaced? Will it be synced when the copying passes "i" for "index.txt" > in that packages folder? My gut is it doesn't matter when the file is sync'd. The file would only be used to prevent pkg_add from checking *every* installed package file *every* time. The effect would be basically the same as how my tool works, which is, it gives you a subset of installed packages to update, except with the added benefit of also detecting same-version rebuilds. pkg_add would still go through its normal recursive dependency checking, just with a (presumably) *much* shorter package list. > What happens if a sync gets cut off, restarted and/or if two syncs suddenly > run into eachother and replace files as they go? > > What if a new batch of amd64/i386 files appears while one of the ongoing > syncs run, do you restart over and hope yet another new one doesn't appear > while that one is running? Is this something that actually happens?
Re: Sysupgrade fails with "cannot create SHA256.sig: Permission denied"
Wild guess, /home is an nfs mount or mounted read-only? That's not going to work unfortunately. On 17 June 2020 22:23:13 CEST, "Raymond, David" wrote: >I am trying to upgrade a bunch of machines from 6.6 to 6.7 using >sysupgrade and I get the message > >/usr/sbin/sysupgrade[136]: cannot create SHA256.sig: Permission denied > >These are AMD64 machines on wired internet at my university. >Sysupgrade worked fine on a laptop and on an AMD desktop using my home >internet provider. > >Any hints? Might there be some protocol that is blocked by the >university network? When I boot bsd.rd directly (after having been >locally verified), the upgrade works fine. > >Dave Raymond -- Sent from a mobile device. Please excuse poor formating.
Sysupgrade fails with "cannot create SHA256.sig: Permission denied"
I am trying to upgrade a bunch of machines from 6.6 to 6.7 using sysupgrade and I get the message /usr/sbin/sysupgrade[136]: cannot create SHA256.sig: Permission denied These are AMD64 machines on wired internet at my university. Sysupgrade worked fine on a laptop and on an AMD desktop using my home internet provider. Any hints? Might there be some protocol that is blocked by the university network? When I boot bsd.rd directly (after having been locally verified), the upgrade works fine. Dave Raymond -- David J. Raymond david.raym...@nmt.edu http://kestrel.nmt.edu/~raymond
Re: New tool to (quickly) check for available package upgrades
On 2020-06-17, Jeremy O'Brien wrote:
> On Wed, Jun 17, 2020, at 13:45, Janne Johansson wrote:
>>
>> Now if someone invents a decent piece of code to use http connection
>> pooling, quic/http3/rsync or whatever to speed up getting the required info,
>> I'm sure we mirror admins would be happy to add/edit our server programs to
>> serve it.
>>
>
> Welp, I got a nice taste of what taking advantage of http-keepalives can do,
> and it is indeed quite a bit faster. Here's all I did (a bit overkill, but a
> neat proof-of-concept):
>
> # pkg_add squid
> # rcctl start squid
> # export http_server=http://localhost:3128/
> # pkg_add -u
>
> squid by default uses keepalives on both the client and server connections.
> It seems that the server closes our connections several times during the
> transfers anyway (I assume either a max request limit or keepalive timeout),
> but it's much better than starting a new connection every time. I'd be really
> interested to see what something like quic can do.
>
Or a bit lighter than squid, you can do something like this in nginx as a
reverse-proxy:
upstream live_pkgcdn {
server cdn.openbsd.org:80;
keepalive 2;
}
server {
server_name xxx;
listen 80;
location ~ /pub/OpenBSD {
proxy_pass http://live_pkgcdn;
proxy_set_header Host "cdn.openbsd.org";
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
Re: New tool to (quickly) check for available package upgrades
On Wed, Jun 17, 2020, at 13:45, Janne Johansson wrote: > > Now if someone invents a decent piece of code to use http connection pooling, > quic/http3/rsync or whatever to speed up getting the required info, I'm sure > we mirror admins would be happy to add/edit our server programs to serve it. > Welp, I got a nice taste of what taking advantage of http-keepalives can do, and it is indeed quite a bit faster. Here's all I did (a bit overkill, but a neat proof-of-concept): # pkg_add squid # rcctl start squid # export http_server=http://localhost:3128/ # pkg_add -u squid by default uses keepalives on both the client and server connections. It seems that the server closes our connections several times during the transfers anyway (I assume either a max request limit or keepalive timeout), but it's much better than starting a new connection every time. I'd be really interested to see what something like quic can do.
Re: New tool to (quickly) check for available package upgrades
Den ons 17 juni 2020 kl 17:04 skrev Marc Espie : > > > > > > The concept you need to understand is snapshot shearing. > > > > > A full package snapshot is large enough that it's hard to > guarantee that > > > > > you will have a full snapshot on a mirror at any point in time. > > > > > In fact, you will sometimes encounter a mix of two snapshots (not > that often, > > > > > recently, but still) > > > > > Hence, the decision to not have a central index for all packages, > but to > > > > > keep (and trust) the actual meta-info within the packages proper. > > > > > > > > Sorry, I guess I should've responded to this as well. Isn't snapshot > shearing going to be a problem regardless of the existence of a single > central-index? For instance, pkg_add notices a chromium update, which > requires a newer version of a dependency that hasn't been propagated to the > mirror yet. > > > Even with snapshot shearing though, having this index file could provide > a substantial speed upgrade. Instead of having to check *all* installed > package's header for updates, you could use the index to know the subset of > packages that you expect to have actually changed, and only download > *those* packages' headers. If the expected "combined" sha of a given > package doesn't match the index's version, then the mirror is clearly out > of sync and we could abort an update as usual. > > Do think of what you call "the index file" in terms of "I check/replace some 100+G of snapshots and packages every 24h", at which point do you replace that single file, before, under or after none,most,all packages for your arch are replaced? Will it be synced when the copying passes "i" for "index.txt" in that packages folder? What happens if a sync gets cut off, restarted and/or if two syncs suddenly run into eachother and replace files as they go? What if a new batch of amd64/i386 files appears while one of the ongoing syncs run, do you restart over and hope yet another new one doesn't appear while that one is running? This is the reality of snapshot package today: du -sh snapshots/packages/* 34.5G snapshots/packages/aarch64 52.4G snapshots/packages/amd64 18.4G snapshots/packages/arm 44.1G snapshots/packages/i386 24.1G snapshots/packages/mips64 10.2G snapshots/packages/mips64el 26.7G snapshots/packages/powerpc 25.4G snapshots/packages/sparc64 Whatever limitations Marcs design has, it makes it possible for us mirror admins to sync with some kind of best-effort while still giving most openbsd users the ability to have pkg_add -u leave you with a working package eco-system on a daily basis. If the cost is that it takes 40 minutes at night from crontab, then I would not trade a greppable file for losing some or a lot of the above-mentioned gotchas that the current system somehow actually handles. Now if someone invents a decent piece of code to use http connection pooling, quic/http3/rsync or whatever to speed up getting the required info, I'm sure we mirror admins would be happy to add/edit our server programs to serve it. -- May the most significant bit of your life be positive.
Re: hostname.pppoe0, !/bin/sh when reconnecting
I am in a similar situation (pppoe sessions restarts, although my IP addresses do not change), and I needed to re-add the default IPv6 route after completion of IPv6CP. Note that there are several layers involved (link, IPv4, IPv6), I would guess that for pppoe "link is up" would mean LCP succeeded, which is before you get a new IP. For this reason I put together a small ad-hoc tool that monitors the addition of a new route, which occurs just after IPv6CP succeeds. See https://marc.info/?l=openbsd-misc=158834859429490=2 You could probably modify it to do what you need, using the monitor option of route(8) to guess what event you want to trigger the execution of your script. In fact it should be simpler. If you manage to use ifstated(8) reliably, please let me know. On Wed, Jun 17, 2020 at 01:08:30PM +, Lévai, Dániel wrote: > Hi misc@! > > I'm trying to run a script whenever I get a new IP address from my ISP over > pppoe0. They disconnect me occasionally and the router reconnects then, eg.: > /bsd: pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated > /bsd: pppoe0: received unexpected PADO > last message repeated 2 times > > I have this as the last line in /etc/hostname.pppoe0: > !/bin/sh /etc/hostname.pppoe0.script pppoe0 0.0.0.1 > > It doesn't seem to be executed when this happens, only when I reboot the > router. Is the culprit here something along the lines of not (re)configuring > the interface with ifconfig up/down (in which case the script would run), > instead only getting disconnected and reconnecting? > > > Daniel >
Re: It's been awhile
Am Mi., 17. Juni 2020 um 17:06 Uhr schrieb Rasmus Liland : > Try to buy sticker_40_w for 7€ from here: > https://kd85.com/notforsale.html Note that the project will probably get no money from that site. If you want more context, search the list. Best Martin
OpenBSD on LG GRAM 14T990-G.AA75B
Hello, I would love to use OpenBSD on my LG GRAM laptop. The boot until up to a point is quite fast, but then slows down dramatically. The same behavior if installed on disk or booting from the USB Installer, every operation takes seconds to complete, the keyboard input seems ok, but after ENTER, it needs a couple of seconds to go further. Kernel relinking is very noticeable, installation (downloading the set and writing the set) is very slow. Formatting a 4G usb pendrive timed with time takes 1m05.09s real, 0m00.02s user, 0m00.25s system Screenrefresh on console is very slow, you see the screen refreshing for every new line on the screen. I tested with 6.7-RELEASE and a snapshot from 16th of June. Investigating the system, I see: one of the 4 cores is with around 97-99 % interrupt use. systat shows "ihidev1" has constantly around 250-260 interrupts Hardware: Intel Core i7-8565U (1.60GHz, Turbo up to 4.60GHz), L3 Cache 6MB, 15W 1 x 8GB (DDR4 2400MHz) 512GB M.2 (mSATA3) 35,5cm (14,0") Táctil, FHD (1920*1080) IPS LCD, GorillaGlass 5, 96% sRGB y 300 nit Intel Dual Band Wireless-AC 8265 2x2 AC (AGN support, BT Combo) Intel UHD Graphics 620 2 x USB 3.1 (tipo A) 1 x USB 3.0 (tipo C) con carga rapida y carga en apagado 1 x HDMI 1 x Toma auriculares 3.5mm 1 x Puerto alimentacion (DC-In) dmesg: OpenBSD 6.7-current (RAMDISK_CD) #264: Tue Jun 16 22:27:53 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 8328798208 (7942MB) avail mem = 8072355840 (7698MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7fab2000 (101 entries) bios0: vendor American Megatrends Inc. version "14T99F06" date 03/06/2019 bios0: LG Electronics 14T990-G.AA75B acpi0 at bios0: ACPI 6.1 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG ECDT MSDM SSDT SSDT PMCT SSDT SSDT HPET SSDT UEFI LPIT SSDT DBGP DBG2 SSDT SSDT DMAR BGRT TPM2 WSMT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1696.79 MHz, 06-8e-0b 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus -1 (RP03) acpiprt7 at acpi0: bus -1 (RP04) acpiprt8 at acpi0: bus -1 (RP05) acpiprt9 at acpi0: bus -1 (RP06) acpiprt10 at acpi0: bus -1 (RP07) acpiprt11 at acpi0: bus 1 (RP08) acpiprt12 at acpi0: bus -1 (RP09) acpiprt13 at acpi0: bus -1 (RP10) acpiprt14 at acpi0: bus -1 (RP11) acpiprt15 at acpi0: bus -1 (RP12) acpiprt16 at acpi0: bus -1 (RP13) acpiprt17 at acpi0: bus -1 (RP14) acpiprt18 at acpi0: bus -1 (RP15) acpiprt19 at acpi0: bus -1 (RP16) acpiprt20 at acpi0: bus -1 (RP17) acpiprt21 at acpi0: bus -1 (RP18) acpiprt22 at acpi0: bus -1 (RP19) acpiprt23 at acpi0: bus -1 (RP20) acpiprt24 at acpi0: bus -1 (RP21) acpiprt25 at acpi0: bus -1 (RP22) acpiprt26 at acpi0: bus -1 (RP23) acpiprt27 at acpi0: bus -1 (RP24) acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpicpu at acpi0 not configured acpitz at acpi0 not configured acpipwrres at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "LGEX0815" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT34BB" at acpi0 not configured "SYNA1D34" at acpi0 not configured "ITE8350" at acpi0 not configured "GXFP5A8B" at acpi0 not configured "PNP0C0A" at acpi0 not configured "ACPI0003" at acpi0 not configured "INT0E0C" at acpi0 not configured "PNP0C0E" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT33A1" at acpi0 not configured "PNP0C0C" at acpi0 not configured "MSFT0101" at acpi0 not configured "PNP0C0D" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT33D3" at acpi0 not configured "INT33D5" at acpi0 not configured "INT3400"
[no subject]
set-check all
Re: hostname.pppoe0, !/bin/sh when reconnecting
On 2020-06-17, Lévai, Dániel wrote: > I'm trying to run a script whenever I get a new IP address from my ISP over > pppoe0. They disconnect me occasionally and the router reconnects then, eg.: > /bsd: pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated > /bsd: pppoe0: received unexpected PADO > last message repeated 2 times > > I have this as the last line in /etc/hostname.pppoe0: > !/bin/sh /etc/hostname.pppoe0.script pppoe0 0.0.0.1 > > It doesn't seem to be executed when this happens, only when I reboot the > router. /etc/hostname.* is only executed once when the system starts. The PPP disconnect/reconnect is handled entirely by pppoe(4)--well, sppp(4) really--in the kernel. There is no callout to the userland available. It may be possible to use ifstated(8) for this. I haven't tried that, but it's where I would start looking. > Is the culprit here something along the lines of not (re)configuring the > interface with ifconfig up/down (in which case the script would run), Note that ifconfig down/up will not run /etc/hostname.* either. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: IKEv2 difference with 6.7
On 2020-06-16 12:32, Tobias Heider wrote: On Fri, Jun 12, 2020 at 09:27:18PM +0200, Tobias Heider wrote: On Fri, Jun 12, 2020 at 03:31:56PM +0200, Patrik Ragnarsson wrote: Hi, We have two OpenBSD machines acting as gateways for our network using CARP and IPsec (IKEv2). When the machines were running OpenBSD 6.6, from an IPSec client, you were able to reach the passive gateway while being connected to the active gateway. On OpenBSD 6.7, it seems this is no longer possible. The setup looks like this: - The two servers share using CARP (carp10 (carpdev trunk1)) - The two servers share 10.200.200.1 using CARP (carp20 (carpdev vlan2000)) - The active (MASTER) gateway has 10.200.200.2 (vlan2000 (parent trunk0)) - The passive (BACKUP) gateway has 10.200.200.3 (vlan2000 (parent trunk0)) iked.conf looks like this on both machines: $ cat /etc/iked.conf local_endpoint = "" roadwarrior_net = "10.100.100.0/24" ikev2 "roadwarrior-psk" ipcomp esp \ from 10.200.200.0/24 to 0.0.0.0/0 \ peer any local $local_endpoint \ srcid $local_endpoint \ psk "" \ config address $roadwarrior_net \ config netmask 255.255.255.0\ tag "$name-$id" sasyncd.conf from the active gateway: $ cat /etc/sasyncd.conf interface carp10 listen on 10.200.200.2 peer 10.200.200.3 control iked sharedkey sasyncd.conf from the passive gateway: $ cat /etc/sasyncd.conf interface carp10 listen on 10.200.200.3 peer 10.200.200.2 control iked sharedkey The PF rules on both gateways looks like this: block drop log all pass on vlan2000 proto carp all keep state (no-sync) pass on trunk1 proto carp all keep state (no-sync) pass on vlan2000 all no state pass out on trunk1 all flags S/SA pass in on trunk1 inet proto tcp from any to (trunk1:0) port = 22 flags S/SA keep state (no-sync) pass in on trunk1 inet proto udp from any to (trunk1:0) port 6:61000 keep state (no-sync) pass out on trunk1:0 all flags S/SA keep state (no-sync) pass in on trunk1 inet proto icmp all block return in on trunk1 proto udp from any to any port 33434:33534 pass out on trunk1 from (vlan2000:network) to any flags S/SA nat-to (carp10:0) pass in on trunk1 inet proto udp from any to port = 500 pass in on trunk1 inet proto udp from any to port = 4500 pass out on trunk1 inet proto udp from to any port = 500 pass out on trunk1 inet proto udp from to any port = 4500 pass in on trunk1 inet proto esp from any to pass out on trunk1 inet proto esp from to any pass in on enc0 inet from 10.100.100.0/24 to 10.200.200.0/24 flags S/SA keep state (if-bound) pass in on enc0 inet proto ipencap from any to keep state (if-bound) pass out on enc0 inet from 10.200.200.0/24 to 10.100.100.0/24 flags S/SA keep state (if-bound) pass out on enc0 inet proto ipencap from to any keep state (if-bound) On both gateways, I can see that the same flows and SAs have been created after the client have connected to the VPN. (ipsecctl -s all) A client (macOS) can reach 10.200.200.1 and 10.200.200.2 (and other servers in 10.200.200.0/24) but not 10.200.200.3: $ ping -c5 10.200.200.3 PING 10.200.200.3 (10.200.200.3): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 --- 10.200.200.3 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss I can see the ICMP echo requests reach the vlan2000 interface on the passive gateway (tcpdump -netti vlan2000 icmp) 1591718254.738903 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718255.740275 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718256.740455 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request 1591718257.743593 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: 10.100.100.173 > 10.200.200.3: icmp: echo request Running iked in the foreground (iked -dv) on the passive gateway, I can see the following when I try to ping 10.200.200.3 from the client: pfkey_process: acquire request (peer ) pfkey_process: flow in from 10.200.200.0/255.255.255.0 to 10.100.100.173/255.255.255.255 via ikev2_acquire_sa: flow wasn't found I've also tried disabling PF on the passive gateway, I still couldn't reach 10.200.200.3. Appreciate it if anyone has any ideas of what's going on. Thanks! Probably related to the following change documented in https://www.openbsd.org/faq/upgrade67.html: iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by iked(8) or isakmpd(8) was changed from "use" to "require". This means unencrypted traffic matching
[no subject]
set misc unique,selfcopy
Re: It's been awhile
On 2020-06-10 22:45 -0700, Greg Thomas wrote: > has anybody ever reprinted the large > wireframe Puffy sticker from around 15 > years ago, or still have one for > trade/sale? Dear Greg, Try to buy sticker_40_w for 7€ from here: https://kd85.com/notforsale.html Perhaps print this in white somehow: http://images.kd85.com/notforsale/blowfish-big-sticker.pdf Best, Rasmus
Re: New tool to (quickly) check for available package upgrades
On Wed, Jun 17, 2020 at 09:44:32AM -0400, Jeremy O'Brien wrote: > On Wed, Jun 17, 2020, at 08:47, Marc Espie wrote: > > On Wed, Jun 17, 2020 at 08:28:02AM -0400, Jeremy O'Brien wrote: > > > On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote: > > > > > > > > The concept you need to understand is snapshot shearing. > > > > > > > > A full package snapshot is large enough that it's hard to guarantee that > > > > you will have a full snapshot on a mirror at any point in time. > > > > > > > > In fact, you will sometimes encounter a mix of two snapshots (not that > > > > often, > > > > recently, but still) > > > > > > > > Hence, the decision to not have a central index for all packages, but to > > > > keep (and trust) the actual meta-info within the packages proper. > > > > > > > > > > Sorry, I guess I should've responded to this as well. Isn't snapshot > > > shearing going to be a problem regardless of the existence of a single > > > central-index? For instance, pkg_add notices a chromium update, which > > > requires a newer version of a dependency that hasn't been propagated to > > > the mirror yet. > > > > > That's not a big problem, it just stops before updating... at least > > your installation doesn't get hosed. > > > > Sorry if I'm being dense here. I'm just trying to understand this completely. > > In the current implementation, does pkg_add recursively verify every > dependency of a package before installing *any* of them? Or does it install > dependency updates as it finds them? Because if it's the latter, I can still > envision scenarios that break a given package, such as: Package A depends on > B and C. B is sync'd, C is not yet. pkg_add installs the update to B, then > encounters the missing C update, and bails the upgrade of A. Now you have A > installed which doesn't work with the new version of B. Is this something > that can currently happen? Nope. That's why we have shared libraries numbers. We keep the old libraries around, so packages will keep working. In the rare case where some packages have tight dependencies (see cups and cups-libs for instance), pkg_add will update both at the same time. An update is done in two steps: first extract the new package(s) to temporary files, THEN delete the old package and move the temporary files in final location. The only way you end up with broken installations is when porters don't do their jobs, that is they fail to bump a shared library or something like that. > Even with snapshot shearing though, having this index file could provide a > substantial speed upgrade. Instead of having to check *all* installed > package's header for updates, you could use the index to know the subset of > packages that you expect to have actually changed, and only download *those* > packages' headers. If the expected "combined" sha of a given package doesn't > match the index's version, then the mirror is clearly out of sync and we > could abort an update as usual. The problem is the multiple RTT...! if you manage to keep one single connection open, you get a substantial speed upgrade. Generating a single index is more problematic than it would seem at first o glance. When everything goes fine, you're happy. If anything is out-of-synch, you're in deep shit. This would mean having several possible modes to cope with that, we don't have enough resources to do that.
Re: New tool to (quickly) check for available package upgrades
On Wed, Jun 17, 2020, at 08:47, Marc Espie wrote: > On Wed, Jun 17, 2020 at 08:28:02AM -0400, Jeremy O'Brien wrote: > > On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote: > > > > > > The concept you need to understand is snapshot shearing. > > > > > > A full package snapshot is large enough that it's hard to guarantee that > > > you will have a full snapshot on a mirror at any point in time. > > > > > > In fact, you will sometimes encounter a mix of two snapshots (not that > > > often, > > > recently, but still) > > > > > > Hence, the decision to not have a central index for all packages, but to > > > keep (and trust) the actual meta-info within the packages proper. > > > > > > > Sorry, I guess I should've responded to this as well. Isn't snapshot > > shearing going to be a problem regardless of the existence of a single > > central-index? For instance, pkg_add notices a chromium update, which > > requires a newer version of a dependency that hasn't been propagated to the > > mirror yet. > > > That's not a big problem, it just stops before updating... at least > your installation doesn't get hosed. > Sorry if I'm being dense here. I'm just trying to understand this completely. In the current implementation, does pkg_add recursively verify every dependency of a package before installing *any* of them? Or does it install dependency updates as it finds them? Because if it's the latter, I can still envision scenarios that break a given package, such as: Package A depends on B and C. B is sync'd, C is not yet. pkg_add installs the update to B, then encounters the missing C update, and bails the upgrade of A. Now you have A installed which doesn't work with the new version of B. Is this something that can currently happen? I'm just trying to understand how the index causes the possibility of *more* breakage when compared to the current system. Even with snapshot shearing though, having this index file could provide a substantial speed upgrade. Instead of having to check *all* installed package's header for updates, you could use the index to know the subset of packages that you expect to have actually changed, and only download *those* packages' headers. If the expected "combined" sha of a given package doesn't match the index's version, then the mirror is clearly out of sync and we could abort an update as usual.
hostname.pppoe0, !/bin/sh when reconnecting
Hi misc@! I'm trying to run a script whenever I get a new IP address from my ISP over pppoe0. They disconnect me occasionally and the router reconnects then, eg.: /bsd: pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated /bsd: pppoe0: received unexpected PADO last message repeated 2 times I have this as the last line in /etc/hostname.pppoe0: !/bin/sh /etc/hostname.pppoe0.script pppoe0 0.0.0.1 It doesn't seem to be executed when this happens, only when I reboot the router. Is the culprit here something along the lines of not (re)configuring the interface with ifconfig up/down (in which case the script would run), instead only getting disconnected and reconnecting? Daniel
Re: New tool to (quickly) check for available package upgrades
On Wed, Jun 17, 2020 at 08:28:02AM -0400, Jeremy O'Brien wrote: > On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote: > > > > The concept you need to understand is snapshot shearing. > > > > A full package snapshot is large enough that it's hard to guarantee that > > you will have a full snapshot on a mirror at any point in time. > > > > In fact, you will sometimes encounter a mix of two snapshots (not that > > often, > > recently, but still) > > > > Hence, the decision to not have a central index for all packages, but to > > keep (and trust) the actual meta-info within the packages proper. > > > > Sorry, I guess I should've responded to this as well. Isn't snapshot shearing > going to be a problem regardless of the existence of a single central-index? > For instance, pkg_add notices a chromium update, which requires a newer > version of a dependency that hasn't been propagated to the mirror yet. > That's not a big problem, it just stops before updating... at least your installation doesn't get hosed.
Re: New tool to (quickly) check for available package upgrades
On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote: > > The concept you need to understand is snapshot shearing. > > A full package snapshot is large enough that it's hard to guarantee that > you will have a full snapshot on a mirror at any point in time. > > In fact, you will sometimes encounter a mix of two snapshots (not that often, > recently, but still) > > Hence, the decision to not have a central index for all packages, but to > keep (and trust) the actual meta-info within the packages proper. > Sorry, I guess I should've responded to this as well. Isn't snapshot shearing going to be a problem regardless of the existence of a single central-index? For instance, pkg_add notices a chromium update, which requires a newer version of a dependency that hasn't been propagated to the mirror yet.
Re: New tool to (quickly) check for available package upgrades
On Tue, Jun 16, 2020, at 21:02, Marc Espie wrote: > > The concept you need to understand is snapshot shearing. > > A full package snapshot is large enough that it's hard to guarantee that > you will have a full snapshot on a mirror at any point in time. > > In fact, you will sometimes encounter a mix of two snapshots (not that often, > recently, but still) > > Hence, the decision to not have a central index for all packages, but to > keep (and trust) the actual meta-info within the packages proper. > > The only way to avoid that would be to have specific tools for mirroring, > and to ask mirror sites to set aside twice as much room so that they > can rotate snapshots. > > Now, each package has all dependency information in the packing-list... > which allows pkg_add to know whether to update or not. We do a somewhat > strict check, we have tried to relax the check at some point in the past, > but this was causing more trouble than it was worth. > > The amount of data transmitted during pkg_add -u mostly depends on signify: > you have to grab at least a full signed block, which is slightly over 64KB. > > On most modern systems, the bandwidth is not an issue, the number of RTT > is more problematic. The way to speed pkg_add -u up would be to keep the > connection alive, which means ditching ftp(1) and switching to specific code > that talks modern http together with byte-ranges. > Thank you for this information. It was very helpful! So currently with my 433 packages installed, I need to transfer ~28MB of data and make the associated RTTs every time I want to know if I have updates. Multiply this by the number of people using OpenBSD that also check for package updates periodically (a completely unknown number to me), and it seems like there could be benefits to both the mirror providers and the users to optimize this a bit :) I'm spit-balling ideas to optimize this in my head, and I came up with something that seems simple and feasible to me. Please let me know if I'm way off-base here with my proposal, as I may be making false assumptions here. I noticed that there doesn't seem to be one "master" sha that hashes *all* of the files of a given package, but rather one sha per file that the package installs. I'm assuming that this is what causes us to have to download the +CONTENTS file from every installed package. Here is my proposal: maintain a single separate file in the mirrors (similar to the index.txt) where each line looks like this: got-0.36.tgzN9IEajlcv8snEv9clqcnsZZodggAR8VnFwCdu8I19WY= where the package name is business as usual, but the hash is actually a reduction of all the existing hashes from the +CONTENTS into a single hash (through concatenation, xor, probably doesn't matter that much; just pick something). Then, 'pkg_add -u' only downloads this single file as the source of truth for the current package state. The file can of course be signed + compressed as well. Does this idea seem to have any basis in reality?
Re: IKEv2 difference with 6.7
On Tue, Jun 16, 2020 at 08:20:59PM -0400, Daniel Ouellet wrote: > Hi, > > > What I see is that the initial message is received but ignored, so this > > side here probably runs into some kind of error. > > To find out what exactly causes this, a more verbose log would help. > > You could manually start iked with -dvv and share the log for an > > incoming IKE_SA_INIT request from 72.83.103.147:500 (best without the > > grep because the following lines may contain the actual error messages). > > gateway# iked -dvv > set_policy_auth_method: using rsa for peer > /etc/iked/pubkeys/ipv4/66.63.5.250 > set_policy: found pubkey for /etc/iked/pubkeys/ipv4/66.63.5.250 > ikev2 "VPN" active tunnel esp inet from 72.83.103.147 to 66.63.5.250 > local 72.83.103.147 peer 66.63.5.250 ikesa enc > aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1 auth > hmac-sha2-256,hmac-sha1 group > curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 > childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 > esn,noesn lifetime 10800 bytes 536870912 rsa > set_policy_auth_method: using rsa for peer > /etc/iked/pubkeys/ipv4/66.63.5.250 > set_policy: found pubkey for /etc/iked/pubkeys/ipv4/66.63.5.250 > ikev2 "Flow" active tunnel esp inet from 66.63.44.66 to 0.0.0.0/0 from > 66.63.44.90 to 0.0.0.0/0 from 66.63.44.96/28 to 0.0.0.0/0 from > 66.63.44.67 to 66.63.0.0/18 from 66.63.44.79 to 45.7.36.0/22 from > 66.63.44.79 to 185.40.64.0/22 from 66.63.44.79 to 43.229.64.0/22 from > 66.63.44.79 to 162.249.72.0/21 from 66.63.44.79 to 104.160.128.0/19 from > 66.63.44.79 to 192.64.168.0/21 from 66.63.44.79 to 103.240.224.0/22 from > 66.63.44.65 to 66.63.5.245 from 66.63.44.65 to 66.63.5.250 local any > peer 66.63.5.250 ikesa enc aes-256,aes-192,aes-128,3des prf > hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group > curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 > childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 > esn,noesn lifetime 10800 bytes 536870912 rsa > /etc/iked.conf: loaded 2 configuration rules > ca_privkey_serialize: type RSA_KEY length 1191 > ca_pubkey_serialize: type RSA_KEY length 270 > ca_privkey_to_method: type RSA_KEY method RSA_SIG > ca_getkey: received private key type RSA_KEY length 1191 > ca_getkey: received public key type RSA_KEY length 270 > ca_dispatch_parent: config reset > config_getpolicy: received policy > ca_reload: local cert type RSA_KEY > config_getocsp: ocsp_url none > config_getpolicy: received policy > ikev2_dispatch_cert: updated local CERTREQ type RSA_KEY length 0 > config_getpfkey: received pfkey fd 3 > config_getcompile: compilation done > config_getsocket: received socket fd 4 > config_getsocket: received socket fd 5 > config_getsocket: received socket fd 6 > config_getsocket: received socket fd 7 > config_getmobike: mobike > config_getfragmentation: no fragmentation > config_getnattport: nattport 4500 > ikev2_init_ike_sa: initiating "VPN" > ikev2_policy2id: srcid FQDN/gateway.ouellet.us length 22 > ikev2_add_proposals: length 156 > ikev2_next_payload: length 160 nextpayload KE > ikev2_next_payload: length 40 nextpayload NONCE > ikev2_next_payload: length 36 nextpayload NOTIFY > ikev2_nat_detection: local source 0xe6b00a86abde210d 0x > 72.83.103.147:500 > ikev2_next_payload: length 28 nextpayload NOTIFY > ikev2_nat_detection: local destination 0xe6b00a86abde210d > 0x 66.63.5.250:500 > ikev2_next_payload: length 28 nextpayload NOTIFY > ikev2_next_payload: length 14 nextpayload NONE > ikev2_pld_parse: header ispi 0xe6b00a86abde210d rspi 0x > nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 > length 334 response 0 > ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 160 > ikev2_pld_sa: more 0 reserved 0 length 156 proposal #1 protoid IKE > spisize 0 xforms 17 spi 0 > ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC > ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4 > ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC > ikev2_pld_attr: attribute type KEY_LENGTH length 192 total 4 > ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC > ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4 > ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES > ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256 > ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 > ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128 > ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id CURVE25519 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_521 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_384 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_256 > ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_4096 >
OpenBSD 6.7 Virtio disk not recognized during install
Hello! I have been running OpenBSD 6.6 on three KVM VPS for months and was able to install without issues all three times. Now however, when trying to install either OpenBSD 6.6 or 6.7 on another VPS, the virtual disk is not recognized by the installer. Running `sysctl hw.disknames` just gives me cd0 and rd0, but no sd0 device. I do know for sure that the device exists though because there is a running Debian 10 installation on it that I can choose to boot from. Looking through my `dmesg`, I see these lines containing "not configured": ``` acpicpu at acpi0 not configured "ACPI0006" at acpi0 not configured "PNP0A03" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0007" at acpi0 not configured "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured"Intel 82801AA AC97" rev 0x01 at pci0 dev 4 function 0 not configured virtio1: no matching child driver; not configured uhid at uhidev0 not configured``` When I do `dmesg | grep "not configured"` on my other running OpenBSD VPS installations, I only get a third of these "* not configured" messages and the installation worked fine for the most part. The KVM- related settings that the VPS hosting company provides are identical between my different installations, so I don't know what could be the cause of this. In case it helps, I will just list the different settings they provide: ACPI (checkbox) APIC (checkbox) Activate Virtio (checkbox) Virtual Network Card (Intel E1000 or Realtek 8139 or Virtio) All three checkboxes are enabled and Intel E1000 selected as default network card. I would very much appreciate any hints on what may be causing my issue and how to work around it. I apologize if part of my problem looks obvious to you, I simply don't have the experience and my searches couldn't help me figure it out. Thank you in advance!
Re: EFI boot on Dell PowerEdge R610
On 2020-05-29 17:01, Johan Hattne wrote:
On May 28, 2020, at 20:38, YASUOKA Masahiko wrote:
Hi,
On Thu, 28 May 2020 09:46:23 -0700
Johan Hattne wrote:
On May 28, 2020, at 06:42, Nick Holland wrote:
On 2020-05-28 05:15, Johan Hattne wrote:
On 2020-05-28 00:56, Johan Hattne wrote:
On 2020-05-28 00:43, YASUOKA Masahiko wrote:
Hi,
On Wed, 27 May 2020 22:32:58 -0700
Johan Hattne wrote:
I've been trying to boot the 6.7 installation media from USB via EFI
on a Dell PowerEdge R610. The screen goes blank and then the thing
resets (so no kernel output or anything). I can boot the same stick
via BIOS.
I've been searching for a while without results. Firmware settings
look sane to me. Is this something anybody has seen before? Any hint
on where I could even start looking for problems would be very much
appreciated!
I'd like you to try the diff attached with the following message.
https://marc.info/?l=openbsd-tech=158280719421562=2
Thanks a lot, Yasuoka! Is there any chance you could provide a compiled
BOOTX64.EFI? I don't have an amd64 build environment at the moment.
After a bit of off-list discussion, Yasuoka concluded that above diff
won't help here. To clarify the issue: there is no output at all before
the machine resets, in particular there is no prompt from the EFI boot
program.
// Johan
Have you tried firmware updates?
That machine is many years old, I'd not be the slightest bit surprised if
the firmware was buggy and didn't boot much of anything in EFI mode other
than Windows and maybe Linux.
Thanks, Nick! The firmware is up to date. And the machine does boot e.g.
NetBSD through EFI.
Probing serial devices is one of the differences from NetBSD efiboot.
diff --git a/sys/arch/amd64/stand/efiboot/conf.c
b/sys/arch/amd64/stand/efiboot/conf.c
index 3eb745d808d..8d385a4f198 100644
--- a/sys/arch/amd64/stand/efiboot/conf.c
+++ b/sys/arch/amd64/stand/efiboot/conf.c
@@ -89,7 +89,7 @@ int ndevs = nitems(devsw);
struct consdev constab[] = {
{ efi_cons_probe, efi_cons_init, efi_cons_getc, efi_cons_putc },
- { efi_com_probe, efi_com_init, efi_com_getc, efi_com_putc },
+ //{ efi_com_probe, efi_com_init, efi_com_getc, efi_com_putc },
{ NULL }
};
struct consdev *cn_tab = constab;
I put a compiled binary on https://yasuoka.net/~yasuoka/BOOTX64.EFI
Thanks a lot, Yasuoka! The binary you compiled still exhibits the same problem
(it immediately resets the machine).
Another difference to NetBSD's efiboot is the way the heap is allocated:
OpenBSD does AllocateMaxAddress, whereas NetBSD does AllocateAnyPages.
Turns out the EFI on this machine fails with AllocateMaxAddress (so I
guess Nick was right). For what it's worth, the patch below allowed me
to eventually boot the kernel through EFI.
Index: Makefile.common
===
RCS file: /cvs/src/sys/arch/amd64/stand/efi64/Makefile.common,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile.common
--- Makefile.common 5 Mar 2020 16:36:30 - 1.5
+++ Makefile.common 17 Jun 2020 04:20:16 -
@@ -7,8 +7,6 @@ EFIDIR= ${S}/stand/efi
OBJCOPY?= objcopy
OBJDUMP?= objdump
-EFI_HEAP_LIMIT=0xc0
-
LDFLAGS+= -nostdlib -T${.CURDIR}/../${LDSCRIPT} -Bsymbolic -shared
COPTS+=-DEFIBOOT -DFWRANDOM -DNEEDS_HEAP_H -I${.CURDIR}/..
@@ -69,7 +67,7 @@ ${PROG}: ${PROG.so}
.include
CFLAGS+= -Wno-pointer-sign
CPPFLAGS+= -DSMALL -DSLOW -DNOBYFOUR -D__INTERNAL_LIBSA_CREAD
-CPPFLAGS+= -DHEAP_LIMIT=${EFI_HEAP_LIMIT} -DHIBERNATE
+CPPFLAGS+= -DHIBERNATE
${PROG.so}: ${OBJS}
${LD} ${LDFLAGS} -o ${.TARGET}.tmp ${OBJS} ${LDADD}
Index: efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efi64/efiboot.c,v
retrieving revision 1.2
diff -u -p -r1.2 efiboot.c
--- efiboot.c 11 May 2019 19:14:41 - 1.2
+++ efiboot.c 17 Jun 2020 04:20:16 -
@@ -275,8 +275,7 @@ efi_heap_init(void)
{
EFI_STATUS status;
- heap = HEAP_LIMIT;
- status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
EfiLoaderData,
+ status = EFI_CALL(BS->AllocatePages, AllocateAnyPages,
EfiLoaderData,
EFI_SIZE_TO_PAGES(heapsiz), );
if (status != EFI_SUCCESS)
panic("BS->AllocatePages()");
Thanks again for all the help!
// Cheers; Johan
