From: Felix Oxley <[email protected]>
Amend Kconfig help text for RAM Disk & initrd to suggest that
these features should be answered Y.
Remove loadlin as an example of a boot loader, replace with grub.
Signed-off-by: Felix Oxley <[email protected]>
---
--- ./drivers/block/Kconfig.orig 2005-10-17 00:20:18.000000000 +0100
+++ ./drivers/block/Kconfig 2005-10-16 23:57:18.000000000 +0100
@@ -368,9 +368,11 @@ config BLK_DEV_RAM
Saying Y here will allow you to use a portion of your RAM memory as
a block device, so that you can make file systems on it, read and
write to it and do all the other things that you can do with normal
- block devices (such as hard drives). It is usually used to load and
- store a copy of a minimal root file system off of a floppy into RAM
- during the initial install of Linux.
+ block devices (such as hard drives).
+
+ It is usually used to load and store a copy of a minimal root file
+ system into RAM during the boot sequence. "Inital RAM disk support"
+ must also be enabled for this option to work.
Note that the kernel command line option "ramdisk=XX" is now
obsolete. For details, read <file:Documentation/ramdisk.txt>.
@@ -378,8 +380,10 @@ config BLK_DEV_RAM
To compile this driver as a module, choose M here: the
module will be called rd.
- Most normal users won't need the RAM disk functionality, and can
- thus say N here.
+ Say Y here if your system uses a RAM disk whilst booting, or if you
+ know you require a RAM disk for another purpose. Otherwise, say N.
+
+ If unsure, say Y.
config BLK_DEV_RAM_COUNT
int "Default number of RAM disks" if BLK_DEV_RAM
@@ -403,11 +407,12 @@ config BLK_DEV_INITRD
depends on BLK_DEV_RAM=y
help
The initial RAM disk is a RAM disk that is loaded by the boot loader
- (loadlin or lilo) and that is mounted as root before the normal boot
+ (lilo or grub) and that is mounted as root before the normal boot
procedure. It is typically used to load modules needed to mount the
"real" root file system, etc. See <file:Documentation/initrd.txt>
for details.
+ Most users will answer Y here.
#XXX - it makes sense to enable this only for 32-bit subarch's, not for x86_64
#for instance.
On Sunday 16 October 2005 19:02, Felix Oxley wrote:
> From: Felix Oxley <[email protected]>
>
> Amend Kconfig help text for RAM Disk & initrd to suggest that
> these features should be answered Y.
> Remove loadlin as an example of a boot loader, replace with grub.
>
> Signed-off-by: Felix Oxley <[email protected]>
> ---
> --- ./drivers/block/Kconfig.orig 2005-10-17 00:20:18.000000000 +0100
> +++ ./drivers/block/Kconfig 2005-10-16 23:57:18.000000000 +0100
> @@ -368,9 +368,11 @@ config BLK_DEV_RAM
> Saying Y here will allow you to use a portion of your RAM memory as
> a block device, so that you can make file systems on it, read and
> write to it and do all the other things that you can do with normal
> - block devices (such as hard drives). It is usually used to load and
> - store a copy of a minimal root file system off of a floppy into RAM
> - during the initial install of Linux.
> + block devices (such as hard drives).
> +
> + It is usually used to load and store a copy of a minimal root file
> + system into RAM during the boot sequence. "Inital RAM disk support"
> + must also be enabled for this option to work.
Actually if this is a patch against 2.6, between ramfs (including initramfs)
and the ability to loopback mount files, I personally consider ramdisks
semi-obsolete. (This might be _why_ it says most normal users won't need
them.)
> config BLK_DEV_RAM_COUNT
> int "Default number of RAM disks" if BLK_DEV_RAM
> @@ -403,11 +407,12 @@ config BLK_DEV_INITRD
> depends on BLK_DEV_RAM=y
> help
> The initial RAM disk is a RAM disk that is loaded by the boot loader
> - (loadlin or lilo) and that is mounted as root before the normal boot
> + (lilo or grub) and that is mounted as root before the normal boot
> procedure. It is typically used to load modules needed to mount the
> "real" root file system, etc. See <file:Documentation/initrd.txt>
> for details.
>
> + Most users will answer Y here.
Again, on 2.6, most users will probably answer N and will instead use
initramfs.
Rob
On Monday 17 October 2005 06:37, Rob Landley wrote:
> Actually if this is a patch against 2.6, between ramfs (including initramfs)
> and the ability to loopback mount files, I personally consider ramdisks
> semi-obsolete. (This might be _why_ it says most normal users won't need
> them.)
Well, you may well know better than I, however on my Suse 10 box,
initrd is used and I see only CONFIG_INITRAMFS_SOURCE="" in my .config.
I made this patch because omiting intrd caused my system to be unable to boot.
regards,
Felix
On Monday 17 October 2005 02:12, Felix Oxley wrote:
> On Monday 17 October 2005 06:37, Rob Landley wrote:
> > Actually if this is a patch against 2.6, between ramfs (including
> > initramfs) and the ability to loopback mount files, I personally consider
> > ramdisks semi-obsolete. (This might be _why_ it says most normal users
> > won't need them.)
>
> Well, you may well know better than I, however on my Suse 10 box,
> initrd is used and I see only CONFIG_INITRAMFS_SOURCE="" in my .config.
There's no config symbol for it because you can't disable it. It's always
hardwired in. (Most of the code for ramfs is just the normal page cache
stuff anyway. It's a filesystem that uses the disk cache mechanism to store
its data. Quiet clever, really.) Initramfs is called "rootfs" in the mount
list, and is always there. (Check proc/mounts on any 2.6 kernel.) Getting
rid of rootfs would cause an immediate deadlock becuase it's used as a search
terminator in the doubly linked list of mounts inside the kernel.
And yes, moving off of initramfs is non-obvious because of this. I talked
about that a bit here:
http://www.busybox.net/lists/busybox/2005-October/016597.html
By default, the build creates an empty archive to initialize initramfs (this
archive gets linked into the kernel image, it's not a separate file), and the
boot process extracts it (a NOP) and then tries to exec /init in rootfs
(which is empty, so this fails), and then falls through to the normal root
partition finding behavior.
> I made this patch because omiting intrd caused my system to be unable to
> boot.
Then your system is setup to boot via initrd. Probably your vendor has
an /sbin/installkernel script that makes one. (See arch/i386/boot/install.sh
for details. When you run "make install" that script looks for an
"installkernel" script on the current system and runs it if it finds it, so
that any vendor weirdness can apply to your new kernel automatically...)
> regards,
> Felix
Rob
On Monday 17 October 2005 08:33, Rob Landley wrote:
> > On Monday 17 October 2005 06:37, Rob Landley wrote:
> > > Actually if this is a patch against 2.6, between ramfs (including
> > > initramfs) and the ability to loopback mount files, I personally consider
> > > ramdisks semi-obsolete. (This might be _why_ it says most normal users
> > > won't need them.)
You are right in all you say.
However, my system uses initrd and I thought that a help message warning newbies
that these options are required if inrd is used, would be useful.
Since I removed it and was uanble to boot :-)
Do you think the slimmed down patch below is appropriate, or shall I just drop the subject?
reagrds,
Felix
Signed-off-by: Felix Oxley <[email protected]>
---
--- ./drivers/block/Kconfig.orig 2005-10-17 13:04:31.000000000 +0100
+++ ./drivers/block/Kconfig 2005-10-17 13:20:31.000000000 +0100
@@ -368,9 +368,9 @@ config BLK_DEV_RAM
Saying Y here will allow you to use a portion of your RAM memory as
a block device, so that you can make file systems on it, read and
write to it and do all the other things that you can do with normal
- block devices (such as hard drives). It is usually used to load and
- store a copy of a minimal root file system off of a floppy into RAM
- during the initial install of Linux.
+ block devices (such as hard drives). This is usually used to load and
+ store a copy of a minimal root file system into RAM during the boot
+ sequence.
Note that the kernel command line option "ramdisk=XX" is now
obsolete. For details, read <file:Documentation/ramdisk.txt>.
@@ -378,8 +378,10 @@ config BLK_DEV_RAM
To compile this driver as a module, choose M here: the
module will be called rd.
- Most normal users won't need the RAM disk functionality, and can
- thus say N here.
+ Say Y here if your system uses an initrd RAM disk whilst booting, you
+ will also need to to enable initrd below. (Check for /boot/initrd*).
+
+ If unsure, say N.
config BLK_DEV_RAM_COUNT
int "Default number of RAM disks" if BLK_DEV_RAM
@@ -403,11 +405,14 @@ config BLK_DEV_INITRD
depends on BLK_DEV_RAM=y
help
The initial RAM disk is a RAM disk that is loaded by the boot loader
- (loadlin or lilo) and that is mounted as root before the normal boot
+ (lilo or grub) and that is mounted as root before the normal boot
procedure. It is typically used to load modules needed to mount the
"real" root file system, etc. See <file:Documentation/initrd.txt>
for details.
+ Some systems will require this to boot (check for /boot/initrd*).
+ Otherwise, say N.
+
#XXX - it makes sense to enable this only for 32-bit subarch's, not for x86_64
#for instance.
On Monday 17 October 2005 07:44, Felix Oxley wrote:
> On Monday 17 October 2005 08:33, Rob Landley wrote:
> > > On Monday 17 October 2005 06:37, Rob Landley wrote:
> > > > Actually if this is a patch against 2.6, between ramfs (including
> > > > initramfs) and the ability to loopback mount files, I personally
> > > > consider ramdisks semi-obsolete. (This might be _why_ it says most
> > > > normal users won't need them.)
>
> You are right in all you say.
> However, my system uses initrd and I thought that a help message warning
> newbies that these options are required if inrd is used, would be useful.
> Since I removed it and was uanble to boot :-)
Understandable concern.
> Do you think the slimmed down patch below is appropriate, or shall I just
> drop the subject?
Well, it's better. The first part's a clear correction.
When you note that some systems need it to build, I'd mention that newer
systems should probably be using initramfs. Other than that, no objection.
Rob