突突唧之家

Hello World,

We have noticed that a lot of people hit the same issue over and over again. When trying to connect via remote desktop protocol (rdp) to the Ubuntu machine, and after providing the credentials in the xRDP Login page, the user will only see a black screen displayed and the desktop interface is never loaded and displayed. This post will basically explain why this happens and how to reproduce the issue.

The "problem" is actually well known and there is really an simple and easy fix for that. So, let's explain the situation.

Reproducing the "Black Screen" Situation

Let's assume that you have performed a successful xRDP installation and you are ready to test your rdp connection to your Ubuntu machine. Let's also assume that you are still logged on into your Ubuntu machine system locally with your user account (which could be called User1). So, you move to your Windows machine (or Linux machine), fire up your favorite remote desktop client and provide the ip address or the hostname.

Since xRDP installation has been successful, you will be presented with the xRDP Login page where you will need to provide the user credentials on the Ubuntu machine. In our example, User1 (yes the one currently logged on locally on the ubuntu machine) account will be used.

If the credentials are correct, you will see your remote desktop session showing a black screen and that’s it !!!!! The desktop interface will never load within your remote session.

Black Screen Situation Explained

As mentioned and explained multiple times, this situation will happen (or can happen) when the same user account is used concurrently locally and remotely. In other words, the problem is related to the fact that the same user account is already logged in locally and a remote connection is attempted at the same time. With xRDP software solution, a specific user account can be logged on either locally or remotely but not both.

The (Standard) Solution

To solve this issue, there is a simple fix. You need to ensure the account you are using to login via the remote desktop client is not currently logged on locally on the Ubuntu target machine. If this is the case, perform a logout operation.

Try again the remote desktop session and you will see that magically, you will be able to perform your remote desktop connection and that your desktop interface will be loaded and made available for you.

To clean all old versions of snaps, try:

LANG=C snap list --all | while read snapname ver rev trk pub notes; do if [[ $notes = *disabled* ]]; then sudo snap remove "$snapname" --revision="$rev"; fi; done

Some checkbox alternatives using bbding, wasysym, or nothing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

\documentclass{beamer}

\usepackage{bbding}
\let\oldSquare\Square % \Square is also defined in wasysym
\usepackage{wasysym}

\begin{document}

\begin{frame}
    \begin{itemize}
        \item[$\boxtimes$] nothing
        \item[$\square$] nothing
            \bigskip
        \item[\fboxsep0pt\fbox{$\times$}] nothing
        \item[\fboxsep0pt\fbox{$\phantom{\times}$}] nothing
            \bigskip
        \item[\CheckedBox] \texttt{wasysym}
        \item[$\XBox$] \texttt{wasysym}
        \item[\Square] \texttt{wasysym} (\texttt{\textbackslash Square})
            \bigskip
        \item[\small\oldSquare] \texttt{bbding} (also \texttt{\textbackslash Square})
        \item[\small\rlap{\Checkmark}\oldSquare] \texttt{bbding}
        \item[\small\rlap{\XSolidBrush}\oldSquare] \texttt{bbding}
    \end{itemize}
\end{frame}

\end{document}

A proxy act as an intermediary host where you could tunnel your connection through the proxy to access another host. Tunneling your SSH connection via a proxy, among other things, could allow you to access hosts in a private network or under a NAT. As such, a proxy avoids the need to set up a more complex infrastructure such as a VPN.

OpenSSH's SSH client supports connecting through both SOCKS and HTTPS proxy. It is achieved with the ProxyCommand option alongside third-party programs such as nc or netcat.

Steps to connect to SSH server via SOCKS or HTTPS proxy:

1. Create SOCKS or HTTPS proxy if you don't already have one.

2. Test if the SOCKS or HTTPS proxy is reachable from the SSH client's host (optional).

   $ nc -zv 127.0.0.1 2222 Connection to 127.0.0.1 2222 port [tcp/*] succeeded!

   -v Produce more verbose output. -z Only scan for listening daemons, without sending any data to them. Cannot be used together with -l.

3. Use ProxyCommand as option for SSH client.

   $ ssh -o ProxyCommand='nc -X4 -x 127.0.0.1:2222 %h %p' remoteuser@remotehost

   1 2 3 4 5 6 7 8 9 10 11 12 13

   -X proxy_protocol Use proxy_protocol when talking to the proxy server. Supported protocols are 4 (SOCKS v.4), 5 (SOCKS v.5) and connect (HTTPS proxy). If the protocol is not specified, SOCKS version 5 is used. -x proxy_address[:port] Connect to destination using a proxy at proxy_address and port. If port is not specified, the well-known port for the proxy pro‐ tocol is used (1080 for SOCKS, 3128 for HTTPS). An IPv6 address can be specified unambiguously by enclosing proxy_address in square brackets. A proxy cannot be used with any of the options -lsuU.

4. Add ProxyCommand to SSH client configuration file for persistence.

   $ cat .ssh/config Host remotehost hostname 192.168.1.10 user remoteuser ProxyCommand nc -X4 -x 127.0.0.1:2222 %h %p

5. Connect again using SSH client with just the Host name as parameter.

   $ ssh remotehost

Most modern Linux distro uses systemd as init replacement. It is a suite of basic building blocks for Linux distros such as RHEL/CentOS, OpenSUSE/SUSE, Fedora, Arch, Debian, Ubuntu, and more. By default, most distro boot into GUI, but you can change to text or vice versa.

The older version of the Linux distros came with SysV init or Upstart. Such init provided a set of runlevels for text, multi user, and GUI system. However, systemd uses the concept of targets instead of runlevels. This page explains procedures to implement runlevel like config when working with systemd targets. In other words, you will learn how to switch between text or GUI mode using systemd instead of init levels on modern Linux distros.

The --first-time flag causes modprobe to fail if the module is already loaded. That in conjunction with the --dry-run (or the shorthand -n) flag makes a nice test:

modprobe -n --first-time $MODULE && echo "Not loaded" || echo "Loaded"

This also prints Loaded if the module does not exist. We can fix this by combining it with modinfo:

modinfo $MODULE >/dev/null 2>/dev/null &&
! modprobe -n --first-time $MODULE 2>/dev/null &&
echo "Loaded" || echo "Not loaded"

If the state of the package got changed to manual from automatic, you can set it back to automatic in the following manner:

sudo apt-mark auto package_name

问题

在 Ubuntu 22.04 LTS 的容器里面运行 apt update 的时候出现了以下报错：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

[root@VM-16-9-centos docker-kubuntu]# docker run --rm -it ubuntu:22.04 bash
root@8ac245b487e6:/# apt update
Get:1 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB]                    
Err:1 http://security.ubuntu.com/ubuntu jammy-security InRelease                   
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
Err:2 http://archive.ubuntu.com/ubuntu jammy InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
Get:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [109 kB]
Err:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
Get:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [90.7 kB]
Err:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
Reading package lists... Done
W: http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: http://security.ubuntu.com/ubuntu jammy-security InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://security.ubuntu.com/ubuntu jammy-security InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: http://archive.ubuntu.com/ubuntu jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://archive.ubuntu.com/ubuntu jammy InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: http://archive.ubuntu.com/ubuntu jammy-updates InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://archive.ubuntu.com/ubuntu jammy-updates InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: http://archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: http://archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: http://archive.ubuntu.com/ubuntu jammy-backports InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://archive.ubuntu.com/ubuntu jammy-backports InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: Problem executing scripts APT::Update::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true'
E: Sub-process returned an error code

原因

经过查询，发现是 Ubuntu 21.10 和 Fedora 35 开始使用 glibc>=2.34 甚至更高的版本。在 glibc 新版本里面，开始使用一个名为 clone3 的系统调用。通常情况下，容器里面所有的系统调用都会被 Docker 捕获，然后 Docker 决定如何处理它们。如果 Docker 中没有为特定系统调用指定策略，则默认的策略会通知容器这边"Permission Denied"。但是，如果 glibc 收到此错误，它不会回退。它仅在收到响应“此系统调用不可用”时才执行此操作。

解决

办法一：

运行容器的时候，加上这个参数来绕过 Docker 系统调用限制

--security-opt seccomp=unconfined

不过这会有很大的问题，一个是你的容器将变得不安全，另一个是这些参数在构建镜像的时候是不可用的。所以，请参考办法二。

办法二：

将 Docker 升级到 20.10.8 以上的版本。

During the installation of a few packages, Ubuntu usually installs the tzdata package. It's usually included in some PHP or Python packages dependencies. The issue with it is that it hangs and waits for user input to continue the installation. It's ok until we are using Docker and trying to build images (it's hanging or even throwing errors in newer versions of Ubuntu). We will try to reproduce the situation and try to fix it.

To reproduce the hanging situation, we can use this Docker image:

FROM ubuntu:20.04
RUN apt update
RUN apt install -y tzdata

Here is the logs that we see in terminal:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Step 1/3 : FROM ubuntu:20.04
 ---> 1e4467b07108
Step 2/3 : RUN apt update
 ---> Using cache
 ---> 174ce3e1bb84
Step 3/3 : RUN apt install -y tzdata
...
Configuring tzdata
------------------

Please select the geographic area in which you live. Subsequent configuration
questions will narrow this down by presenting a list of cities, representing
the time zones in which they are located.

  1. Africa      4. Australia  7. Atlantic  10. Pacific  13. Etc
  2. America     5. Arctic     8. Europe    11. SystemV
  3. Antarctica  6. Asia       9. Indian    12. US
Geographic area: 

And here it hangs waiting for us enter data, and even after you'll enter a region — the process will not resume.

To fix this situation we need to add lines 3 and 4 to our Dockerfile. We will create a variable called $TZ which will hold our timezone, and the create a /etc/timezone file:

1
2
3
4
5
6
7

FROM ubuntu:20.04

ENV TZ=Asia/Dubai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

RUN apt update
RUN apt install -y tzdata

And after building image we will see this output:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Step 1/5 : FROM ubuntu:20.04
 ---> 1e4467b07108
Step 2/5 : ENV TZ=Asia/Dubai
 ---> Using cache
 ---> 7f4c85bd0d3e
Step 3/5 : RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
 ---> Using cache
 ---> f6f784dfbad5
Step 4/5 : RUN apt update
 ---> Using cache
 ---> 5b1b5617eaa5
Step 5/5 : RUN apt install -y tzdata
 ---> Running in e71a917a9b6b
Current default time zone: 'Asia/Dubai'
Local time is now:      Tue Aug  4 12:14:55 +04 2020.
Universal Time is now:  Tue Aug  4 08:14:55 UTC 2020.
Run 'dpkg-reconfigure tzdata' if you wish to change it.

Removing intermediate container e71a917a9b6b
 ---> 3d29f4e8f7eb
Successfully built 3d29f4e8f7eb
Successfully tagged tzdata:latest

So it's used the timezone that we provide and nothing hangs.

从 Windows 10开始，微软在操作系统中设置了一个 HDR 模式。如果用户的显示器支持 HDR，打开系统中的 HDR 开关就能让整个 Windows 处于 HDR 的画面状态下。但是几乎所有人都发现，无论 HDR 的显示器亮度有多高，打开 HDR 模式后整个画面都会显得发灰，同时亮度似乎也低了一些。这个现象在亮度低色域差的显示器上会更为明显。但哪怕是 LG 的 OLED 显示器，同样会出现类似的问题，只是情况会稍微好一些。

关于这个问题网友的争论已久，也想出各种办法进行调试，但都没得到一个很好的结果。那么这个问题到底是怎么产生的呢？又有没有什么办法让显示器在 Windows 的 HDR 模式下显示出正常的颜色呢？

先看看微软怎么说

因为这个问题牵涉太多，而且现在的显示器几乎全部无解，所以很多人也希望不管是啥原因，微软最好给一个好的解决方案出来。而在微软的官方页面中，的确也有 HDR 相关的说法。其实无非是两方面，一个是开启 HDR 后画面亮度降低，一个就是开启 HDR 后颜色显示不准确，这两种问题加起来就是我们常说的画面发灰。针对亮度变化的情况，微软也有自己的说法，微软表示如果遇到所有 SDR 内容和应用，在支持 HDR 的显示器上出现显示亮度过高或过低的情况时，可以在 HDR 的选项中，在“HDR/SDR 亮度平衡”下面，拖动滑块以在 HDR 和 SDR 内容之间获得正确的亮度平衡。这个方法的确有效，可以调整桌面的亮度，但很明显会让整个画面呈现过曝或者曝光不足的状态，而且实际上桌面整体发灰颜色暗淡的问题并没有解决，只是可以让视觉上得到一些观感的改善。而在颜色部分，微软也单独说明了，如果遇到支持 HDR 的外部显示器上无法正确显示颜色时，应该如何做。当然微软说的都是废话，微软表示支持 HDR 的显示器支持比 sRGB 更宽的色域，所以在打开“使用 HDR”后，HDR 显示器应该会正确再现桌面应用中使用的 sRGB 颜色。如果某些支持 HDR 的显示器未正确再现这些颜色，那么用户要考虑购买经过 VESA DisplayHDR 认证的显示器……

但这显然并不正确，因为我们在使用经过 VESA 认证的 HDR 显示器上，同样会遇到颜色不准确的情况，色彩暗淡即使调整亮度也无法解决，无论是 HDR400 还是 HDR1000 的显示器上都是如此。LCD也好，Mini LED 也好，OLED 也好，各种类型的显示器我们都试过了，全部都会在 Windows 的 HDR 模式下，无法显示出精准的色彩，特别是颜色亮度会明显下降，而这和实际显示器的亮度关系已经不大了。

那么要如何解决这个问题呢？