From Gentoo-en
Jump to: navigation, search

mount root -o ro

When mounting root readonly does not work /dev/console is probably missing on the (new) root fs. This should be mentioned somewhere... See also:

This works fine for me.
Why would /dev/console be missing on the new rootfs? That usually only happens when you mess up copying old rootfs to a new filesystem/partition - and forget to copy the original root's static /dev. Which may or may not be important at bootup. But that's a problem with missing dev nodes in your rootfs then, not with the Initramfs itself.
That said, it's probably safe to mount devtmpfs to root/dev. Since the kernel has an option to do the same (devtmpfs automount), and I'm not sure if the kernel would still do it by itself after Initramfs.
AndreasKlauer 20:03, 24 February 2013 (GMT)


From the man page:

switch_root moves already mounted /proc, /dev and /sys to newroot and makes newroot the new root filesystem and starts init process.

Given that, is it really necessary to umount /proc and /sys? --Titan 09:59, 20 September 2011 (GMT)

It might not be necessary (I've never tested), but the question here is, what does the installed init system expect? In a default install, when using a kernel without initramfs whatsoever, at the time /sbin/init is executed by the kernel, only / is mounted readonly, and nothing else. This tutorial suggests that you keep the initramfs as minimalistic as possible and provide the installed system the same clean state so the installed system can decide how to mount things by itself. If you want to do it differently that is your decision. -- AndreasKlauer 10:57, 21 September 2011 (GMT)


According to using the -l option is not allowed to gether with -p or -s, plus -w is ignored :P

The lower example of starting telnet with netcat might just not work at all.

Those switches work fine with net-analyzer/netcat, the man page you linked seems to be for a different implementation of netcat (there are quite a few different ones floating about). It's actually the -i switch that won't work because it requires an argument. I've updated the article to reflect that.

device nodes

I added the device node section yesterday because I noticed that some stuff does not work without basic device nodes being present. Now it seems to be getting a bit out of hands with three different approaches to device nodes 1) copy them 2) mdev 3) devtmpfs. Should we leave it like that or settle on one method? Just wondering if it confuses people. On the other hand, it gives them a choice... AndreasKlauer 14:47, 3 May 2010 (GMT)

Just tried devtmpfs for the first time myself, it's really nice and seems to be a better solution than mdev. I guess I'll change the page to reflect that by mentioning devtmpfs before mdev. AndreasKlauer 23:07, 12 May 2010 (GMT)

I was also wondering about this. I discovered that you will need to set up the three basic nodes manually always, because otherwise your init can't be executed with #!/bin/busybox sh. Then init can mount devtmpfs, which works nicely for me as well, except for not having udev-style /dev/disk/by-id etc niceties. lkraav 11:20, 10 Apr 2011 (GMT)


When I get dumped to the rescue shell, I am unable to use nano. I only get: "Error opening terminal: linux" Is this happening to anyone else? Anyone know why this might be happening? Thanks. Luckally busybox has vi built in and I like it better anyway.

+nano is not a busybox module, is it? the real nano is rather picky about terminals, it has similar issue with exotic terminal emulators (such as rxvt-unicode). Similar issue is described here Not sure if a terminfo file can be included in initramfs to make it acceptable for nano. An alternative workaround is to set the terminal variable to something else that nano will accept... although I'm not sure that will work in initramfs either since there are no terminfo files by default there AndreasKlauer 01:23, 28 August 2010 (GMT)

I've tested nano with a terminfo file that is in the initramfs called "/etc/terminfo/l/linux" copied from a standard gentoo and nano works with it now.
Not all functions of nano were tested but opening, editing and saving worked for me. --Dermund 16:06, 15 November 2010 (GMT)

clean up

Several snippets add stuff to the initramfs that also requires cleaning up later (additional mounts etc). However the cleanup phase is currently not mentioned, apart from the 'basics' version that umounts /proc and /sys. Not cleaning up properly can cause a lot of problems later on though (for example messing with /dev/pts can cause xterm/urxvt to not work, had this issue earlier during testing). Should I add cleanup instructions to each snippet individually or should I just mention the issue in the troubleshooting section? AndreasKlauer 14:50, 3 May 2010 (GMT)

multiple initramfs

this is in the basic section, I think it's too advanced / not useful to a lot of people, and I'd like to keep the basics as basic as possible. wondering whether to include this at all (functionality section then maybe) or just leave it out, haven't seen this used ever. For it to be useful you'd have to invent some split init script structure that executes all scripts it finds in a subdir in a specific order somehow - none of this is explained anywhere in this guide and that's something a binary distro would be more likely to use (add functionality to initramfs as binary packages are emerged). AndreasKlauer 23:19, 12 May 2010 (GMT)

I personally use this a lot. I manage a number of machines and have a single generic initramfs which I deploy on all machines, I then override certain config files with an extra machine specific initramfs. It's a lot easier than remaking a ton of different initramfs when I only want to make single global change. I think it's also useful to understand that multiple initramfs override each other, especially if you accidentally embed one in the kernel as well as specifying an external one, I've seen that problem catch a few people out. I agree that it shouldn't be in the basic section though, it's definitely an advanced topic. Malone 08:46, 13 May 2010 (GMT)
Hmmm, okay. I'll put it in the functionality section then. AndreasKlauer 11:53, 13 May 2010 (GMT)

It is possible to specify multiple initramfs to be extracted during boot. This can be useful if you want to create a generic initramfs and then add modifications in separate files. You can specify multiple initramfs archives in your grub config by using multiple initrd lines.

File: /boot/grub/grub.conf
title=Gentoo Linux 2.6.27-r8 with initramfs (hd0,0)
root (hd0,0)
kernel /boot/kernel-2.6.27-gentoo-r8
initrd /boot/first-initramfs.cpio.gz
initrd /boot/second-initramfs.cpio.gz
initrd /boot/third-initramfs.cpio.gz

The kernel will extract these files in the order they are specified. The files will all be extracted into the same place, this means files from later archives will overwrite former ones if they have the same filename. Also note that it is possible to have an initramfs archive embedded in the kernel as well as extra ones specified in the grub config. The archive in the kernel will be extracted first, followed by the ones in the grub config.

Added a sentence referring to the "Bootsplash" section - see the discussion under that.

--Greyspoke 18:43, 19 December 2010 (GMT)

UUID/LABEL root mounting

Initramfs#UUID.2FLABEL_Root_Mounting currently does three separate things at once: 1) it parses kernel parameters, 2) it finds device by uuid/label, 3) it mounts the device. Should I leave it like that or would it make more sense to split it up into separate functionality sections, one that does kernel parameters (may be useful for things other than just root=), one that finds devices by uuid/label/..., and leave out the mounting part since that's done in the basics already? AndreasKlauer 12:10, 13 May 2010 (GMT)

Nobody commented; since I have to work with network and kernel parameters on a server next week, I guess I'll just go ahead and do this, along with a rudimentary networking section (which is currently somewhat done in Remote Rescue Shell). AndreasKlauer 13:46, 20 May 2010 (GMT)
Started work on a networking section, will add an nfs mount example and move the Remote Rescue Shell down there later. The other stuff will follow later AndreasKlauer 12:31, 26 May 2010 (GMT)
Another idea is to have a "Parser" heading and then the UUID/Label stuff as a heading under that. The reason I didn't write that section so is because there wasn't anything else in the article that really needed it, so everything got thrown in as one. Ni1s 11:40, 31 May 2010 (GMT)


I added the network section recently, but didn't have time since, so it's only half finished. Also it recently came to my attention that the kernel can mount NFS root partitions without the help of initramfs, depending on how the network is set up. Currently the initramfs wiki page suggests that initramfs is necessary for network filesystems. This should be rephrased, and I'll do that when I find the time, but for now I only added a note AndreasKlauer 06:53, 25 June 2010 (GMT)

busybox static / Applications: nano

For me it is impossible to include dynamically link binaries into a initramfs with a statically linked busybox. At least I get errors for trying this with strace, and error says: "sh: /bin/strace: not found". If I am not doing something else wrong, the article section currently is not working this out, I think.

Sounds like you are missing the libraries for the app, proabbly ld-linux*
Error message doesn't make much sense to me. Did you try this with the nano example? AndreasKlauer 12:16, 14 November 2010 (GMT)
Ok, strace error message got away. The steps I did were:
- in order for recompile of the strace package I re-emerge linux-headers because I had messed around with headers in the past.
- remerge strace
- copy strace over the former strace in initramfs directory / made a cpio of initramfs
Strace is usable now. Strange.
Besides "nano" fails with "Error opening terminal: linux." (see "Applications" section above) .--Dermund 15:20, 14 November 2010 (GMT)
nano may be a bad example. Who needs nano in initramfs anyway? But it shows that it works in general. Some apps may have dependencies that are more than just libraries; I suggest avoiding unnecessary complexity in initramfs altogether, if you can help it. AndreasKlauer 20:03, 15 November 2010 (GMT)
Then I would suggest to replace nano in the wiki page by some program that is independant of other deps but libraries. Otherwise the user, that strictly follows the wiki stumbles into other errors, that aren't explained. Better than this would be imho to just give this section a tag that nano needs the terminfo file also. This would make clear that other deps than libraries may be needed. --Dermund 21:58, 15 November 2010 (GMT)
It's a Wiki so you're free to improve it yourself :) I can't come up with a good example at the moment. I only use cryptsetup and lvm in my initramfs, both static... AndreasKlauer 18:23, 16 November 2010 (GMT)


I got a bit confused (easy in my case) over bootsplash when combined with the "you must have an init in your initramfs" message. In fact if you have fbsplash enabled in your kernel all you need is an initramfs with the necessary files in it and the kernel will deal with the bootsplash, no init script required. Similarly, if you want a bootsplash and you need an initramfs for other reasons (so your initramfs needs an init script in it) you just add the files and devices that are in the initramfs generated by splashutils (if they are not there already). You don't need to put anything extra in your init script to make the bootsplash work.

Presumably, you could also just add the initramfs generated by splashutils to your grub.conf in addition to your hand-made initramfs, though I haven't tried this.

This is no doubt obvious to many - but it wasn't to me!

--Greyspoke 15:33, 16 December 2010 (GMT)

I never ever used bootsplash, so I didn't know it didn't need /init. ;^) Pretty much everything else in this guide needs the init file. If the kernel sets up bootsplash, how would you go about selecting a random bootsplash image in the init? Make sure the files aren't there at first (so the kernel doesn't do it itself) and then rename them or load them manually or what? Or disable the autoload with another kernel parameter? Fascinating. Anyhow, I added a "usually" in there, if you think it can be worded better somehow, please feel free do so. If it's normal for pure bootsplash to not have an init file, maybe we should move the non-existent bootsplash section to the multiple initramfs section as example. Or at least write one or two sentences on bootsplash. Since I don't know anything about it (not interested in whizbangs at boot) someone else please do it. If it's not too long I'm completely fine with it and everything AndreasKlauer 08:05, 17 December 2010 (GMT)

--AndreasKlauer 08:05, 17 December 2010 (GMT)

OK, I have added a bit under Bootsplash, I hope it is OK (I don't wiki much - edit/ criticise as necessary). I have done it the "adding an extra initramfs" way and it works fine, even though there are some duplicate device files in the two (I would never have thought of that without having read this wiki). With regard to your question, I think that you can also control the bootsplash by starting the sbin/fbcondecor_helper and/or sbin/splash_helper programs that are in all fbsplash initramfs files from the command line of your init with appropriate arguments. But that is not well documented and I have no idea how it is done, or whether you still need the patched kernel when you do it this way.
Edited to add - added a bit to the "Multiple Initramfs" section and a brief comment there as well.

--Greyspoke 18:33, 19 December 2010 (GMT)

I've added a bit on how the kernel fbsplash patch works(or rather, what it needs), the other bits I removed as this and the Fbsplash article already covers it(i.e appending to a initramfs, etc.). /Ni1s 18:53, 20 December 2010 (GMT)

Root device sda3 instead of sda1 in init script

In the part about: "Init The file structure of your initramfs is almost complete."

I am very new to this but would it not be better to change sda1 to sda3 here:

mount -o ro /dev/sda1 /mnt/root

There reason I see is that according to the gentoo handbook:

sda3 is the root

Partition Filesystem Size Description /dev/sda1 ext2 32M Boot partition /dev/sda2 (swap) 512M Swap partition /dev/sda3 ext3 Rest of the disk Root partition

The device name will be different for everyone. The article says clearly """Throughout this document, /dev/sda1 will be used as example device.""" Obviously you have to replace it according to your situation. With a standard setup such as described in the Gentoo Handbook (ext3 on sda3) you don't even need Initramfs at all... AndreasKlauer 22:14, 11 July 2012 (GMT)