* Separate Initramfs dependency on initrd (and therefore ramdisks)
@ 2006-02-17 16:20 Kris Shannon
2006-04-11 1:55 ` Kris Shannon
0 siblings, 1 reply; 3+ messages in thread
From: Kris Shannon @ 2006-02-17 16:20 UTC (permalink / raw)
To: Linux Kernel Mailing List
A number of distributions (most importantly for me - Debian) use the
initrd as initramfs facility
I assumed that the passing of the data block would be independent of
ram disks seeing as
not using a ram disk was one of the major reasons for initramfs, but
it seems that you need
CONFIG_BLK_DEV_INITRD=y which depends on CONFIG_BLK_DEV_RAM=y
Would a patch separating out the init image handling from the initrd
handling be welcome
and if so should the resulting init image code be dependant on a
CONFIG variable or
always on (like initramfs is now)
The only reference to this I found in the archives was:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0508.1/0097.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Separate Initramfs dependency on initrd (and therefore ramdisks)
2006-02-17 16:20 Separate Initramfs dependency on initrd (and therefore ramdisks) Kris Shannon
@ 2006-04-11 1:55 ` Kris Shannon
2006-04-11 8:57 ` Michael Tokarev
0 siblings, 1 reply; 3+ messages in thread
From: Kris Shannon @ 2006-04-11 1:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
A number of distributions (most importantly for me - Debian) use the
initrd as initramfs facility. I assumed that the passing of the data
block would be independent of ram disks seeing as not using a ram
disk was one of the major reasons for initramfs, but it seems that
you need CONFIG_BLK_DEV_INITRD=y which depends on
CONFIG_BLK_DEV_RAM=y
Would a patch separating out the init image handling from the initrd
handling be welcome and if so should the resulting init image code
be dependant on a CONFIG variable or always on (like initramfs is now)
The only reference to this I found in the archives was:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0508.1/0097.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Separate Initramfs dependency on initrd (and therefore ramdisks)
2006-04-11 1:55 ` Kris Shannon
@ 2006-04-11 8:57 ` Michael Tokarev
0 siblings, 0 replies; 3+ messages in thread
From: Michael Tokarev @ 2006-04-11 8:57 UTC (permalink / raw)
To: Kris Shannon; +Cc: Linux Kernel Mailing List
Kris Shannon wrote:
> A number of distributions (most importantly for me - Debian) use the
> initrd as initramfs facility. I assumed that the passing of the data
> block would be independent of ram disks seeing as not using a ram
> disk was one of the major reasons for initramfs, but it seems that
> you need CONFIG_BLK_DEV_INITRD=y which depends on
> CONFIG_BLK_DEV_RAM=y
>
> Would a patch separating out the init image handling from the initrd
> handling be welcome and if so should the resulting init image code
> be dependant on a CONFIG variable or always on (like initramfs is now)
>
> The only reference to this I found in the archives was:
>
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0508.1/0097.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0603.1/0969.html
/mjt
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-04-11 8:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-17 16:20 Separate Initramfs dependency on initrd (and therefore ramdisks) Kris Shannon
2006-04-11 1:55 ` Kris Shannon
2006-04-11 8:57 ` Michael Tokarev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox