migration hickup

Wed Mar 10 18:34:12 UTC 2021

On Mar 10, 2021, at 05:26, joerg van den hoff wrote:

> On 09.03.21 18:41, Ryan Schmidt wrote:
>> On Mar 9, 2021, at 11:34, joerg van den hoff wrote:
>>> so I find this strange: seemingly everything is just fine (macports user and its home dir exists etc.) but I get that "cannot change owner: no macports user" warning nonetheless. so this looks like OSX had not a consistent view of the state of affairs across different utilities at that point? notably `dscl' knowing that user is not sufficient? what, then, is the reliable/correct way to decide whether a user account "really" exists? but whatever ...
>> I'm sorry, I don't know and I can't completely explain what you've observed.
>>> understood. will try to recall the procedure in due time when doing another migration to a new machine...
>> No need to recall anything since it's documented in https://trac.macports.org/wiki/Migration. That document is geared toward migrating from one OS version or architecture to another, but it could be enhanced to address the case of migrating from one machine to another while keeping the same OS version and architecture. If you'd like to make those enhancements feel free; anyone can edit the wiki.
> 
> well, I might try that. at least it seems not true that for said type of migration (same OS/arch) one needs to first nuke the macports installation. from the current migration page: "Note: If you move from one Mac to another Mac using Migration Assistant, you have to do it ["it" meaning uninstall MacPorts] first."

That sentence is meant to be taken in context of the rest of the page, which is currently all about the need to reinstall MacPorts and ports when migrating from one OS version or arch to another.

If you're moving from one Mac to another where both have the same OS version and arch, then you don't need to do anything to fix MacPorts; your existing MacPorts installation will work just fine if you copy everything correctly. For example, using a cloning utility like Carbon Copy Cloner copies everything correctly.

Migration Assistant does not copy everything correctly. It does not preserve the correct home directory location of the macports user nor of any of the user accounts that MacPorts ports might create. So if you use Migration Assistant, then you will have to take additional steps afterward. Either you have to exclude those accounts from migration and recreate them afterward, or if you did not exclude the user accounts then you have to fix their home directories afterward. 

> OTOH I am not quite sure _what_ to recommend: my "strategy" was
> 
> 1. migrate everything offered by Migration Assistant _except_ the macports user's account.
> 
> 2. reinstall MacPorts from dmg image
> 
> so I could write something to that extent into the wiki if it helps...
> 
> but I am not at all sure what would have happened if I had done it the way you suspect to be better:

You misread me. I agreed with you that *not* migrating the macports user was the easiest way to do it, provided that you recreate the user later by re-running the MacPorts installer.

If you instead *did* migrate the macports user, then Migration Assistant will have messed it up and it would need to be fixed.

> 1. migrate everything offered by Migration Assistant _including_ the macports user's account (whose home dir than is moved apparently to /Users in the process)
> 
> 2. mv macport home dir back into the /opt/local tree
> 
> open questions would be: how exactly? with what permissions? does that really yield a working MacPorts installation or would the same warning result I have seen ("no macports user") and which necessitated reinstall of MacPorts from the dmg image?

If you tell Migration Assistant to migrate a user account, it will migrate the user account. That means the user account and its home directory will exist on the new system. Migration Assistant will relocate the user's home directory into /Users, which is inappropriate for the macports user and all of the user accounts that ports might create, therefore you will need to undo those changes manually later. To do that, for each affected user account, you need to:

1. mv the home directory from /Users/whatever to where it was supposed to be, and
2. use the dscl command to fix the user's NSHomeDirectory entry to match where the home directory now is.

For the macports user this is easy enough since we know that its home directory is /opt/local/var/macports/home. But for all of the other user accounts, you would need to read that port's Portfile to figure out where its home directory is supposed to be.

If you tell Migration Assistant *not* to migrate a user account, it will not migrate the user account. That means the user account will not exist on the new system. I am not certain whether the user's home directory would be copied. It seems like it should not be, but I can't test it right now.

I think it would be a good idea if the migration wiki page specifically mentioned this problem of the Migration Assistant. I would probably have the page recommend not to migrate MacPorts-related user accounts and instead recreate them after migration. To recreate the macports user, re-run the MacPorts installer. To recreate users and home directories created by any port, reinstall that port (sudo port -n upgrade --force portname). Users might want to look into the home directories of each MacPorts-created user before migration to make sure there's nothing important in there in case it does not get copied.

Many users will not be aware of the problem until after migration is complete, so we should also describe how to recover from a migration where the user accounts were migrated and relocated.

`port diagnose` should probably be modified so that it detects any home directories that were misrelocated to /Users and warns the user about it, perhaps referring them to the future version of the Migration page for help in fixing it.

Maybe an even nicer idea: Whenever MacPorts creates a user account, it could record its home directory in a new table in the registry. `port diagnose` could check if any home directory doesn't match what we recorded and offer a way to set it back. Or this could become part of the unfinished `port migrate` command (https://trac.macports.org/ticket/56019) (or maybe it already includes this; I don't know).