Andy Ruhl <acruhl%gmail.com@localhost> writes: > 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. [dropped port-i386; this is only of interest to people with amd64 hardware!] I have done this successfully (intentionally). It sounds like you are running an amd64 kernel but not yet an amd64 userland. What I did was: install the amd64 kernel reboot (always recommended but really really necessary for this) install the amd64 userland carefully merge the files in etc. I use etcmanage, but then I went over the diffs from distribution to what I had and did manual merges. Takes a while, maybe an hour, but saves that tracking down things you don't understand later. re-run MAKEDEV in /dev, (the MAKEDEV and MAKEDEV.local from amd64 that got updated above as I think it's part of etcdist) because some of the device nodes are different reboot again mark every package as 'pkg_admin set rebuild=YES' run pkg_rollling-replave -ukv, deal with issues In your case you could "pkgin export" to get a list and then remove them all and then add back what you need. i386 packages will run ok, almost entirely, but if you mix i386/amd64 you will quickly have a huge mess. There is no advantage to running an emulated pkgsrc setup, so changing it to native is best. > 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. This is because you have packages that are installed that are i386 mode. I am not clear on if pkgin considers a package needing replacement if the arch differs. This situation is of course unusual. > I don't know how or where to fix this. My repositories.conf file is > already pointing to an amd64 location. I don't know why pkgin thinks > it's still i386. I replaced all packages with pkg_add instead of pkgin > and that seemed to work. I would prefer to use pkgin obviously. If you had deleted and used pkgin add or import, should be ok. Now you should be able to "pkgin up", munge keep flags, etc. and use pkgin. > Second: > # sleep 1 > could not load libm387.so.0 for libm.so.0 > (this load error happens with various commands) > > While researching this I went to a VM with a pretty clean install of > netbsd-9 amd64 and it doesn't even have libm387 as far as I can tell. > My "upgraded" system does have libm387.so.0.1 and it is 32 bit. This > doesn't appear to actually cause a problem. Did you unpack the n9 amd64 userland? Check "file /bin/sleep" and make sure it is the amd64 version. Note that /usr/lib/i386 has compat libs for i386, as part of the amd64 build. > So far so good, I'm sticking with amd64 but I'd like to fix the > problems I can see and anything I don't know about that someone can > point me to. Hope this helps. You may also want to purge things that are from the i386 install that were not overwritten from the amd64 install. But make sure all packages are amd64 before you do that.
Attachment:
signature.asc
Description: PGP signature