vole

vole, 7 months ago

POP!_OS apparently uses systemd-boot (not to be confused with systemd). It apparently adds a Windows entry automatically if Windows is installed on the same disk. When Windows is installed on a different disk, it looks like booting the windows boot manager EFI program is still possible with systemd-boot. The instructions given in that link are a bit vague, though.

This page has a different, simpler approach and more specific steps. Apparently you can just copy the Microsoft EFI folder to a specific directory in your Linux drive’s ESP partition. I’d be a little bit concerned about Windows not being able to update its EFI bootloader, but I also don’t know if Windows ever updates that. The page also has instructions on how to interact with the systemd-boot menu during boot.

You could also install grub yourself, but I can’t guarantee that’ll be easy. Mashing F2 might be the sanest solution, unless you plan on booting into Windows every day.

vole, 7 months ago

This is a text post, so the OP wrote text corresponding to the title. You should be able to see it at the top of the post. (Spoiler, OP is basically asking the community why NixOS is better, because they don’t quite understand the advantages of using NixOS.)

vole, 7 months ago

Oh wow, I didn’t know (free) Davinci didn’t support using H.264 as source media, that feels rather limited.

vole, 7 months ago (edited 4 months ago)

Completely tangential tip, but in the very-limited video editing I’ve done recently: I’ve used Davinci Resolve, rendered as .mov, and then used ffmpeg to render to my actual desired format. e.g. h264 w/ aac audio so I can upload to Youtube:

ffmpeg -i input.mov -c:v libopenh264 -profile:v high -c:a aac -pix_fmt yuv420p output.mp4

I do think that finding the right flags to pass to ffmpeg is a cursed art. Do I need to specify the video profile and the pix_fmt? I don’t know; I thought I did when I adventured to collect these flags. Though maybe it’s just a reflection of the video-codec horrors lurking within all video rendering pipelines.

edit: there may also be nvidia-accelerated encoders, like h264_nvenc, see ffmpeg -codecs 2>/dev/null | grep -i ‘h.264’. I’m not sure if the profile:v and pix_fmt options apply to other encoders or just libopenh264.

vole, 7 months ago

thanks, I’ll try out the libx264 encoder next time

vole, 7 months ago (edited 17 days ago)

I got interested, so I spent some time looking into what’s going on here. I’m not intimately familiar with X11 or Wayland, but I figured out some stuff.

Why sudo ip netns exec protected sudo -u user -i doesn’t work for X11 apps

Short answer: file permissions and abstract unix sockets (which I didn’t know were a thing before now).

File permissions: when I start an X11 login session, the DISPLAY is :0 and /tmp/.X11-unix/ has only 1 file X0. This file has 777 access. When I start my wayland session with Xwayland, the DISPLAY is :1 and /tmp/.X11-unix/ has 2 files X0 (777) and X1 (755). I can’t figure out how to connect to display :0, so I guess I’m stuck with :1. When you change to a different (non-root) user, the user no longer has access to /tmp/.X11-unix/X1.

Abstract unix sockets: When I start my wayland/xwayland session, it creates abstract unix sockets with ids @/tmp/.X11-unix/X0 and @/tmp/.X11-unix/X1. See ss -lnp | grep Xwayland. The network namespace also sandboxes these abstract unix sockets. Compare socat ABSTRACT-CONNECT:/tmp/.X11-unix/X1 STDIN and sudo ip netns exec private socat ABSTRACT-CONNECT:/tmp/.X11-unix/X1 STDIN.

When you do sudo ip netns exec protected su - user, you loose access to both the filesystem unix socket /tmp/.X11-unix/X1 and the abstract unix socket @/tmp/.X11-unix/X1. You need access to one or the other for X11 applications to work.

I tried using socat to forward X1 such that it works in the network namespace… and it kinda works. sudo ip netns exec protected socat ABSTRACT-LISTEN:/tmp/.X11-unix/X1,fork UNIX-CONNECT:/tmp/.X11-unix/X1. It appears having ABSTRACT-LISTEN before UNIX-CONNECT is important, I guess it would be worth it to properly learn socat. With this sudo ip netns exec protected su - testuser -c ‘env DISPLAY=:1 xmessage hi’ works, but sudo ip netns exec protected su - testuser -c ‘env DISPLAY=:1 QT_QPA_PLATFORM=xcb kcalc’ does not work. 😞

Changing the file permissions on /tmp/.X11-unix/X1 to give the user access seems to work better.

Wayland waypipe

Waypipe works as advertised. But it’s still a little bit tricky because you need to have two separate processes for the waypipe client and server, wait for the waypipe socket to be created, adjust file permissions for the waypipe socket file, and set (and probably mkdir) XDG_RUNTIME_DIR.

<span style="color:#323232;">waypipe -s /tmp/mywaypipe client &amp;
</span><span style="color:#323232;">sleep 0.1
</span><span style="color:#323232;">chgrp shared-display /tmp/mywaypipe
</span><span style="color:#323232;">chmod g+w /tmp/mywaypipe
</span><span style="color:#323232;">sudo ip netns exec protected su - testuser -c 'mkdir -p -m 0700 /tmp/runtime-testuser &amp;&amp; env XDG_RUNTIME_DIR=/tmp/runtime-testuser waypipe -s /tmp/mywaypipe server -- env QT_QPA_PLATFORM=wayland kcalc'
</span><span style="color:#323232;">kill -SIGINT %1
</span>

Combined

into this script github.com/…/run-netns-user-wayland.bash