1 |
On 09/15/2011 01:03 PM, Joost Roeleveld wrote: |
2 |
> On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: |
3 |
>> On 09/15/2011 09:04 AM, Joost Roeleveld wrote: |
4 |
>>> Thank you for your response, however, I do have a few questions about |
5 |
>>> this. Where will this default initramfs actually need to be placed? |
6 |
>> |
7 |
>> It should be similar to how sys-apps/v86d is used for uvesafb support. |
8 |
>> It installs /usr/share/v86d/initramfs and when you configure your |
9 |
>> kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in |
10 |
>> order to have in included in your kernel image. |
11 |
> |
12 |
> Will this be set somewhere globally to the initramfs automatically? |
13 |
> And doesn't this mean that a new kernel will need to be build just to satisfy |
14 |
> this? |
15 |
|
16 |
You could also pass it as an initrd via your bootloader, like rich0 said |
17 |
in his reply. |
18 |
|
19 |
> I'm trying to think of how best to avoid users who are not aware to get caught |
20 |
> with non-booting systems. |
21 |
> |
22 |
> Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if |
23 |
> grub.conf can handle a "global" setting for initramfs. |
24 |
|
25 |
Maybe so. I'm not involved the implementation. I was just telling you |
26 |
the obvious stuff that I've gleaned from the discussions. |
27 |
|
28 |
>>> Also, how will |
29 |
>>> we be able to deal with situations where this script fails? |
30 |
>> |
31 |
>> It should drop you to a minimal shell. |
32 |
> |
33 |
> But, with udev then failing, will there be the /dev-entries to mount the |
34 |
> different partitions to fix the environment? |
35 |
|
36 |
I the preferred approach is to enable CONFIG_DEVTMPFS=y and |
37 |
CONFIG_DEVTMPFS_MOUNT=y, so that the kernel populates /dev for you |
38 |
automatically. |
39 |
|
40 |
>>> If Gentoo does decide to follow the initramfs-route, why not simply |
41 |
>>> implement /etc/init.d/localmount in the initramfs? |
42 |
>> |
43 |
>> I think that's pretty close to what we have planned, since the plan is |
44 |
>> to have the initramfs mount configuration stored on the root filesystem. |
45 |
> |
46 |
> But still require a seperate configuration file for this? |
47 |
|
48 |
I guess it could probably just use fstab. Again, I'm not involved in the |
49 |
implementation of all this. |
50 |
|
51 |
>>> Why require users to figure out which |
52 |
>>> filesystems are needed for udev? |
53 |
>> |
54 |
>> Simply mount all filesystems containing files managed by the package |
55 |
>> manager with the initramfs. Anything else would expose you to the |
56 |
>> possibility of unsatisfied dependencies. |
57 |
> |
58 |
> On my desktop, that would mean the following list: |
59 |
> /usr/ |
60 |
> /var/ |
61 |
> /opt/ |
62 |
> /tmp/ |
63 |
> /opt/tmp/ |
64 |
> |
65 |
>>> Also, I was actually hoping for a reply to the rest of my email as well, |
66 |
>>> especially the idea for splitting udev into 2 seperate processes. |
67 |
>> |
68 |
>> In essence, what your doing here is playing a game of "let's see how |
69 |
>> long we can delay the mounting of essential filesystems". If you play |
70 |
>> this game, then again, you expose yourself to the possibility of |
71 |
>> unsatisfied dependencies. Therefore, the only foolproof approach is to |
72 |
>> mount all essential filesystems as soon as possible (via initramfs). |
73 |
> |
74 |
> True, but I don't have any scripts configured for udev on my desktop. |
75 |
> My server has some scripts related to Xen, and those are all under |
76 |
> /etc/xen/... |
77 |
> |
78 |
> In this case, would it still be necessary to use an initramfs? |
79 |
|
80 |
Well, as long as your essential filesytems aren't mounted before init is |
81 |
called, there's always the possibility that some issue of unsatisfied |
82 |
dependencies will arise in the future. Therefore, the most foolproof and |
83 |
future-proof approach is to have them all mounted before init is called. |
84 |
|
85 |
>>> If someone can explain to me why my idea won't work, please let me know. |
86 |
>> |
87 |
>> If your goal is to expose yourself to the possibility of unsatisfied |
88 |
>> dependencies, they your idea will achieve it. |
89 |
> |
90 |
> No, my goal is to come up with a different solution to this problem which, on |
91 |
> my system and possibly also on a lot of other systems, doesn't actually exist. |
92 |
|
93 |
If a problem doesn't exist now, that doesn't mean one won't arise in the |
94 |
future. As said, the most future-proof approach is to have them all |
95 |
mounted before init is called. |
96 |
-- |
97 |
Thanks, |
98 |
Zac |