initrd importance

timm · 2005-10-30 17:38:20

I see there's a new kernel in testing that replaces the -scsi kernel and uses initrd. I read the man page on initrd, but don't understand what the practical importance of this change is.

Can someone elaborate?

shadowhand · 2005-10-30 19:23:43

initrd is bascially a big archive with modules in it that the kernel can load on boot. This means that instead of having a kernel that eats a lot of memory (because the modules are built into the kernel) you can have a lean kernel with an initrd specifically for your computer (man mkinitrd).

kakabaratruskia · 2005-10-30 19:27:54

No manual entry for mkinitrd

sud_crow · 2005-10-30 19:33:32

I have the same doubt.

I used to think that way, and build modules instead of compile everything inside the kernel. Whats the difference with an initrd? (Now i dont care that much, i have plenty of ram and find loading modules i know i need annoying).

Also, by default the kernel is at a weight of 2.8mb right now... i dont think thats eating a lot of memory... where is the real benefit? i mean, is there something about kernel resources im missing?

shadowhand · 2005-10-30 19:53:18

modules in the initrd can be loaded before init starts, so the kernel can consist of nothing except the absolute bare necessities.

initrd also allows for there to be a single kernel with every possible module built, then using an initrd for users to make only the modules they need available.

I can't really answer in any more detail than that. I don't know why the devs decided to go the initrd route (although I know that initrd is necessary for some RAID/SCSI setups).

Dusty · 2005-10-30 20:04:45

I thought the main reason for initrd was to combine the kernels (I don't know why this could not be done before). I don't know about other advantages, I'm confused.

Dusty

cactus · 2005-10-30 23:18:58

initrd has always been a pain in the butt from my experience. I am sad to see arch go the way of the initrd...

Gullible Jones · 2005-10-30 23:39:13

Wouldn't it be easy enough to make kernel26-scsi the default? Even very outdated machines shouldn't have any problem with that.

kth5 · 2005-10-30 23:46:31

cactus wrote:

initrd has always been a pain in the butt from my experience. I am sad to see arch go the way of the initrd...

same here... *sigh*

Gullible Jones · 2005-10-31 00:45:42

Perhaps we should petition the maintainers to just get rid of kernel26 and use kernel26-scsi as the default?

Dusty · 2005-10-31 00:51:43

I'd say we should find out what the reason for going with initrd is first... they probably know what they're doing.

Dusty

elasticdog · 2005-10-31 02:17:47

From the mailing list:

Let me list some benefits of initrd:
* You are able to boot from what you want, think of USB/FW SATA,IDE ,SCSI
* The ability to enable cryptfs support etc.
* It will add more flexibility to Archlinux boot process.
* Less maintance work needs to be done.
* It was on the 0.8 roadmap, atm it looks good to be included in 0.7.1.
Don't forget the basic setup atm is to include all modules, so noone should
run into trouble if the bootloader is set up correct.
--
Tobias Powalowski

Granted I haven't personally had any experience with initrd, and have yet to try the version in testing, but from the quote above and what I've read, it seems like they have more than enough reason to make the switch. Plus if it's a bit more memory efficient as well, then all the better...

Gullible Jones · 2005-10-31 11:50:19

Heh... Any chance of being able to configure the initrd from /etc/rc.conf?

paranoos · 2005-10-31 20:14:26

this might clarify things a little bit for some people, so i'm going to mention it here.

when your kernel is being loaded, it needs to access your hard drive, to get to conf files, etc. without access to your hard drive, it can't load modules. so, in order to get a kernel to boot, one solution is to compile your hard drive controller directly into the kernel. if you have a look, there are quite a few controller drivers available - i'm using via82cxxx, which is quite common. distributions like arch have to provide support for all the controllers though, so that nobody is left in the dark.

the -scsi kernels add built-in support for all the scsi controllers, as well as usb flash readers, among other things, to allow users to boot from those drives, whereas the standard kernel includes these as modules instead. i figured the -scsi kernel has the ide drivers as modules, but they are built-in as well.

initrd cleans things up a bit by allowing the developers to include everything as a module, instead of worrying which ones should be built-in. the bootloader opens the necessary modules from the initrd img file created by mkinitrd. some may argue that everyone could just use the -scsi kernel, but looking at the diff between the two kernel's config files, it seems some things are disabled in -scsi. i don't know if it's intentional or not.

I think it's neat being able to specify exactly which controllers to load on boot, it makes for a leaner kernel, especially when you configure mkinitrd to only load the modules you need.

somebody argued that their kernel isn't so large anyway, so what's the big deal? well, the smaller the kernel, the faster it loads. maybe somebody would care to post a bootchart comparisson. i'm quite sure initrd could shave a few seconds off of boot time, especially if you were stuck with the -scsi kernel previously.

apeiro · 2005-10-31 20:23:59

Gullible Jones wrote:

Heh... Any chance of being able to configure the initrd from /etc/rc.conf?

What was how tpowa had originally set it up, but I asked him to move the config to a separate config file instead. I don't think the mkinitrd options belong in Arch's central config file. The rc.conf directives are all involved in getting the system up and running after the kernel passes control to the init process. mkinitrd options are used only when the mkinitrd script is called, not during bootup. It makes sense that the mkinitrd script would have a mkinitrd config file.

Gullible Jones · 2005-10-31 20:42:51

Oh.... You have to remake the initrd every time you change something. D'oh.

This is looking to be troublesome, methinks... :?

T-Dawg · 2005-10-31 23:51:07

paranoos wrote:

when your kernel is being loaded, it needs to access your hard drive, to get to conf files, etc. without access to your hard drive, it can't load modules. so, in order to get a kernel to boot, one solution is to compile your hard drive controller directly into the kernel. if you have a look, there are quite a few controller drivers available - i'm using via82cxxx, which is quite common. distributions like arch have to provide support for all the controllers though, so that nobody is left in the dark.

So is initrd only for the modules that are neccessary to get the kernel up and running to a state at which it can mount the hard drive and access the root filesystem? Obviously hardrive controllers would be one but are there more? If so what would they be?

EDIT: Furthermore, having said all this, would it be pointless to compile other drivers such as your ethernet module directly into the kernel since it doesn't need it to get the kernel up to a usable state?

paranoos · 2005-11-01 00:18:31

Penguin wrote:

So is initrd only for the modules that are neccessary to get the kernel up and running to a state at which it can mount the hard drive and access the root filesystem? Obviously hardrive controllers would be one but are there more? If so what would they be?
EDIT: Furthermore, having said all this, would it be pointless to compile other drivers such as your ethernet module directly into the kernel since it doesn't need it to get the kernel up to a usable state?

once your hard drive controller is loaded, the kernel can load any other modules it needs. things such as architecture / cpu options have to be built-in, they can't be compiled as a module.

using initrd, you can pretty much compiling everything as a module. note though that initrd is only beneficial if you're making a kernel for a variety of systems, like what Arch is doing.

if you are creating a custom kernel for your own system, you don't need initrd. compiling your ethernet card into the kernel instead of as a module may be beneficial, in that you don't have to play with module loading, and the system may boot faster if it doesn't have to load modules.

the new initrd arch kernel shouldn't have much of anything built-in, most everything should be a module.

EDIT: i've mentioned a few times how to make kernels load faster. they may seem to contradict each other, so here's a little clarification. for arch's kernel, where it needs to support every system, they have let's say 20 different hard drive controller drivers built into the kernel. using initrd, they can compile all 20 of the drivers as modules, and then the user can set up initrd to only load the module for their specific controller.

when you're compiling your own kernel, you can include your own controller driver, and not the others, thus keeping the kernel small, and loading fewer modules, which load (theoretically) slower.

basically, if you've got to compile a kernel for all sorts of systems, initrd gives you the best of both worlds - you can keep your kernel very small, and allow your users to load only the modules necessary for their system.

T-Dawg · 2005-11-01 00:35:10

ok, I think I understand it now. But still, I couldn't add say tg3(ethernet module) to the mkinitrd.conf file and expect initrd to load that up, correct? Its not needed by the kernel to mount the root filesystem.

paranoos · 2005-11-01 08:42:02

Penguin wrote:

ok, I think I understand it now. But still, I couldn't add say tg3(ethernet module) to the mkinitrd.conf file and expect initrd to load that up, correct? Its not needed by the kernel to mount the root filesystem.

i think you can do that, and i don't see why it wouldn't work, it just wouldn't be necessary, as you said. it's more convenient to specify modules to load in your rc.conf. if you set your ethernet module to load with mkinitrd, it would have to copy that module into the initrd.img file every time you upgrade your kernel (it's done automatically by the .install file though). also if you've got a tiny /boot partition, it wouldn't be a good idea to stash all your modules in there.

T-Dawg · 2005-11-01 12:01:13

I see. Thanks for the explaination, it cleared up alot questions I had about all this 8)
There still isn't a "what is initrd" section in the wiki, maybe you could add it? I could do it myself when I have more time but you seem to have a better grasp on it then me

jondkent · 2005-11-01 12:55:05

Interesting information. So the bottom line is that intird will make life easier for the devs as its just one kernel, as opposed to multiple.

People do seem to get hung up on boot time which seems odd to me so I don't view that as a reason for using initrd.

Jon

xerxes2 · 2005-11-01 20:32:20

hmmm, so if i run a homemade kernel nothing would happen then? i don't need to do anything to get the system going?

Arch Linux

#1 2005-10-30 17:38:20

initrd importance

#2 2005-10-30 19:23:43

Re: initrd importance

#3 2005-10-30 19:27:54

Re: initrd importance

#4 2005-10-30 19:33:32

Re: initrd importance

#5 2005-10-30 19:53:18

Re: initrd importance

#6 2005-10-30 20:04:45

Re: initrd importance

#7 2005-10-30 23:18:58

Re: initrd importance

#8 2005-10-30 23:39:13

Re: initrd importance

#9 2005-10-30 23:46:31

Re: initrd importance

#10 2005-10-31 00:45:42

Re: initrd importance

#11 2005-10-31 00:51:43

Re: initrd importance

#12 2005-10-31 02:17:47

Re: initrd importance

#13 2005-10-31 11:50:19

Re: initrd importance

#14 2005-10-31 20:14:26

Re: initrd importance

#15 2005-10-31 20:23:59

Re: initrd importance

#16 2005-10-31 20:42:51

Re: initrd importance

#17 2005-10-31 23:51:07

Re: initrd importance

#18 2005-11-01 00:18:31

Re: initrd importance

#19 2005-11-01 00:35:10

Re: initrd importance

#20 2005-11-01 08:42:02

Re: initrd importance

#21 2005-11-01 12:01:13

Re: initrd importance

#22 2005-11-01 12:55:05

Re: initrd importance

#23 2005-11-01 20:32:20

Re: initrd importance

Board footer