Well if it was for a tech job im sure you could’ve shown off some troubleshooting skills haha

And the ArchWiki link is perfect. Ill read up on that and ensure I’m using it correctly. Thank you very much for the pointer kind stranger! :)

I’ll ask! How do you know? Lol

All jokes aside, I think this might really help me with a side project I’ve been working on. Ive been trying to get full disk encryption working on a NanoPi R6S running NixOS. The issue that im having is that im not sure exactly what modules I need in the initrd. When I boot, there is no output on the display after systemd-boot shows.

The manufacturer puts out a version of Ubuntu thats works flawlessly so I know its possible. But I’ll pass on the snaps and id rather not use uboot. System is working with edk2 and nixos.

Long story short, will this software allow me to figure out what is running in the manufacturer’s kernel and port it over?

If you run systemctl reboot on a non-vm it will actually power cycle the system and cause it to go back through the BIOS and then the bootloader. Using systemctl kexec allows you to “restart” the computer without having to go all the way back through the full boot process.

In the case of a VM, some are setup to do this behind the scenes. For example, virt-manager allows for direct kernel booting. If you look in the options there will be a path to the kernel. If its not setup that way, then the VM still has a bootloader. In that case, restarting the VM with kexec will allow for a faster reboot since the bootloader is skipped completely.

So you can just run kexec if its installed on the distro. This tells the kernel to boot into another kernel. The reason to use it with systemctl is to properly shut down all the services running in userspace. That command will have systemd gracefully turn off all services and then the new kernel with whatever updates / modules can be loaded in a clean environment.

Its useful if say, you have a VM in a data center. Now most of them provide a web gui where you can turn your VM off and then on. But if you’re lazy like me and already remoted into the terminal lol

I hope it helps you someday! :)

I think the command “systemctl kexec” would like to have a word. Great command to know if you have a VM on a system you dont manage / share with others.

Woah woah… is there someplace in the event logs where this would show? Does this mean that you cannot run a windows computer headless?

Bless your heart

Not OP but I use headscale and have it configured using Authentik for SSO. Works flawlessly once its up and running. I also use headplane for the UI. It has SSO integration as well which makes everything a breeze.

Edit: Forgot to mention, all running in docker with traefik as the reverse proxy.

Holy shit I had no idea about this. Thank you so much!

Looking into the history of Kodak is crazy. They used a 13 month calendar and secretly kept a nuclear reactor in the basement for years.

People forget that Kodak was a chemical company, not just photography.

c/unixsocks

Ah, what you’re looking for is called udev. It supplies the system with device events from the linux kernel.

This gist of it is, to use this command

udevadm monitor --environment --udev

then unplug and plug in your monitor. You should see the events on screen. You then write a rule and place it in /etc/udev/rules.d. To run a script add something like

ACTION=="change", SUBSYSTEM=="drm", KERNEL=="card0-HDMI-A-1", \
  RUN+="/usr/local/monitor-script.sh"

See the man udev page for more info (☞ﾟヮﾟ)☞

Have you tried setting up qemu with virt-manager? Theres a lot of info on how to set it up for most distros and I find the GUI is very straightforward and easy to use.

Made me laugh in the middle of a restaurant, thanks 🤣

Yeah you just have to deal with mast bumping, as if thats any less worrying.

You can use Authentik to setup an LDAP outpost then use a jellyfin LDAP plug-in to sync everything up.

https://github.com/jellyfin/jellyfin-plugin-ldapauth?tab=readme-ov-file

Course, feel free to DM if you have questions.

This is a common setup. Have a firewall block all traffic. Use docker to punch a hole through the firewall and expose only 443 to the reverse proxy. Now any container can be routed through the reverse proxy as long as the container is on the same docker network.

If you define no network, the containers are put into a default bridge network, use docker inspect to see the container ips.

Here is an example of how to define a custom docker network called “proxy_net” and statically set each container ip.

networks:
  proxy_net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16

services:
  app1:
    image: nginx:latest
    container_name: app1
    networks:
      proxy_net:
        ipv4_address: 172.28.0.10
    ports:
      - "8080:80"

  whoami:
    image: containous/whoami:latest
    container_name: whoami
    networks:
      proxy_net:
        ipv4_address: 172.28.0.11

Notice how “who am I” is not exposed at all. The nginx container can now serve the whoami container with the proper config, pointing at 172.28.0.11.

Well if your reverse proxy is also inside of a container, you dont need to expose the port at all. As long as the containers are in the same docker network then they can communicate.

If your reverse proxy is not inside a docker container, then yes this method would work to prevent clients from connecting to a docker container.

Something like this. This is a compose.yml that only allows ips from the local host 8080 to connect to the container port 80.

services:
  webapp:
    image: nginx:latest
    container_name: local_nginx
    ports:
      - "127.0.0.1:8080:80"