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