Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On Sat, Oct 09, 2021 at 09:46:24AM +0200, FreeBSD User wrote: > On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: > Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > appliance failed very early in the build process of the 13-STABLE > sources as shown below. 13-STABLE is most recent, since the sources are > fetched every time the build process is triggered. > > The framework for the build process is nanoBSD, the same error occurs > when building poudriere's jail based upon 13-STABLE from scratch via > the FreeBSD native build framework. > > "Cross building" of 13-STABLE on a CURRENT platform worked in most > cases and most time, hopefully this hickup is a solveable problem and > it would be nice to have this fixed. > > What is the reason for the linker fail? > > Are there any recommenadtions how to "cross build" 13-STABLE on a > 14-CURRENT platform in case the approach of mine s not a desireable on? > > Thanks in advance, > > Oliver > > [...] > > sh > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > -s -o root -g wheel -m 555 compile_et > /pool/home/ohartmann/Projects/router/router/apu2 > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: undefined > symbol: setupterm > >>> referenced by Process.cpp > >>> Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > >>> in archive > >>> /pool/home/ohartmann/Projects/router/router/apu2c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a > Anyone else still hitting this? I am. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
NFSv4 client: Doesn't see files/protocol error 10020
I have a -CURRENT box that I upgraded yesterday & today, and it no longer can read NFS mounts from my TrueNAS 12.0-U6 server. It mounts, but any access garners: nfsv4 client/server protocol prob err=10020 nfsv4 client/server protocol prob err=10020 the fstab entries: freenas.lerctr.org:/mnt/data/TBH/vault/backup/TBHnfs rw,nfsv4,minorversion=1 0 0 freenas.lerctr.org:/mnt/data/BACULA /vault/backup/BACULA nfs rw,nfsv4,minorversion=1 0 0 Ideas? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: [HEADSUP] the default root shell is now /bin/sh
On Wed, Oct 20, 2021 at 12:02:23PM -0300, Renato Botelho wrote: > On 20/10/21 04:40, Baptiste Daroussin wrote: > > Hello, > > > > Following up on the proposal which happened last month, /bin/sh is now the > > default shell for the root user. > > > > As claimed during that proposal, I have so far no intention to change > > anything > > more: I won't remove or modify the 'toor' user, neither modify the root > > gecos. > > > > By popular demand on the thread about the proposal the following bindings > > have > > been set by default: > > > > navigation through history "ala" csh via the up and down arrow > > navigation on the command line via ctrl+arrow (left/right) jumps from words > > to > > words > > An alias on fc -l named "history", so the history command to exist. > > > > etcupdate will silently switch to sh(1) the first time, for people who > > wants to > > keep root on csh, they will have to run: > > $ chsh -s csh > > > > The next upgrade will keep that setting > > Will sh config be upgraded to reflect all recent changes as well or we need > to do it manually? For root yes, for users you will have to do it manually Best regards, Bapt
Re: [HEADSUP] the default root shell is now /bin/sh
On 20/10/21 04:40, Baptiste Daroussin wrote: Hello, Following up on the proposal which happened last month, /bin/sh is now the default shell for the root user. As claimed during that proposal, I have so far no intention to change anything more: I won't remove or modify the 'toor' user, neither modify the root gecos. By popular demand on the thread about the proposal the following bindings have been set by default: navigation through history "ala" csh via the up and down arrow navigation on the command line via ctrl+arrow (left/right) jumps from words to words An alias on fc -l named "history", so the history command to exist. etcupdate will silently switch to sh(1) the first time, for people who wants to keep root on csh, they will have to run: $ chsh -s csh The next upgrade will keep that setting Will sh config be upgraded to reflect all recent changes as well or we need to do it manually? -- Renato Botelho
Re: poudriere jail with todays current: Install fail?
On 10/20/2021 7:11 am, Dimitry Andric wrote: On 20 Oct 2021, at 13:51, Larry Rosenman wrote: On 10/20/2021 6:41 am, Dimitry Andric wrote: On 20 Oct 2021, at 03:50, Larry Rosenman wrote: Anyone else having poudriere jail -u or jail -c fail in the installworld? log: https://www.lerctr.org/~ler/jail-install.log The actual error is pretty far from the bottom of that log: --- realinstall_subdir_usr.sbin/lpr/chkprintcap --- install: chkprintcap: No such file or directory So probably usr.sbin/lpr wasn't built during buildworld? Do you have any special settings in e.g. src.conf? -Dimitry I had WITHOUT_LPR=yes in make.conf. But I've had that in there for a LONG time, and this is the first time poudriere has complained. So, I commented that out for now, but I'd like to know why the sudden change. I haven't been able to find how poudriere jail -c passes any src.conf settings to its installworld phase. It does seem to have a bunch of stuff that goes through contortions to put a src.conf into the jail directory, but only during *buildworld*, not during installworld. It could very well be that this use case was broken due to a recent poudriere update. I don't see anything in the recent log of -CURRENT hat indicates some sort of flipping of the MK_LPR default, it has been "yes" for ages now. Whatever the case may be, for some reason you now run into a common problem with the disconnect between buildworld and installworld: if you run these under even slightly different environments, there can be unexpected consequences... :) -Dimitry Thanks, Dimitry! -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 signature.asc Description: OpenPGP digital signature
Re: poudriere jail with todays current: Install fail?
On 20 Oct 2021, at 13:51, Larry Rosenman wrote: > > On 10/20/2021 6:41 am, Dimitry Andric wrote: >> On 20 Oct 2021, at 03:50, Larry Rosenman wrote: >>> Anyone else having poudriere jail -u or jail -c fail in the installworld? >>> log: >>> https://www.lerctr.org/~ler/jail-install.log >> The actual error is pretty far from the bottom of that log: >> --- realinstall_subdir_usr.sbin/lpr/chkprintcap --- >> install: chkprintcap: No such file or directory >> So probably usr.sbin/lpr wasn't built during buildworld? Do you have any >> special settings in e.g. src.conf? >> -Dimitry > > I had > WITHOUT_LPR=yes > > in make.conf. But I've had that in there for a LONG time, and this is the > first time poudriere has complained. > > So, I commented that out for now, but I'd like to know why the sudden change. I haven't been able to find how poudriere jail -c passes any src.conf settings to its installworld phase. It does seem to have a bunch of stuff that goes through contortions to put a src.conf into the jail directory, but only during *buildworld*, not during installworld. It could very well be that this use case was broken due to a recent poudriere update. I don't see anything in the recent log of -CURRENT hat indicates some sort of flipping of the MK_LPR default, it has been "yes" for ages now. Whatever the case may be, for some reason you now run into a common problem with the disconnect between buildworld and installworld: if you run these under even slightly different environments, there can be unexpected consequences... :) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: poudriere jail with todays current: Install fail?
On 10/20/2021 6:41 am, Dimitry Andric wrote: On 20 Oct 2021, at 03:50, Larry Rosenman wrote: Anyone else having poudriere jail -u or jail -c fail in the installworld? log: https://www.lerctr.org/~ler/jail-install.log The actual error is pretty far from the bottom of that log: --- realinstall_subdir_usr.sbin/lpr/chkprintcap --- install: chkprintcap: No such file or directory So probably usr.sbin/lpr wasn't built during buildworld? Do you have any special settings in e.g. src.conf? -Dimitry I had WITHOUT_LPR=yes in make.conf. But I've had that in there for a LONG time, and this is the first time poudriere has complained. So, I commented that out for now, but I'd like to know why the sudden change. -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 signature.asc Description: OpenPGP digital signature
Re: poudriere jail with todays current: Install fail?
On 20 Oct 2021, at 03:50, Larry Rosenman wrote: > Anyone else having poudriere jail -u or jail -c fail in the installworld? > > log: > https://www.lerctr.org/~ler/jail-install.log The actual error is pretty far from the bottom of that log: --- realinstall_subdir_usr.sbin/lpr/chkprintcap --- install: chkprintcap: No such file or directory So probably usr.sbin/lpr wasn't built during buildworld? Do you have any special settings in e.g. src.conf? -Dimitry signature.asc Description: Message signed with OpenPGP
[HEADSUP] the default root shell is now /bin/sh
Hello, Following up on the proposal which happened last month, /bin/sh is now the default shell for the root user. As claimed during that proposal, I have so far no intention to change anything more: I won't remove or modify the 'toor' user, neither modify the root gecos. By popular demand on the thread about the proposal the following bindings have been set by default: navigation through history "ala" csh via the up and down arrow navigation on the command line via ctrl+arrow (left/right) jumps from words to words An alias on fc -l named "history", so the history command to exist. etcupdate will silently switch to sh(1) the first time, for people who wants to keep root on csh, they will have to run: $ chsh -s csh The next upgrade will keep that setting Best regards, Bapt
