1 |
On Thursday, September 15, 2011 01:34:50 PM Zac Medico wrote: |
2 |
> On 09/15/2011 01:03 PM, Joost Roeleveld wrote: |
3 |
> > But, with udev then failing, will there be the /dev-entries to mount the |
4 |
> > different partitions to fix the environment? |
5 |
> |
6 |
> I the preferred approach is to enable CONFIG_DEVTMPFS=y and |
7 |
> CONFIG_DEVTMPFS_MOUNT=y, so that the kernel populates /dev for you |
8 |
> automatically. |
9 |
|
10 |
Will this be sufficient for "localmount" to get the system to work correctly? |
11 |
It is my understanding that some udev-scripts are the actual problem that is |
12 |
being solved with this? |
13 |
|
14 |
I wasn't aware of these kernel options also being required. |
15 |
|
16 |
> >>> Also, I was actually hoping for a reply to the rest of my email as |
17 |
> >>> well, especially the idea for splitting udev into 2 seperate |
18 |
> >>> processes.>> |
19 |
> >> In essence, what your doing here is playing a game of "let's see how |
20 |
> >> long we can delay the mounting of essential filesystems". If you play |
21 |
> >> this game, then again, you expose yourself to the possibility of |
22 |
> >> unsatisfied dependencies. Therefore, the only foolproof approach is to |
23 |
> >> mount all essential filesystems as soon as possible (via initramfs). |
24 |
> > |
25 |
> > True, but I don't have any scripts configured for udev on my desktop. |
26 |
> > My server has some scripts related to Xen, and those are all under |
27 |
> > /etc/xen/... |
28 |
> > |
29 |
> > In this case, would it still be necessary to use an initramfs? |
30 |
> |
31 |
> Well, as long as your essential filesytems aren't mounted before init is |
32 |
> called, there's always the possibility that some issue of unsatisfied |
33 |
> dependencies will arise in the future. Therefore, the most foolproof and |
34 |
> future-proof approach is to have them all mounted before init is called. |
35 |
|
36 |
With systemd, one of these is the dbus-stack. Yes, I'm aware of this. |
37 |
But, if systemd isn't used, init should work. Or have I missed something about |
38 |
init being deprecated for systemd? |
39 |
|
40 |
I think systemd is nice for desktops/laptops. But on servers it seems to be |
41 |
overkill to me and as I umount filesystems as part of my backup-scripts, |
42 |
having something force-mount them in the background is going to kill those |
43 |
scripts. |
44 |
But this bit is off-topic. |
45 |
|
46 |
> >>> If someone can explain to me why my idea won't work, please let me |
47 |
> >>> know.>> |
48 |
> >> If your goal is to expose yourself to the possibility of unsatisfied |
49 |
> >> dependencies, they your idea will achieve it. |
50 |
> > |
51 |
> > No, my goal is to come up with a different solution to this problem |
52 |
> > which, on my system and possibly also on a lot of other systems, |
53 |
> > doesn't actually exist. |
54 |
> If a problem doesn't exist now, that doesn't mean one won't arise in the |
55 |
> future. As said, the most future-proof approach is to have them all |
56 |
> mounted before init is called. |
57 |
|
58 |
Or, if I am not mistaken, before udev is started when not using systemd. |
59 |
|
60 |
-- |
61 |
Joost |