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