Tag: bug

家裡電腦裝 Ubuntu 18.04

上個禮拜四家裡的桌機開不了機，找了一天發現是系統的 SSD 掛掉了，就買了張 M.2 SSD，然後計畫順便把本來的 Ubuntu 16.04 升級到 Ubuntu 18.04，但 Ubuntu 18.04 把預設的界面從 Unity 換成 GNOME (然後披上 Unity 的皮)，加上前陣子系統從 Intel 平台換到 AMD，整個狀況變得超混亂之後，就變成一連串踩地雷的過程...

最一開始是 UEFI + LUKS 的安裝問題，本來想裝到 M.2 SSD 上面，但 Ubuntu 18.04 的 grub-install 就是硬寫到 /dev/sda 不能改：「“Unable to install GRUB in /dev/sda” when installing GRUB」，照著這篇的 workaround 用還是不行，最後放棄，直接生一顆 SATA SSD 接到 SATA Port 1，把 M.2 當作資料碟。

硬體相關的問題：

軟體相關的問題：

  • 目前不支援從 GUI 設定 PPPoE 的網路 (沃槽)，幾種方式裡面我推薦用 pppoeconf 設定會比較好，然後可以改 /etc/ppp/options 加上 IPv6 的設定。
  • 本來想裝 gnome-shell-extension-system-monitor 觀察系統狀態，但會造成系統超級卡，關掉後就變成普通的卡 (後來就找到 Intel I211-AT 的那個問題了)。

現在至少是堪用的程度了，接下來就是不斷的補各種設定...

Google Chrome 對 CPU bug 的 patch

既然有方向了，後續應該會有人去找底層的問題...

先是在 Hacker News 上看到「Speculative fix to crashes from a CPU bug」這個猜測性的修正，這是因為他們發現在 Intel 的 Gemini Lake 低功耗晶片組上會發生很詭異的 crash：

For the last few months Chrome has been seeing many "impossible" crashes on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes only happen with 64-bit Chrome and only happen in the prologue of two functions. The crashes come and go across different Chrome versions.

然後依照 crash log 猜測跟 alignment 有關，所以決定用 gcc/clang 都有支援的 __attribute__ 強制設定 alignment 來避開，但看起來手上沒有可以重製的環境，所以只能先把實做丟上來...

各種對 AWS Managemenet Console 的抱怨...

在 Hacker News Daily 上看到 Reddit 上面有一篇對 AWS Management Console 的抱怨文，差不多是兩個月前開始累積的：「I am stupefied every day by the awfulness of the AWS web console」。

AWS 的主力開發因為是以 API 為主，而 AWS Management Console 能做的事情一直都少蠻多的 (看起來是一個團隊在開發，然後呼叫 API)，而且的確是常常中 bug，所以會有這樣的抱怨其實不太意外...

然後就有人放火了：

[–]canadian_sysadmin 24 points 2 months ago
I see you've never used Azure...

[–]myron-semack 18 points 2 months ago
AWS’s console sucks because they don’t give a damn about UI. They are API-first.

Azure’s console sucks because they tried to make it nice but failed.

[–]ryantiger658 5 points 2 months ago
I was scrolling looking for this comment. Azures interface has made me appreciate AWS even more.

Azure 被偷戳了好幾下 XDDD 然後 GCP 也被偷戳了：

[–]edgan 1 point 2 months ago
It could br better, but it is far better than than Azure and GCP. Azure's old one was better than their new beta interface last I saw it. GCP has some interesting ideas, but the side bar centric design doesn't function well. It also tries to do too much, and is too JavaScript-y happy.

通常用 AWS 自己的 CloudFormation 或是第三方的 Terraform 管理還是比較常見的方式 (基於 Infrastructure as code 的概念)，而 AWS Managemenet Console 當作是輔助，因為目前的雲端服務在設計上的確是希望你多用 API...

Raspberry Pi 4 的 Type C 無法使用 Macbook Charger 供電的問題

Raspberry Pi 4 出來後有些災情 (畢竟又加了不少東西近去)，在 Hacker News 上看到的 Type C 介面的充電問題：「Raspberry Pi 4 not working with some chargers (scorpia.co.uk)」，引用的原文可以在「Pi4 not working with some chargers (or why you need two cc resistors)」這邊看到，裡面提到了新的 Type C 供電介面在接某些充電器時不會供電 (包括了 Macbook 的充電器)：

The new pi has been released and it has a USB Type-C connector for power however people are finding some chargers are not working with it (notably macbook chargers). Some have speculated that this is due to a manufacturer limitation on the power supplies however it is actually due to the incorrect detection circuitry on the Pi end of the USB connection.

這樣說有點偏頗，但是 Macbook 的充電器一向是 Type C 裡的指標，如果這顆充電器跟其他裝置配合上有問題，通常都是代表其他裝置的實作有問題... (噗)

這次發現的電阻問題看起來有點苦 (看起來需要改版子)，目前文章作者建議的 workaround 主要就是「不要用那麼好的設備」，比較簡單的包括了 Type C 的線不要那麼好 (像是找充手機用的線就好，不要找拿可以跑 5A 的線)，或是透過 Type A 轉 Type C 的線也應該可以避開這個問題，最差的情況應該是找其他的充電器：

Now onto some solutions. Assuming the issue you are having is caused by the problem discussed above, using a non e-marked cable (most USB-C phone charger cables are likely this type) rather than an e-marked cable (many laptop charger/thunderbolt cables and any 5A capable cable will be in this category) will allow for the pi to be powered. In addition using older chargers with A-C cables or micro B to C adaptors will also work if they provide enough power as these don’t require CC detection to provide power. Ultimately though the best solution in the long run will be for there to be a board revision for the pi 4 which adds the 2nd CC resistor and fixes the problem.

對於已經入手的人，如果真的中獎，workaround cost 應該還在可以控制的範圍...

歐盟對十四套 Open Source 軟體推出 Bug Bounty Program

歐盟對於 14 套 open source 軟體推出 bug bounty program，協助改善這些軟體的品質 (主要是資安這塊)：「EU to fund bug bounty programs for 14 open source projects starting January 2019」、「In January, the EU starts running Bug Bounties on Free and Open Source Software」。

這十四套軟體的選擇應該可以參考「EU aims to increase the security of password manager and web server software: KeePass and Apache chosen for open source audits」這邊...

然後看到「Intigriti/Deloitte」這個才知道原來 Deloitte 也有做這個啊...

Ubuntu 撥 HiNet PPPoE 時會因為 MTU 而導致有些網站連不上

之前用 HiNet 固定制 (不需要 PPPoE，直接設 IP 就會通的那種)，跑起來順順的也沒麼問題，最近剛好合約滿了就打算換成非固定制 (需要撥 PPPoE 才會通)，結果換完後發現有些網站常常連不上 (不是一直都連不上)，但只要設了 proxy.hinet.net (今年年底要停止服務了) 或是改從 cable 線路出去就正常。

測了不少設定都沒用 (像是改 tcp timestamp 設定，或是 sack 之類的設定)，後來發現 MTU 的值不太對，用 ifconfig 看發現我的 ppp0 是 1500 而不是 1492，直接先 ifconfig ppp0 mtu 1492 改下去測，發現本來不能連的網站就通了...

(補充一下，我看了 Windows 的設定是 1480，所以也沒問題，但不知道怎麼算的...)

查了一下 MTU 相關的問題，發現在「wrong mtu value on dsl connection」這邊有討論到。裡面提到的 workaround 是到 /etc/NetworkManager/system-connections/ 裡找出你的 PPPoE 設定檔，然後在 ppp 區域的裡面寫死 mtu 參數：「mtu=1492」(這邊的 1492 是從 1500 bytes 扣掉 PPPoE 的 8 bytes 得出來的)，不過我測試發現在修改設定檔時會被改回來，加上測試發現沒用，只好自己寫一個 /etc/network/if-up.d/pppoe-mtu 惡搞了：

#!/bin/sh -e

if [ "$IFACE" != "ppp0" ]; then
        exit 0
fi

/sbin/ifconfig ppp0 mtu 1492

放進去後要記得 chmod 755。

從 ticket 上面看起來還是沒有解 (2009 年就發現了)，看起來 PPPoE 不是絕對多數而且又有 workaround，短期應該不會修正...

CVE-2018-14665：setuid 複寫檔案的 security issue...

在 Twitter 上看到的 security issue，好久沒在這麼普及的軟體上看到這種 bug 了：

在 CVE - CVE-2018-14665 的說明裡面有提到 1.20.3 前的版本都有中，但沒講到從哪個版本開始，看起來是全系列...？

A flaw was found in xorg-x11-server before 1.20.3. An incorrect permission check for -modulepath and -logfile options when starting Xorg. X server allows unprivileged users with the ability to log in to the system via physical console to escalate their privileges and run arbitrary code under root privileges.

這一臉 orz...

ORM 常見的效能問題

在「How not to structure your database-backed web applications: a study of performance bugs in the wild」這邊看到的，裡面提到的論文是以 Rails 的 ActiveRecord 分析，不過概念上還算通用...

重點在最後一張 (Table 7 那張)：

看一下在腦裡留個印象，之後遇到的時候至少大概知道怎麼查...

把本來 dehydrated 的 PPA 改成 dehydrated-lite

本來有做 dehydrated 的 PPA (在「PPA for dehydrated : Gea-Suan Lin」這邊)，後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」)，為了避免名稱相同但是內容物差很多，我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。

然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正，這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1)，這點需要注意一下：

Don't walk certificate chain for ACMEv2 (certificate contains chain by default)

之後再找機會拔掉 gslin/dehydrated，也許會照著現在 APT 內的架構來做...