Problems loading Window Manager after disabling desktop GUI

Hope this is the best place to post. I’m new to Jetson Nano and trying to use as part of a PhD I’m working on. Have some limited linux/ubuntu knowledge but definitely not an expert.

I’ve been going through the tutorials as recommended and had an issue going through this one from Dusty “jetson-inference/pytorch-collect.md at master · dusty-nv/jetson-inference · GitHub”. It ran out of memory during the training so I disabled the GUI using “sudo init 3” which did the trick. However when I re enabled using “sudo init 5” and rebooted the nano, I was faced with a prompt to “please select your default window manager” but nothing to select apart from a file browser option.

After reading through forums I eventually figured out a work around to install ubuntu-desktop and switch to the lightdm by using the a terminal from my laptop. However the desktop font was tiny and completely unreadable. I tried to switch to gdm3 but then but got the message “gdm.service is not active”. On another forum they recommended installing ubuntu-gnome-desktop and this seemed to return it to “normal”. Tried to then return to the LXQt from within the GUI and ended up back at square one with the prompt to select a Window Manager but this time could not get out of it despite throwing everything but the kitchen sink at it - I spent so much time at it I just gave up and re-flashed the SD card back to the jetpack 4.6 but would love to know why it happened and how to get out of it if it happens again. Thanks in advance to anyone that can shed some light in it
Aidan

I can’t say why, but the init command should not have made any permanent changes, e.g., reboot should have gone back to what it had been for runlevel. On the other hand, init is becoming a deprecated way of working with this for Ubuntu (and some other distributions). Now you would probably execute this to go to non-graphical mode:
sudo systemctl isolate multi-user.target
(which is run level 3)

Or to go back to GUI mode:
sudo systemctl isolate graphical.target

This way some more modular (not always more popular) code would do the job rather than just an init script file. Should be the same result, but perhaps the older init scripts got lost in updates.