如何在 Disco 中升級到 systemd-241?

如何在 Disco 中升級到 systemd-241?

systemd-240 中存在一個影響 jackdbus 的錯誤,它破壞了我的整個音訊設定。該錯誤已在 systemd-241 中修復。有沒有辦法升級到systemd-241?

答案1

另一個選擇是重新編譯 systemd-240 並套用補丁,假設它完全適用於 systemd-240。

如果可以的話,確實很簡單。您只需將您的補丁新增至 ubuntu 已使用的補丁清單即可。

答案2

免責聲明

我並不是提倡用這種方法來解決問題。嘗試一下,風險自負。

此外,Ubuntu 19.10 附帶 systemd 242,因此,如果您計劃升級到 Ubuntu 19.10,則沒有理由嘗試此操作。

“修復”目前安裝

基本上就是這個想法solsTiCe 的回答:修補發行版的原始碼。但是:不要重新安裝整個systemd系統。僅替換systemd可執行檔 - 這是可以完成的,因為補丁僅影響systemd.這樣我就確信不會嚴重搞亂目前的安裝。

我的解決方案路徑並不像我將要描述的那樣“線性”,因為首先我想修補原始系統 v240(使用 v241 中的正確位元),建立它並自訂安裝它。然後我轉向使用建構器

下面的描述是這樣寫的彷彿我直接明白了。我希望在清理台階的過程中我沒有忘記細節。

跟隨這個指南安裝建構器、準備建置環境(sudo pbuilder create --distribution disco --debootstrapopts --variant=buildd)、下載原始碼(apt-get source systemd)。您將獲得三個檔案(兩個存檔和一個.dsc)和一個目錄。因此,您可能希望在一個全新的資料夾中執行 apt-get 命令,以避免當前目錄中的檔案污染。

然後,克隆systemd github 儲存庫並查看標籤 v241 ( git checkout tags/v241)。

現在,diff -u在 Ubuntusrc/core/main.c和標籤 v241 之間取得補丁,例如my.patch。我對其進行了編輯,以刪除可能影響內存鎖限制之外的內容(對打開文件描述符的數量也進行了類似的修復,我也保留了它),並且還以以下形式獲得正確的標頭:

--- a/src/core/main.c ....
+++ b/src/core/main.c ....

當然,您可以使用其他名稱來代替a和。b

資料夾內systemd-240(透過運行獲得apt-get source systemd)有debian/patches.複製到my.patch那裡並將文件名添加到debian/patches/series.

嘗試建置包(sudo pbuilder build systemd_240-6ubuntu5.dsc);這也應該獲得依賴關係,如果一切正常,你就可以得到.debin /var/cache/pbuilder/result/;但這是「原創」。

更改目錄systemd-240並運行pdebuild --use-pdebuild-internal.

過了一會兒……出現/var/cache/pbuilder/result了一個新的.deb(與之前的名稱相同……),但這次是經過修補的。如果這樣做,您應該會看到一條線

tar -tJf /var/cache/pbuilder/result/systemd_240-6ubuntu5.debian.tar.xz |grep my.patch

前提是您已命名您的補丁my.patch並且該補丁也tar.xz如此命名。

現在,將.debin a-folder( dpkg-deb -R systemd_240-6ubuntu5_amd64.deb a-folder) 解壓,並作為根複製a-folder/lib/systemd/systemd/lib/systemd/.不要忘記備份原始文件/lib/systemd/systemd(我已將其重命名為__systemd)。如果出現問題,您可以用舊的替換新的,可能是透過還原 shell 進行的。

重新啟動後ulimit -l應該說unlimited(取決於您的配置,但我想您已經閱讀到目前為止,因為這是您對音訊群組中的使用者的期望)。

資源

  • 系統v240已打補丁;我還沒有編譯並嘗試過這個 - 如果你並且想要systemd從原始版本升級,那麼我建議使用最新版本,選擇最新標籤,例如今天是v243
  • 補丁為github上的要點,這個應用在Ubuntu的systemd源碼上,版本240-6ubuntu5.7。

該補丁不會按照上一節中的說明生成,因為我已經不同的Ubuntu 的原始碼已經打過補丁,main.c你可以在前述關聯分支。最終結果應該不會相差太大。

最後說明

當我第一次注意到這個問題時,有時候,在檢查配置是否正確後,我決定等待 Ubuntu 修復它(我無法追溯到 systemd 的錯誤)。

但今天它阻止了我做我真正想做的事情,因此我決定是時候做點什麼了。

這裡評論7這是我發現的地方系統錯誤第一次提到,然後我發現了這個問題。

幾個小時後,我還看到了兩天前的 19.10 公告。

無需指出,替換「套件控制系統」中的可執行檔不一定是個好主意。不過,在這種情況下,我覺得沒問題。

相關內容