1 |
On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs <williamh@g.o> wrote: |
2 |
> On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: |
3 |
>> How does the tool that creates an initramfs know which files to copy from |
4 |
>> /usr and /var anyhow? |
5 |
> |
6 |
> My understanding is that nothing gets copied from /usr and /var, and it |
7 |
> doesn't have to. |
8 |
> |
9 |
> Here is my basic understanding of how the boot sequence works: |
10 |
> |
11 |
> 1) rootfs is mounted on /. Rootfs contains the contents of the |
12 |
> initramfs. |
13 |
|
14 |
Ok, so the initfs is typically in /boot, though it need not be. It |
15 |
needs to be someplace the bootloader can find it, and with grub legacy |
16 |
that typically means on a bare hard drive partition, or one using md |
17 |
raid-1 with older metadata. The initramfs doesn't need to find itself |
18 |
- the bootloader loads it into ram and passes its address to the |
19 |
kernel when executing it. |
20 |
|
21 |
> 2) the init program inside the initramfs is run. |
22 |
> 3) This init program will mount the real /usr and /var. |
23 |
|
24 |
So, this is the chicken and egg bit that led to the question about how |
25 |
the tool that creates initramfs knows what to copy from /usr, etc. If |
26 |
/usr can be mounted without any files from /usr, then clearly booting |
27 |
without /usr mounted shouldn't be a problem (just mount it early). If |
28 |
it does need files from /usr, then the initramfs has to contain those |
29 |
files since /usr isn't mounted yet. |
30 |
|
31 |
The answer isn't that complicated - the tool just knows what files are |
32 |
needed from a hardcoded list/etc. It might also use some static |
33 |
linked tools. It might also use a subset of the regular udev/etc |
34 |
tools - it doesn't need to configure your video capture card and mouse |
35 |
- it just needs to find anything that could contain the root |
36 |
filesystem (and now /usr as well). |
37 |
|
38 |
Keep in mind the initramfs does not need to fully initialize the |
39 |
system, and it doesn't need to do it in a way compatible with anything |
40 |
that will subsequently load. It doesn't need to populate /dev the way |
41 |
the rest of the stuff in the distro expects it to be, since the /dev |
42 |
it is populating will get unmounted/wiped/etc before switching roots. |
43 |
Initramfs just has to quickly operate in a scratch filesystem, mount |
44 |
the real filesystems, then wipe itself out and chroot. It doesn't |
45 |
need to be compatible with the latest version of |
46 |
dbus/hal/X11/openrc/etc - it just needs to be internally |
47 |
self-consistent. |
48 |
|
49 |
For whatever reason it still isn't working for me (using dracut) - for |
50 |
some bizarre reason it can't auto-detect my raid, even though running |
51 |
mdadm --assemble --scan and exiting the dash shell allows it to boot. |
52 |
Oh well - I'm sure I'll work it out. Then of course somebody needs to |
53 |
patch it to mount /usr as well, or grab a copy of whatever Fedora is |
54 |
doing if it is open source. |
55 |
|
56 |
And as previously stated I'm fine with a more minimal initramfs being |
57 |
provided as well, although my feeling is that if the dracut solution |
58 |
works reliably it seems redundant. In fact, dracut -H creates a |
59 |
host-only solution that should only have minimal drivers installed, |
60 |
and once it finishes running it should free any RAM it is using and |
61 |
not leave any processes around. |
62 |
|
63 |
Rich |