Microsoft, Windows 10 güncellemesini yüklemek için komut satırı işlemlerini öneriyor

• Windows 10 için KB5034441, BitLocker atlatma açığını engellemeye yönelik bir güvenlik güncellemesi, ancak bazı PC'lerde yükleme aşamasında başarısız oluyor
• Sorunun merkezinde WinRE kurtarma bölümü var; standart Windows 10 kurulum ortamındaki bölüm boyutu güncellemeyi işlemek için yetersiz kalabiliyor
• Yükleme başarısız olduğunda 0x80070643 görüntülenebilir, ancak asıl neden CBS_E_INSUFFICIENT_DISK_SPACE anlamına gelen kurtarma ortamı hizmeti hatası olabilir
• Microsoft'un geçici çözümü, yönetici komut isteminde WinRE'yi kapatıp kurtarma bölümünü silip yeniden oluşturmayı içerdiği için sıradan kullanıcılar açısından riskli
• Kullanıcılar bu sürece “fazla teknik ve korkutucu” diyerek tepki gösteriyor ve Microsoft'un doğrudan bir düzeltme yayımlaması gerektiğine yönelik şikayetler büyüyor

---

KB5034441 yükleme hatası ve kurtarma bölümü sorunu

• Microsoft, 9 Ocak 2024'te Windows 10 21H2 ve 22H2 için KB5034441 güncellemesini dağıttı
  • Amaç, Windows Recovery Environment yani WinRE üzerinden BitLocker şifrelemesini atlatmayı mümkün kılan açığı kapatmak
• Bazı kullanıcılar güncelleme kurulumu sırasında 0x80070643 hatasıyla karşılaşıyor
  • Bu kod genel bir kurulum başarısızlığı mesajına daha yakın ve Microsoft'a göre “hata kodu işleme rutinindeki bir hata” nedeniyle gerçek nedeni doğru biçimde göstermeyebilir
• Gerçek neden, kurtarma bölümünde yetersiz alan olabilir
  • Microsoft'un verdiği gerçek hata iletisi Windows Recovery Environment servicing failed. (CBS_E_INSUFFICIENT_DISK_SPACE)
  • Standart Windows 10 yüklü PC'lerdeki kurtarma bölümünün bu güncellemeyi işlemek için yeterince büyük olmama ihtimali var

Riskli manuel geçici çözüm süreci

• Microsoft, disk alanı sorunu yaşayan kullanıcılara KB5028997 uyarınca kurtarma bölümünü elle ayarlamalarını öneriyor
  • Yönetici yetkileriyle Komut İstemi açılması gerekiyor
  • WinRE devre dışı bırakıldıktan sonra kurtarma bölümünü silip yeniden oluşturan komutların çalıştırılması gerekiyor
  • Bu, konuya alışık olmayan kullanıcıların kolayca hata yapabileceği bir süreç
• Sosyal medyada sorunun yaygın biçimde yaşandığı görülüyor ve kullanıcılar Microsoft'un sunduğu geçici çözümü uygulamaya isteksiz
  • Bazı kullanıcılar süreci “fazla teknik ve korkutucu” olarak tanımlıyor
  • Başka kullanıcılar bunun “Microsoft'un doğrudan çözmesi gereken bir sorun” olduğunu söylüyor
  • Bir diğer kullanıcı ise Microsoft'un hatasını kullanıcıların düzeltmek zorunda olmadığını, güncelleme ertelenirse Microsoft'un ileride bir düzeltme yayımlayacağını belirtiyor
• Microsoft, 16 Ocak'ta ilgili herkese açık belgeyi güncelledi
  • Ancak kılavuzun kendisi değişmedi
  • Şirket, “çözüm üzerinde çalıştığını ve gelecekteki bir sürümde güncelleme sağlayacağını” söyledi

[GN⁺]

Hacker News yorumları

• Bazı kullanıcılar güncelleme kurulumu sırasında 0x80070643 hatasını görüyor; Microsoft’a göre bu, “hata kodu işleme yordamındaki bir hata” nedeniyle gerçek bir hata olmayabilir
  Yani hata için hata kodu kodu, bir hata yüzünden hatanın hata kodunu yanlış gösteriyor
  Hata kodu işleme koduna ne kadar sık dokunuyorlar da uzun zaman önce düzeltilmemiş bir hata hâlâ kalmış merak ediyorum. Normalde bir kez yazılıp unutulacak türden bir şeye benziyor; eğer uzun süredir vardı ama fark edilmediyse, hata kodu kodunun kalite güvencesinde de bir hata varmış gibi

  • Bu yüzden istisnalar ve hata yollarıyla ilgilenen kod yazarken ya da incelerken daha katı ve titiz davranıyorum
    Normal akış kodundan daha basit, saçma derecede anlaşılır ve düşük bağlımlı olması gerektiğini düşünüyorum. Ne kalıtım ne soyutlama olmalı; bağımlılık ağacı da sığ kalmalı
    İstisna işleme hataları yüzünden sistemlerin çöktüğünü fazlasıyla sık yaşadım. İstisna yolları zaten çoğu zaman neredeyse hiç test edilmez ya da atlanır; istisnalar da tanımı gereği beklenmeyen yerlerden fırlama eğilimindedir
  • Yaşımı belli edecek ama, eskiden kullandığım OS/2 derlemesi ara sıra “Bu hata mesajı silindi” gösterirdi
  • Yaklaşık bir yıl önce üstlendiğim bir hata en sonunda günlükleme kodundaki bir istisnadan kaynaklanmıştı
    İstisna işleme kodunun fırlattığı istisnayı kaydettiği tam o durumda, günlükleme kodu bir kez daha istisna fırlatıyordu. Dahili bir araç olduğu için değişiklik günlüğü maddesini bilerek olabildiğince kafa karıştırıcı yazıp eğlenmiştim
  • En sevdiğim mesaj, küçük puntolarla “Something Happened”, sonra yine “Something Happened” idi

• Talimatları izledim ve bunun bazı kullanıcılar için epey ürkütücü görünebileceğini de anlıyorum
  Komut satırı yerine Windows Disk Management ile bölümü küçültüp gereken alanı oluşturdum
  Bu süreç için bir betik olmaması şaşırtıcı; bu da işin o kadar karmaşık ve hataya açık olduğu anlamına geliyor gibi. Bu yüzden basitçe çift tıklamayla biten bir betik olmamasının nedeni de işlemin kendisinin zor olması diye düşünüyorum
  Birçok kişinin beklediği hızlı Windows Update düzeltmesi konusunda iyimser olmak zor; ama yakında üçüncü taraf geliştiricilerin bu süreci otomatikleştiren betikler ya da programlar çıkaracağını düşünüyorum

  • Otomatik disk ve bölüm değişiklikleri ciddi veri kaybı açısından oldukça yüksek risk taşıyor gibi
  • Şu an bir PowerShell betiği çıkmış gibi görünüyor ama bölüm boyutunu değiştiriyor gibi değil. Deneyen var mı merak ediyorum
    https://support.microsoft.com/en-us/topic/kb5034957-updating...

• “Saldırganın Windows Recovery Environment (WinRE) kullanarak BitLocker şifrelemesini aşmasına olanak tanıyan açık” kısmı var; uzun zamandır kurtarma ortamının, otomatik olarak şifresi çözülmüş sistem sürücüsüne SYSTEM yetkileriyle erişim sağlıyor gibi görünmesi bana hep tuhaf gelmişti
  Yıllardır böyleydi ve oturum açma parolası kaybedilmiş makinelerin içeriğini dökmek için de kullanılabiliyordu. Muhtemelen asıl amaçlanan davranış bu değildi

  • Bu ancak TPM PIN kullanmıyorsanız ya da TPM 2.0’dan düşükse geçerli
    PIN ile birlikte kullanılan BitLocker’ın TPM yöntemi, TPM’e sormadan sabit disk anahtarını bilmenin bir yolu olmamasını sağlar; TPM de PIN ister. Kaba kuvvet denemesini önleme ve kilitleme de yerleşik olarak vardır
  • Hatırladığım kadarıyla WinRE, kurtarma işlemlerinden önce yerel yönetici parolasını istemiyor mu?
    Bu yüzden “otomatik kilit açma” genelde büyük bir şartlı kayıtla gelen bir özellik ve mümkünse PIN, parola veya ağ üzerinden kilit açmanın önerilmesinin nedenlerinden biri de bu. Ancak dezavantajı, her güncellemede dizüstüyle ilgilenip her yeniden başlatmada kilidi açmak zorunda kalmanız

• Microsoft, ücretsiz Insiders’a bırakmak yerine düzgün bir kalite güvence departmanını yeniden kuramaz mı? Flavor-Aid içip Microsoft’un kodu asla yanlış yazmayacağına inanan insanlara bel bağlıyor gibi görünüyor

  • Geri bildirim topluluğuna bakınca Insiders’ın tamamını böyle görmek pek doğru değil gibi
    Ancak geleneksel kalite güvence departmanını kapatmalarının üzerinden neredeyse 10 yıl geçti ve o departman dış kullanıcı doğrulamasından yararlanmanın ötesinde işler yapıyordu. Açıkçası, ondan önceki 10 yıla kıyasla Windows’un daha sık patladığını söylemek zor; ama son 20 yılda sağlık sistemleri gibi yerlerde yama sorunları yüzünden yaşanan kesinti istatistiklerini gerçek rakamlarla görmek isterdim

• Düzeltme yöntemi korkutucu görünse de, yine de bir şeyler sunmalarını olumlu karşılıyorum
  Birkaç yıl önce bir güncelleme azımsanmayacak sayıda kişinin ReFS dizilerini bozduğunda, geri alma dışında hiçbir çözüm alamamıştık; sonunda o güncelleme zorunlu hâle gelip kaldırılması da imkânsız olunca diziyi baştan oluşturmak zorunda kalmıştık

  • Bir şey sundukları doğru ama bu hâlâ büyük bir fiyasko
    Ücretli bir üründe önümüze kırıntı atıyorlar diye minnettar olacak değiliz. Niyetini farklı okuduysam kusura bakma
    Microsoft’un kurulumu bozup yarım yamalak bir düzeltme sunmasının hesabı sorulmalı. Sorun karmaşık olsa bile, masaüstü işletim sistemi pazarının lideri olup bundan muazzam para kazanan bir şirket daha iyisini yapmalı

• Sorun, kurtarma bölümünün olmaması ya da yeterince büyük olmaması
  Win10 sanal makinesinde kurtarma bölümüne ihtiyacım olmadığı için kurulumdan sonra silmiştim; şimdi o kurulumu güncelleyemez hâle geldim

  • Kurtarma bölümünü devre dışı bırakma talimatlarını izledim; sanırım en başta alan ayırmamıştım
    Yeniden başlattıktan sonra Windows 11’e yükseltebildim ve umarım ileride daha büyük sorun çıkmaz. Sonraki adım olarak yönlendirilen sistem bölümü boyutlandırmasına gerçekten dokunmak istemedim
    Duruma göre değişir ama tesadüfen karşıma çıkan bu hatanın Hacker News ana sayfasına çıkması ilginç

• “Basit bir sorunu düzeltmek için komut satırına gitmek istemediğimden Windows kullanıyorum” diye bir söz var; meğer zaten o kulübe girmişiz
  Birkaç yıl önce Windows birden kullanıcı dizinime erişim yetkim olmadığına karar vermişti; Explorer ve görev çubuğu garip şekilde bozulmuş bir sisteme dönüşmüştü
  Düzeltmek için yönetici konsoluna girip yeni bir kullanıcı oluşturmak, eski hesabın dosyalarını yeni hesaba taşımak, sonra sahiplik ve izinleri değiştirmek gerekiyordu. Yani Windows’un grafik arayüzlü olduğu için kolay olduğu düşüncesi saçmalık
  Nasıl olsa tuhaf bir hata moduna düşüp komutlar yazarak toparlamak zorunda kalacaksam, ben Linux ve NetBSD kullanmaya devam ederim

• Eski bir Windows geliştiricisi olarak Windows yükseltmeleri yüzünden ciddi şekilde sinirlendiğim anılarım var
  Kurulum klasörüne artık güvenilir biçimde yazılamaz oldu; kayıt defterine yazdırdı, sonra da veri klasörü ve başka konumlara bölerek yazmaya zorladı. Bu yüzden kurulumu “on parçaya” bölüp veri konumlarını yönetmek, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER vb. ile uğraştıktan sonra kurulum için yetki yükseltme istemek gerekiyordu
  Kurulum klasöründeki bir dosyayı silmiştim ama Windows’un arka planda o dosyanın eski sürümünü geri yüklediği bir hatayı ayıkladığımı da belli belirsiz hatırlıyorum. c:\program files sanallaştırılmıştı ve artık gerçek bir dizin gibi davranmıyordu

  • Kurulum klasörüne güvenilir biçimde yazılamaz hale gelinmesi muhtemelen Windows XP döneminde gelen bir değişiklikti ve bence iyi bir değişiklikti
    Kullanıcı programlarının çalıştırılabilir dosyalarla dolu bir klasöre yazmasına izin vermek güvenlik açısından korkunç

• Tüm güncellemeleri yayımlanır yayımlanmaz hemen kurmamanın daha iyi olduğu sonucuna da varılabilir

  • macOS ve iOS’ta biraz bekleyerek kullanıyorum, ama Windows’ta otomatik güncelleme istemediğimi anlatmanın bir yolunu bulamadım
    Özellikle gece boyunca süren hesaplama işlerinin ortasında güncelleme yapılması sıkıntı
  • Microsoft bunu değiştirdi mi, yoksa Windows 10 Home hâlâ kullanıcıyı en yeni güncellemeyi hemen kurmaya mı zorluyor?
  • Google’ın Android ve Chrome OS’ta yaptığı gibi Microsoft da bu güncellemeleri önce kendi içinde deniyor mu?

• Muhabir Linux kullanmış olsaydı, rastgele sayılar gibi görünen hata kodlarından çok daha iyi hata mesajları gösterdiğini bilirdi

  • Kelimenin tam anlamıyla yanlış hata mesajının gösterildiği bir durum değil mi?
    Microsoft’a göre “hata kodu işleme rutinindeki bir hata nedeniyle” bu hata doğru hata olmayabilir deniyor
  • Windows’u kullanımı kolay yapan şey hata mesajları değil, tek tıkla çözümdür
  • Çıkış kodu 139, hımm
  • Doğru, ama bazen işe yarar mesajı yalnızca dmesg içinde bulabiliyorsunuz