[arch-general] /usr is not mounted. This is not supported.
C Anthony Risinger
anthony at xtfx.me
Thu Oct 27 05:22:59 EDT 2011
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
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
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)
More information about the arch-general