Re: Memory defined at boot time incorrect

[Andy Ruhl <acruhl%gmail.com@localhost>]

On Thu, Feb 6, 2020 at 7:26 AM Greg Troxel <gdt%lexort.com@localhost> wrote:
> Not that you asked how to do this, but changing a system from i386 to
> amd64 in place is doable, assuming you have physical console access.  I
> did this on one system without too much trouble, basically:
>
>  - making sure I had a bootable amd64 CD that worked on the machine
>
>  - installing an amd64 kernel and booting it instead
>
>  - installing amd64 userland and merging /etc (using INSTALL-NetBSD from
>    pkgsrc/sysutils/etcmanage), and then diffing the unpacked etc sets
>    against /etc.  This is good to do anyway (not saying make them match
>    - just understand every difference)
>
>  - running MAKEDEV (the new one after merging etc set contents!) in /dev
>    as some device numbers have changed).  This might have required using
>    the rescue CD; I don't remember
>
>  - marking all packages for rebuild: "pkg_admin set rebuild=YES \*"
>
>  - pkg_rolling-replace
>
>  - clean out i386 libs from /usr/lib and /lib, and also look for things
>    in {,/usr}/{,s}bin that did not get an updated ctime from unpacking
>    userland and pruning those
>
> I know that sounds like a lot, but I find it easier and more reliable
> than reinstalling and trying to move config.

Funny you mention this. Yes, I have been thinking about this for
years. I'm alternating between "why bother?" because it's working just
fine, and "let's do it" because I could do more stuff on this machine
by moving stuff from other machines to this one.

My plan was to buy a new hard drive that the root fs lives on, because
the current one is pretty old. Then just install amd64 and run the old
system as a virtual machine inside of the amd64 one and just migrate
over stuff that I need.

It seems starting from scratch would be cleaner, even if upgrade is
possible. I would always wonder if there's something broken waiting to
show itself at the worst time.

Thanks all!

Andy