Fed up with kernel panics- WHY INIT RAM DISKS?

SystemParadox · 2006-10-11 15:44:32

Alright that's it.
Virtually every time I do a kernel upgrade I get a flaming kernel panic on the next boot and have to use a bootable CD to chroot to the hard disk, re-build the ram disk and run lilo. I've started changing my systems to grub, since I discovered that you don't need to re-run it every time.

Too late for my headless server 100 miles away. I few months ago I upgraded it because every time the power was lost it needed manual help to boot again (some major hardware issue- it was pretty old). But I can't remember how many times my new Arch server hasn't rebooted because it couldn't use the ramdisk after a kernel upgrade.

The last one got me. kernel 2.6.18-7. No matter what I did it just wouldn't boot. I was wondering if the latest current kernel has a major bug, but surely someone tried booting it before putting it in the current repo so it can't be that.

So I installed GRUB instead. Now it doesn't boot my fallback system either. So I either have to go without a server until Christmas, or go back for a weekend specifically to fix it.

This begs the question:
WHY ON EARTH ARE WE USING INIT RAM DISKS?

When I compiled my own custom kernel for slackware I never bothered with an initrd. That was great. If I installed a new kernel and didn't rerun lilo it would still boot and I could fix it (it also didn't overwrite the old one, so if it was broken I could boot the previous kernel anyway).

Why, oh why oh why are the filesystem modules not in the kernel? It would save so much trouble.

phrakture · 2006-10-11 16:16:47

SystemParadox wrote:

This begs the question:
WHY ON EARTH ARE WE USING INIT RAM DISKS?

Because it makes the stock kernel, provided in binary form, much more feature rich. Without an initramfs there is no way to use an encrypted root partition, use lvm on your root partition, and many other things.

The initial ram disk is there to provide users of the _stock_ kernel more options. If you wish to compile your own kernel as you did under slackware, feel free. There is nothing stopping you.

There was a call for testing for months before this was moved into current. I'm sure you had to see it. If there were any issues, they could have been found at this point.

curtdodds · 2006-10-12 04:36:16

I too experience the same problems.
Simply putting ext3 in the kernel, instead of a module,
would eliminate the need for an initrd for many of us.

Trying to accomodate all exotic features leaves some of us
with an unusable system.

NOT deleting any existing kernel would allow us to boot
into the system using the previous kernel and fix any problem.

We should not have to boot from another linux and chroot
into arch every time we upgrade the kernel.

brain0 · 2006-10-12 06:33:18

Instead of whining about problems, you could properly report the error messages and help to solve them. We don't add <insert feature here> in the kernel, because it works well if we add it as a module, and people who don't need it won't waste their RAM with it. And if you properly set up your system, missing filesystem modules won't be a problem either.

If you have a dedicated server that you don't have access to, then you should really check the initramfs images and bootloader BEFORE you reboot, analyze them for possible errors in image generation, maybe recreate them (and yes, if you use Arch on a dedicated server, then you should know how to do that, or be able to find it out).

BTW, I didn't have a kernel panic with the new initramfs for months now.

T-Dawg · 2006-10-12 10:44:42

brain0 wrote:

If you have a dedicated server that you don't have access to, then you should really check the initramfs images and bootloader BEFORE you reboot, analyze them for possible errors in image generation, maybe recreate them (and yes, if you use Arch on a dedicated server, then you should know how to do that, or be able to find it out).

WHAT!!??
Hey guys I've news for you. Upgrading a kernel shouldn't be this much trouble, escpecially when its something that critical. Initramfs/cpio/rd is nice and all for devs and people who want special features like encrypted rootfs as phrak mentioned but honestly, most people don't know anything about them nor how to set them up. Not only that but its added shit that could go wrong during boot up. What if mkinitcpio silently failed at generating the images and your server 100 miles away won't boot afterwards?
I think its safe to say at least 75% archers don't utilize the advantages of initrd and more or less don't want the added headache. It would be nice if we could bring back the plain old non-ramdisk kernel as another to choose from. Maybe even make it the default kernel26 and move kernel26 to kernel26-rd. I know you guys like kernels, hell we have a lollypop kernel26beyond for christ's sakes.

toxic · 2006-10-12 11:21:48

I think it's fair to use mkinitcpio, it doesn't add that much extra boot time for the functionality improvements it offers either.

I think it's probably a good idea, that if you want your kernel bootable, to compile it yourself. Including all the kernel modules in the kernel image rather than modularizing them as done now, would probably give about equal boot times with the initrd enabled.

Updating your system, a message appears telling you that you SHOULD look at your mkinitcpio.conf file, and possibly generate a new image. If everyone follows those instructions, I'm sure there would be less hazzle with kernel panics.

So in my opinion, it's wise to leave things as they are, and those who'd like to exclude initrd may well do so by compiling their own kernel. I think this mirrors the general knowledge of arch users as well, experienced users may well get their own kernel to work, while others may enjoy the current precompiled environment.

tomk · 2006-10-12 12:00:50

Hmmm. How about this - Arch is designed and developed in line with a particular philosophy and set of principles, which are available for all to read and absorb. Choosing to use Arch is an implicit endorsement of the "Arch way", and the move to initramfs is entirely consistent with that.

Developers, like everyone else, are only human, and may make mistakes, hence the lengthy test period, during which many issues were identified and resolved. We're now in the post-implementation stage, and I see Archers of all sorts - users, TUs, FAs, Devs - helping out those who are
still having problems.

My point? Well, there's a few.
Firstly, and a bit bluntly, there's no point saying "I don't want these new features" because it's not your decision. Everyone can, and should IMO, participate in discussions about Arch development, but decisions are made by the Arch leader and dev team, in accordance with Arch philosophy and principles.
Secondly, you won't get help if you don't ask. Despite detailed advance announcements and the lengthy testing period, users have still had problems with this change, and have got the answer by asking. The Arch community has a good reputation for a reason.
Thirdly, nobody is being forced to use initramfs - Arch does not limit you. As the OP used to do on Slack (but has chosen not to do on Arch), users can compile their own kernels to meet their particular requirements, and still avail of the benefits of Arch for the rest of their systems.
And finally, and this is meant in the most benign way possible, there are situations where Arch may not be the best choice of distro, and I would certainly consider my options if I was relying on a remote server to which I had no physical access.

(some overlap with toxic here - I've been writing this for quite a while. )

P.S. Penguin, I'm not sure what you mean about beyond - if you don't like it, don't use it. :?

T-Dawg · 2006-10-12 12:17:49

tomk wrote:

P.S. Penguin, I'm not sure what you mean about beyond - if you don't like it, don't use it. :?

I meant I found it ironic that we can have a patched-up glamourized version of the vanilla initrd kernel but not a vanilla non-initrd kernel which gave very few people trouble in the past.

I'm not saying we should abolish initrd kernels, they have their advantages, I'm saying for some its not necessary and not worth extra setup hassel -especially when a misconfigured one can leave the system unusable. For people with mission critical servers this kiss approach is more ideal.

iphitus · 2006-10-12 12:18:34

Penguin wrote:

I know you guys like kernels, hell we have a lollypop kernel26beyond for christ's sakes.

Settle down Mr Forum Adviser.

Arch isnt really suitable to mission critical servers anyway, I wouldnt run it on one myself. Blindly updating on a mission critical server is pathetic practice anyway. If i had such an important server, I'd almost certainly have a sandbox or backup server or vmware image where I would try things before updating.

mkinitcpio should cause zero problems. It's all setup to 'just work'. It went through a very extensive testing period, and reached an adequate level of stability, and remained at that for a long time before being merged. initcpio, IS KISS. If adding one line to your bootloader is too much for you to comprehend then you simply should not be using Arch.

Us developers did everything we possibly could to ensure mkinitramfs would work. We all tested it on whatever systems we had available, and attempted to fix every problem reported.

What doesnt help, is when users, make posts like this, or simply never report the issue. "omg it doesnt work this is crap" is completely counterproductive. It is the exact reason why people have problems with it now - because those who do have them, fail to report them. It isnt unreasonable to expect people to report these problems, and I know many users feel that they shouldnt need to, But from our perspective, those with problems are corner cases and minorities which we simply cant forsee and will only ever be known of and fixed if reported.

The move from initrd -> initcpio was heavily documented and advertised. Every kernel 2.6.17 had a message. It was available in testing for months and months before. There was an extremely popular thread in announcements, and there were a multitude of news items on the home page. Mailing list posts, IRC discussions, a bot in the irc channel spitting it out at regular intervals -- pacman asking you if it is OK to replace mkinitrd/mkinitramfs with mkinitcpio. Ignorance here is not bliss, it's stupidity and lazyness.

I'm sorry you have had problems, but the move to initcpio was essential for reasons detailed countless times elsewhere and you have only yourself to blame for those problems.

James

phrakture · 2006-10-12 15:42:59

This rant has gone on long enough.

As iphitus said, the move was mentioned a lot and documented like mad. If you have errors, please post them here. We can speculate all we want about this-and-that, but without error messages, nothing happens.

If you want anything fixed... let us know the error please. No more rants in this thread - the question has been answered.

Thanks

SystemParadox · 2006-10-13 10:43:22

phrakture wrote:

SystemParadox wrote:
This begs the question:
WHY ON EARTH ARE WE USING INIT RAM DISKS?
Because it makes the stock kernel, provided in binary form, much more feature rich. Without an initramfs there is no way to use an encrypted root partition, use lvm on your root partition, and many other things.

But just how many people actually use those features?

curtdodds wrote:

I too experience the same problems.
Simply putting ext3 in the kernel, instead of a module,
would eliminate the need for an initrd for many of us.

What do we loose by putting ext2/3, IDE and SATA in the kernel? How many people use a different filesystem to ext2/3 on their root partition? How many people have their root partition on something that isn't IDE or SATA?

brain0 wrote:

We don't add <insert> in the kernel, because it works well if we add it as a module, and people who don't need it won't waste their RAM with it.

All we need is ext2/3 and IDE/SATA. For virtually everyone that will either mean IDE is unused (very unlikely- isn't this used as a base for other things?) or SATA is unused. Surely more RAM/CPU time is wasted dealing with an rd containing mostly modules that won't be used?

Penguin wrote:

I think its safe to say at least 75% archers don't utilize the advantages of initrd and more or less don't want the added headache. It would be nice if we could bring back the plain old non-ramdisk kernel as another to choose from. Maybe even make it the default kernel26 and move kernel26 to kernel26-rd.

That's another good alternative.

brain0 wrote:

And if you properly set up your system, missing filesystem modules won't be a problem either.

I use the kernel26-fallback image to try and avoid this.

brain0 wrote:

If you have a dedicated server that you don't have access to, then you should really check the initramfs images and bootloader BEFORE you reboot, analyze them for possible errors in image generation, maybe recreate them (and yes, if you use Arch on a dedicated server, then you should know how to do that, or be able to find it out).

toxic wrote:

Updating your system, a message appears telling you that you SHOULD look at your mkinitcpio.conf file, and possibly generate a new image. If everyone follows those instructions, I'm sure there would be less hazzle with kernel panics.

Every time I update I check the output for image generation. I've never seen an error. What else can I do?

toxic wrote:

So in my opinion, it's wise to leave things as they are, and those who'd like to exclude initrd may well do so by compiling their own kernel. I think this mirrors the general knowledge of arch users as well, experienced users may well get their own kernel to work, while others may enjoy the current precompiled environment.

Is that not a bit backwards? That means that all the people who don't want to bother with an rd have to work at removing it. We're including this for the very few people who want lvm, encryted root, etc.

iphitus wrote:

If adding one line to your bootloader is too much for you to comprehend then you simply should not be using Arch.

I'm not that stupid. I moved to initcpio the moment I saw the message (which was kernel 2.6.15 I think).

iphitus wrote:

The move from initrd -> initcpio was heavily documented and advertised. Every kernel 2.6.17 had a message. It was available in testing for months and months before. There was an extremely popular thread in announcements, and there were a multitude of news items on the home page. Mailing list posts, IRC discussions, a bot in the irc channel spitting it out at regular intervals -- pacman asking you if it is OK to replace mkinitrd/mkinitramfs with mkinitcpio. Ignorance here is not bliss, it's stupidity and lazyness.
I'm sorry you have had problems, but the move to initcpio was essential for reasons detailed countless times elsewhere and you have only yourself to blame for those problems.

My problem is not with moving to initcpio or initcpio vs initramfs vs initrd or whatever. My problem is about initial ramdisks full stop.

brain0 wrote:

Instead of whining about problems, you could properly report the error messages and help to solve them.

What error messages?
cannot mount root fs: device not found (or whatever it is)
kernel panic: not syncing: attempted to kill init!

The thing is on a serial terminal, and I've been working over the phone, so that's all I can do. I know that it's the same error you get if you update the kernel and then don't run lilo.

phrakture wrote:

This rant has gone on long enough.
If you want anything fixed... let us know the error please. No more rants in this thread - the question has been answered.

I don't want the ranting to continue, but I still don't know why I've got to deal with a RD when hardly anyone needs it, and why ext2/3, IDE and SATA aren't built into the kernel anyway.

Now don't get me wrong- Arch is amazing, and the developers do a great job, but this whole issue seems completely unnecessary.
Please can we have either ext2/3, iDE and SATA built into the kernel, or two kernel26 packages- one with an rd and one without.

T-Dawg · 2006-10-13 11:11:59

and why ext2/3, IDE and SATA aren't built into the kernel anyway.

because that would defeat its purpose. The idea is to modularize the filesystem and hard drive drivers and let rd create an image of it. Initrd's main purpose is to mount the root filesystem as quickly as possible and pass the rest off to the kernel. It allows end users a smaller footprint during bootup because whereas before with the non-rd kernel you had to have every single filesystem and hard disk driver BUILT-IN to the kernel to account for all users, now you can easily specify in mkinitcpio/rd/ramfs.conf. This behaviour also allows all the added rootfs features as stated previously.

iphitus · 2006-10-13 13:02:11

SystemParadox wrote:

But just how many people actually use those features?

Take a look at how many people use the beyond kernel for fbsplash support - which requires an initramfs. From my understanding, some raid setups benefit from an initrd/initramfs too.

What do we loose by putting ext2/3, IDE and SATA in the kernel? How many people use a different filesystem to ext2/3 on their root partition? How many people have their root partition on something that isn't IDE or SATA?
All we need is ext2/3 and IDE/SATA. For virtually everyone that will either mean IDE is unused (very unlikely- isn't this used as a base for other things?) or SATA is unused. Surely more RAM/CPU time is wasted dealing with an rd containing mostly modules that won't be used?

Saying that all we need is ext2, ext3, IDE and SATA is a horrendously ignorant and flawed point. There is not 'one' sata driver, there is not 'one' IDE driver, and extX is not the 'one' filesystem.
On a quick count, I find in the kernel:
33 IDE drivers
40 SCSI drivers
16 filesystems
27 SATA drivers
I for one dont want these loaded, inducing other bugs, and clogging up CPU cache and ram.

And all of these figures are understated, in reality there's more than that. Compiling these all in is not a solution, and you'll be hard pressed to find a top notch distro that does this by default. Ubuntu, Mandriva, Debian, SuSE Enterprise Desktop, Fedora, Red Hat Workstation... and others, all use a form of initrd/initramfs. This is the direction the kernel is going, and is the best way to make it work for the widest amount of people on the widest and most complex of setups.

Most importantly, this is the way the kernel is going. It's a matter of time before this is the DEFAULT way for the kernel to boot, using klibc and kinit. It will happen. See $kernel-source/Documentation/early-userspace/README

My problem is not with moving to initcpio or initcpio vs initramfs vs initrd or whatever. My problem is about initial ramdisks full stop.

Penguin wrote:

I think its safe to say at least 75% archers don't utilize the advantages of initrd and more or less don't want the added headache. It would be nice if we could bring back the plain old non-ramdisk kernel as another to choose from. Maybe even make it the default kernel26 and move kernel26 to kernel26-rd.

There is no problem with initramfs. There is no headache. The developers have tested initcpio on all of our own machines available, and it works on all of them. It went through a long long testing period where a huge array of people also tested it and confirmed it working. It reached the stage where, we were all confident it could be released safely -- as no more bugs were being reported, it had been tested on a huge array of systems, and it worked.

The problem and headache in the system is the users, who have a problem with it, and then take the kneejerk reaction to call for it's removal. You generate the headache for others. You are in the minority here, and have encountered what's known as a software bug. The best thing you can do to get a software bug fixed, is to report it. As far as I know, you have not filed a bug.

You are in the minority here. For 99% of people, all they need to do is add that one bootloader line and it works out of the box, because this was wasted so extensively. Calling for it's removal and disadvantaging another minority isnt a solution.

Initcpio 'just works'. There is no problem. You encountered a bug. Help us fix it instead of overhauling and causing trouble to the majority again. Remember, what works for you, need not be the best solution for everyone.

http://bugs.archlinux.org/

phrakture wrote:

This rant has gone on long enough.
If you want anything fixed... let us know the error please. No more rants in this thread - the question has been answered.

Agreed.

What error messages?
cannot mount root fs: device not found (or whatever it is)
kernel panic: not syncing: attempted to kill init!

hurrah! Error messages!

Could you get the context of this error, and as many lines preceding it as you can, irrelevant of whether you think they are an error or not. If you file a bug, please include this information, as well as hardware, the server's configuration, your mkinitcpio.conf and mkinitcpio version.

phrakture · 2006-10-13 15:39:02

Christ... I'm locking this - if you have errors, post them... but this is just going to be a "he said, she said" battle.

If you don't like using an ramdisk compile your own kernel. As such, if the developers have to support a kernel that is going to satisfy ALL users this _will_ be this one.

Arch Linux

#1 2006-10-11 15:44:32

Fed up with kernel panics- WHY INIT RAM DISKS?

#2 2006-10-11 16:16:47

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#3 2006-10-12 04:36:16

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#4 2006-10-12 06:33:18

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#5 2006-10-12 10:44:42

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#6 2006-10-12 11:21:48

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#7 2006-10-12 12:00:50

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#8 2006-10-12 12:17:49

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#9 2006-10-12 12:18:34

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#10 2006-10-12 15:42:59

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#11 2006-10-13 10:43:22

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#12 2006-10-13 11:11:59

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#13 2006-10-13 13:02:11

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

#14 2006-10-13 15:39:02

Re: Fed up with kernel panics- WHY INIT RAM DISKS?

Board footer