# [SOLVED]devtmpfs question

## cach0rr0

probably a quick/easy one

at the moment I have a "custom" (very simple) initramfs running as part of my boot routine, that handles the task of handling the crypto for my root partition

As part of its setup, I copied over the device node for sda2 (my root partition) to the initramfs source directory, and so of course, this gets included in the initramfs so that I can later:

```

cryptsetup luksOpen /dev/sda2 root

```

the question: if I build my kernel with devtmpfs support, what all does it provide? Is devtmpfs going to create those device nodes at boot, so that i shouldn't need to manually copy over that device node? 

Right now my dev structure in the initramfs looks like so:

```

ricker dev # ls -alh /usr/src/initramfs/dev/

total 0

drwxr-xr-x  2 root root  216 Feb 27 21:20 .

drwxr-xr-x 12 root root  344 Mar  5 22:03 ..

crw-------  1 root root 5, 1 Feb 14 12:07 console

crw-rw-rw-  1 root root 1, 3 Feb 14 06:07 null

crw-rw-rw-  1 root root 1, 8 Feb 14 06:07 random

brw-rw----  1 root disk 8, 2 Feb 14 12:07 sda2

crw-rw-rw-  1 root tty  5, 0 Feb 24 16:49 tty

crw-rw-rw-  1 root root 1, 9 Feb 14 06:07 urandom

```

Just for grins, I could try adding something like this in my /init

 *Quote:*   

> 
> 
> #!/bin/busybox sh
> 
> #mount proc and sys
> ...

 

If I did that, would i be able to safely remove random, urandom, sda2, tty, null, and console, from my initramfs dev directory? By that i mean, could I remove those nodes from the source directory, so that they do NOT get bundled into my initramfs.cpio.gz, using the assumption that devtmpfs is going to create them. 

I guess I'm still just a bit muddy on what all devtmpfs is supposed to do, since it isn't really particularly well documented anywhere. 

This would make my initramfs a good deal more portable, and would mean I could use it on any of my systems, whether root was sda2, sda3, sdb1, whatever. 

I'm planning on trying it anyway and seeing what happens, no harm in experimenting I suppose, but I'd rather know that what I'm doing is sound logic - hell, maybe there's some other caveat to its use that I'm unaware of that would render this idea null and void. Don't know, thanks in advance for any input

----------

## Hu

Using devtmpfs will expose device nodes for the hard drives the kernel knows how to operate.  Your initramfs will still need some way to determine which one should be used with the call to cryptsetup.  Even without devtmpfs, you can avoid creating copied device nodes by using the kernel's native support for building an initramfs, which allows you to specify device nodes via a list file.

----------

## cach0rr0

 *Hu wrote:*   

> Using devtmpfs will expose device nodes for the hard drives the kernel knows how to operate.  

 

i assume the ones it 'knows how to operate' means ones for which I've built the requisite drivers into the kernel, is that correct?

 *Hu wrote:*   

> Your initramfs will still need some way to determine which one should be used with the call to cryptsetup.  

 

This can be done as part of /init, yes? At the moment I have a very small simple init, and it's working quite nicely. I am assuming what you mean by this is that as part of init, I need to have the cryptsetup line (which I do) as seen below (comments and rescue_shell function omitted:

```

#!/bin/busybox sh

mount -t proc none /proc

mount -t sysfs none /sys

mount -t devtmpfs none /dev #this is the main subject of this question/topic

cryptsetup -T 5 luksOpen /dev/sda2 root 

mount -o ro /dev/mapper/root /mnt/root || rescue_shell

umount /proc

umount /sys

umount /dev

exec switch_root /mnt/root /sbin/init

```

small, simple, inflexible, but it works  :Laughing: 

I would of course need to change the way I invoke cryptsetup within init should i have a machine with a different partition scheme, I'm comfy enough with changing that. 

 *Hu wrote:*   

> 
> 
> Even without devtmpfs, you can avoid creating copied device nodes by using the kernel's native support for building an initramfs, which allows you to specify device nodes via a list file.

 

I've had..a pretty bad time trying to get that to work, and it doesn't seem to be particularly well documented (spent more time googling and siphoning through ./linux/Documentation/* than a sane man should). So for the time being, I'm going the external/manual route. 

If the devtmpfs mount line I have in init means that I don't need to have copied over the sda2 block device, then really I suppose that answers my question...mostly at least. 

What about things like /dev/console, /dev/null, /dev/urandom, /dev/tty, and so forth. Will these all be created as well? If so, I don't need to copy those over either. 

This is partially for my own uses, but more than anything for documentation's sake (I wrote up a very simplified HOWTO, now that i finally have this working). If I can tell people 'just include devtmpfs support in your kernel, and mount it within /init", it's easier than copying over the device nodes (e.g. disks, character devices, etc)

----------

## cach0rr0

interesting. as ive been googling around, I stumbled upon this:

http://groups.google.com/a/chromium.org/group/chromium-os-dev/browse_thread/thread/6154a3e3b137e4a0?pli=1

why that's interesting, it seems it's easy enough you/me to test this out, and see what all gets created, e.g.:

```

mkdir /tmp/devstuff

mount -t devtmpfs none /tmp/devstuff

```

looking in /tmp/devstuff, i see loads of stuff - including tty, console, urandom, mapper/control, null, more devices than i can shake a stick at! 

this does look promising. I think I can forgo the 'cp -a /dev/sda1 /usr/src/initramfs/dev/' piece of this, and just do everything with devtmpfs 

chime in if I'm incorrect, but i think I have the answer I need - as always, a thousand thanks @Hu for yet again pointing me in the right direction!

----------

## Hu

 *cach0rr0 wrote:*   

> i assume the ones it 'knows how to operate' means ones for which I've built the requisite drivers into the kernel, is that correct?

 Yes.  If udev would expose it to you once your system is booted, I would expect it to be in devtmpfs.

 *cach0rr0 wrote:*   

> 
> 
> This can be done as part of /init, yes?
> 
> ```
> ...

 Correct.  That script looks fine.  I prefer unmounting in reverse order, but there are no dependencies among the three you specify, so that is irrelevant here.

You can inspect /proc/cmdline to see what options were passed by LILO/Grub.  Some people opt to have an initramfs /init that examines /proc/cmdline to learn which device node should be treated as the root.  You can also use that to pass a request to call rescue_shell independent of an error, in case you want to inspect the initramfs environment.

 *cach0rr0 wrote:*   

> I've had..a pretty bad time trying to get that to work, and it doesn't seem to be particularly well documented (spent more time googling and siphoning through ./linux/Documentation/* than a sane man should).

 Fair enough.  Did you look at Documentation/filesystems/ramfs-rootfs-initramfs.txt?  Once I found and read that, I was able to get a working initramfs with no other instructions.  This is fortunate, since I have never seen any other good references on making an initramfs using the built in mechanism.

 *cach0rr0 wrote:*   

> What about things like /dev/console, /dev/null, /dev/urandom, /dev/tty, and so forth. Will these all be created as well? If so, I don't need to copy those over either.

 I believe they are created.  Mounting a devtmpfs shadows the underlying directory, just like any other filesystem mount.  Therefore, even if you did ship a null node in your initramfs, mounting devtmpfs would hide it.

 *cach0rr0 wrote:*   

> chime in if I'm incorrect, but i think I have the answer I need - as always, a thousand thanks @Hu for yet again pointing me in the right direction!

 I did not check the cited Chromium thread, but everything you stated in this lower post sounds correct.

----------

## cach0rr0

 *Hu wrote:*   

> 
> 
> You can inspect /proc/cmdline to see what options were passed by LILO/Grub.  Some people opt to have an initramfs /init that examines /proc/cmdline to learn which device node should be treated as the root.  You can also use that to pass a request to call rescue_shell independent of an error, in case you want to inspect the initramfs environment.

 

That's my next order of business actually. Believe it or not, it seems the more one reads, the more one learns; imagine that! So I've been reading, trying/testing/failing, but figuring out how to piece things together. There's an example of doing this up on the wiki, but it's a touch convoluted (I actually went last night and plucked out all of the suspend and splash nonsense from their example, left me with a much saner init to read - oh, and my revision does not die if a font fails to load :lol)

 *Hu wrote:*   

> ]Fair enough.  Did you look at Documentation/filesystems/ramfs-rootfs-initramfs.txt?  Once I found and read that, I was able to get a working initramfs with no other instructions.  This is fortunate, since I have never seen any other good references on making an initramfs using the built in mechanism.

 

I haven't seen it, no, strangely this is the first time I've seen anyone reference that file. I will absolutely give it a read. 

 *Hu wrote:*   

> I believe they are created.  Mounting a devtmpfs shadows the underlying directory, just like any other filesystem mount.  Therefore, even if you did ship a null node in your initramfs, mounting devtmpfs would hide it.

 

 *Hu wrote:*   

> I did not check the cited Chromium thread, but everything you stated in this lower post sounds correct.

 

Right, perfect, I'm good to go, I think I have my head around all of this pretty well. Things have "clicked" in my brain. I kinda sorta had some ideas, wasn't sure if they were right wrong crazy or otherwise, now they've been explained and sanity checked, main thing i was after. 

Thanks as always!

----------

## V10lator

Maybe the next step you could try is modifying the udev startup script (simply adding a & at one point should do the trick, but I didn't take a look at it so I'm not sure) to let it start in the background while other init script which need it can start in parallel.

This should give you a little shorter boot and everyone could benefit from it, even if he/she is not using initramfs (with a script executed before udev which starts devtmpfs, this of course is not needet when doing that in the initramfs before).

P.S. sorry for my bad english.  :Smile: 

----------

