[Gelistirici] init script mudur parametreleri ve initramfs-tools

[Onur Küçük]

On Fri, 2 Jan 2009 20:49:28 +0100
"Emre Erenoglu" <erenoglu at gmail.com> wrote:

> Merhaba,
> 
> Bir kac haftadir Mete ile lvm2 paketi ile ugrasiyoruz. Genel olarak
> sistemin RAID ustundeki bir LVM volume'unden boot edebilmesi icin
> degistirilmesi gereken bir kac parca var gibi gorunuyor. Bu parcalar,
> mudur.py, /lib/initramfs/init, /sbin/mkinitramfs, udev kurallari gibi
> temel parcalar. Ancak bu asamaya gelmeden once, baska bir sorun var,
> once bunu halledelim veya halletmemeye karar verelim:
> 
> Su anda LVM volume'lerini ve/veya RAID uzerindeki bir diski kok sistem
> olarak kullanabilmek icin, GRUB'un kernel satirina mudur=raid veya
> mudur=lvm gibi parametre girmemiz gerekiyor, ancak init script, bir
> sekilde 2 mudur parametresi alamiyor. Ornegin:
> 
> mudur=raid,lvm : calismiyor
> mudur=lvm,raid: calismiyor
> 
> bunlar gibi diger lvmraid, raidlvm, raid-lvm, lvm-raid vs.
> kombinasyonlari calistirmayi basaramadim.

 bu parametreleri initramfs e tanıtırsanız çalışması lazım
 
> Tek basardigim ise GRUB'un kernel satirina iki ayri mudur= yazmak,
> yani:
> 
> kernel   /kernel-2.6.25.20-114  root=/dev/mapper/os-pardus mudur=lvm
> mudur=raid ro
> 
> Burada da sorun, sistem /newroot'a gecip init:1'den boot etmeye
> basladiginda, mudur.py 'nin hangi mudur= parametresini gorecegi veya
> gormeyecegi. Sanirim su anda ilk yazdigimiz neyse onu goruyor.

 burası gerçek anlamı ile müdür ile ilgili, müdür kernel satırında
gördüğü ilk mudur= i alıyor ve kalanını es geçiyor

> Kullandigimiz patch'li init script'in parametreleri okuyan ilgili
> kismi asagidaki gibi ve *'lar arasina yazilan bu testlerin neden
> calismadigina dair bir fikrim yok:
> 
>            ;;
>             mudur=*raid*)
>                 RAID=1
>             ;;
>             mudur=*lvm*)
>                 LVM=1
>             ;;
>             mudur=*thin*)
>                 NFSROOT=1
>             ;;
>             mudur=*virtio*)
>                 VIRTIO=1
>             ;;

 burası initramfs ile ilgili, çalışıyorlar, ama istediğiniz gibi
değil :)

 for x in `cat /proc/cmdline`; do
 	case "${x}" in
		mudur=*armut*)
                ARMUT=1
            ;;
            	mudur=*karpuz*)
                KARPUZ=1
            ;;
	esac
done

 kısmında, cmdline içinde her x için bir kontrol yapılıyor ve o kontrol
bulunursa o $x es geçiliyor, yani bir seferde armut ya da karpuz
yakalanıyor. Şu ana kadar birden fazla parametreye aynı anda
ihtiyacımız olmadığı için, ve bu parametrelerin birbirleri ile aynı
anda kullanılmasını istemediğimiz için böyle yaptık (it is not a bug,
it is a feature).

 Eğer aynı anda birden fazla parametrenin incelenmesi gerekiyorsa bunun
kodunun farklı yazılması gerekiyor (mudur=* yakalayıp cut la bölüp
bunun altına bir case/if bloğu eklenebilir mesela, sıkıntı olursa ne
yazılacağını belirlediğimizde ben yazarım, initramfs de bash
kullanmadığımız için iyice sinir bir bölge orası).

 Benim anlamadığım, bunun illa müdür= ile mi tanımlanması gerekiyor ?
Bunun için başka bir parametre mi bulsak ? Ya da farklı bir aile mi
tanımlasak (boottype gibi) ? Daha da güzeli, root= den zaten lvm/raid
olduğunu çıkaramıyor muyuz ?

 Aynı şekilde livecd/livedisk için de mudur= içinde olmalı mı diye
düşünmeye başladım. mudur= kullanmamızın sebebi kernel parametreleri
ile çakışmasını engellemek, ama gfxtheme de (grub/isolinux) mudur=
parametresini alıp değiştirmekte zorlanıyorum.

 Fikirler öneriler ? Böyle kalsın dersek ona göre birşeyler
uydurabilirim, illa değişsin diye ısrar etmiyorum, sadece yeri gelmişken
konuyu genişleteyim istedim.

> Bunu dusunurken, bir yandan da initramfs-tools [1] gibi bir cozume
> (Debian ve Ubuntu'daki) gidip gitmeme konusunda da karar vermek
> gerekiyor. Bu gibi bir cozumde yukardaki sistem komple
> degisebileceginden dusunmemiz gerekmeyebilir. initramfs-tools ile kok
> dosya sistemi EVMS, MD, LVM2, LUKS veya NFS uzerinde olabiliyor ve
> sistemde eger RAID, LVM vs. varsa, gerekli "hook"lar tanimlanarak
> initramfs'ler buna gore olusturuluyor, kernel satirina ek bir
> parametre vermek gerekmiyor. Ilerde olasi sanal bir sistemde virtio
> suruculeri ile boot etmek icin de faydali olabilir.

 Biz de istersek biryerlere initramfs.conf koyup initramfs i ona göre
oluşturabiliriz, burada bir sorun yok bence.

 Debian paketini kullanmaya taraftar değilim. Başka dağıtımların
ihtiyaçları için yine onlara özel araçları kullanan bir initramfs
sistemi bakımını yapmak anlamsız külfet getiriyor. Bir de zaten genelde
karman çorman yazıyorlar, o anlamsız uzun kodların içinden çıkmak iyice
zor oluyor.

 Daha önce 2 kere denedik, initrd yi adam etmeye çalışırken geçen bir
sürü zaman sonunda dellenip betiği baştan yazmıştım, hem çok kısaldı
hem de tertemiz olmuştu. Bunu kaybetmek anlamlı gelmiyor.


-- 
 Onur Küçük                                      Knowledge speaks,
 <onur.--.-.pardus.org.tr>                       but wisdom listens