| 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 |
Archives