* 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