# Where can I build libasn.1



## dalecosp (May 21, 2021)

I recently used freebsd-update to upgrade a couple machines to 13.0-RELEASE.  Unfortunately, my job control and networking were pretty poor that day on a remote box; one of them ended up not completing correctly and I ended up with some zero-sized shared objects in /usr/lib.  One of these is preventing SSHD from running: */usr/lib/libasn1.so.11* ... no problem, I thought, I'll just somehow get one in there from the working system.

Alas, the working system is amd64 and the hosed system is i386. 

Where does libasn1.so come from?  I'm thinking I can build that library with a different arch target and then move it onto the borken box, perhaps?

Thank you in advance,


----------



## cmoerz (May 21, 2021)

I believe it might be a better approach to either boot with a rescue media and install files from install media or prop up a VM with bhyve from which to extract the files. 

Also, won't you have trouble getting those files onto your destination system anyways if ssh isn't working? Or do you have FTP or anything similar still working? 

Cross compiling might also introduce an additional level of complexity and potential for failure that you would then have to troubleshoot.

If you still intend to compile library by library: I believe libasn1.so originates out of /usr/src/kerberos5/lib/libasn1. If you upgrade got borked, you might end up with the identification of another library missing or broken after this one. So this may very easily turn out to be a long path to restoration.


----------



## datasmurf (May 21, 2021)

You can fetch the base.txz from the FTP Server, extract it and use those, no need to spin up a VM for that purpose at least.


----------



## astyle (May 21, 2021)

have you tried security/heimdal, which is a Kerberos5 implementation? I think that if you compile that, you can fix your problem.  Or, just take the hosed system, and do a fresh install if you don't care about the contents too much.


----------



## dalecosp (May 22, 2021)

Thanks for the excellent input!

Contents are pretty important.  Fetch, Lynx, etc. are working and I have a VNC login to the VM. _ Datasmurf _... *base.txz* sounds a pretty good idea, though I've not tried FTP yet, but as it doesn't require a secure link, the ASN lib _probably_ isn't crucial to that.

As for getting files up there, I was able to get the amd64 version up with a little magic I won't tell about unless you really need to know (hint, lots of services appear to be okay, but not any that depend on libasn).  Believe me, what I was really sweating out yesterday was that PAM was broken too ;-)


----------



## datasmurf (May 22, 2021)

When it's time to move to 14.0 and above I would suggest reading this excellent Blog Post from vermaden about ZFS Boot Environments. 
Maybe this would have saved you some trouble. 

Hope you can resolve your issue soon. Happy hacking


----------



## SirDice (May 22, 2021)

dalecosp said:


> Unfortunately, my job control and networking were pretty poor that day on a remote box;


Run the upgrade in a tmux(1) or screen(1) session. If, for whatever reason, you lose connection to the remote server the upgrade will just continue as if nothing happened. You can then just reattach to the tmux/screen session when you reconnect.


----------



## dalecosp (May 22, 2021)

Thanks again for your awesome help, gentlemen and esp. Datasmurf.  FTP was working, grabbed the base tarball from ftp1.freebsd.org, xz was working, had a partition with enough space.  Some "find . -type f -size 0" in /bin, /usr/bin, /usr/sbin, /lib, /usr/lib and about 8 cp operations and I believe all's well with the world as far as that server's concerned now.


----------

