On Wed, Dec 02, 2020 at 06:56:40AM -0700, Andy Ruhl wrote: > So I've been playing with NetBSD-amd64 a lot lately and I accidentally > upgraded my 20+ year old i386 system to amd64 using an install kernel > with sysinst. I didn't realize it until it rebooted and I saw a few > errors. I could restore the system - but this needed to happen at some > point. The machine is amd64 capable and booted mostly just fine. I'm > going to go with it if I can. > > I used the netbsd-9 snapshot from nyftp marked 202011301900Z > > So, "I don't know what I don't know" is wrong with it. So far 2 things > are sticking out: > > First: > # pkgin ls > reading local summary... > processing local summary... > > /!\ Warning /!\ i386 doesn't match your current architecture (x86_64) > You probably want to modify /usr/pkg/etc/pkgin/repositories.conf. The same warning tormented me for the longest time. I figured out how to fix it just the other night. First, I searched the `pkg_info -aB` output for i386. That showed me that I had both pkg_install-20101122 and pkg_install-20200701 registered as installed. The former was built for i386, and the latter for amd64. You may find that your system is in a similar state. I could find no i386 executables on my system: the pkg_install-20200701 content had overwritten the pkg_install-20101122 binaries. Since pkg_install-20101122 is used for installing packages, and it was the *only* package built for i386, I guessed that the mere fact that it was registered was the problem. It took a little while to figure out an incantation that would remove pkg_install-20101122 without erasing any pkg_install-20200701 content, since that would leave my system in a bad state. Complicating matters, both versions of pkg_install were registered as must-not-delete packages. I thought `pkg_delete -fN pkg_install-20101122` looked like a safe candidate. I tried it. It worked. No more warnings. Maybe my fix will work for you. It will be inconvenient if you end up without any pkg_install whatsoever, so proceed cautiously. > Second: > # sleep 1 > could not load libm387.so.0 for libm.so.0 > (this load error happens with various commands) I haven't seen this one. Dave -- David Young dyoung%pobox.com@localhost Urbana, IL (217) 721-9981