[arch-general] /usr is not mounted. This is not supported.

[C Anthony Risinger]

On Wed, Oct 26, 2011 at 5:57 AM, clemens fischer
<ino-news at spotteswoode.dnsalias.org> wrote:
> Thomas Bächler wrote:
>
>> Am 25.10.2011 20:12, schrieb clemens fischer:
>>
>>>> Mounting /usr needs to go to the initramfs. It is possible to
>>>> implement a mount handler for this. At this stage, the by-label
>>>> symlinks exist already.
>>>
>>> AFAIU udevd(8) is responsible for setting up those symlinks.  How can
>>> they exist _before_ udevd(8) is started?
>>
>> I'll let you go back and read everything again, what you are saying
>> makes no sense whatsoever, and I have no idea how to reply to it.
>
> Lucky you, I have a way to explain it:  There are udev rules referencing
> stuff in /usr.  If people mount /usr by-label or by-uuid, udev must have
> completed to setup those symlinks.  Catch-22.

most of the time initramfs install scripts will inject everything you
need, even if stuff is in /usr, just fine, and it will all work
correctly ... in initramfs.  udev has everything it needs to run
properly in that environment (once the real init takes over these
assurances *POOF*) ... keep in mind udev will actually be ran twice,
the first being killed off before real init exec's and takes over.

the reasons for not supporting separate /usr are very similar to the
reasons for not supporting /run and /run/lock on within var anymore --
define "system binary".  the answer is transient, subjective, and
contextual -- my system is not your system is not their system -- eg,
systemd needs udev at step ONE ... nobody would have guessed init
would dep dbus 5+ years ago (except the visionaries of course ;-).
separate usr is mostly pointless in my experience, though there are
probably several appropriate niche cases.

per your "udev references /usr", if you look at the rule, it tries
/sbin and /usr/sbin -- in that order -- and it just so happens that:

# which dmsetup
/sbin/dmsetup

udev doesnt do much beyond actually creating the symlinks, the
UUIDs/LABELs -> blockdev mappings are discovered by blkid (take a look
at the rules).  like most things "*nix-ey", udevd is more-or-less a
dumb shell that provides a convenient environment for *other* tools to
do the heavy lifting.  it's "personal" task is to create nodes with
proper permissions + names + links as the kernel finds them ... that's
about it.

Tom/Thomas, I would be interested in experimenting with this as time
allows.  I'm not sure i grasp the problem though ... after switch_root
and mount --move why can't initiscripts or systemd simply notice the
mount and tear it down?  i must be overlooking something critical
because it's like 4am, but this seems related to a problem ive been
having w/systemd (on GPT -> MDRAID -> LVM2 ->EXT4) where at the last
second systemd flashing a message about not being about to deactivate
one device (the root?, i have swap/boot/root all on that array)

-- 

C Anthony