Thanks! I’ve come across many of Simos’ posts while getting up to speed on LXD. I had previously ended up settling on using the forgotten xdmcp to establish and manage the connections. My next go around will probably use a different approach that is more secure.

My use case for code-server is that I can then access the IDE from any computer allowing me greater flexibility of the device that I code on.

I use LXD (too lazy to move to Incus at the moment) for this exact purpose. It’s definitely nice having a greater degree of isolation between the various projects I’m working on — especially when working with confidential information from clients. Depending on what you’re looking to do there are simpler ways to manage isolation between projects like chroot and nspawn or Nix’s environments. Then again by using LXD/Incus you get that plus lots of other useful tools baked in.

Regarding not getting an IP address have you checked your base configuration to see if dhcp has been configured for the bridge? If that isn’t the issue then all I can think of is that you somehow deleted the interface and should check the container config.

That said the commands provided above are how I usually access the container command line. For coding I use code-server to put VS Code in a browser. I’m sure there are better options and look forward to the suggestions.

Keep going and learning!

Providing more specific information about what isn’t working would help resolve the issue.

The flathub page lists some additional steps that need to be performed to allow virtual input. Did you do this?

I would check system level logs to start like dmesg and syslog.

Someone else might have better tips of what to grep for in the logs. One thing you could do is try to ssh into the system when it’s locked up and check the logs to see what’s being reported during or immediately before the lockup.

Once you get a sense for what’s going on at a system level you can start to look in more specific logs.

Not to be that guy but have you checked the system logs when this happens?

I’d investigate the differences between the installs particularly around graphics and power management. It sounds like your system is getting woken up but it’s hanging at some stage in the process of resuming. You might get lucky and the issue might show up in the logs if you’re willing to investigate them.

When I’ve run NUCs in the past I’ve had issues with external nvidia GPUs dropping off the bus when resuming from suspend. To “fix” the issue, I ended up limiting the power state to S2 or S3 so that the graphics card was kept on the bus.

Do you know what display server, DE, power management service you were running on both? If the logs don’t turn anything up you can always compare the configs too to see how they’re suspending/waking the system.