Hacker News Reader

Comment by yellowapple | Hacker News Reader

You really only need two (kernel and initrd/initramfs), at least to get into a basic running state. This requires building your own initrd, of course, but it's pretty common in non-graphical Linux installers (Slackware's install media still does this, IIRC).

I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that.

View on HN

CoreOS's "system volumes" are just rather large initramfs images. This means you don't really have a rootfs partition on CoreOS, just a boot partition (containing a newer and older set of kernel + initramfs) and a "state" partition (containing whatever you like.)

This choice creates a very nice upgrade-management strategy for CoreOS clusters: rather than letting each machine have its own boot partition and asynchronously downloading updates into it, you can just stand up a PXE server to serve the current CoreOS kernel+initramfs and tell your machines to boot from that. Now the entire OS (~200MB) is streamed to each machine on boot; to "update" a machine, you just reboot it. (And, unlike a shared NFS/iSCSI rootfs disk server, you don't have to be careful when updating to tiptoe around the machines that haven't rebooted yet; they just stay happily on the old OS until you kick them over.)

As an added benefit, if the programs you're running on those CoreOS nodes don't need any persistent storage either (i.e. they're not database nodes), then they can be entirely diskless, and just let the rootfs tmpfs hold everything.

Yes, it's a fun exercise to build a tiny Linux install that's fully on the initrd. Not that you'd want to have that kind of system in daily use outside of special applications.

> I think it's even possible to embed the initrd in the kernel binary itself, but I've never really investigated that.

Yes, the kernel config has an option to embed the initrd in the kernel image. I'm not sure if there are any advantages to this.

I use the initramfs method to put an small ssh server in that I can use to unlock full disk encrypted headless boxen, so I could see initrd in the kernel being used in a similar way.

The advantage to embedding the initrd is usually that you don't have to worry about a separate initrd (for example, if you're reliant on some really basic bootloader). It's also more in-line with, say, OpenBSD (AFAICT) which doesn't use a separate initrd/initramfs (not sure if this is true of all BSDs).

> I'm not sure if there are any advantages to this

This comes to mind: http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-l...

Having the initrd merged with the kernel is slightly less hassle when netbooting to test during kernel development

You can ditch the initrd if you compile in the kernel the drivers you need to boot the system, as a minimal example SATA/SCSI, EXT4/JFS, that usually are compiled as kernel modules.

How most sane distros do it.

Build a kernel with the most common hardware built into it, and use that to bootstrap. No need for messy things like balled up temporary rootfs in a ram drive.

Initrd/initramfs have become an excuse for piling on complexities that frankly should be added by the sysadmin after initial install.

The purpose of the initrd to have the initrd bootstrap to rootfs. This involves userspace tools like mdadm, lvm2, cryptsetup, zfsprogs, etc.

It's not very common to need kernel modules (drivers) on initrd on typical hardware.

It's not common to need them, perhaps, but it's still useful if you don't want to recompile your kernel just to add on-boot support for various devices. Slackware's 'mkinitrd' tool is one example of this sort of approach; you can add various modules (like for your root filesystem, keyboard, etc.) by adding to the $MODULE_LIST variable defined in '/etc/mkinitrd.conf' or by running 'mkinitrd -k $MODULES'.

You can of course accomplish similar things by just recompiling the kernel (which Slackware makes very easy to do), but if you still need to use 'mkinitrd' anyway (perhaps because you're using LVM or softraid or LUKS), it's often more convenient to just throw in the modules you need while you're at it.

The keywords there are 'typical hardware', but it can get worse. How about 'badly selected' hardware on a short time frame, in situ, waiting for an install and application port process to be performed by non-technical users following a recipe. Proprietary drivers for network and soft raid with a large enterprise linux vendor support and site license basically voided. There are worse things than starting an install,loading storage drivers, creating the lvm partitioning, hup'ing disk druid, installing, rebooting and adding the network driver to initrd, and having to explain and document that manual procedure to the same people who ordered the hardware...but I've forgotten them.

This only works if you stick to a simple filesystem, not crypto, RAID, etc. Otherwise you'll need to have file system utilities (lvm2, mdadm, cryptsetup, zfsprogrs, etc) on the initrd to get your rootfs mounted.

Damn, you are absolutely right!

It never crossed my mind that LVM and similar needs utilities to access the filesystem and to be honest, I thought initrd/initramfs contained only kernel modules, not executables and scripts... ^__^;

Reply on news.ycombinator.com