Is using an initrd a good idea?

Gullible Jones · 2005-10-31 20:10:46

In the interest of simplicity, I'm gonna have to say no, and that it would be better to just make kernel26-scsi the default kernel26. I frankly doubt that even an embedded Pentium 2 system would have trouble with that.

ozar · 2005-10-31 20:51:30

I voted "more trouble than it's worth", but only because there weren't any other options that I felt comfortable with at the current time. That's because it's been a pleasure to use Arch without having to fool around with any initrd issues. The lack of an initrd has always been one of the main attractions to Archlinux from my perspective. I did often use an initrd when I ran Slackware and rarely had any problems doing so.

Having said all that, I'm not exactly sure how much trouble it will cause once it's implemented in Arch, but suspect it will be a real kick in the ass for some users, while others will glide right through it without any problems.

Hopefully, all the fuss about this subject will prove to be unwarranted.

elasticdog · 2005-10-31 21:38:28

I don't know enough about it either way, so I'll have to stay out of this debate. Only time will tell...

dtw · 2005-10-31 21:40:10

Let's face it...it is in [testing] - it's hardly supposed to be perfect yet...

kth5 · 2005-10-31 23:11:26

(going to cause more trouble than it's worth)

well, i do see reasons for using an initrd but let's take look at the real advantages compared to mass of users not able to take any advantage of this. sure it's great to be able to easily assemble a ramdisk with modules and stuff to boot off a sata-, scsi-, usb-storage or whatever-device but what about the 80% - or even more - who don't have such setups? even i can boot my machine using s-ata w/o any preloaded module configuration.
personally i doubt loosing 100K-1M RAM because of built-in drivers really makes a difference nowadays, where 512M is quite the standard. lowend freaks love to compile their custom kernels anyway.

so why force the regular user to go through the hassle of creating his personal initrd even if it's not necessary? as maintainer of the archppc kernel do not see much of a difference either, except for i could use a similar setup for a livecd or something.

deficite · 2005-10-31 23:58:49

I voted "going to cause more trouble than it's worth"

And last time I checked, wasn't KISS Arch's philosophy? *hint*

alexmat · 2005-11-01 00:58:42

I fear change :shock:

kakabaratruskia · 2005-11-01 01:13:18

I like it very much, still I don't think it should be the default. It would be better as an option. Maybe the scsi kernel should be default (renamed as kernel26), and there could be a kernel26-initrd package for performance freaks.

Gullible Jones · 2005-11-01 03:40:48

I think the idea was to eliminate need for two separate 2.6.x packages.

phrakture · 2005-11-01 04:10:32

Gullible Jones wrote:

I think the idea was to eliminate need for two separate 2.6.x packages.

That and provide more flexability going forward. I mean, what if tomorrow, JaboboATA comes out which is 30x better than SATA and SCSI and all that crap, but because of the architecture, it requires a whole mess of stuff which can't be built into the kernel just yet (it's going to take at least a month to develop it fully). Your choices are: 1) cram an initrd together or 2) stare at your new hardware in all it's off-ness

That said, I have no opinion on the subject. I do, however, believe some premade initrd's should be distributed with pacman, just because I don't want to remake an initrd every kernel upgrade, but other than that, I'l lwait and see.

elasticdog · 2005-11-01 04:29:48

If I'm not mistaken, I think most of the necessary initrd modules for the most common configurations will be there by default if you don't happen to make your own config...thus things will still work, but they won't be "optimized" for your particular system. I don't remember where I read that...either here or on the mailing list. Either that, or it's late and I made it up in my head...

paranoos · 2005-11-01 08:53:36

yes, i don't see any trouble here. i built a custom kernel that uses initrd just to see what the fuss was, and it wasn't difficult at all.

mkinitrd makes it very easy. if you don't set anything up at all, it will load all the modules that were normally compiled into the kernel anyway. when you DO configure mkinitrd for your hardware, it only loads exactly what you need! it's like having a custom built kernel without any of the headache. if you're only running an ide system, running the scsi kernel loads drivers for roughly 40 interface cards FOR NO REASON.

i haven't measured how much bigger the kernel is, nor have i checked if it loads faster. but it's SIMPLER and CLEANER with initrd. the devs don't have to worry about what should or should not be compiled directly into the kernel. in the scsi kernel, the USB Storage driver was compiled directly in, for the off chance that somebody might be booting off of a Compact Flash card connected by USB. this isn't simple or clean at all, it's catering to a minority. now the devs don't have to worry about that.

i voted that it was a smart decision. because it is. i'm sorry, but it seems a lot of people are being vocal about this issue without having tried it.

High|ander · 2005-11-01 12:05:11

I think it is a good idea because its less jobb for teh devs

jondkent · 2005-11-01 12:40:43

I voted "More trouble than it is worth" as I'm not sold on the benefits of initrd once you have a working system

Also, it complicates the system, something I do not want and I thought Arch was trying to avoid.

At least make it optional.

Jon

neotuli · 2005-11-08 05:05:22

It is optional, compile your own kernel that works for your system, and you have no need to make an initrd.

Gullible Jones · 2005-11-08 11:55:33

Compiling one's own kernel takes loonnng time.

deficite · 2005-11-08 22:42:56

Yeah, because I can't possibly spare a half hour of my precious life.

Gullible Jones · 2005-11-08 22:52:20

Look, sorry if I sound like a stodgy conservative or something, but Arch is about simplicity, and an initrd doesn't look like it will make things simpler. I would think it might be better to make custom kernels for embedded systems that can't spare an extra meg of memory... And I've used kernel26-scsi on very outdated i686 machines with no performance hit.

(Remember: Arch does not even support 486s!)

Hmmm... Thinking of other options... The BIOS IIRC has limited drivers that the bootloader uses. So I'm wondering, could something be done so that the bootloader could load the necessary modules to memory without requiring that said modules be copied into an initrd?

IceRAM · 2005-11-08 22:57:59

Ok, it's been a long time since the initrd talk started. Could someone sum up the advantages/disadvantages initrd brings for
a) a user
b) a package maintainer

I find it pretty hard to discover advantages for an enduser. How many people on Earth would possibly want to use the kernel on the hdd, build for the system on the hdd, to boot a system on a USB stick, for example?

I understand that it's a great option for the installer. I completely agree that something simpler should be done. BUT, wouldn't it be a lot easier to use such a kernel for the install CD and use afterwards a kernel26/kernel26scsi/kernel26initrd(?) kernel and live happily ever after?

I really want to find out what can I do with this "improvement", as a kernel end-user.

Lots of thanks for putting in such an effort.

Gullible Jones · 2005-11-09 00:52:07

One question: why should the encrypted FS support be in the initrd, or compiled into the kernel? You use encryption to hide personal data, not the whole root dir... So you'd want to encrypt the partitions used for /home, /pub, etc. I just can't see why you'd want to encrypt the root partition.

(But what the heck, though, I suppose it could be compiled into a generic kernel without any performance loss.)

tpowa · 2005-11-09 07:17:58

Hi
somehow i missed this thread since 9 days
ok let's start:
1. why should it make things worse for the user?
it's only 1 entry in your bootloader that loads the initrd26.img file,
if you don't change anything on mkinitrd.conf, all is as you would use the kernel26-scsi. That's the default by first installing the kernel26.
After kernel26 install you can tweak your mkinitrd.conf to fit to your needs run mkinitrd auto afterwards and you are done, if you don't care about it, everything just works, for those who play around with mkinitrd and do a wrong switch in it a backup image is in place called initrd26-full.img to be able to boot again.
If you decide to build your own kernel with everything included, you are not affected by initrd at all.
The only problem is the right entry in your bootloader, but that's the only problem.

2. Advantages:
All users can use the same kernel without bothering it is scsi or not.
Try to explain a SATA user why he/she has to use a scsi kernel.

Flexibility is greatly improved:
booting from different hardware is possible, crypt fs is possible, a bootsplash would be possible in the future etc.
Disabling modules you don't need is possible, which is great if they cause trouble on your system, startup time could be improved too.

Less work:
The devs (judd and me) only have to build the kernel 1 time, means less time is needed for building and uploading.
It's easier to ship around problems in the kernel, when everything is modularized.

hope that explains it good enough for what the initrd is good for.
Probably there are possibilities to use the initrd for more stuff, that hasn't come to my mind yet.
I know change is something people are scared, but i think the benefits are great and that is a good reason for using initrd, and as usual you have the choice to use our kernel or your own kernel.
Come on and one little bootloader entry is not really complicated is it?

Enjoy the initrd,
greetings
tpowa

Gullible Jones · 2005-11-09 20:04:21

Good points all... I suppose I just dislike the idea of having duplicate sets of modules on my HDD, or that I have to make a new initrd after tweaking the config.

(Hmmm... Maybe symlinks to /boot could be used to create a sort of dynamic initrd? That might be something to investigate in the future...)

tpowa · 2005-11-09 20:26:14

i don't know how often you change your hardware, but if you leave the hd in the pc, you need only to tweak once your config and then you are done until your hardware changes, the initrd will be updated with each kernel upgrade.
greetings
tpowa

apeiro · 2005-11-09 20:27:30

Gullible Jones wrote:

One question: why should the encrypted FS support be in the initrd, or compiled into the kernel? You use encryption to hide personal data, not the whole root dir... So you'd want to encrypt the partitions used for /home, /pub, etc. I just can't see why you'd want to encrypt the root partition.

How can you be sure all your sensitive data is in /home? How about /tmp? Your swap partition? Files in /var/cache, /var/log and friends? Your /root/.bash_history file?

It's not as easy to reliably localize data as you'd think. If people are using encryption for privacy's sake, then they should encrypt all disk-based storage, including swapspace.

AndyRTR · 2005-11-09 20:52:36

For me the update was as easy as written in the wiki. I remembered once again your describtion here 8).

The devs will know if it saves time and will be 100% compatible to have one common kernel. So I voted for their choice.

Arch Linux

#1 2005-10-31 20:10:46

Is using an initrd a good idea?

#2 2005-10-31 20:51:30

Re: Is using an initrd a good idea?

#3 2005-10-31 21:38:28

Re: Is using an initrd a good idea?

#4 2005-10-31 21:40:10

Re: Is using an initrd a good idea?

#5 2005-10-31 23:11:26

Re: Is using an initrd a good idea?

#6 2005-10-31 23:58:49

Re: Is using an initrd a good idea?

#7 2005-11-01 00:58:42

Re: Is using an initrd a good idea?

#8 2005-11-01 01:13:18

Re: Is using an initrd a good idea?

#9 2005-11-01 03:40:48

Re: Is using an initrd a good idea?

#10 2005-11-01 04:10:32

Re: Is using an initrd a good idea?

#11 2005-11-01 04:29:48

Re: Is using an initrd a good idea?

#12 2005-11-01 08:53:36

Re: Is using an initrd a good idea?

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

Re: Is using an initrd a good idea?

#14 2005-11-01 12:40:43

Re: Is using an initrd a good idea?

#15 2005-11-08 05:05:22

Re: Is using an initrd a good idea?

#16 2005-11-08 11:55:33

Re: Is using an initrd a good idea?

#17 2005-11-08 22:42:56

Re: Is using an initrd a good idea?

#18 2005-11-08 22:52:20

Re: Is using an initrd a good idea?

#19 2005-11-08 22:57:59

Re: Is using an initrd a good idea?

#20 2005-11-09 00:52:07

Re: Is using an initrd a good idea?

#21 2005-11-09 07:17:58

Re: Is using an initrd a good idea?

#22 2005-11-09 20:04:21

Re: Is using an initrd a good idea?

#23 2005-11-09 20:26:14

Re: Is using an initrd a good idea?

#24 2005-11-09 20:27:30

Re: Is using an initrd a good idea?

#25 2005-11-09 20:52:36

Re: Is using an initrd a good idea?

Board footer