I believe this should open up console 5 and 6 to workstation where I get a prompt to login.
I also want to be able to launch wayland / X sessions (The host is just a server and does not utilize the GPU at all), so I followed:
However, when I try to login into the workstation console now, the input and output seems messed up. By that, I mean that it seems every other character is accepted and some characters are echoed even when entering my password.
I can see /dev/dri exists in the container.
What else do I need to do in order to be able to run sway in my container where my hosts is just a barebones install?
Yes, my /etc/inittab is posted above. I just put in incus console workstation where agetty was: c4:2345:respawn:/sbin/agetty 38400 tty4 linux
Hmm, that’s a bummer about the keyboard - does that mean I just need to add those devices? If I add them, then I won’t be able to access them from the host any longer?
I primarily use the machine as a workstation and when something goes wrong, I usually ssh into the host or router. If it goes really wrong, I go directly to the console to get to the host system.
Theoretically, I could add those devices to the workstation and if the workstation fails to start, reassign them back to the host. Alternatively, rather than have a host with 2 containers, I could make the workstation the host, and have a container inside that which is the router.
I am still leaning towards a barebones host with 2 containers as I am envisioning using the same process for applying updates as I do on FreeBSD. I create a new ZFS dataset, apply the updates there, and then reboot into that. Having a smaller system means fewer updates, granted, kernel updates are always going to be there.
EDIT:
Thanks for sharing, I read through your post, I’m reconsidering my options then. I like the idea of structuring or organizing services, but at the same rate, perhaps I’m trying to do something outside of what the typical use case is and it is not really designed for that.
Are you saying that I can only run incus console workstation once? So, one of the consoles wouldn’t not work?
Hmm, then it seems that perhaps I should just setup my workstation on the physical device and then run the router jail inside that. And, then, do away altogether with incus console and instead just rely on SSH to get to the container. I really only used that (in FreeBSD) so that I could startx and use my workstation.
You can verify whether both consoles are able to give you a login: prompt through incus console.
As far as I can guess, only one should work, the other would get stuck. But if you managed to get two consoles at the same time for the same Incus instance, then this information is important to report.
Using incus console in inittab is an interesting trick. You mention some issues with the standard input and output. This could be related to incus console and perhaps if you can figure out the problem, it could be fixed. The alternative would be to use the incus console code to develop a standalone application that only does the functionality of giving you a console
Yeah, you’re right, the other one does not appear to work.
Hmm, ok, at this point, I will go the route of putting my workstation directly on bare metal and will run the router container inside that and just SSH into it when I need to ‘maintain’ it.
I will come back around to making the workstation a container, but it doesn’t look like it’d be something that can be done today.
You misunderstood, it’s you will not be able to use keyboard in container, all keyboard input will happen in host, and I don’t know how to solve that, and have no bare metal for test. But there is a possible way to let keyboard input happen in container if running x11:
In host, use evdev to lock keyboard and capture input. No need to pass mouse and keyboard to container.
In container, start x11 and use proxy device to mount container’s x11 socket in host.
In host, use Xlib to pass keyboard input through x11 socket.
It requires a lot of coding. I writes about 100 line to move mouse and to click left and right buttons, but when come to keyboard, there are too many buttons.
Shutdown container’s x11 is easy, just click logout, then you will see a black screen, use ctrl+alt+F2 and ctrl+alt+F1 to flush framebuffer, everything will be normal again.
I don’t know whether it’s possible after you add gpu to it.
As for now, the best way for running desktop environment in container is nesting, prefer wayland.
Edit: I just tried startx using console way, still no keyboard input in container.
Ah ok. That might be what is happening with my FreeBSD jail, I don’t know precisely. I just know that it works well enough for me to use it that way on a daily basis for the past few years.
What I really want to do is to run my router on the same physical box as my workstation. This desire originated out of me having to physically walk over to my router to perform maintenance. While I don’t tweak the firewall nearly as much as I used to, this approach is much quicker and easier.
I can still achieve that, I just won’t have the workstation in a container too.
Are you just trying to run an xorg inside a container? Because if so then you don’t need to worry about changing any of the inittab or much of anything on the host (except for video card drivers).
If you just set up a normal container, then just pass through video/sound/input (/dev/dri, /dev/vga_arbiter, /dev/input, /dev/psaux, /dev/snd), then install a display manager like lightdm which will then automatically run xorg on vty7 (by default). Then when you restart lightdm, you’ll have X running.
I have been doing this for many years. It leaves the host clean. You can even run multiple containers with xorg at the same time but sound is a little tricky to get working (needs own pulseaudio container that handles the audio, then the xorg containers become the client accessible over avahi).
I must admit though I like the idea of assigning a separate vty to a container’s console. But yeah if you have your desktop container to start on boot then you’ll never need to login to those consoles.
Yes, I wanted to run xorg, or better yet, sway inside the container.
Yes, the goal was to keep the host minimal so the number of times I would need to reboot the host would be minimal if at all. With FreeBSD, this was only for kernel updates which weren’t all that frequent.
I couldn’t figure it out, so instead, I have my workstation operating as the host and my ‘router’ as a container. In FreeBSD space, one minor issue I discovered was that USB hotplug was not working in Xorg / i3 for some reason. So, I would start i3 then if I decided to plug in a different keyboard for fun, that keyboard would not work.
If you have an idea how to accomplish that, I’d still be interested.
Ok. Yeah I’m not sure about FreeBSD. I did actually have a desktop running inside a jail but it wasn’t as smooth as linux (video playback was a little jerky) so didn’t spend much time with it.
I haven’t tried wayland yet but I will soon as I want to give Niri a try. But yeah at the moment xorg with i3 works really good with this setup, I have been running this setup for probably close to 10 years now.