Unable to build OpenBSD 6.6 libc on beaglebone black
When trying to build libc with the latest security patch applied on my beaglebone black, I was met with the following error: cc -O2 -pipe -g -Wimplicit -I/usr/src/lib/libc/include -I/usr/src/lib/libc/hidden -D__LIBC__ -Werror-implicit-function-declaration -include namespace.h -Werror=deprecated-declarations -DAPIWARN -DYP -I/usr/src/lib/libc/yp -DSOFTFLOAT_FOR_GCC -I/usr/src/lib/libc/softfloat -I/usr/src/lib/libc -I/usr/src/lib/libc/gdtoa -I/usr/src/lib/libc/arch/arm/gdtoa -DINFNAN_CHECK -DMULTIPLE_THREADS -DNO_FENV_H -DUSE_LOCALE -I/usr/src/lib/libc -I/usr/src/lib/libc/citrus -DRESOLVSORT -DFLOATING_POINT -DPRINTF_WIDE_CHAR -DSCANF_WIDE_CHAR -DFUTEX -MD -MP -c /usr/src/lib/libc/db/btree/bt_close.c -o bt_close.o In file included from /usr/src/lib/libc/db/btree/bt_close.c:37: /usr/src/lib/libc/hidden/stdlib.h:68:14: error: use of undeclared identifier 'calloc_conceal' PROTO_NORMAL(calloc_conceal); ^ /usr/src/lib/libc/hidden/stdlib.h:109:14: error: use of undeclared identifier 'malloc_conceal' PROTO_NORMAL(malloc_conceal); ^ 2 errors generated. *** Error 1 in /usr/src/lib/libc (:39 'bt_close.o': @cc -O2 -pipe -g -Wimplicit -I/usr/src/lib/libc/include -I/usr/src/lib/libc/...) I unpacked a copy of the 6.6 src.tar.gz that I had downloaded a while ago in /usr/src, and then updated to the stable branch with: cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs up -Pd -rOPENBSD_6_6 I then ran: cd lib/libc make obj make and encountered this error. Clearly I've done something wrong, could someone please point me to my mistake? Thanks, Jacob
Re: Patch for sysupgrade of a disc constrained net4801
> *** /usr/sbin/sysupgrade Sat Oct 12 18:52:33 2019 > --- sysupgrade Fri Oct 25 02:02:11 2019 > *** > *** 1,6 > #!/bin/ksh > # > ! # $OpenBSD: sysupgrade.sh,v 1.25 2019/09/28 17:30:07 ajacoutot Exp $ > # > # Copyright (c) 1997-2015 Todd Miller, Theo de Raadt, Ken Westerback > # Copyright (c) 2015 Robert Peichaer > --- 1,6 > #!/bin/ksh > # > ! # $OpenBSD$ > # > # Copyright (c) 1997-2015 Todd Miller, Theo de Raadt, Ken Westerback > # Copyright (c) 2015 Robert Peichaer > *** > *** 158,163 > --- 158,172 > # INSTALL.*, bsd*, *.tgz > SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \ > -e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256) > + + echo "===" > + echo "$SETS" > + echo "---" > + SETS="INSTALL.i386\nbsd\nbsd.rd\nbase66.tgz\nman66.tgz" > + echo "---" > + echo "$SETS" > + echo "===" > + return #Comment out this line once you are satisfied with the set > selection. > OLD_FILES=$(ls) > OLD_FILES=$(rmel SHA256 $OLD_FILES) For small resource-constrained systems this is probably a good idea, but this patch will only work for an upgrade to 6.6. It would be a bit more future-proof to just modify the call to sed directly to get bsd*, base*, and man*: --- sysupgrade.sh Fri Oct 18 10:38:51 2019 +++ sysupgrade-base.sh Fri Oct 18 10:48:13 2019 @@ -157,7 +157,7 @@ # INSTALL.*, bsd*, *.tgz SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \ --e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256) +-e '/^INSTALL\./p;/^bsd/p;/^base/p;/^man/p' SHA256) OLD_FILES=$(ls) OLD_FILES=$(rmel SHA256 $OLD_FILES) Hope this helps, Jacob
Re: auto_upgrade.conf et al man pages or documentation?
On 10/17/19 9:49 PM, Theo de Raadt wrote: > Shane Lazarus wrote: > >> I was interested in what it would do by default, and in how I could alter >> those defaults if I did not like them. >> >> The sysupgrade man page informed me of a configuration file. > > Your complaint directly referenced the configuration filename > /auto_upgrade.conf > > That filename is not mentioned in the sysupgrade man page, as you just > claimed. > > In fact, it is mentioned nowhere. Your following complaints are that > it is mentioned nowhere. Quoting directly from https://man.openbsd.org/sysupgrade : "FILES /auto_upgrade.conf Response file for the ramdisk kernel." Shane, you appear to be on the right track. From what I can tell it seems to be the same thing as install.conf in autoinstall. According to autoinstall(8): "The response file is a line-oriented ASCII text file. The format of each line is: question = answer question is an installer question (not including the question mark) or a non-ambiguous part of it, consisting of whitespace separated words. answer is the answer to the question. Passwords may be in plaintext, encrypted with encrypt(1), or set to ‘*’ (13 '*'s) to disable password logins, only permitting alternative access methods (for example, ssh(1) keys)." Therefore it seems that to ensure that the sets you do not want installed are not installed you can use the "Set name(s)" question. For example to just install the base system and no other sets, hypothetically you would put: "Set name(s) = -all base66.tgz bsd.mp bsd" in /auto_upgrade.conf However, looking at the source code this file is created by sysupgrade: "cat <<__EOT >/auto_upgrade.conf Location of sets = disk Pathname to the sets = /home/_sysupgrade/ Set name(s) = done Directory does not contain SHA256.sig. Continue without verification = yes __EOT" Thus you can't really change this unless you want to edit the script directly. The easiest method to install a limited number of sets would be to use sysupgrade -n and then remove the sets you do not want from /home/_sysupgrade before rebooting. Hope this helps, Jacob
Re: Correct pexp variable for a shell script
On 6/29/19 8:46 AM, Antoine Jacoutot wrote: > On Sat, Jun 22, 2019 at 02:14:12PM -0400, Jacob Adams wrote: >> On 6/22/19 12:43 PM, Antoine Jacoutot wrote: >>> On Sat, Jun 22, 2019 at 10:42:39AM -0400, Jacob Adams wrote: >>>> On 6/22/19 7:05 AM, Antoine Jacoutot wrote: >>>>> On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote: >>>>>> I've got a shell script I'd like to run as a system service. Due to the >>>>>> 16 character limitation on pgrep and the -x flag that rc.subr passes to >>>>>> check by default, I can't get check or stop to work correctly. The >>>>>> problem is that the process name looks like "/bin/sh >>>>>> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match >>>>>> when -x is used. >>>>>> >>>>>> My rc.d script currently looks like this: >>>>>> >>>>> Hi. >>>>> >>>>> That should not be an issue, that's why pexp is used for. >>>>> But without more context it's hard to know how to help you. >>>>> >>>>> I can match sh scripts without issue: >>>>> $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session" >>>>> 77289 >>>>> >>>>> Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"? >>>>> We don't run into the 16 chars limitation when using -xf >>>> Here's what I was seeing that led me to that conclusion: >>>> >>>> rukey$ ps aux | grep authmail >>>> root 51889 0.0 0.1 724 568 p0- Ip Fri12AM 0:00.01 >>>> /bin/sh /usr/local/bin/authmail >>>> jacob 25510 0.0 0.2 272 892 p0 S+p 10:36AM 0:00.01 grep >>>> authmail >>>> rukey$ pgrep -f /bin/sh /usr/local/bin/authmail >>>> 51889 >>>> rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail >>>> >>>> >>>> However, I didn't think to quote it. that seems to fix it: >>>> >>>> rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail" >>>> 51889 >>>> >>>> It appears that rc.subr uses quotes, but: >>>> >>>> rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail" >>>> 51889 >>>> rukey# rcctl check authmail >>>> authmail(failed) >>>> rukey# >>>> >>>> Any idea what could be going wrong here? >>> Dunno, run rcctl in debug mode. >> >> rukey# ps ux | grep authmail >> root 93772 0.0 0.2 272 892 p0 S+p 2:10PM 0:00.01 grep >> authmail >> rukey# rcctl -d start authmail >> doing _rc_parse_conf >> doing _rc_quirks >> authmail_flags empty, using default >< >> doing _rc_parse_conf /var/run/rc.d/authmail >> doing _rc_quirks >> doing rc_check >> authmail >> doing rc_start >> doing _rc_wait start >> doing rc_check >> doing rc_check > Can you share you /var/run/rc.d/authmail file please. That seems to be the problem daemon_class=daemon daemon_flags= daemon_rtable=0 daemon_timeout=30 daemon_user=root pexp=/usr/local/bin/authmail.sh Deleting that file and restarting authmail fixed the issue, allowing me to start authmail successfully Thanks for your help! Jacob
Re: Correct pexp variable for a shell script
On 6/22/19 12:43 PM, Antoine Jacoutot wrote: > On Sat, Jun 22, 2019 at 10:42:39AM -0400, Jacob Adams wrote: >> On 6/22/19 7:05 AM, Antoine Jacoutot wrote: >>> On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote: >>>> I've got a shell script I'd like to run as a system service. Due to the >>>> 16 character limitation on pgrep and the -x flag that rc.subr passes to >>>> check by default, I can't get check or stop to work correctly. The >>>> problem is that the process name looks like "/bin/sh >>>> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match >>>> when -x is used. >>>> >>>> My rc.d script currently looks like this: >>>> >>> Hi. >>> >>> That should not be an issue, that's why pexp is used for. >>> But without more context it's hard to know how to help you. >>> >>> I can match sh scripts without issue: >>> $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session" >>> 77289 >>> >>> Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"? >>> We don't run into the 16 chars limitation when using -xf >> >> Here's what I was seeing that led me to that conclusion: >> >> rukey$ ps aux | grep authmail >> root 51889 0.0 0.1 724 568 p0- Ip Fri12AM 0:00.01 >> /bin/sh /usr/local/bin/authmail >> jacob 25510 0.0 0.2 272 892 p0 S+p 10:36AM 0:00.01 grep >> authmail >> rukey$ pgrep -f /bin/sh /usr/local/bin/authmail >> 51889 >> rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail >> >> >> However, I didn't think to quote it. that seems to fix it: >> >> rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail" >> 51889 >> >> It appears that rc.subr uses quotes, but: >> >> rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail" >> 51889 >> rukey# rcctl check authmail >> authmail(failed) >> rukey# >> >> Any idea what could be going wrong here? > Dunno, run rcctl in debug mode. rukey# ps ux | grep authmail root 93772 0.0 0.2 272 892 p0 S+p 2:10PM 0:00.01 grep authmail rukey# rcctl -d start authmail doing _rc_parse_conf doing _rc_quirks authmail_flags empty, using default >< doing _rc_parse_conf /var/run/rc.d/authmail doing _rc_quirks doing rc_check authmail doing rc_start doing _rc_wait start doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check doing rc_check Alarm clock /etc/rc.d/authmail: kill: 73440: No such process doing _rc_write_runfile (ok) rukey# rcctl -d check authmail doing _rc_parse_conf doing _rc_quirks authmail_flags empty, using default >< doing _rc_parse_conf /var/run/rc.d/authmail doing _rc_quirks authmail doing rc_check (failed) rukey# ps | grep authmail 17035 p0 Ip 0:00.01 /bin/sh /usr/local/bin/authmail 25162 p0 R+p 0:00.01 grep authmail rukey#
Re: Correct pexp variable for a shell script
On 6/22/19 7:05 AM, Antoine Jacoutot wrote: > On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote: >> I've got a shell script I'd like to run as a system service. Due to the >> 16 character limitation on pgrep and the -x flag that rc.subr passes to >> check by default, I can't get check or stop to work correctly. The >> problem is that the process name looks like "/bin/sh >> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match >> when -x is used. >> >> My rc.d script currently looks like this: >> > Hi. > > That should not be an issue, that's why pexp is used for. > But without more context it's hard to know how to help you. > > I can match sh scripts without issue: > $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session" > 77289 > > Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"? > We don't run into the 16 chars limitation when using -xf Here's what I was seeing that led me to that conclusion: rukey$ ps aux | grep authmail root 51889 0.0 0.1 724 568 p0- Ip Fri12AM 0:00.01 /bin/sh /usr/local/bin/authmail jacob 25510 0.0 0.2 272 892 p0 S+p 10:36AM 0:00.01 grep authmail rukey$ pgrep -f /bin/sh /usr/local/bin/authmail 51889 rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail However, I didn't think to quote it. that seems to fix it: rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail" 51889 It appears that rc.subr uses quotes, but: rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail" 51889 rukey# rcctl check authmail authmail(failed) rukey# Any idea what could be going wrong here? Thanks, Jacob
Correct pexp variable for a shell script
I've got a shell script I'd like to run as a system service. Due to the
16 character limitation on pgrep and the -x flag that rc.subr passes to
check by default, I can't get check or stop to work correctly. The
problem is that the process name looks like "/bin/sh
/usr/local/bin/script.sh" which, even if passed to pgrep, won't match
when -x is used.
My rc.d script currently looks like this:
#!/bin/ksh
AUTHMAIL="/usr/local/bin/authmail"
daemon=${AUTHMAIL}
daemon_timeout=1
. /etc/rc.d/rc.subr
rc_reload=NO
rc_bg=YES
pexp="/bin/sh ${AUTHMAIL}"
rc_cmd $1
Do I have any other options, or do I just need to override rc_check to
remove -x?
