1 |
On Tue, Jan 29, 2019 at 3:37 PM Grant Taylor |
2 |
<gtaylor@×××××××××××××××××××××.net> wrote: |
3 |
> |
4 |
> On 01/29/2019 01:26 PM, Rich Freeman wrote: |
5 |
> > Uh, an initramfs typically does not exec a second kernel. I guess it |
6 |
> > could, in which case that kernel would need its own initramfs to get |
7 |
> > around to mounting its root filesystem. Presumably at some point you'd |
8 |
> > want to have your system stop kexecing kernels and start actually doing |
9 |
> > something useful... |
10 |
> |
11 |
> Which ever type of initramfs you use, the kernel that you are running |
12 |
> MUST have support for the minimum number of devices and file systems it |
13 |
> needs to be able to load other things. |
14 |
|
15 |
Certainly, which is what I've been saying. And what you've been saying as well. |
16 |
|
17 |
> Hence the difference between |
18 |
> built-in and modular drivers that I'm talking about. |
19 |
|
20 |
The kernel doesn't care where the driver came from. If you want to |
21 |
put root on ext4 then the kernel needs ext4 support. It doesn't |
22 |
matter if it is built-into the kernel or in a module stored in the |
23 |
initramfs. |
24 |
|
25 |
> And where is it going to load them from if said kernel doesn't support |
26 |
> initrds or loop back devices or the archive or file system type that the |
27 |
> initramfs is using? |
28 |
|
29 |
Why would you use an initramfs with a kernel incapable of using an initramfs? |
30 |
|
31 |
> |
32 |
> > Sure, and those are in the kernel that runs the initramfs. |
33 |
> |
34 |
> Not if they aren't compiled in. |
35 |
> |
36 |
|
37 |
Sure, in that case they would be in modules. I don't really get your |
38 |
point here. |
39 |
|
40 |
> I feel like this (sub)thread has become circular and unproductive. |
41 |
|
42 |
Clearly... |
43 |
|
44 |
-- |
45 |
Rich |