Stuck on login for one user after migration assistant I recently got my MacBook Air 2018 fixed after having some cryptographic error.
I backed up all my data with time machine and I was able to transfer my data using migration assistant. I now have 3 users and I am only able to log in to two out of the 3. The third user is actually the only one I use and has everything on it. When I log in, (I know it’s the right password), I’m stuck on the loading page. I’ve been waiting for almost two hours.
I know there are threads that have a similar problem but the solutions offered didn’t really fit the criteria of my situation (meaning I was able to log in to other users except one). Please help I am so grateful it’s my university’s spring break I think I’d be having a panic attack if it wasn’t. Id really really appreciate simple and detailed instructions because I’m not knowledgeable on operating systems, etc. Thank you so much.
**I don’t know if this info is related to my problem but before I got my MacBook Air fixed, it  couldn’t update the OS due to that cryptographic error I mentioned before. So when I backed up my data it was on mojave. I didn’t realize my OS wasn’t updating until I needed to download XCode for class and it required the latest OS. I ended up wiping the whole disk after backing up my data and then going to a distribution center. Now I have the latest OS (Big Sur) and that is the backstory to my current problem after transferring my data back.
Here is the link to the spindump.txt file : https://drive.google.com/file/d/1Hscr19_0gnp_4TxW3XxtFgeirxVTIOy5/view?usp=sharing
We can try to approach this a few different ways. Let's start with the easiest and see if we can collect a sysdiagnose during the login process:

Log in to one of your working accounts.
Run the following Terminal command to enable kernel symbolication: sudo nvram boot-args=&quot;keepsyms=1&quot;. Make sure to copy-paste this so that you're entering straight quotes rather than curly/“smart” quotes. (If you get a permission error, you will first need to disable System Integrity Protection. You can re-enable it after you're done with this investigation.)
Reboot your machine normally.
Attempt to log in to your problematic user account.
As soon as you attempt to log in, press and hold the ShiftControlOptionCommand keys together, and while holding these keys press and release the period . key.
This is intended to silently initiate a sysdiagnose. Wait for at least 10 minutes to give it ample time to complete, then do a forced shutdown (press and hold the [POWER] button for 10 seconds).
Wait 10 more seconds with the machine off.
Press the [POWER] button. Immediately afterwards, press and hold CommandS in order to boot your machine into Single User Mode. We are doing this because otherwise the sysdiagnose report will get deleted when /tmp is cleaned during multiuser boot.
You can release the CommandS keys when you're at a command prompt and there is no more scrolling text.
From here, you need to move the sysdiagnose report to a location where it will not be deleted: mv /private/var/tmp/sysdiagnose* /Users/YOUR_USERNAME/Desktop. Here you need to replace YOUR_USERNAME with the short username of one of your functioning users.
exit
Log in with the functioning user whose name you used in Step 10.
Locate the sysdiagnose archive on your Desktop. Double-click to decompress it.
Upload the spindump.txt file in the decompressed report directory using PasteBin or an equivalent service and add the link to your question.

UPDATE 1:
Looking at your spindump, there are several processes that are using significant CPU:
% grep &quot;CPU Time:         &quot; spindump.txt  | sort -d | tail -n 5
CPU Time:         0.330s (661.7M cycles, 244.5M instructions, 2.71c/i)
CPU Time:         0.792s (1615.4M cycles, 642.4M instructions, 2.51c/i)
CPU Time:         2.675s (5.9G cycles, 7.4G instructions, 0.80c/i)
CPU Time:         4.263s (9.6G cycles, 9.0G instructions, 1.07c/i)
CPU Time:         6.450s (12.6G cycles, 15.3G instructions, 0.82c/i)

The 6.45s one belongs to spindump, which is to be expected. The more interesting processes are
% grep -B 12 4.263s spindump.txt | grep Process:
Process:          ReportCrash [369]
% grep -B 12 2.675s spindump.txt | grep Process:
Process:          MRT [83]
% grep -B 12 0.792s spindump.txt | grep Process:
Process:          WindowServer [144]
% grep -B 12 0.330s spindump.txt | grep Process:
Process:          kernel_task [0]

First, it's surprising to see ReportCrash running. This suggests that there has been a recent process that's crashed and is now being analyzed and prepared for reporting to Apple. Although there are several possible explanations for why this is occurring right now, one theory is that either a login item or a launch agent is (repeatedly) crashing upon your attempted login. You can check this by examining (either from a working account or from Single User Mode) the /Library/Logs/DiagnosticReports directory and sorting by timestamp (ls -lt in Terminal / command line). Check for crash logs around the time of your attempted login.
Next, MRT is using a lot of time. MRT is the Malware Removal Tool. Examining its stackshot, its main thread doesn't seem to be blocked and appears to just be doing a lot of normal I/O and analysis. I'm guessing it's doing its ordinary job of scanning your filesystem for malware. Nothing to indicate that it's involved in the failure chain.
Finally, coming to WindowServer and kernel_task, either of which can easily stall a login if they misbehave, I again don't see anything in either stackshot to indicate abnormal behavior.
So we have ruled out CPU starvation as a failure mode here. Now let's see if there's a blocked process within the critical login path. I notice prominently the absence of Finder from the list of running processes, so there is very clearly something preventing it from launching.
% grep -c &quot;Process:          Finder&quot; spindump.txt
0

Let's see if there are any processes that are trying to fork() and might be getting stalled:
% grep &quot;Parent:           &quot; spindump.txt | grep -v &quot;launchd \[1\]&quot; | sort -d 
Parent:           UserAccountUpdater [363]
Parent:           UserAccountUpdater [363]
Parent:           UserAccountUpdater [363]
Parent:           kernel_task [0]
Parent:           loginwindow [147]
Parent:           sysdiagnose [404]
Parent:           systemstats [84]

That's interesting. UserAccountUpdater is running, suggesting that your user account is being upgraded. Given that you mentioned using Migration Assistant to bring your Mojave account into Big Sur, it makes sense that the upgrade has started and has not had a chance to complete. So is anything blocked on this?
% grep UserAccountUpdater spindump.txt | grep block
             *1000  ??? (kernel + 6600128) [0xffffff800085b5c0] (blocked by wait4 on UserAccountUpdater [363])

The answer is yes. This frame comes from a thread in loginwindow, which will also absolutely hang up the login process if something isn't right. There are three children of UserAccountHelper:
% grep -C 6 &quot;Parent:           UserAccountUpdater&quot; spindump.txt | grep &quot;Process:          &quot;
Process:          mbcachecleanup [396]
Process:          migrationhelper [389]
Process:          ReminderMigrationTool [390]

mbcachecleanup and migrationhelper both have healthy traces. ReminderMigrationTool, however, is blocked on an XPC transaction:
Thread 0xcf2    DispatchQueue &quot;com.apple.main-thread&quot;(1)    1000 samples (1-1000)    priority 31 (base 31)
1000  start + 1 (libdyld.dylib + 87585) [0x7fff20555621]
1000  ??? (ReminderMigrationTool + 15952) [0x101fa0e50]
  1000  -[CalInProcessReminderMigrator attemptMigrationWithHomeDirectory:] + 278 (ReminderMigration + 20449) [0x7fff732c0fe1]
    1000  -[CalTruthFilesReminderMigrator attemptMigrationWithHomeDirectory:] + 196 (ReminderMigration + 28484) [0x7fff732c2f44]
      1000  -[CalTruthFilesReminderMigrator _attemptMigrateRemindersDataWithCalendarDirectory:] + 175 (ReminderMigration + 28783) [0x7fff732c306f]
        1000  -[CalTruthFilesReminderMigrator _performMigrationInCalendarDirectory:withContext:] + 941 (ReminderMigration + 30684) [0x7fff732c37dc]
          1000  -[CalReminderMigrationContext ensureAccountsExist:] + 48 (ReminderMigration + 21943) [0x7fff732c15b7]
            1000  -[CalDefaultReminderKitDatabaseMigrationContext ensureAccountsExist:error:] + 142 (ReminderMigration + 9833) [0x7fff732be669]
              1000  -[REMDatabaseMigrationContext ensureAccountsExist:error:] + 64 (ReminderKit + 442631) [0x7fff3d851107]
                1000  -[REMDatabaseMigrationContext ensureAccountsExistWithMigrationAccountInfos:error:] + 219 (ReminderKit + 440075) [0x7fff3d85070b]
                  1000  -[REMDatabaseMigrationContext _cleanLocalDatabases:] + 100 (ReminderKit + 444147) [0x7fff3d8516f3]
                    1000  -[REMStore fetchAccountsIncludingInactive:error:] + 75 (ReminderKit + 107141) [0x7fff3d7ff285]
                      1000  -[REMAccountsDataView fetchAllAccountsForAccountManagementWithError:] + 114 (ReminderKit + 633685) [0x7fff3d87fb55]
                        1000  -[REMStore resultFromPerformingInvocation:error:] + 839 (ReminderKit + 119019) [0x7fff3d8020eb]
                          1000  -[REMStore _xpcSyncStorePerformerWithReason:errorHandler:] + 164 (ReminderKit + 124938) [0x7fff3d80380a]
                            1000  -[REMXPCDaemonController syncStorePerformerWithReason:errorHandler:] + 145 (ReminderKit + 466128) [0x7fff3d856cd0]
                              1000  -[REMXPCDaemonController _syncPerformerWithResolver:reason:errorHandler:] + 109 (ReminderKit + 467124) [0x7fff3d8570b4]
                                1000  -[REMXPCDaemonController _resolveAndCachePerformerWithResolver:reason:errorHandler:] + 482 (ReminderKit + 469269) [0x7fff3d857915]
                                  1000  -[REMXPCDaemonController _resolvePerformerWithResolver:reason:errorHandler:] + 544 (ReminderKit + 473070) [0x7fff3d8587ee]
                                    1000  -[REMXPCDaemonControllerPerformerResolver_store resolveWithDaemon:reason:completion:] + 209 (ReminderKit + 475082) [0x7fff3d858fca]
                                      1000  _NSXPCDistantObjectSimpleMessageSend4 + 42 (Foundation + 821239) [0x7fff214267f7]
                                        1000  -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:arg3:arg4:] + 155 (Foundation + 821458) [0x7fff214268d2]
                                          1000  -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 3090 (Foundation + 118889) [0x7fff2137b069]
                                            1000  __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 9 (Foundation + 126953) [0x7fff2137cfe9]
                                              1000  xpc_connection_send_message_with_reply_sync + 238 (libxpc.dylib + 45484) [0x7fff2027c1ac]
                                                1000  dispatch_mach_send_with_result_and_wait_for_reply + 50 (libdispatch.dylib + 105326) [0x7fff203a5b6e]
                                                  1000  _dispatch_mach_send_and_wait_for_reply + 518 (libdispatch.dylib + 104310) [0x7fff203a5776]
                                                    1000  mach_msg_trap + 10 (libsystem_kernel.dylib + 3710) [0x7fff20505e7e]
                                                     *1000  ipc_mqueue_receive_continue + 0 (kernel + 573344) [0xffffff800029bfa0] (blocked by turnstile waiting for launchd [1] after 3 hops)

Are there others?
% grep -c &quot;1000  __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__&quot; spindump.txt
6

Yes: There are six frames that are similarly blocked. One was accounted for above. Another is in UserAccountHelper, blocking access to the font registry. Very interestingly, fontworker and fontd are both also blocked this way. fontd's instance is in the com.apple.xtype.ScannerQueue dispatch queue. This immediately leads me to suspect that the font manager is hanging while scanning your local font library. Perhaps there is a corrupted font and/or font collection installed in your user ~/Library/Fonts and/or ~/Library/FontCollections. You should rename these directories and try logging in again.
Two more frames are in WiFiAgent and otherbsd. I also saw blocked frames in securityd and secinitd which may be relevant, but let's investigate what we've discussed so far.
To summarize:

Rename your user's Fonts and FontCollections directories (probably easiest to boot into Single User Mode and do this from the command line, e.g., cd /Users/YOUR_USERNAME/Library &amp;&amp; mv Fonts FontsDISABLED &amp;&amp; mv FontCollections FontCollectionsDISABLED).
Check if there's anything in that user's ~/Library/LaunchAgents.
Check in /Library/Logs/DiagnosticReports for crash reports around the time of failure.