Re: Proper way to set PATH environment with SSH non-interactive command
On Sun, Feb 04, 2024 at 08:39:27AM -0700, Andy Bradford wrote: > Hello, > > When using SSH to invoke a remote command via the syntax: > > ssh remotehost remotecommand > > The $HOME/.profile is not used and there appears to be a very minimal > environment setup. The PATH does not include any components that have > been added in .profile. > > This is probably what step 5 in the LOGIN PROCESS is all about: > > http://man.openbsd.org/sshd#LOGIN_PROCESS > > According to the man page for sshd(8): > > After this, the client either requests an interactive shell or execution > of a non-interactive command, which sshd will execute via the user's > shell using its -c option. > > So in the case where an interactive shell is chosen, the PATH will be > set according to .profile, but in the case where a non-interactive > command is chosen, a shell is invoked with -c. So I have a script in > $HOME/bin (which is defined in PATH normally in .profile) which I can > run when logged in interactively: > > $ helloworld > HELLO WORLD > > But when I try to run it as a non-interactive command, it fails: > > $ ssh localhost helloworld > amb@localhost's password: > ksh: helloworld: not found > > Obviously, one way to do this is by calling the command like: > > $ ssh localhost PATH=\$HOME/bin:\$PATH helloworld > amb@localhost's password: > HELLO WORLD > > This works and can be seen in ssh -v output as: > > debug1: Sending command: PATH=$HOME/bin:$PATH helloworld > > But is there a file that I can modify that will cause the shell proper > to load some kind of environment setup also for non-interactive shells > started with -c? > > sshd does have PermitUserEnvironment and that works, however, it's not > enabled by default and it's not a function of the SHELL proper. From a > user perspective, it seems that the user only has control of the > environment when using interactive shells and there is no way to control > the environment for non-interactive shells (from the remote side). Are > these the only 2 options (PermitUserEnvironment or prepend the command > with the environment) or is there something I'm missing from ksh(1)? See ssh_config(5): SetEnv Directly specify one or more environment variables and their contents to be sent to the server. Similarly to SendEnv, with the exception of the TERM variable, the server must be prepared to accept the environment variable.
Re: AAAA entry for openbsd.org
On Sun, Oct 22, 2023 at 10:29:08PM +0200, Armin Jenewein wrote: > Hi, > > as I'm almost 100% sure adding IPv6 connectivity to the openbsd.org host > wouldn't introduce side-effects for IPv4 users: is there any reason > openbsd.org still has no entry at the end of 2023? Why do you need it? > > This has likely be discussed in the past and OpenBSD does a good job for > me on both servers and desktops running IPv6, but with IPv4 addresses > becoming more and more expensive, I would love to have the option to > deploy OpenBSD on IPv6-only hosts, even IPv6 only with NAT64 was no > problem here - the installer defaults to do auto configuration for v4 > only and by default doesn't even auto-configure v6, which surprised me, > too, though. Nothing prevents you from installing ipv6-only hosts, just use mirrors as installurl. Four out of six CDN mirrors listed on https://www.openbsd.org/ftp.html have ipv6 addresses with appropriate DNS entries. -Kastus
Re: OT: Github requiring 2FA auth, meaning
On Thu, Aug 31, 2023 at 08:59:46AM +0900, lain. wrote: > On 2023年08月30日 19:35, the silly Daniele B. claimed to have said: > > Finally I activated a couple of 2FA options on my Github account > > Imagine entrusting Microsoft with your source code lol. You may make as many jokes about Microsoft as you want, but please remember that Microsoft Corporation has been gold or silver donor of the OpenBSD Foundation for the past 7 years [1] 1. http://www.openbsdfoundation.org/contributors.html
Re: Ryzen 9 (7x000) users: do you experience hangs?
On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: > Not really. But. > > I have an APU2 which runs two VMs that do practically nothing, > although the box itself is used actively. The VMs consistently, and > without warning, hang in a way which matches the description "nothing > new can be execed" although I recall being able to log in on the > console. I noticed shortly after I installed the VMs in around May > but I haven't got very far diagnosing it because it's a low priority. > However there is a common denominator: AMD > > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 > 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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > cpu0: 512KB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > > Times two. > > As you say the existing processes seem to work fine right up until > sshd is nearly (but not quite?) ready to fork: > > . > . > . > debug1: SSH2_MSG_EXT_INFO received > debug1: kex_input_ext_info: > server-sig-algs= > debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> > debug1: SSH2_MSG_SERVICE_ACCEPT received > > Ordinarily it would next attempt authentication. Does sshd fork and > drop privileges to do that? > > I don't know if that could help or even if it's related, but it can > be reproduced with confidence. I can poke the box or its VMs any > way that could shake some data loose. > > Matthew > Is AMD errata referenced from https://inks.tedunangst.com/l/4996 any relevant? (errata #1474 in https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf) -Kastus
Re: program compiled with clang from base runs 4 times slower than compiled with gcc-11.2.0p6 from ports
On Sun, Jun 04, 2023 at 05:31:34PM -0600, Todd C. Miller wrote: > Take a look at the clang-local man page, it documents the difference > between the OpenBSD base clang and stock llvm. You can try disabling > some of the options to find which one (or combination of options) > is causing the slowdown. Thanks for the pointer, that man page is really what I missed. > > I would try building with -fno-stack-protector and -mno-retpoline > first to see if either of those are the cause. Neither of them made any difference: henryk$ make clean rm -f enchive src/enchive.o src/chacha.o src/curve25519-donna.o src/sha256.o enchive-cli.c henryk$ make CFLAGS='-ansi -pedantic -Wall -Wextra -O3 -g3 -fno-stack-protector -mno-retpoline' cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-stack-protector -mno-retpoline -o src/enchive.o src/enchive.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-stack-protector -mno-retpoline -o src/chacha.o src/chacha.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-stack-protector -mno-retpoline -o src/curve25519-donna.o src/curve25519-donna.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-stack-protector -mno-retpoline -o src/sha256.o src/sha256.c cc -o enchive src/enchive.o src/chacha.o src/curve25519-donna.o src/sha256.o enchive.c:209 (src/enchive.c:209)(src/enchive.o:(load_seckey)): warning: sprintf() is often misused, please use snprintf() henryk$ time enchive a /dev/null 0m55.07s real 0m49.69s user 0m05.47s system Next I tried -fno-pie: henryk$ make clean rm -f enchive src/enchive.o src/chacha.o src/curve25519-donna.o src/sha256.o enchive-cli.c henryk$ make CFLAGS='-ansi -pedantic -Wall -Wextra -O3 -g3 -fno-pie' LDFLAGS='-nopie' cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-pie -o src/enchive.o src/enchive.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-pie -o src/chacha.o src/chacha.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-pie -o src/curve25519-donna.o src/curve25519-donna.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-pie -o src/sha256.o src/sha256.c cc -nopie -o enchive src/enchive.o src/chacha.o src/curve25519-donna.o src/sha256.o enchive.c:209 (src/enchive.c:209)(src/enchive.o:(load_seckey)): warning: sprintf() is often misused, please use snprintf() henryk$ time enchive a /dev/null 0m54.65s real 0m49.21s user 0m04.54s system Still no cigar... Next I tried -fno-fixup-gadgets, and that made a radical difference: henryk$ make clean rm -f enchive src/enchive.o src/chacha.o src/curve25519-donna.o src/sha256.o enchive-cli.c henryk$ make CFLAGS='-ansi -pedantic -Wall -Wextra -O3 -g3 -fno-fixup-gadgets' cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-fixup-gadgets -o src/enchive.o src/enchive.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-fixup-gadgets -o src/chacha.o src/chacha.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-fixup-gadgets -o src/curve25519-donna.o src/curve25519-donna.c cc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -fno-fixup-gadgets -o src/sha256.o src/sha256.c cc -o enchive src/enchive.o src/chacha.o src/curve25519-donna.o src/sha256.o enchive.c:209 (src/enchive.c:209)(src/enchive.o:(load_seckey)): warning: sprintf() is often misused, please use snprintf() henryk$ time enchive a /dev/null 0m16.63s real 0m14.31s user 0m02.36s system 14.31s is on par with 12.85s of gcc-compiled binary: henryk$ make clean rm -f enchive src/enchive.o src/chacha.o src/curve25519-donna.o src/sha256.o enchive-cli.c henryk$ make CC=egcc egcc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -o src/enchive.o src/enchive.c egcc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -o src/chacha.o src/chacha.c egcc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -o src/curve25519-donna.o src/curve25519-donna.c egcc -c -ansi -pedantic -Wall -Wextra -O3 -g3 -o src/sha256.o src/sha256.c egcc -o enchive src/enchive.o src/chacha.o src/curve25519-donna.o src/sha256.o enchive.c:209 (src/enchive.c:209)(src/enchive.o:(agent_addr)): warning: sprintf() is often misused, please use snprintf() henryk$ time enchive a /dev/null 0m14.36s real 0m12.85s user 0m00.39s system So to me it seems that fixup-gadgets is the culprit. Thanks, Kastus
program compiled with clang from base runs 4 times slower than compiled with gcc-11.2.0p6 from ports
I am puzzled with performance of a C program compiled with clang from base. The program in question is enchive [1] Most of the time I use it on macos or linux, but recently I had to install it on openbsd. I compiled it with default clang from base, and the first thing that struck me was long time it took to extract archive. The same operation takes less than 2 seconds on macos and 12 seconds on openbsd. I asked the author on github [2], and he mostly pointed at the compiler. Following his advise, I did my own testing. I compiled enchive with default cc (which is clang 13) make clean make I created a test zero file: $ dd if=/dev/zero of=zero bs=1M count=512 512+0 records in 512+0 records out 536870912 bytes transferred in 1.393 secs (385381071 bytes/sec) Then I archived the zero file: $ time enchive a /dev/null 0m55.08s real 0m49.55s user 0m03.38s system Next, I installed gcc-11.2.0 from ports and recompiled enchive: make clean make CC=egcc Then I ran the same test: $ time enchive a /dev/null 0m14.37s real 0m12.91s user 0m00.35s system The program uses only libc: $ ldd enchive enchive: StartEnd Type Open Ref GrpRef Name 0f5c9cdbe000 0f5c9ce0e000 exe 10 0 enchive 0f5ed3724000 0f5ed381a000 rlib 01 0 /usr/lib/libc.so.97.0 0f5f8523a000 0f5f8523a000 ld.so 01 0 /usr/libexec/ld.so Why gcc produces a binary that runs 4 times faster than binary compiled with clang? Am I missing any compiler flags for clang? Makefile defines CFLAGS = -ansi -pedantic -Wall -Wextra -O3 -g3 This is all on 7.3-release system. Thanks for any pointers to the gaps in my knowledge of compilers. -Kastus 1. https://github.com/skeeto/enchive 2. https://github.com/skeeto/enchive/issues/31
Re: vi - inability to search backwards for ?
On Fri, May 12, 2023 at 11:11:23PM -0700, Jeremy Mates wrote: > A search for /\/ is okay; this discards the \ and searches for "/" > > A search for ?\? is not okay; this discards the \ and searches for "?" > which is an invalid regular expression, "RE error: repetition-operator > operand invalid". > > A problematic bare leading ? on a backwards search can be escaped by > the following, though I'm not sure if that's an ideal fix. Thoughts? Have you tried using ?[\?] in extended mode? It works for me.
Re: Asymmetric file encryption… use gnupg from ports or is there something else?
On Tue, May 09, 2023 at 09:21:03AM +1000, Stuart Longland wrote: > Hi all, > > Silly question… is there a tool for encrypting files with asymmetric > keys on OpenBSD? I'm aware of GnuPG in ports, and I'm fine with using > that, however I'm curious to know what other options there are out > there, especially options that are part of the base system. You may want to take a look at enchive (http://nullprogram.com/blog/2017/03/12/) It's not in base, but it's self-contained and tiny.
Re: Home folder default permission
On Thu, Mar 23, 2023 at 06:08:05AM +0100, Jasper Valentijn wrote: > Op di 21 mrt. 2023 20:33 schreef Denis Mikhlevich : > > > > > By hand I change the permision to 750 after creation a new user. > > Could I change the default behavior without manual change the permission? > > > > https://man.openbsd.org/login.conf.5 login class does not define permissions of the user home directory. I don't know how change default 755 in useradd(8). On the other hand, adduser(8) copies permissions of the directory specified with -dotdir option when creating user home directory. So, you may make a copy of /etc/skel, change permission of the new directory to 750 and then use it in -dotdir option.
Re: Possible typo in fw_update
On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> substitution ${name:#word} is not documented in the manual page for ksh yet
> its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> a typo, a patch is provided to remove the colon. If it is not a typo, could
> someone explain what this syntax does?
>
> Is this was a typo however, and this parameter substitution is not
> officially supported, why did ksh not complain?
I would guess syntax ${name:#word} is akin to other colon substitutions
${name:-word}, ${name:=word}, ${name:+word}, ${name:?word} although
it is not documented.
${name:%word} works too (and is not documented either)
And actually man page says that colon can be omitted from :- := :+ :?
which hints that # and % are treated as substitutions with omitted colon.
I wonder if we would rather update man page of ksh.
-Kastus
Re: ksh: documented substitution behavior contradicts actual behavior
On Sun, Oct 16, 2022 at 11:48:35AM +0100, cho...@jtan.com wrote:
> Kastus Shchuka writes:
> > On Sat, Oct 15, 2022 at 11:42:17PM -0300, Lucas de Sena wrote:
> > > Hi,
> > >
> > > After trying to split a string into fields delimited with colons and
> > > spaces, I found this bug in how ksh(1) does substitution. The actual
> > > behavior contradicts what other shells like bash and mksh do and also
> > > contradicts its own manual.
> > >
> > > Running the following on other shells (say, bash) prints "/foo/bar/".
> > > This command splits the string " foo : bar " into two fields: "foo"
> > > and "bar", considering colon and space as delimiters.
> > >
> > > echo " foo : bar " | {
> > > IFS=": "
> > > read -r a b
> > > printf -- "/%s/%s/\n" "$a" "$b"
> > > }
> > >
> > > However, running the same command in OpenBSD ksh(1) (or sh(1)) splits
> > > the string into "foo" and ": bar".
> >
> > This is because the last parameter (b) is a concatenation of two fields.
> > Parsing
> > is done properly if you add c to the read command:
> >
> > + echo foo : bar
> > + IFS=:
> > + read -r a b c
> > + printf -- /%s/%s/%s/\n foo bar
> > /foo//bar/
> >
> >
> > >
> > > The manual ksh(1) provides the following, similar example:
> > >
> > > > Example: If IFS is set to “:”, and VAR is set to
> > > > “A:B::D”, the substitution for $VAR
> > > > results in four fields: ‘A’, ‘B’, ‘’ (an empty field), and ‘D’.
> > > > Note that if the IFS parameter is set to the NULL string, no field
> > > > splitting is done; if the parameter is unset, the default value of
> > > > space, tab, and newline is used.
> > >
> > > Let's try it:
> > >
> > > echo " A : B::D" | {
> > > IFS=" :"
> > > read -r arg1 arg2 arg3 arg4
> > > printf -- '1st: "%s"\n' "$arg1"
> > > printf -- '2nd: "%s"\n' "$arg2"
> > > printf -- '3rd: "%s"\n' "$arg3"
> > > printf -- '4th: "%s"\n' "$arg4"
> > > }
> > >
> > > bash(1) splits the line into the following fields:
> > >
> > > 1st: "A"
> > > 2nd: "B"
> > > 3rd: ""
> > > 4th: "D"
> > >
> > > This is actually the expected output, as described in the manual.
> > >
> > > However, running the same command in OpenBSD ksh, prints this:
> > >
> > > 1st: "A"
> > > 2nd: ""
> > > 3rd: "B"
> > > 4th: ":D"
> > >
> > > A completelly different thing.
> > > The same occurs with OpenBSD sh(1).
> >
> > What you observe is the result of the next paragraph in the man page
> > after the example you quoted:
> >
> > Also, note that the field splitting applies only to the immediate
> > result
> > of the substitution. Using the previous example, the substitution for
> > $VAR:E results in the fields: `A', `B', `', and `D:E', not `A', `B',
> > `',
> > `D', and `E'. This behavior is POSIX compliant, but incompatible with
> > some other shell implementations which do field splitting on the word
> > which contained the substitution or use IFS as a general whitespace
> > delimiter.
>
> Actually you need to look further into the manual since the word
> splitting is performed not by parameter substitution but by read:
>
> Reads a line of input from the standard input, separates the line
> into fields using the IFS parameter (see Substitution above), and
> assigns each field to the specified parameters.
>
> This is why adding an extra variable to read above (and here) makes
> it capture the remainder of the string.
>
> For example:
>
> $ alias dump="perl -MData::Dumper -e 'print Dumper @ARGV'"
> $ dump a b c
> $VAR1 = 'a';
> $VAR2 = 'b';
> $VAR3 = 'c';
>
> $ ( IFS=:; dump $PATH )
> $VAR1 = '/bin';
> $VAR2 = '/sbin';
> $VAR3 = '/usr/bin';
> $VAR4 = '/usr/sbin';
> $VAR5 = '/usr/X11R6/bin';
> $VAR6 = '/usr/local/bin';
>
Re: ksh: documented substitution behavior contradicts actual behavior
On Sat, Oct 15, 2022 at 11:42:17PM -0300, Lucas de Sena wrote:
> Hi,
>
> After trying to split a string into fields delimited with colons and
> spaces, I found this bug in how ksh(1) does substitution. The actual
> behavior contradicts what other shells like bash and mksh do and also
> contradicts its own manual.
>
> Running the following on other shells (say, bash) prints "/foo/bar/".
> This command splits the string " foo : bar " into two fields: "foo"
> and "bar", considering colon and space as delimiters.
>
> echo " foo : bar " | {
> IFS=": "
> read -r a b
> printf -- "/%s/%s/\n" "$a" "$b"
> }
>
> However, running the same command in OpenBSD ksh(1) (or sh(1)) splits
> the string into "foo" and ": bar".
This is because the last parameter (b) is a concatenation of two fields.
Parsing
is done properly if you add c to the read command:
+ echo foo : bar
+ IFS=:
+ read -r a b c
+ printf -- /%s/%s/%s/\n foo bar
/foo//bar/
>
> The manual ksh(1) provides the following, similar example:
>
> > Example: If IFS is set to “:”, and VAR is set to
> > “A:B::D”, the substitution for $VAR
> > results in four fields: ‘A’, ‘B’, ‘’ (an empty field), and ‘D’.
> > Note that if the IFS parameter is set to the NULL string, no field
> > splitting is done; if the parameter is unset, the default value of
> > space, tab, and newline is used.
>
> Let's try it:
>
> echo " A : B::D" | {
> IFS=" :"
> read -r arg1 arg2 arg3 arg4
> printf -- '1st: "%s"\n' "$arg1"
> printf -- '2nd: "%s"\n' "$arg2"
> printf -- '3rd: "%s"\n' "$arg3"
> printf -- '4th: "%s"\n' "$arg4"
> }
>
> bash(1) splits the line into the following fields:
>
> 1st: "A"
> 2nd: "B"
> 3rd: ""
> 4th: "D"
>
> This is actually the expected output, as described in the manual.
>
> However, running the same command in OpenBSD ksh, prints this:
>
> 1st: "A"
> 2nd: ""
> 3rd: "B"
> 4th: ":D"
>
> A completelly different thing.
> The same occurs with OpenBSD sh(1).
What you observe is the result of the next paragraph in the man page
after the example you quoted:
Also, note that the field splitting applies only to the immediate result
of the substitution. Using the previous example, the substitution for
$VAR:E results in the fields: `A', `B', `', and `D:E', not `A', `B', `',
`D', and `E'. This behavior is POSIX compliant, but incompatible with
some other shell implementations which do field splitting on the word
which contained the substitution or use IFS as a general whitespace
delimiter.
>
> I could not understand how OpenBSD does the spliting, but the way it
> does is clearly a bug: it does not only contradicts its own manual,
> but also differs from other implementations.
I do not see contradictions in the man page. It does say that behavior
is incompatible with other shells.
>
> Thank you,
> Lucas de Sena.
>
Re: My home router, running OpenBSD 7.1, won't boot headlessly
On Sun, Sep 25, 2022 at 08:12:51AM -0400, Z. Charles Dziura wrote: > Hello everybody, > > A couple of months ago, I decided to build my own custom router for my home > network by following this[1] guide. The machine itself works quite well, > except for one glaring flaw: it won't boot up properly unless I have a > monitor plugged into one of the display ports. Of course, this makes things > a bit difficult to debug. > > I'm curious if anyone else has encountered such a bug in the past; and if > so, how did you fix it? Below are the relevant specs of my router. > > Specs: > - Motherboard: ASUS PRIME H610I-PLUS D4-CSM > - CPU: Intel Celeron G6900 > - RAM: Patriot Viper Steel DDR4 2x8G > - SSD: WD Green 240GB > - NIC: Intel I340-T4 > Seems you need a dummy HDMI plug, similar to what was described in this thread: https://marc.info/?l=openbsd-misc=165192618008143=2
Re: serial console works only if system is booted from it
On Sun, Jul 24, 2022 at 11:35:18PM -0700, Kastus Shchuka wrote: > On Mon, Jul 25, 2022 at 01:38:41AM -0400, Hugo Villeneuve wrote: > > > > I wrote this ages ago: > > > > https://marc.info/?l=openbsd-misc=139089795907395=2 > > > > it may apply to you. > > Thank you for the link. Unfortunately, adding "local" to tty00 made no > difference. > Apparently, restarting getty on tty00 was not enough. After reboot, I got login prompt on tty00 line. So, "local" really fixes it. I guess without "local" getty waits for the carrier which never comes on a null modem. > The other percularity that I noticed, getty on tty00 stays in > ttyopn wait state, while other terminals where I can see login prompt, > are in ttyin state. Please see pid 11907 below: > > jetway$ pgrep -lf getty > 11907 /usr/libexec/getty std.9600 tty00 > 21180 /usr/libexec/getty std.9600 ttyC0 > 18041 /usr/libexec/getty std.9600 ttyC5 > 70940 /usr/libexec/getty std.9600 ttyC3 > 62965 /usr/libexec/getty std.9600 ttyC2 > 65765 /usr/libexec/getty std.9600 ttyC1 > > > and top shows > > load averages: 0.02, 0.01, 0.00 > jetway.tprfct.net 23:31:10 > 39 processes: 38 idle, 1 on processor > up 3:46 > CPU0 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% > idle > CPU1 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% > idle > CPU2 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% > idle > CPU3 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% > idle > Memory: Real: 34M/1320M act/tot Free: 6520M Cache: 711M Swap: 0K/8349M > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND > 21180 root 30 512K 1500K idle ttyin 0:03 0.00% getty > 70940 root 30 516K 1492K idle ttyin 0:00 0.00% getty > 62965 root 30 508K 1476K idle ttyin 0:00 0.00% getty > 65765 root 30 508K 1472K idle ttyin 0:00 0.00% getty > 18041 root 30 508K 1476K idle ttyin 0:00 0.00% getty > 11907 root 30 508K 1496K idle ttyopn0:00 0.00% getty > > I wonder if getty cannot open tty00 for some reason. > Now getty looks like it should: jetway$ pgrep -lf getty 33943 /usr/libexec/getty std.9600 tty00 31285 /usr/libexec/getty std.9600 ttyC5 69646 /usr/libexec/getty std.9600 ttyC3 36033 /usr/libexec/getty std.9600 ttyC2 90820 /usr/libexec/getty std.9600 ttyC1 13016 /usr/libexec/getty std.9600 ttyC0 PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 33943 root 30 508K 1520K idle ttyin 0:07 0.00% getty 90820 root 30 512K 1512K idle ttyin 0:00 0.00% getty 36033 root 30 508K 1492K idle ttyin 0:00 0.00% getty 69646 root 30 512K 1512K idle ttyin 0:00 0.00% getty 13016 root 30 504K 1500K idle ttyin 0:00 0.00% getty 31285 root 30 508K 1500K idle ttyin 0:00 0.00% getty Thanks a lot!
Re: serial console works only if system is booted from it
On Mon, Jul 25, 2022 at 01:38:41AM -0400, Hugo Villeneuve wrote: > > I wrote this ages ago: > > https://marc.info/?l=openbsd-misc=139089795907395=2 > > it may apply to you. Thank you for the link. Unfortunately, adding "local" to tty00 made no difference. The other percularity that I noticed, getty on tty00 stays in ttyopn wait state, while other terminals where I can see login prompt, are in ttyin state. Please see pid 11907 below: jetway$ pgrep -lf getty 11907 /usr/libexec/getty std.9600 tty00 21180 /usr/libexec/getty std.9600 ttyC0 18041 /usr/libexec/getty std.9600 ttyC5 70940 /usr/libexec/getty std.9600 ttyC3 62965 /usr/libexec/getty std.9600 ttyC2 65765 /usr/libexec/getty std.9600 ttyC1 and top shows load averages: 0.02, 0.01, 0.00 jetway.tprfct.net 23:31:10 39 processes: 38 idle, 1 on processor up 3:46 CPU0 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU1 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU2 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle CPU3 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle Memory: Real: 34M/1320M act/tot Free: 6520M Cache: 711M Swap: 0K/8349M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 21180 root 30 512K 1500K idle ttyin 0:03 0.00% getty 70940 root 30 516K 1492K idle ttyin 0:00 0.00% getty 62965 root 30 508K 1476K idle ttyin 0:00 0.00% getty 65765 root 30 508K 1472K idle ttyin 0:00 0.00% getty 18041 root 30 508K 1476K idle ttyin 0:00 0.00% getty 11907 root 30 508K 1496K idle ttyopn0:00 0.00% getty I wonder if getty cannot open tty00 for some reason. Thanks, Kastus > > > > On Sun, Jul 24, 2022 at 08:37:06PM -0700, Kastus Shchuka wrote: > > Hi, > > > > I tried to set up serial console on my system in addition to the > > regular monitor/keyboard, and I am running into a problem. > > > > I want to have both local monitor and serial console. > > > > This is what I have tried. > > > > The system is booted with console on the attached monitor/keyboard. > > > > I change the line in /etc/ttys for tty00 to enable getty on tty00: > > > > tty00 "/usr/libexec/getty std.9600" vt220 on secure > > > > I reloaded init after the change by sending SIGHUP to it. I can see getty > > process running for tty00. Terminal emulator connected to the serial port > > shows nothing. > > > > Now I reboot the system and type "set tty com0" at the boot prompt > > on the locally attached keyboard/monitor. The boot process continues > > on the serial port and I see all output on the terminal emulator. > > After boot finishes, I have login prompt both on the serial port > > and on the monitor/keyboard. Login works from both. > > > > It appears that serial console works for me only if I booted the system > > from it. I am not able to activate serial console if the system was > > not booted from it. > > > > Is this expected behavior or am I doing something wrong here? > > > > I can see a difference in dmesg between boot on serial console > > and regular monitor/keyboard. > > > > Boot on serial has > > > > com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > > com0: console > > com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo > > com2 at acpi0 UAR3 addr 0x3e8/0x8 irq 10: ns16550a, 16 byte fifo > > com3 at acpi0 UAR4 addr 0x2e8/0x8 irq 11: ns16550a, 16 byte fifo > > > > Boot on monitor/keyboard has > > > > com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > > com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo > > com2 at acpi0 UAR3 addr 0x3e8/0x8 irq 10: ns16550a, 16 byte fifo > > com3 at acpi0 UAR4 addr 0x2e8/0x8 irq 11: ns16550a, 16 byte fifo > > > > > > Full dmesg is below: > > > > OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8486543360 (8093MB) > > avail mem = 8212041728 (7831MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec120 (16 entries) > > bios0: vendor American Megatrends Inc. version "BASII
serial console works only if system is booted from it
Hi, I tried to set up serial console on my system in addition to the regular monitor/keyboard, and I am running into a problem. I want to have both local monitor and serial console. This is what I have tried. The system is booted with console on the attached monitor/keyboard. I change the line in /etc/ttys for tty00 to enable getty on tty00: tty00 "/usr/libexec/getty std.9600" vt220 on secure I reloaded init after the change by sending SIGHUP to it. I can see getty process running for tty00. Terminal emulator connected to the serial port shows nothing. Now I reboot the system and type "set tty com0" at the boot prompt on the locally attached keyboard/monitor. The boot process continues on the serial port and I see all output on the terminal emulator. After boot finishes, I have login prompt both on the serial port and on the monitor/keyboard. Login works from both. It appears that serial console works for me only if I booted the system from it. I am not able to activate serial console if the system was not booted from it. Is this expected behavior or am I doing something wrong here? I can see a difference in dmesg between boot on serial console and regular monitor/keyboard. Boot on serial has com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com0: console com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo com2 at acpi0 UAR3 addr 0x3e8/0x8 irq 10: ns16550a, 16 byte fifo com3 at acpi0 UAR4 addr 0x2e8/0x8 irq 11: ns16550a, 16 byte fifo Boot on monitor/keyboard has com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo com2 at acpi0 UAR3 addr 0x3e8/0x8 irq 10: ns16550a, 16 byte fifo com3 at acpi0 UAR4 addr 0x2e8/0x8 irq 11: ns16550a, 16 byte fifo Full dmesg is below: OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8486543360 (8093MB) avail mem = 8212041728 (7831MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec120 (16 entries) bios0: vendor American Megatrends Inc. version "BASIIA06" date 03/23/2021 bios0: NF792I NF792I acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT CSRT acpi0: wakeup devices XHC1(S4) HDEF(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) BRC1(S0) 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) Celeron(R) CPU N3160 @ 1.60GHz, 1600.43 MHz, 06-4c-04 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 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 80MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1600.02 MHz, 06-4c-04 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1600.02 MHz, 06-4c-04 cpu2: 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1600.02 MHz, 06-4c-04 cpu3: 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpiprt0 at
Re: setting up an email server in a recent version of OpenBSD
On Mon, Sep 27, 2021 at 08:42:30PM +0300, Teno Deuter wrote: > Dear group, > > anyone could point to some recent online resources how to setup an email > server in OpenBSD? What I found from Google was a bit thin. So I'm > wondering if I was missing something out there. Did https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/ come up in your search?
Re: vi: count occurrences of a substring
On Sat, Sep 04, 2021 at 05:00:29PM +0100, ropers wrote: > However, that's as inaccurate as, or potentially even more inaccurate > than your version, at least as far as vim-ilarity is concerned. My > awk-ward incantation matches vim's :%s/abc//gn precisely. Not sure if this is less "awk-ward": :%!perl -0777 -ne 'print s/abc//g;' and then undo the change to the buffer - Kastus
Re: snapshot boot fails with error "entry point at 0x1001000"
On Sun, Jul 05, 2020 at 09:32:47PM -0700, Kastus Shchuka wrote:
> On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
> > Kastus Shchuka wrote:
> > “I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able
> > to boot it.
> > Boot stops at the line
> >
> > entry point at 0x1001000
> >
> > If I try bsd.rd kernel, it boots just fine. After this failure with
> > snapshot I
> > installed 6.7-release, and it boots without any issues.”
> >
> >
> > I've experienced something similar, including the sensitivity to kernel
> > size. As best I can observe, the EFI bootloader is being handed a different
> > block of RAM than where the kernel is actually loaded (which is at a fixed
> > address defined in boot.c). Which block of memory gets returned, and
> > whether boot fails, seems to be dependent on the particular UEFI
> > ROM/chipset. In my case, debugging over serial, I observe a page fault
> > while the kernel is still being loaded into RAM.
> > “Are there any other solutions than compiling a custom smaller kernel?”
> >
> >
> > Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it
> > for me:
> > --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> > +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> > @@ -303,9 +303,9 @@ efi_memprobe(void)
> > bios_memmap_t *bm;
> > EFI_STATUS status;
> > EFI_PHYSICAL_ADDRESS
> > -addr = 0x1000ULL; /* Below 256MB */
> > +addr = 0x100;
> >
> > - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
> > EfiLoaderData,
> > + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
> > EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
> > if (status != EFI_SUCCESS)
> > panic("BS->AllocatePages()");
> > Let me know if that helps. I can't guarantee that this is actually what is
> > causing your issue but it worked for me.
>
> I tried this patch and was able to boot kernel from snapshot 2007-07-03 with
> recompiled BOOTX64.EFI.
> It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.
>
> I wonder what would it take for the patch to be accepted in -current?
>
As Mike Larkin pointed in
https://marc.info/?l=openbsd-misc=160377179930502=2, "mach mem"
output may shed some light on the problem.
So, for the ASRock J4105M motherboard, the output is this:
>> OpenBSD/amd64 BOOTX64 3.50
boot> mach mem
Region 0: type 1 at 0x0 for 248KB
Region 1: type 2 at 0x3e000 for 8KB
Region 2: type 1 at 0x4 for 376KB
Region 3: type 2 at 0x9e000 for 392KB
Region 4: type 1 at 0x10 for 261120KB
Region 5: type 1 at 0x12151000 for 1454584KB
Region 6: type 2 at 0x6adcf000 for 41480KB
Region 7: type 1 at 0x6d651000 for 324KB
Region 8: type 4 at 0x6d6a2000 for 160KB
Region 9: type 2 at 0x6d6ca000 for 3916KB
Region 10: type 1 at 0x6da9d000 for 10388KB
Region 11: type 2 at 0x6e4c2000 for 688KB
Region 12: type 1 at 0x6e56e000 for 6728KB
Region 13: type 1 at 0x1 for 6291456KB
Region 14: type 2 at 0x1000 for 34116KB
Region 15: type 2 at 0x6ec0 for 282624KB
Region 16: type 2 at 0xd000 for 16384KB
Region 17: type 2 at 0xd3709000 for 4KB
Region 18: type 2 at 0xe000 for 262144KB
Region 19: type 2 at 0xfe042000 for 12KB
Region 20: type 2 at 0xfe90 for 12KB
Region 21: type 2 at 0xfec0 for 4KB
Region 22: type 2 at 0xfed01000 for 4KB
Region 23: type 2 at 0xfee0 for 4KB
Region 24: type 2 at 0xff00 for 16384KB
Low ram: 1024KB High ram: 295236KB
With the patch, kernel is loaded in region 14 and it fits there.
Without patch, memory is allocated down from 0x1, and large kernel
overlaps with something and fails to boot.
There were reports on -misc that the patch does not help on some systems.
I wonder what can be tried differently to make it work on all systems?
Thanks,
Kastus
Re: 6.8 release crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
On Mon, Oct 26, 2020 at 07:48:32PM -0700, Alfred Morgan wrote: > I just wanted to report 6.8 release is having the same issue as > https://marc.info/?l=openbsd-misc=160224393101534=2 > except I have a CHUWI HeroBox Windows 10 Mini PC,Intel Gemini-Lake N4100 > Quad-Core Processor,8GB DDR4 256GB SSD,Expandable 2TB 2.5 Inch HDD,1TB SSD > with 2.4GHz/5GHz Dual WiFi 1000Mbps/BT4.2 > https://www.amazon.com/gp/product/B082VZP76P > > On a 6.7 release I did syspatch and then a sysupgrade and got the entry > point at: 0x1001000 error trying to boot after the upgrade was successful. 6.8 kernel is larger and does not play well with EFI on your system. Can you try to patch efiboot.c as described in https://marc.info/?l=openbsd-misc=159401011632149=2 and see if it works on your system? It did help me on ASRock J4105M, but there are reports on the list that it does not work on some other systems, like Lenovo V130. Thanks, Kastus
Re: OpenSMTP - Wrong user for Dovecot LMTP
On Sun, Oct 18, 2020 at 08:55:16PM -0400, Aisha Tammy wrote: > Hi, > > I just upgraded to 6.8 and the upgrade process has been super cool and > simple :) > > Unfortunately I seem to have hit some weird issue in OpenSMTPD where it has > stopped > delivering the mail using Dovecots LMTP due to sending as wrong user. > > osmtpd tries to send the mail as *_smtpd* even when configured to send as a > different user *excision* Could it be this change: https://marc.info/?t=15878902902=1=2 ?
Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
On Fri, Oct 09, 2020 at 03:37:37PM +0400, Michel von Behr wrote: > Hi all, > I'm trying to run snapshot on a Chuwi Lapbook laptop (Intel Gemini Lake), > but I get stuck at boot time with the message "entry point at: 0x1001000". > Based on previous discussions [1] it looks like the problem is with > BOOTX64.EFI > For now I'll be running -stable, but I would like to follow -current. Is > there a way to run -current with an old version of BOOTX64.EFI for example? > (i.e., the only alternatives I'm seeing is either 1) compiling a GENERIC > kernel with the older version of BOOTX64.EFI src, or 2) (try to) compile a > custom/smaller kernel to avoid the issue). > > [1] https://marc.info/?l=openbsd-misc=159147446008114=2 > > Any pointing to the right direction is welcome. I had the same problem with EFI on ASRock J4105M system, essentially failing to boot a kernel larger than certain size. I posted my solution here: https://marc.info/?l=openbsd-misc=159401011632149=2 I guess the patch requires more testing before asking for it to be committed. Thanks, Kastus
Re: smtpd returns 'TempFail' and 'No route to destination' when using localhost as source behind NAT
On Sat, Aug 15, 2020 at 07:49:28AM +, Martin wrote:
> It is worth to mention smtpd works absolutely fine for outgoing/incoming mail
> if local machine has static IP address when:
> ...
> table sources {1.2.3.4} equivalent to
> table helonames {1.2.3.4 = smtp.domain.tld}
> ...
>
> And yes, I have exactly the same action in /etc/mail/smtpd.conf
>
> ...
> table sources {127.0.0.1}
> table helonames {1.2.3.4 = smtp.domain.tld}
Your helonames table does not have an entry for 127.0.0.1, that is why it
cannot find helo string for it.
Re: snapshot boot fails with error "entry point at 0x1001000"
On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
> Kastus Shchuka wrote:
> “I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to
> boot it.
> Boot stops at the line
>
> entry point at 0x1001000
>
> If I try bsd.rd kernel, it boots just fine. After this failure with snapshot
> I
> installed 6.7-release, and it boots without any issues.”
>
>
> I've experienced something similar, including the sensitivity to kernel size.
> As best I can observe, the EFI bootloader is being handed a different block
> of RAM than where the kernel is actually loaded (which is at a fixed address
> defined in boot.c). Which block of memory gets returned, and whether boot
> fails, seems to be dependent on the particular UEFI ROM/chipset. In my case,
> debugging over serial, I observe a page fault while the kernel is still being
> loaded into RAM.
> “Are there any other solutions than compiling a custom smaller kernel?”
>
>
> Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it
> for me:
> --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> @@ -303,9 +303,9 @@ efi_memprobe(void)
> bios_memmap_t *bm;
> EFI_STATUS status;
> EFI_PHYSICAL_ADDRESS
> -addr = 0x1000ULL; /* Below 256MB */
> +addr = 0x100;
>
> - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
> EfiLoaderData,
> + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
> EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
> if (status != EFI_SUCCESS)
> panic("BS->AllocatePages()");
> Let me know if that helps. I can't guarantee that this is actually what is
> causing your issue but it worked for me.
I tried this patch and was able to boot kernel from snapshot 2007-07-03 with
recompiled BOOTX64.EFI.
It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.
I wonder what would it take for the patch to be accepted in -current?
Thanks,
Kastus
snapshot boot fails with error "entry point at 0x1001000"
Hi, I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to boot it. Boot stops at the line entry point at 0x1001000 If I try bsd.rd kernel, it boots just fine. After this failure with snapshot I installed 6.7-release, and it boots without any issues. I suspect I am hitting the same problem as in https://marc.info/?l=openbsd-misc=159325874410286=2. Disk is partitioned with GPT, and system boots through EFI. There were other reports about BOOTX86.EFI supposedely causing this problem, as in https://marc.info/?l=openbsd-misc=159147446008114=2. I tried to boot snapshot kernel on 6.7-release system to make use of older BOOTX86.EFI, but it stopped at the same line "entry point at 0x1001000" I could be wrong, but I doubt that efi is the problem. It seems that kernel size is. If kernel is smaller than 20MB, it boots. If it is larger, it doesn't. Are there any other solutions than compiling a custom smaller kernel? I cannot produce dmesg from snapshot, but here is dmesg from 6.7-release: OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8201129984 (7821MB) avail mem = 7939952640 (7572MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6d946000 (18 entries) bios0: vendor American Megatrends Inc. version "P1.30" date 05/04/2018 bios0: ASRock J4105M acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BGRT WDAT WSMT acpi0: wakeup devices SIO1(S3) PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1496.53 MHz, 06-7a-01 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.86 MHz, 06-7a-01 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.87 MHz, 06-7a-01 cpu2: 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 4MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.86 MHz, 06-7a-01 cpu3: 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 4MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP03) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus 3 (RP05) acpiprt4 at acpi0: bus 4 (RP06) acpiec0 at acpi0: not present acpipwrres0 at acpi0: DRST
