Ubuntu 上 PPPoE 自動重撥的設定

tl;dr:在設定檔裡面除了 persist 外,還要加上 maxfail 0

中華 HiNet 家用方案有提供固一動七的 IPv4 address 可以用,我自己因為玩 DevOps/SRE 的項目,有個固定 IPv4 address 弄一台便當盒小主機跑個 Ubuntu 系統當 jump server (跳板機) 總是對於防火牆的設定比較友善。

家用方案的固定 IP 在網站上申請完以後,透過 PPPoE 撥號指定另外一組 username 拿到。

我遇到的問題時大多數斷線後會自己重連,但偶而就是不會,這次難得在土城家裡的主機發生,看 log 發現是 pppd 自己 exit 了:(時間是 UTC,大約是 2024/02/22 的早上三點多)

Feb 21 19:09:15 kennel pppd[716]: No response to 4 echo-requests                                                      
Feb 21 19:09:15 kennel pppd[716]: Serial link appears to be disconnected.                                             
Feb 21 19:09:15 kennel pppd[716]: Connect time 7434.5 minutes.                                                        
Feb 21 19:09:15 kennel pppd[716]: Sent 1240056869 bytes, received 1018762497 bytes.                                   
Feb 21 19:09:21 kennel pppd[716]: Connection terminated.                                                              
Feb 21 19:09:21 kennel pppd[716]: Connect time 7434.5 minutes.                                                        
Feb 21 19:09:21 kennel pppd[716]: Sent 1240056869 bytes, received 1018762497 bytes.                                   
Feb 21 19:09:21 kennel pppd[716]: Modem hangup                                                                        
Feb 21 19:10:27 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:10:27 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:11:32 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:11:32 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:12:37 kennel pppd[716]: Timeout waiting for PADO packets                                                    
Feb 21 19:12:37 kennel pppd[716]: Unable to complete PPPoE Discovery                                                  
Feb 21 19:13:42 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:13:42 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:14:47 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:14:47 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:15:52 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:15:52 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:16:57 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:16:57 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:18:02 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:18:02 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:19:07 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:19:07 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:20:12 kennel pppd[716]: Timeout waiting for PADO packets
Feb 21 19:20:12 kennel pppd[716]: Unable to complete PPPoE Discovery
Feb 21 19:20:12 kennel pppd[716]: Exit.

這邊算了一下「Unable to complete PPPoE Discovery」出現了十次,這種數字看起來就蠻可疑的,回頭去 pppd 的說明找 10 可以看到這段:

Terminate after n consecutive failed connection attempts. A value of 0 means no limit. The default value is 10.

接著網路上翻,在「How do I set a PPPoE connection to redial?」這邊看到有人也提到了這點:除了 persist 以外,也要記得改 maxfail...

Ubuntu 的 Phased Update

Ubuntu 22.04 上面常常會遇到跑 apt upgrade 時系統跟你說有些 package 不打算升級:

$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  python3-distupgrade ubuntu-release-upgrader-core ubuntu-release-upgrader-gtk
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

以往遇到這種情況,如果確定要裝就是開 dist-upgrade 下去,但會發現也還是不為所動:

$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  python3-distupgrade ubuntu-release-upgrader-core ubuntu-release-upgrader-gtk
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

這個可能是遇到 PhasedUpdates,這個設計是在最後一關推出去的階段,一次不要更新 100% 的機器。

可以從 apt policy 看到現在的比率是 20%:(這是我已經升級上去的樣子)

$ apt policy python3-distupgrade
python3-distupgrade:
  Installed: 1:22.04.18
  Candidate: 1:22.04.18
  Version table:
 *** 1:22.04.18 500 (phased 20%)
        500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
        100 /var/lib/dpkg/status
     1:22.04.10 500
        500 http://tw.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://tw.archive.ubuntu.com/ubuntu jammy/main i386 Packages

而對於 LTS 的使用者,這個功能在 APT 的支援是從 Ubuntu 22.04 開始,以前只有桌面的 Update Manager 才有支援,所以不太會遇到:

Up to Focal (20.04), Update Manager is the only package manager that supports phased updates (reference). Any other update mechanism installs all updates regardless of the Phased-Update-Percentage.

(話說 wiki 頁上面可以看到有「User stories」這段,用 User story 的格式把這個功能的目的描述出來了)

所以一般人可以忽略掉,而對於有意願想要幫忙測試的人,也可以透過設定蓋過 Phased Updates 的比例設定...

VirtualBox 的 KVM backend 版本

看到「VirtualBox KVM Public Release (cyberus-technology.de)」這邊的討論,原文是「VirtualBox KVM public release」,專案則是在 GitHub 上的 cyberus-technology/virtualbox-kvm 這邊。

這個算是解決了 VirtualBoxLinux 上常遇到的問題:當使用 VirtualBox 時無法同時使用 KVM,像是 qemu-kvm 這樣的工具。

不過看起來是直接大改 VirtualBox,而不是補一個 extension 或是 plugin 的感覺,雖然說明現有的 guest OS 可以直接套用。

沒有 pre-compiled binary,需要自己編,而且目前的版本得用 Ubuntu 22.04 內的 GCC 11 編譯,裝了新版的 GCC 12 會有狀況:

Newer GCC versions (>= 12) might cause build issues.

另外目前的主要測試的平台還是以 Intel 為主,AMD 這邊是「會動」但沒有詳細測過:

Currently, Intel x86_64 is the only supported host platform.
AMD will most likely work too but is considered experimental at the moment.

然後在比較新的 Intel 平台上,Linux kernel 有些東西要開機參數調:

Starting with Intel Tiger Lake (11th Gen Core processors) or newer, split lock detection must be turned off in the host system. This can be achieved using the Linux kernel command line parameter split_lock_detect=off or using the split_lock_mitigate sysctl.

看到編譯參數裡面的 --disable-hardening,hmmm... 先繼續放著看看?

Gentoo 宣佈支援 binary package

Hacker News 上看到「Gentoo goes Binary (gentoo.org)」這篇,原文在「Gentoo goes Binary!」這。

Gentooportage 知名,這點在維基百科條目開頭就有提出來:

Gentoo Linux (pronounced /ˈdʒɛntuː/ JEN-too[3]) is a Linux distribution built using the Portage package management system. Unlike a binary software distribution, the source code is compiled locally according to the user's preferences and is often optimized for the specific type of computer.

這算是 Gentoo 的特色,不過即使 Gentoo 超愛 source package,也還是支援 binary package 安裝,但以前只提供重點套件,這包括了像是 Linux kernel 以及 gcc 這種套件,總是要有這些東西才能開始編軟體。

而這次公告宣佈要全面支援 binary package 算是個大轉變:

To speed up working with slow hardware and for overall convenience, we’re now also offering binary packages for download and direct installation!

目前 binary package 的主力會在 amd64 與 arm64 平台,然後提到這會對 mirror site 有額外的空間需求:

For most architectures, this is limited to the core system and weekly updates - not so for amd64 and arm64 however. There we’ve got a stunning >20 GByte of packages on our mirrors, from LibreOffice to KDE Plasma and from Gnome to Docker. Gentoo stable, updated daily.

從文末的圖也可以看到「the amount of binary package data in GByte for each architecture」得資訊:

想得到的客群大概是兩種,第一類是對於想用 Gentoo 看看的人來說會更好入手,尤其是手上是 Raspberry Pi 這些 CPU 不快的 SBC 會方便不少...

另外一種是不太在意效能,但是對某些 package 來說有高度客製化需求的人,會希望自己編這些 package 的人,透過 portage 自己調整。

AMD Zen 3 與 Zen 4 上 FSRM (Fast Short REP MOV) 的效能問題

前幾天 Hacker News 上討論到的一篇:「Rust std fs slower than Python? No, it's hardware (xuanwo.io)」,原文則是在「Rust std fs slower than Python!? No, it's hardware!」。

原因是作者收到回報,提到一段 Rust 寫的 code (在文章裡面的 read_file_with_opendal(),透過 OpenDAL 去讀) 比 Python 的 code 還慢 (在文章裡面的 read_file_with_normal(),直接用 Python 的 open() 開然後讀取)。

先講最後發現問題是 Zen 3 (桌機版 5 系列的 CPU) 與 Zen 4 (桌機版 7 系列的 CPU) 這兩個架構上 REP MOV 系列的指令在某些情境下 (與 offset 有關) 有效能上的問題。

FSRM 類的指令被用在 memcpy()memmove() 類的地方,算是很常見備用到的功能,這次追蹤的問題發現在 glibc 裡面用到導致效能異常。

另外也可以查到在 Linux kernel 裡面也有用到:「Linux 5.6 To Make Use Of Intel Ice Lake's Fast Short REP MOV For Faster memmove()」,所以後續應該也會有些改善的討論...

Ubuntu 這邊的 issue ticket 開在「Terrible memcpy performance on Zen 3 when using rep movsb」這,上游的 glibc 也有對應的追蹤:「30995 – Zen 4: sub-optimal memcpy on very large copies」。

從作者私下得知的消息,因為 patch space 的大小限制,AMD 可能無法提供 CPU microcode 上的 patch,直接解決問題:

However, unverified sources suggest that a fix via amd-ucode is unlikely (at least for Zen 3) due to limited patch space. If you have more information on this matter, please reach out to me.

所以目前比較可行的作法是在 glibc 裡面使用到 FSRM 的地方針對 Zen 3 與 Zen 4 放 workaround,回到原來沒有 FSRM 的方式處理:

Our only hope is to address this issue in glibc by disabling FSRM as necessary. Progress has been made on the glibc front: x86: Improve ERMS usage on Zen3. Stay tuned for updates.

另外在追蹤問題的過程遇到不同的情境,得拿出不同的 profiling 工具出來用,所以也還蠻值得看過一次有個印象:

一開始的 timeit 算是 Python 裡面簡單的 benchmark library:

接著的比較是用 command line 的工具 hyperfine 產生出來的 (給兩個 command 讓他跑),查了一下發現在 Ubuntu 官方的 apt repository 裡面有包進去 (22.04+):

再來是用 strace 追問題,這個算是經典工具了,可以拿來看 syscall 被呼叫的時間點:

到後面出現了 perf 可以拿來看更底層的資訊,像是 CPU 內 cache 的情況:

接續提到的「hotspot ASM」應該也還是 perf 輸出的格式,不過不是那麼確定... 在「perf Examples」這邊可以看到 function 的分析:

而文章裡的則是可以看到已經到 assembly 層級了:

差不多就這些...

Bcachefs 進入 Linux Kernel 6.7 主線了

Bcachefs 是 Linux 下一個新的 filesystem (但也發展了好幾年),剛剛看到進入 Linux Kernel 6.7 的主線了:「Bcachefs Merged Into The Linux 6.7 Kernel」。

看起來沒搭上 6.6 的列車 (前幾天出的,2023/10/30),但以目前 Linux Kernel 的步調來看,6.7 應該是兩個月後就會釋出,Ubuntu 有機會在明年的 24.04 內建...

從官網列出來的功能可以知道,Bcachefs 實作了很多現代 filesystem 會發展的功能,像是 compression、encryption 以及 snapshots,另外底層也實作了 checksum 與 copy on write。

這樣看起來,Bcachefs 目前在 Linux 上主要的競爭對象應該會是 OpenZFS。真正的比較應該會等到 6.7 的 rc 版本就會有人下去測,到時候再看看,甚至看看有沒有機會取代 ext4 變成預設的 filesystem。

查詢 Debian 與 Ubuntu 官方的 apt repository 的版本資訊

因為在寫「Python 3 的支援週期」這篇時需要查不同作業系統版本下的 python3-minimal 版本資訊,一開始是到 packages.ubuntu.com 上查,但上面只列出了目前還有支援的作業系統的套件。

所以就到 Ask Ubuntu 上面問:「How to search package information on unsupported Ubuntu distribution」。

看起來有兩個方法可以拉到歷史資料,一個是 devscripts 裡面的 rmadison,直接帶入要查的套件名稱就可以了:

$ rmadison python3-minimal

另外一個是到 https://ubuntu-archive-team.ubuntu.com/madison.cgi 這邊查,這個位置也是 rmadison 預設的 backend,資料應該是一樣的。

而加上 -u debian 可以改查 Debian 這邊的資訊,用 -h 可以看到還有那些 alias 可以用。

目前 Ubuntu 這邊可以查到最舊的版本是 trusty (14.04),如果要更舊的版本資訊,需要去 launchpad.net 上面翻,像是 https://launchpad.net/ubuntu/precise/+package/python3-minimal 這個。

Linux Kernel 後續的 LTS 版本將縮短成兩年

在「Long-term support for Linux kernel to be cut as maintainence remains under strain」這邊看到 Linux Kernel 後續的 LTS 版本將縮短成兩年的消息:

Here's one major change coming down the road: Long-term support (LTS) for Linux kernels is being reduced from six to two years.

主要的原因是舊版用的人並不多:

Why? Simple, Corbet explained: "There's really no point to maintaining it for that long because people are not using them." I agree. While I'm sure someone out there is still running 4.14 in a production Linux system, there can't be many of them.

而目前的 LTS kernel 還是會走完本來計畫的時間,4.14、4.19、5.4 以及 5.10 從表上看都是六年,5.15 是五年,最新的 LTS 6.1 則是四年。

降到兩年的話,代表各家 Linux distribution 在 LTS kernel 跑完生命週期後就得自己維護安全性更新了,或是直接升級到另外一個 kernel 版本 (後者的方法風險高一點,不確定系統的相容性)。

看起來 5.10 與 6.1 會跑很久了,都到 2026 年十二月...

ReiserFS 被標為 Obsolete

八月底的時候看到「ReiserFS Officially Declared "Obsolete"」這則新聞,這個有進到 Linux kernel 的是 Reiser3,不是後來有人接手但沒有進到 Linux kernel 裡的 Reiser4

在 5.18 的時候先標成 deprecated:「Linux 5.18 Moves Ahead With Deprecating ReiserFS」。

這次的 6.6 則是標成 Obsolete,逐步從 Linux kernel 裡面拔除:

As part of updates to the older file-system drivers for Linux 6.6, the ReiserFS file-system is no longer marked as "Supported" but is officially treated as "Obsolete" within the Linux kernel.

目前各大 Linux 套件的預設檔案系統應該都是 ext4,另外有些特殊情境下 XFS 也蠻好用的 (像是資料庫),對於追求極限性能的情境下比 ext4 快一些。

憑著印象,加上查了說明確認,ResierFS 應該是在小檔時會有優勢:

Compared with ext2 and ext3 in version 2.4 of the Linux kernel, when dealing with files under 4 KiB and with tail packing enabled, ReiserFS may be faster.

不過這是前 SSD 時代的產物了,但也沒有看到後續的比較了...

Mac (M1/M2) 上的 Asahi Linux 支援 OpenGL ES 3.1

在「The first conformant M1 GPU driver」這邊看到 Mac (M1 系列與 M2 系列) 上的 Asahi Linux 支援 OpenGL ES 3.1 了。

文章裡面有提到,目前 macOS 上沒有業界標準介面可以用:

Unlike ours, the manufacturer’s M1 drivers are unfortunately not conformant for any standard graphics API, whether Vulkan or OpenGL or OpenGL ES. That means that there is no guarantee that applications using the standards will work on your M1/M2 (if you’re not running Linux).

也許有機會會看到有人 backport 回 macOS 上?