Linux'ta güncellemeleri otomatik denetlemeyi iptal etmek

Genellikle linux bilgisayarlarda ilk yaptığım, açılışta güncellemeleri kontrol etmek olur. Ama ben bunu yaparken zamanlanmış görevlerden biri de aynı işlemi yapıyor olur. Bu durumda önce devam eden görevin bitmesini beklemem gerekir. Ben kullandığım bilgisayarlarda otomatik güncelleme denetlemesini faydalı bulmadığım için devre dışı bırakmak istiyorum. Fedora GNOME için bu:

sudo systemctl disable dnf-makecache.timer
sudo systemctl disable dnf-makecache.service
sudo systemctl disable packagekit

komutlarıyla mümkün. Ubuntu GNOME için ise bunlara ek olarak

sudo systemctl disable apt-daily.timer
sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily.service
sudo systemctl disable apt-daily-upgrade.service

yapılması ve /etc/apt/apt.conf.d/20auto-upgrades dosyasının ilk satırındaki

APT::Periodic::Update-Package-Lists "1";

satırının sonundaki 1'in 0 yapılarak şu hale getirilmesi gerekiyor:

APT::Periodic::Update-Package-Lists "0";

systemctl disable işlemine ek olarak systemctl stop işlemleri de mevcut oturum için gerekli olabilir. Seçimlik.

Fedora XFCE için ise dnfdragora'nın her açılışta sistem tepsisinde görünmesini ve bildirimler vermesini engellemek için /etc/xdg/autostart konumundaki ilgili dosyanın etkisiz hale getirilmesi (silinerek, başka yere taşınarak veya dosyanın düzenlenmesi aracılığıyla) gerekiyor.

LVM - LV genişletme

Bir RockyLinux sunucum vardı. Varsayılan kurulumda disk bölümlendirmesini bırakarak gitmenin cezasını 1 TB'lık bir diskte 900 GB home bölümü ve 70 GB'lık bir root bölümü oluşturması şeklinde ödedim. Root doldu. Home'u küçültüp, root'a yer açmak gerek. Ama bütün Redhat, CentOS ve RockyLinux kurulumlarında varsayılan dosya sistemi XFS olduğu için ve XFS de küçültme işlemini desteklemediği için bu disk bölümünü silip tekrar oluşturmak zorundayım. Bu amaçla sanal makineyi ISO disk kalıbı ile açmak (ilk ekranda "Troubleshooting", sonra "Rescue a Rocky Linux system", sonrasında da 3'e basarak "Skip to shell" diyerek) bir seçenek. Ama LVM ve XFS üzerinde çalışırken diski unmount etmemize gerek yok. /home disk bölümü içine erişen bir uygulama yoksa (ya da onu geçici olarak durdurabiliyorsak) sunucuyu root ile açıp işlemlerimize devam edebiliriz.

Başlamadan önce sunucumuzda xfsdump ve xfsprogs paketlerinin yüklü olduğunu doğrulamak gerek:

# dnf list installed xfsdump xfsprogs

Her şeyin durumunu görebilmek için mevcut volume gruop (VG) yapısını listeleyerek başlayalım:

# vgs

VG        #PV        #LV        #SN    VSize        VFree
rl        1            3          0    <1022.41G    0

Bundan sonra da mantıksal bölümleri (logical volume, LV) inceleyelim:

# lvs
LV      VG    LSize
home    rl    948.46g
root    rl     70.00g
swap    rl     <3.95g

İlk iş, home'un yedeğini almak. Bunun için xfs araçlarından xfsdump ve xfsrestore'u kullanabiliriz. Bu aşamada /home mount edilmiş olmalı.

# mkdir /backup

# xfsdump -l 0 -f /backup/home_backup.dump /home

Sonrasında .dump dosyasının durumunu kontrol etmek için

# ls -lh

# xfsdump -I

# xfsrestore -t -f /backup/home_backup.dump

kullanılabilir. Bu aşamada artık /dev/rl/home'u silip yeniden oluşturabiliriz. Silmeden önce unmount etmeliyiz.

# umount /home

Eğer /home bağlantı noktasının meşgul olduğuna dair bir hata ile karşılaşırsak lsof /home ile bakabilir, PID'leri kontrol ettikten sonra kill -9 <PID> ile sonlandırıp tekrar unmount etmeyi deneyebiliriz.

Şimdi home mantıksal bölümünü silebiliriz:

# lvremove /dev/rl/home

home'u sildikten sonra VG içinde boş yer açılmış olmalı:

# vgs
VG    #PV    #LV    #SN    VSize        VFree
rl    1        2      0    1022.41g    948.46g

#LV bir azaldı, VFree alanı da sildiğimiz mantıksal bölüm boyutunca arttı. Şimdi tekrar, daha küçük bir home mantıksal birimi oluşturalım. 20G yeter de artar bile.

# lvcreate -L 20G -n home rl

Bu komut sonunda

WARNING: xfs signature detected on /dev/rl/home at offset 0 Wipe it? [y/n]:

gibi bir uyarı verdi. Oluşturduğumuz yerde eski bir xfs bölümü kalıntısı bulmuş. Bu bilgiyi kullanabileceğim bir yer bulamadım. Sanıyorum veri kurtarma teknikleri ile yanlışlıkla silinmiş bir mantıksal bölümü geri getirmek için. Bizim amacımız bu değil; y'ye basarak işleme devam edebiliriz. Sonrasında sırasıyla yeni oluşturulan bölümü biçimlendirip, mount edip, yedekten geri yükleyeceğiz:

# mkfs.xfs /dev/rl/home

# mount /dev/rl/home /home

# xfsrestore -f /backup/home_backup.dump /home

Bu sayede çok ilginç bir şey daha öğrendim; eğer bir sunucu için /home klasörü ve içindekiler, bir kişisel bilgisayarın /home klasörüne kıyasla daha vazgeçilebilir ise veya yedeklemeyi unuttuysak /home klasörümüzü ve diğer birkaç varsayılan dosyayı yaratmak için şurada bahsedildiği gibi aşağıdaki komutu kullanabiliriz:

# mkhomedir_helper kullanici_adi

Nihayet /dev/rl/root mantıksal birimini genişletebiliriz. Önce mevcut VG'deki boş yeri kontrol edelim:

# vgs

VG    #PV    #LV    #SN    VSize        VFree
rl    1        3      0    1022.41g    928.46g

Evet, 928 GB yer hala mevcut. root mantıksal birimini VG içindeki tüm boş alanı kapsayacak şekilde (-l +100%FREE) genişletelim:

# lvextend -l +100%FREE /dev/rl/root

LV'nin genişlediğini doğrulayalım:

# vgs

VG    #PV    #LV    #SN    VSize        VFree
rl    1        3      0    1022.41g        0

ve

# lvs 

LV      VG    LSize
home    rl     20.00g
root    rl    998.46g
swap    rl     <3.95g

LV genişledi, ama içindeki xfs dosya sisteminin boyutu hala eski boyutlarında:

#df -hT

Filesystem           Type  Size   Used    Avail  Use%    Mounted on
/dev/mapper/rl-root  xfs   70G    50G    20G     72%     /
/dev/mapper/rl-home  xfs   20G    176M   20G      1%     /home
/dev/sda1            vfat  599M    7.0M  592M     2%     /boot/efi
/dev/sda2            xfs  1014M   316M   699M    32%     /boot

Sıra root mantıksal biriminin içindeki xfs dosya sistemini genişletmeye geldi:

# xfs_growfs /dev/rl/root

Nihayet o da genişledi

# df -hT

Filesystem           Type    Size    Used   Avail  Use%   Mounted on
/dev/mapper/rl-root  xfs     999G    57G    942G    72%   /

Eğer herşey tamamsa /backup/home_backup.dump'ı silebiliriz.

chrony

Yerel ağda çevrimdışı çalışan linux çalışan bir makinede zaman eşitleme sorunu olduğunu farkettim. Yerel ağımızdaki tüm Windows bilgisayalarlar, zaman eşitlemesi için etki alanı sunucumuzu kullanıyorlar. Ama linux makine için bu yapılandırma atlanmış.

Önce timedatectl ile mevcut zaman eşitlemesi yapılandırmasını kontrol ettim:

# timedatectl

               Local time: Pzt 2023-07-10 08:38:03 +03
           Universal time: Pzt 2023-07-10 05:38:03 UTC
                 RTC time: Pzt 2023-07-10 05:38:03
                Time zone: Europe/Istanbul (+03, +0300)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Zaman dilimi bilgisi doğru ve NTP eşitlemesi etkin gözüküyor. Zaman eşitleme alt bileşeni olarak ntpd, systemd-timesyncd veya chronyd kullanılıyor olabilir. systemctl status ile var olan hizmetlere baktım, sadece chronyd'nin aktif olduğunu gördüm. chrony'nin yapılandırma dosyası /etc/chronyd.conf'u açtıım

# vim /etc/chronyd.conf

Tek yaptığım ilk satırda pool direktifinin yanında yer alan eski NTP sunucusu 2.fedora.pool.ntp.org'u kaldırıp yerine yerel ağdaki sunucumun IP adresini girdim. Aslında pool kullanıldığı için yanına da ekleyebilirdim ama cihaz çoğunlukla çevrimdışı çalışacağından gerek görmedim. Daha sonra chronyd hizmetini yeniden başlattım:

# systemctl restart chronyd.service

chrony yerine ntp kurulu olsaydı onun yapılandırma dosyası da /etc/ntp.conf olacaktı. systemd-timesyncd için de yapılandırma dosyası /etc/systemd/systemd-timesyncd.conf olurdu.

Hizmetin tekrar başlatılması sonucunda zaman eşitlemesi yapılacak. Ben tcpdump ile durumu takip etmek istedim:

# tcpdump udp port 123 -i eth0

Buna alternatif olarak chronyc komut dosyası ile durumu takip edebilirim:

# chronyc sources

# chronyc tracking

Ek 2024-03-20: Alternatif bir zaman senkronizasyonu bileşeni kullanmak için chronyd hizmetini durdurup diğer hizmeti devreye almak yeterli olurdu. Örneğin systemd ile gelen timesyncd hizmetini kullanmak için aşağıdaki komutları çalıştırıp

# systemctl disable chronyd

# systemctl stop chronyd

# systemctl enable systemd-timesyncd

# systemctl start systemd-timesyncd

Sonrasında timesyncd hizmetinin /etc/systemd/timesyncd.conf konumundaki yapılandırma dosyasına bir göz atmak faydalı olurdu. Örneğin referans zaman sunucusu ile yerel saat arasında farkın çok fazla olması sebebiyle zaman eşitlenemezse journal loglarına 

Server has too large root distance. Disconnecting.

mesajı düşebilir. Bu durumda söz konusu yapılandırma dosyasındaki 

RootDistanceMaxSec

değerini saniye cinsinden aradaki farktan büyük bir değere eşitlemek gerekirdi.

---

[1] https://www.redhat.com/sysadmin/chrony-time-services-linux

[2] https://www.golinuxcloud.com/configure-chrony-ntp-server-client-force-sync/

Manjaro'da açılışta donma sorunu

Sorun birkaç kez tekrarlayınca sistem kayıtlarını incelemek istedim. Sondan bir önceki (-b -1)  boot'taki hataları ve daha önemli mesajları (-p 3) görmek için

$ journalctl -b -1 -p 3

kullandım. Şöyle birkaç satır gördüm:

Haz 25 20:32:49 manjaro kernel: iwlwifi 0000:02:00.0: pci_enable_msi failed - -22
Haz 25 20:32:49 manjaro kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000
Haz 25 20:32:49 manjaro kernel: #PF: supervisor read access in kernel mode
Haz 25 20:32:49 manjaro kernel: #PF: error_code(0x0000) - not-present page

Sonra kırmızı ile işaretlediğim "supervisor read access in kernel mode" satırını tüm kayıtlarda arattım:

$ journalctl | grep 'supervisor read access in kernel mode' 

Bu hatalar acaba her seferinde bir donma ile sonuçlanan ve güç düğmesine basılı tutarak sistemi zorla kapattığım durumlara mı sebep oluyordu, yoksa bazı durumlarda sistem normal açılmış olabilir miydi? Bunu bulmak için şu yazdımdaki yöntemi kullanarak normal kapanmayan durumları listeledim: 

$ last -Fxn52 shutdown reboot

Son iki komudun çıktılarındaki tarihlerin arasındaki korelasyon bu hatanın sonucunda bilgisayarın donduğunu gösteriyordu. journal kayıtlarımın el verdiği (yakın bir dönemde eski kayıtları bir miktar temizlemiştim) ölçüde bunun manjaro 6.1 LTS çekirdek sürümüyle ilgili olabileceğini gördüm. %100 diyemesem de sanki 6.1 sürümü öncesinde yaşamadığım bir olaydı. Bir denemek için 6.1 LTS sürümü kaldırmaya karar verdim. Önce bilgisayarı bir kez yeniden başlatıp daha önceki (5.15 LTS) bir çekirdek sürümü ile açtım. Daha sonra da şu komutla 6.1'i kaldırdım: 

$ sudo mhwd-kernel --remove linux61

Bir süre kullanıp göreceğim. Bu arada Manjaro Forum'da ([1],[2]) bu hatanın 2021'den bu yana karşılaşılabilen bir hata olduğu, ve 5.10 LTS'de bile olduğunu gördüm. Şu anda 5.15 LTS sürümümü deniyorum, birkaç gün içinde olay tekrarlarsa başka çekirdekler denemem gerekebilir.

2023-09-01: 5.15 çekirdek sürümüne geçtikten sonra bugüne kadar benzer bir sorunla karşılaşmadım. Bir sonraki LTS çekirdek sürümüne kadar 5.15'te kalacağım.

2024-03-10: Bir süre önce 6.6 LTS sürümünü görünce yükledim, ama farklı bir sonuç çıkmadı. Benim donanımımla ilgili bir sorun olduğu kesin. Hala 5.15'e devam.

---

[1] https://forum.manjaro.org/t/system-freezes-bug-kernel-null-pointer-dereference/81207/2 

[2] https://forum.manjaro.org/t/linux-5-13-acpi-call-bug-kernel-null-pointer-dereference/74307