SGI O2: PROM'dan bootp ile IRIX Kurtarmaya

SGI O2'yi component video capture denemek için yeniden kurduğumda bir dizi sorunla karşılaştım. Bunları çözdükten sonra makineyi ağa bağladım; IRIX ortamını düzenleyip Nekoware ve wget kurulumuna kadar ilerledim. Fakat ertesi gün sistemi açtığımda öncekilerden farklı boot hatalarıyla karşılaştım. Böylece tek bir arıza hikâyesi değil, peş peşe yaşanan iki ayrı kurtarma süreci ortaya çıktı: önce SGI'yi yeniden kullanılabilir hâle getirmek, ardından yeni önyükleme hatalarını ağ üzerinden IRIX kurulum ortamına girerek çözmek.

Yıllar Sonra İlk Açılış

PROM monitöründe önce hinv ile donanım envanterine baktım. Sistem IP32 olarak kendisini, 256 MB belleği ve SCSI aygıtlarını görüyordu. Gerçek sistem diski SCSI ID 2 üzerindeydi. Buna karşılık önyükleme denemelerinde media not loaded, no recognizable filesystem, Unable to execute ... /unix ve SASH ile ilgili hatalar geliyordu.

PROM donanım envanteri: IP32 sistem, 256 MB RAM ve SCSI aygıtları.

İlk açılışta karşılaşılan disk ve önyükleme hataları.

SASH ve /unix yolları denenirken alınan media/file hataları.

printenv çıktısı: bazı önyükleme değişkenleri yanlış diski gösteriyor.

Değişkenler disk(2)'ye çevrildikten sonra görülen SASH relocation/bootfile hatası.

IRIX 6.5 IP32 PROM ekranında CD-ROM ve SASH denemeleri.

PROM'da Kaybolan HDD Ayarları

printenv çıktısı sorunun ilk kısmını gösterdi: SystemPartition ve OSLoadPartition değişkenleri disk(1) tarafına kaymışken gerçek IRIX diski disk(2) idi. kernname ise disk(2)'yi gösteriyordu; yani PROM ortamındaki yollar kendi aralarında da tutarlı değildi.

Önyükleme değişkenlerini gerçek diske göre yeniden girdim:

setenv SystemPartition pci(0)scsi(0)disk(2)rdisk(0)partition(8)
setenv OSLoadPartition pci(0)scsi(0)disk(2)rdisk(0)partition(0)
setenv OSLoader sash
setenv OSLoadFilename /unix
setenv OSLoadOptions auto
setenv AutoLoad Yes
setenv kernname pci(0)scsi(0)disk(2)rdisk(0)partition(0)/unix

SystemPartition volume header içindeki standalone araçları, OSLoadPartition kök bölümü, kernname ise yüklenecek IRIX çekirdeğini gösteriyor. Bunlardan biri yanlış SCSI ID'ye baktığında disk fiziksel olarak görülse bile sistem açılmıyor.

Sorun Yalnızca PROM Değişkenleri Değilmiş

Disk yollarını düzeltmek tek başına yeterli olmadı. Bu kez SASH tarafında relocation error, invalid argument ve invalid bootfile mesajları gördüm. Bir noktadan sonra güç kablosunu takar takmaz sistem kendiliğinden çalışıyor, ön panel LED'i kırmızı yanıp sönüyor ve normal açılışa geçemiyordu. Bu aşamada yalnızca yazılım ayarıyla uğraşmayı bırakıp donanım tarafını kontrol ettim.

RTC/NVRAM, PROM Reset ve RAM'ler

İlk şüphelerden biri Dallas DS1687 RTC/NVRAM entegresiydi. Dahili pil hattını ölçtüğümde yaklaşık 3,05 V gördüm. Bu değer tamamen bitmiş bir pil göstermiyordu; dolayısıyla arızayı yalnızca “RTC pili ölmüş” diye açıklamak mümkün değildi.

Anakartı çıkarıp RTC/NVRAM bölgesini inceledim. Kartı kaldırmaya yarayan mandallardan birinin kırılması nedeniyle bunun elektriksel bir kilit olup olmadığından da şüphelendim; fakat mandalı kesin arıza nedeni yapacak bir bulgu yoktu.

CDRW konfigürasyon jumperları.

Yamaha CDRW.

PROM donanım envanterinin yeniden kontrolü.

İşlemci, bellek ve SCSI aygıtlarının kontrolü.

Donanım envanteri: disk ve CD-ROM aygıtları.

Anakart üzerindeki Dallas RTC/NVRAM entegresi.

DS1687'nin söküldükten sonraki pinleri.

Dallas DS1687-5 RTC/NVRAM.

DS1687 pinlerinin yan görünümü.

RTC/NVRAM entegresinin diğer yüzü.

DS1687 üzerinde yapılan fiziksel inceleme.

Dallas alt yüz.

RTC/NVRAM entegresinin sabitlenerek kontrol edilmesi.

DS1687 voltaj ölçümü için yontma.

Sonra PROM ayarlarını sıfırladım ve RAM modüllerini tamamen söküp yeniden oturttum. İşlemleri peş peşe yaptığım için sistemi tek başına PROM resetinin mi yoksa RAM temasının mı düzelttiğini kesin olarak ayıramıyorum. Bildiğim şey, RAM'ler yeniden takıldıktan ve PROM tarafı temizlendikten sonra makinenin yeniden normal açılış sürecine döndüğü.

1. PROM'daki hatalı HDD yollarını tespit edip disk(2)'ye göre düzelttim.
2. DS1687 RTC/NVRAM pil hattını ölçtüm: yaklaşık 3,05 V.
3. PROM ayarlarını sıfırladım.
4. RAM modüllerini söküp yeniden oturttum.
5. Disk yollarını tekrar doğrulayıp sistemi açtım.

IRIX Yeniden Açıldı

RAM/PROM işlemleri öncesindeki başarısız açılış ekranı.

RAM'ler yeniden oturtulduktan sonraki donanım kontrolü.

PROM komutları ve disk yollarının tekrar sınanması.

Önyükleme değişkenlerinin doğrulanması.

Disk ve /unix önyükleme denemesi.

Sistemin yeniden PROM menüsüne ulaşması.

Sistem açıldıktan sonra PROM/HDD değişkenlerini IRIX içinden de tekrar kontrol ettim. Aşağıdaki görüntüde SystemPartition, OSLoadPartition, OSLoader, OSLoadFilename ve kernname değerlerinin disk(2) üzerinde tutarlı hâle geldiği görülüyor.

Sistem açıldıktan sonra doğrulanan PROM/HDD değişkenleri. IRIX diski scsi(0)disk(2) yolunda.

Makine ayağa kalkınca asıl ikinci aşamaya geçtim. IRIX tarafındaki ağ ayarları yarım yamalak durumdaydı: sistem yönlendiriciye ve doğrudan IP adreslerine ulaşabiliyor, buna rağmen alan adlarını çözemiyordu. Üstelik normal kullanıcı hesabında ping bile “Command not found” diyordu. Buradan devam edip ağ, DNS, kabuk ayarları ve Nekoware paket kurulumunu tek seferde toparladım.

Bu yazı IRIX'in eski UNIX alışkanlıklarıyla modern ağın birbirine sürttüğü yerleri, yaptığım yanlış denemeleri ve çalışan son düzeni içeriyor. Ekran fotoğraflarını özellikle sırayla bıraktım; komutların gerçek sistemdeki karşılığını takip etmek isteyen için küçük bir kurulum günlüğü oldu.

Ağ Arayüzü ve /etc/hosts

Önce root oldum ve ağ servisini, makine adını, arayüzü ve yönlendirme tablosunu kontrol ettim. Makineye 192.168.1.50 adresini verdim; varsayılan ağ geçidi 192.168.1.1. /etc/hosts içinde hem localhost hem de SGI'ın kendi adı doğru IP ile bulunmalı. Ben makine adını sgi-irix olarak kullandım.

su root
hostname
ifconfig -a
netstat -rn
cat /etc/hosts
/usr/etc/ping 192.168.1.1

IRIX'te bazı yönetim komutları /usr/etc altında. Root ortamında bulunan bir komut normal kullanıcıda PATH'e girmemiş olabiliyor. Bu yüzden “ping yok” sonucu ağ aracının kurulu olmadığı anlamına gelmiyor; önce /usr/etc/ping ile denemek gerekiyor.

İlk durum: ağ servisi ve DNS çözümleme hatası.

/etc/hosts ve makine adı kontrolü.

/etc/hosts dosyasının düzenlenmesi.

ec0 arayüzü ve 192.168.1.50 adresi.

192.168.1.1 ağ geçidine ping testi.

/etc/nsswitch.conf içindeki çözümleme sırası.

DNS sunucuları ve doğrudan IP erişimi.

IP çalışırken alan adı çözümlemesinin başarısız olması.

nslookup çalışıyor; nsd önbelleği yeniden yükleniyor.

nsd süreci ve yapılandırma dosyalarının kontrolü.

nsd günlüğündeki domain/search path uyarısı.

IP Çalışıyor, DNS Çalışmıyor

Ağ geçidine ve 8.8.8.8 adresine ping başarılıydı. Yani Ethernet, IP adresi ve route tarafı çalışıyordu. Buna karşılık ping google.com hâlâ “Cannot resolve” hatası veriyordu. /etc/resolv.conf içine DNS sunucularını ekledim:

nameserver 8.8.8.8
nameserver 1.1.1.1

İlginç tarafı, nslookup google.com cevap veriyor ama normal uygulamalar alan adını çözemiyordu. IRIX isim çözümlemeyi doğrudan yalnızca resolv.conf üzerinden değil, nsd ve /etc/nsswitch.conf üzerinden yürütüyor. nsd günlüklerinde “no domain or search path in resolv.conf” uyarısını görünce dosyaya yerel ağ için bir arama alanı ekledim ve servisi yeniden yükledim.

search local
killall -HUP nsd
/etc/init.d/network stop
/etc/init.d/network start
/usr/etc/ping google.com

Buradaki local yalnızca ev ağı için kullandığım arama alanı. Kendi DNS alanınız varsa onu yazmanız gerekir. Bu düzeltmeden sonra hem IP hem alan adı çözümlemesi çalıştı.

PATH, Komut Geçmişi ve tcsh

Normal kullanıcı hesabında ping komutunun bulunmamasının nedeni PATH'ti. /usr/etc dizinini kullanıcı ortamına ekledim. Ardından her oturumda yukarı/aşağı oklarla komut geçmişini kullanabilmek için tcsh ayarlarını kalıcılaştırdım.

which tcsh
echo $SHELL
set path = ( /usr/etc $path )
set history = 100

Bu satırları kullanıcı hesabındaki ~/.cshrc dosyasına ekledim ve yeni oturum açmadan denemek için source ~/.cshrc çalıştırdım. Sonuçta ping doğrudan çağrılabildi, komut geçmişi çalıştı ve istemde makine adı görünür hâle geldi.

Kullanıcı kabuğunda ping komutunun PATH içinde bulunmaması.

/usr/etc/ping komutunun doğrudan çalıştırılması.

Ağ geçidine kullanıcı hesabından başarılı ping.

Ağ bağlantısının kararlı hâle gelmesi. (olmalı :P)

PATH değişkenine /usr/etc eklenmesi.

Kullanıcı .cshrc dosyasının incelenmesi.

Komut geçmişi ve istem ayarlarının eklenmesi.

Yeni .cshrc ayarlarının source ile yüklenmesi.

tcsh testi, tarih ve internet bağlantısının doğrulanması.

Türkçe Klavye Denemesi

Ağ işi bitince Türkçe klavye düzenine de baktım. IRIX'teki find, GNU find ile aynı seçeneklere sahip değil; örneğin -iname yok. X11 tuş eşlemelerini xmodmap -pke ile çıkardım, Türkçe karakter keysymlerini ve ISO-8859-9 fontlarını aradım.

xmodmap -pke
xlsfonts | grep iso8859-9
locale
locale -a
setenv LC_CTYPE tr

xmodmap ile tek tek keycode eşlemek mümkün görünse de sistemde xev bulunmadığı için fiziksel tuşları rahatça teşhis edemedim. Ayrıca locale ile klavye eşlemesi aynı şey değil: LC_CTYPE=tr Türkçe karakter sınıflandırmasını sağlıyor, tuşların hangi karakteri ürettiğini tek başına değiştirmiyor. Bu yüzden bu aşamada çalışan ağı bozacak kadar dosya kurcalamak yerine Türkçe klavyeyi ayrı bir işe bıraktım.

IRIX find ve chsh farklılıklarının görülmesi.

Varsayılan kabuğun /usr/bin/tcsh olarak doğrulanması.

xmodmap ile mevcut tuş eşlemelerinin dökülmesi.

Harf tuşlarının keycode değerleri.

Noktalama ve işlev tuşlarının keycode değerleri.

Yön ve sayısal tuş takımının eşlemeleri.

Üst keycode bölgesinin kontrolü.

Türkçe karakter keysymlerinin aranması.

xmodmap ile geçici Türkçe karakter eşlemesi denemesi.

Eşleme denemesinin tekrar kontrolü.

İlgili keycode satırının bulunması.

ISO-8859-9 destekli fontların listelenmesi.

Geçerli LANG ve LC_* değerleri.

Sistemdeki Türkçe locale seçeneklerinin aranması.

locale komutu ve kabuk sözdizimi denemeleri.

LC_CTYPE=tr denemesi.

xev bulunmadığı için klavye teşhisinin burada bırakılması.

Nekoware ve wget Kurulumu

IRIX üzerinde wget ve curl kurulu değildi; fakat klasik FTP istemcisi vardı. IRIX Network'ün FTP sunucusuna anonymous olarak bağlanıp nekoware/current dizinine geçtim. Nekoware paketleri tardist biçiminde ve IRIX'in kendi inst aracıyla kuruluyor.

ftp ftp.irixnet.org
Name: anonymous
cd nekoware
cd current
binary
get neko_wget-1.11.3.tardist
quit

İlk denemede paketi yanlış dizinden açmaya çalıştığım için “No such file or directory”, salt okunur konuma yazmaya çalıştığım için de izin hataları aldım. inst içinde göreli dosya adıyla uğraşmak yerine tardist dosyalarının tam yolunu vermek en temiz çözüm oldu.

Donanım özeti ve wget/curl/ftp kontrolü.

IRIX Network FTP sunucusuna bağlantı.

FTP dizinleri ve IRIX Network açıklaması.

Nekoware paket arşivinin incelenmesi.

inst paket yöneticisinin ana menüsü.

wget tardist paketinin ürün listesi.

İlk kurulum denemesinde dağıtım kaydetme uyarısı.

Salt okunur konum ve izin hatası.

root posta bildirimi ve düzenlenen sistem dosyaları.

Ara kontrol ekranı.

root .cshrc dosyasına kalıcı kabuk ayarları.

root oturumunda PATH ve kabuk kontrolü.

DISPLAY olmadığı için nedit'in açılamaması.

xmodmap denemesinin root oturumundaki sonucu.

Bağımlılıklar ve inst

wget tek başına kurulmadı; kullandığım Nekoware paketinin gettext, libiconv ve OpenSSL bağımlılıkları vardı. Paketleri önce kullanıcı dizinine indirdim, ardından root olarak inst başlattım.

su root
cd /usr/people/kadir
inst

inst ana menüsünde her paketi tam yoluyla açtım:

open /usr/people/kadir/neko_libiconv-1.14.tardist
open /usr/people/kadir/neko_gettext-0.18.1.1.tardist
open /usr/people/kadir/neko_openssl-0.9.8x.tardist
open /usr/people/kadir/neko_wget-1.11.3.tardist
list
go

Paket adı veya sürümü FTP'deki dosyayla birebir aynı olmalı. Fotoğraflardaki bazı “file not found” ve tar hataları, adı ezberden yazdığım ya da eksik inmiş dosyayı açmaya çalıştığım denemelere ait. Son turda dosyaları ls -l ile doğrulayıp tam yolları kullanınca ürün açıklamaları düzgün okundu ve bağımlılıklar birlikte seçilebildi.

inst ile yerel tardist paketlerini açma.

FTP'deki Nekoware current dizininde paket seçimi.

PASV önerisi ve gerekli bağımlılıkların indirilmesi.

libiconv, OpenSSL ve wget paketlerinin hazırlanması.

İndirilen tardist dosyalarının kullanıcı dizininde kontrolü.

root oturumuna geçiş ve paket listesinin doğrulanması.

inst ana menüsüne dönüş.

Kurulum ve kaldırma komutlarının özeti.

gettext paketi açılırken libiconv dosya adı hatası.

Dağıtımın /var/tmp altına açılması.

Paketlerin tam yol kullanılarak yeniden açılması.

inst kurulum seçim ekranı.

FTP sunucusunda nekoware/current dizinine geçiş.

gettext paketinin binary modda indirilmesi.

İndirilen paketlerle inst'in yeniden başlatılması.

Bağımlılıkların hazırlanması.

Eksik veya bozuk tardist denemesinin tespiti.

Yerel dizindeki paket dosyalarının kontrolü.

Paket adlarının ve sürümlerinin doğrulanması.

inst ile paketlerin tam yoldan açılması.

Kurulum seçimlerinin gözden geçirilmesi.

Paket açma ve bağımlılık çözümleme adımı.

Eksik OpenSSL paketiyle ilgili hata.

Nekoware paketlerinin masaüstünde kontrolü.

Kurulumun tam yollarla son kez tekrarlanması.

Netscape üzerinden yerel HTTP erişim testi.

Nekoware current dizininin Netscape'te açılması.

Paket listesinin tarayıcıdan görüntülenmesi.

İkinci Perde: Farklı Boot Hataları ve Ağdan IRIX Kurtarma

İlk sorunları giderip ağı çalıştırmış, Nekoware paketleri ve wget aşamasına kadar gelmiştim. Bugün karşıma çıkan boot hataları ise önceki arızaların devamı değil, ayrı bir olaydı. Bu kez SGI O2'yi CD-ROM'a bağımlı kalmadan modern bir Windows bilgisayar üzerinden kurtarma ortamına alabilmek için bir ağ kurulum sunucusu hazırladım. Amaç mevcut diski hemen silmek değildi; önce kurulum medyasını görünür hâle getirmek, fx ve inst yollarını doğrulamak ve diskteki mevcut IRIX kurulumunu onarmaktı.

Modern araçlardan eski silikona: Windows, WSL, Vagrant, VirtualBox ve ağ servisleri üzerinden SGI O2'ye uzanan kurtarma zinciri.

Windows tarafındaki arşivde IRIX 6.5 taban diskleriyle 6.5.3, 6.5.9 ve 6.5.30 overlay setleri zaten duruyordu. Bunları E:\Program\SGI\irixboot\irix\6.5 altında aracın beklediği foundation ve overlay30 dizinlerine yerleştirdim. Ardından Vagrantfile içindeki istemci adı, O2'nin Ethernet adresi, SGI'nin sabit IP'si, sunucu IP'si ve köprü kurulacak Windows adaptörünü kendi ağıma göre düzenledim.

clientname   = 'o2'
clientip     = '192.168.1.50'
clientether  = '08:00:69:0c:09:68'
hostip       = '192.168.1.109'
bridgenic    = 'Ethernet 2'

Vagrant ve VirtualBox ağ düzeni: köprü adaptörü, irixboot sunucusu ve SGI O2'nin aynı yerel ağdaki rolleri.

IRIX 6.5.3 kurulum ve overlay ISO dosyaları.

Arşivdeki IRIX sürüm dizinleri.

Vagrantfile'ın O2 ve yerel ağ için düzenlenmesi.

WSL, Windows yolu ve Vagrant kurulumu arasında ilk temas.

Windows tarafında irixboot dizininin kontrolü.

İlk Vagrant Çalıştırması ve Jessie Duvarı

vagrant up sanal makineyi oluşturdu, ikinci adaptörü köprü modunda açtı ve paylaşımlı klasörü bağladı. Fakat irixboot projesi artık arşivlik sayılabilecek Debian Jessie tabanını kullanıyordu. Normal paket depoları taşındığı için provision aşamasında apt 404 hataları verdi; bunun zincirleme sonucu olarak parted, mkfs.xfs, rsync, dnsmasq, DHCP, TFTP ve inetd eksik kaldı. Ekranda “Ready to network boot” yazması bu yüzden gerçeği tam anlatmıyordu: servisleri olmayan bir sunucu hazır sayılmazdı.

parted: command not found
mkfs.xfs: command not found
rsync: command not found
Failed to start dnsmasq.service
Failed to start isc-dhcp-server.service
Failed to start tftpd-hpa.service

Debian Jessie sanal makinesi oluşturuluyor.

Sanal makineye girip Jessie kaynaklarını inceleme.

IP erişimi var, DNS yok: ikinci küçük zaman kapsülü.

Jessie depoları archive.debian.org'a taşındıktan sonra apt yeniden çalışıyor.

Eksik ağ ve disk araçlarının kurulması.

Dağıtım Diskinin Yeniden Hazırlanması

Paketler kurulunca paylaşımlı dizindeki Foundation ve 6.5.30 overlay görüntülerini doğruladım. İlk başarısız deneme geride yarım hazırlanmış bir /irix dizini ve .irixboot işaret dosyası bırakmıştı. Betik bu dosyayı görünce dağıtımın hazır olduğunu sanıyordu. İşaret dosyasını kaldırıp dist.sh 6.5 komutunu yeniden çalıştırınca ikinci sanal disk XFS olarak biçimlendirildi ve disk görüntülerinin içeriği gerçek dağıtım ağacına kopyalandı.

ls -lh /vagrant/irix/6.5/foundation/ /vagrant/irix/6.5/overlay30/
sudo rm /irix/.irixboot
sudo /vagrant/scripts/dist.sh 6.5

Yarım kurulumun bıraktığı yanıltıcı .irixboot işareti.

Betiğin dağıtımı hangi koşulla hazır saydığının bulunması.

O2 için BOOTP/TFTP/RSH zincirinin başlatılması.

Foundation ve overlay30 görüntüleri doğru yerde.

O2 Üzerinde inst ile Onarım

Sunucu tarafı ayağa kalktıktan sonra O2'yi PROM menüsünden Install System yoluyla ağ kaynağına yönlendirdim. inst açıldığında önce dağıtım kaynağını, ardından sistem diskini denetledim. Bu noktada kritik ayrıntı, IRIX'in kök dosya sistemini geçici olarak /root altına bağlamasıydı. Dolayısıyla normal açılmış sistemdeki /bin yerine kurtarma ortamında /root/usr/bin ve benzeri yolları görmek doğaldı.

Dosya sistemi erişilebiliyordu; /root/unix okunuyor, dizin yapısı duruyordu. Kurulum/onarım işlemi tamamlandıktan sonra restart seçildi. Asıl hüküm yeniden açılışta verildi: makine PROM'a geri düşmedi, IRIX masaüstüne sorunsuz ulaştı.

O2, ağdaki IRIX kurulum ortamına bağlanıyor.

inst içinde dağıtım kaynağı ve sistem diski.

Kök dosya sistemi kurtarma ortamında /root altında.

Dizinler ve /root/unix yerinde.

Onarımın ardından restart aşaması.

Sonuç

Son durumda SGI yerel ağda 192.168.1.50 adresiyle çalışıyor; ağ geçidine, internetteki IP adreslerine ve alan adlarına ulaşabiliyor. Normal kullanıcı ortamında /usr/etc PATH içinde, varsayılan kabuk tcsh ve komut geçmişi kalıcı. Daha önemlisi, Windows üzerindeki modern araçlardan başlayıp Vagrant içindeki tarihî Debian'a, oradan BOOTP/TFTP/RSH zincirine ve nihayet O2'nin inst ortamına uzanan ağdan kurtarma yolu da sınanmış oldu.

Bu işte en yanıltıcı nokta tek bir arızanın olmamasıydı. IRIX tarafında nsd, nsswitch.conf ve resolv.conf; Windows tarafında köprü adaptörü; sanal makinede ömrünü tamamlamış Jessie depoları; dağıtım betiğinde ise yarım kalmış .irixboot işareti aynı hikâyenin ayrı katmanlarıydı. Sistem bozuk değildi; yalnızca 1990'ların UNIX mantığıyla, 2010'ların Linux betikleriyle ve 2020'lerin sanallaştırma araçlarıyla aynı anda konuşmak gerekiyordu :)

---

SGI O2, IRIX 6.5, PROM, SASH, inst, Vagrant, VirtualBox, BOOTP, TFTP, RSH, Debian Jessie, nsd, DNS, tcsh, Nekoware, tardist, wget, IRIX Network.