[Gelistirici] init script mudur parametreleri ve initramfs-tools

[Mete Alpaslan]

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


Şu anda cmdline 'a boottype=raid,lvm gibi parametreler verip düzgün bir
şekilde lvm ve raid bölümleri üzerinden sistemi ayağa kaldırabiliyoruz.

Gerekli  mudur (2.0.1, sürüm 70, inşa 34) ve mkinitramfs (versiyon 0.4,
sürüm 41, inşa 7) yamaları ektedir.

Not : mkinitramfs içinde şu anda lvm kütüphaneleri dinamik olduğundan  kirli
şekilde kopyalıyoruz .Device-mapper ,Lvm2 paketleri sorumlusu İşbaranla
konuştum bu paketlerin statik hallerini derledikten sonra yamalar son
hallerini almış olacak.



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


Şu anki haliyle dinamik ve kolay bir şekilde initramfs değiştiremiyoruz.
Sadece yapılandırma dosyası belki yeterli gelmeyebilir. Yüklenecek modul
listesi initramfs içine konacak statik araçlar ve ekstra yapılandırma
parametreleri gibi seçenekleri kolay hale getirmemiz gerekiyor. :)



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


+1 :)

Mete Alpaslan


>
>
>  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
>
> _______________________________________________
> Gelistirici mailing list
> Gelistirici at pardus.org.tr
> http://liste.pardus.org.tr/mailman/listinfo/gelistirici
>
-------------- sonraki bölüm --------------
Bir HTML eklentisi temizlendi...
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20090116/ea76470b/attachment-0002.htm>
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: init.patch
Type: text/x-diff
Size: 1398 bytes
Desc: kullanılamıyor
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20090116/ea76470b/attachment.patch>
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: mkinitramfs.patch
Type: text/x-diff
Size: 980 bytes
Desc: kullanılamıyor
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20090116/ea76470b/attachment-0001.patch>
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: mudur.patch
Type: text/x-diff
Size: 2237 bytes
Desc: kullanılamıyor
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20090116/ea76470b/attachment-0002.patch>