Re: prepare 2.6.13
On Tuesday 30 August 2005 07:47, you wrote:
> > > > > > - initrd-tools needs to loose devfs usage.
> > > > > BTW, isn't it time to switch to initramfs ?
> >
> > I saw that ubuntu use "initramfs-tools" and in debian we have "yaird"
> > that I personally use since it hit sid to boot from lvm on a md array.
> >
> My personal believe is that something like yaird will produce smaller
> intram filesystems, and thus better suited to arches and subarches who have
> actually trouble with bigger bloated initrds.
This is sure but I think will be a really nice feature to have in etch, with
initramfs-tools concept we could change hardware quite a few and expect our
beloved debian to boot without problem, recognizing at startup that e.g. we
changed the mainboard and cpu so the old sata disc is mounted on a sas
controller and change the module to load without leaving a un-bootable sistem
like out actual mkinitrd and it seems also yaird.
> I am also a bit curious how initramfs behaves on the kernel wise, i mean i
> understand and all that it is just a bunch of cpio archives which are
> copied at the end of the kernel, but, taking the powerpc case for an
> example, there is either a bootwrapper, like the arch/ppc/boot/openfirmware
> stuff, or boot loaders, like yaboot, who know how to put the kernel and
> initrd in ram, and then pass the right info to the kernel to find the
> ramdisk back (passed as argument in r3/r4 if i remember well.
I remebered booting linux from the destkop gui on in my Amiga times...
> Now, initramfs is nothing more than a file organisation which is a bit
> different for the initial ramdisk, or is there more to it, and the above
> code path, for which i have seen no major change recently, will still work
> ?
The question is : we want to support nice things like EVMS at boot time? A
tool for generating bootable initrd for evms is needed, it is targeted for
etch evms support I hope.
It seems that none our 3 tools supports it right now.
--
ESC:wq
Reply to: