[Gelistirici] init script mudur parametreleri ve initramfs-tools

[Emre Erenoglu]

2009/1/3 Onur Küçük <onur at pardus.org.tr>

>
> 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


OK, ayri ayri tanitilabilir, case olayini yeni farkettim ben de :)  ama
asagida devam edelim, belki baska cozum olur.

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 ?


Aradaki diger kisimlari cikardim. Esasen burda derdimiz, sistemi LVM ve/veya
RAID ve/veya VIRTIO ve/veya XEN uzerinde boot edebilmek. Ben initramfs
kismiyla ilgili konusayim, mudur.py 'nin ne yaptigi veya ne yapmasi
gerektigini bilmiyorum. Su anda mudur=lvm diyerek mudur.py'den LVM volume
group'lari aktif hale getirebiliyoruz, ancak esas UDEV ile yapmak lazim,
bunu basarabilmis degiliz.

Sistem bir sekilde acilista, root girdisinden olsun, verilen parametre'den
olsun, veya initramfs icindeki dosyalari test ederek vs. RAID/LVM/VIRTIO
ustunde boot etmesi gerektigini farkedip, modulleri ona gore probe etmeli,
gereken userspace binarysini (lvm icin) ona gore calistirmali.

mudur= gibi bir parametre koymak bana da cok mantikli gelmiyor, diger
dagitimlarin yeni versiyonlarinda bu tip bir yaklasim gormedim, ancak
mecbursak ya da kolayimiza gelirse olabilir.  Burada mkinitramfs script'ine
ve YALI'ya (sonraki asama) da is dusecek tabi.

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.


Bence kalmasin, daha esnek bir yapi olusturalim.

>
>
> > 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.


Guzel fikir. initramfs.conf yapalim, icinde ornegin RAID=1 yaziyorsa atalim
icine raid modullerini, LVM=1 yaziyorsa icine device mapper modullerini
atalim, bi de userspace'den gerekli dosyalari atalim (vgchange, vgscan),
VIRTIO=1 varsa virtio modullerini probe ettirelim (kernel in-built bunlar
sanirim) vs.

Belki bunlari atan script'leri de mkinitramfs'in icine direk kodlamaktansa,
bir yere koyup source edilecek sekilde ayarlamak gerekebilir. Ornegin lvm
paketi kuruldugunda /etc/initramfs/inputs/getlvm gibi bir dosya atar, raid
kuruldugunda /etc/initramfs/inputs/getraid gibi bir dosya atar, sonra
mkinitramfs calistiginda (ornegin kernel update'te) bu dizinin altinda ne
var ne yoksa okunur ve her dosyanin icindeki islem yapilir. (esnek olmak
acisindan, udev'in rules.d dizini gibi).

Yok eger buna gerek yok, bize simdilik LVM/RAID/VIRTIO yeter dersek,
mkinitramfs'in icine direk de kodlanabilir. Ancak mesela ilerde haydi XEN
unmodified_drivers ekleyelim dedigimizde mkinitramfs'i ellemek gerekecek
gene.

Bu initramfs.conf yerine bir fikir de, mkinitramfs calistiginda
/etc/mdadm.conf varsa RAID'i trigger edecek sekilde, /etc/lvm/lvm.conf varsa
lvm'yi trigger edecek sekilde ayar yapabilir. VIRTIO'yu test etmenin de bir
yolu bulunabilir belki. Bunlar varsa initramfs ona gore olusturulur,
initramfs'in icindeki init script de test ederken icinde lvm.conf bulursa
gerekeni yapar, mdadm.conf bulursa gerekeni yapar vs.


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.


OK kullanmayalim, bana da zor geliyor sonradan ne neymis diye anlamak.

-- 
Emre
-------------- sonraki bölüm --------------
Bir HTML eklentisi temizlendi...
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20090103/3116a49c/attachment-0002.htm>