[systemd-devel] /usr on separate file system

[Michael Biebl]

2011/2/25 Kay Sievers <kay.sievers at vrfy.org>:
> On Fri, Feb 25, 2011 at 20:12, Bill Nottingham <notting at redhat.com> wrote:
>> Kay Sievers (kay.sievers at vrfy.org) said:
>>> >> > Well, it hasn't been working correctly in ages. It's really not new
>>> >> > policy we came up with here. It's just a warning to the user that setups
>>> >> > like this will break. End of story.
>>> >>
>>> >> Is this flagged for the Fedora 15 release notes?
>>> >
>>> > Speaking as a non-systemd maintainer, IMO:
>>> >
>>> > - Issues that arise with separate /usr should likely be fixed
>>>
>>> D-Bus has its config there, we rely on D-Bus, so this would be the
>>> first thing to fix. Unless this is done, the warning is really useful.
>>> It's more like a "taint" flag that tells "you are on your own here"
>>> than anything else.
>>
>> This only matters if systemd relies on dbus, or a dbus-activated service,
>> to bring up local-fs.target. If it doesn't, it's not an issue.
>
> That's right today, but the use of D-Bus is growing. And I'm not even
> sure that we currently handle the D-Bus daemon startup with an empty
> /usr properly.

I talked to Keybuk about this and he told me that dbus should handle
this case (/usr not being available) rather gracefully.

What doesn't work is dbus activation, when /usr is not available. But
dbus-daemon will recheck /usr/share/dbus-1 on every activation
request, so as soon as /usr becomes available it should behave as
normal.

What is more of a problem is machine-id living in /var/lib, so
currently you can't start dbus-daemon earlier before local-fs.target
anyway, as /var being on a separate partition is quite a common setup.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?