Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:
> viv...@gmail.com wrote:
>> First problem udev/SD has is that it can't see all the file system
>> labels, for some reason it only see sda and sdb so it's able to partly
>> proceed in the boot sequence, mount / (root) but can't mount anything
>> else.
>
> What software parses the filesystem labels when you boot with openrc?
>
> (I ask because I never use labels myself.)
Short answer, mount and udev, and the kernel directly when fed that
information for root= on the kernel commandline. Openrc has basically
nothing to do with it. As such, I don't know what systemd's doing, but
if it indeed is a systemd bug, it's obviously doing /something/ rather
different... probably interacting in some unpredicted way with udev now
that they're integrating it.
Slightly more detail, quoting the mount (8) manpage:
>>>>>
It is possible to indicate a block special device using its volume LABEL
or UUID (see the -L and -U options below).
The recommended setup is to use LABEL=<label> or UUID=<uuid> tags rather
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file.
The tags are more readable, robust and portable. The mount(8) command
internally uses udev symlinks, so use the symlinks in /etc/fstab has no
advantage over LABEL=/UUID=. For more details see libblkid(3).
Note that mount(8) uses UUIDs as strings. The UUIDs from command line or
fstab(5) are not converted to internal binary representation. The string
representation of the UUID should be based on lower case characters.
<<<<<
The implication of the "as strings, not converted to binary" in the last
paragraph is that mount's simply doing a dumb string match against the
appropriate /dev/disk/by-* symlink names and dereferencing the symlink
after which it can proceed as usual if there's a match. It's udev (and
thus now systemd, since they're combining) that's actually doing the
work, exposing the /dev/disk/by-* symlinks with the correct references.
As such, mount basically supports anything found in that location,
including device hardware ID (combined with partition number where
appropriate, listed in /dev/disk/by-id), the already mentioned filesystem
LABEL (/dev/disk/by-label), PARTLABEL (GPT partitions have a partition
label that's similar in function to the filesystem label, but set at gdisk
time, not mkfs time, obviously this doesn't apply to legacy MBR
partitioning), PARTUID, PATH (bus path, tho like traditional /dev/[hs]dX,
this can be dynamic and the bus paths are longer and more obtuse for
humans so there's generally little practical use for this one), and (as
the manpage mentions, partition) UUID.
It is however worth noting that PARTLABEL at least is new enough that at
least as of a couple months ago when I looked at it for my md/raid setup,
while udev passed thru the PARTLABEL for physical devices, it was NOT
doing so for partitioned md/raid devices. (That mobo died and I don't
have md/raid on the new system so I can't verify current kernel 3.6-rc1+
and udev-187-r3 PARTLABEL-on-md/raid behavior.) So while people could
setup their md/raid gpt partitions with partition-labels using gptfdisk
(aka gdisk) or whatever, and I did so, only the ones on the physical
disks showed up in udev, and at the time I was looking at it, I was
running md/raid on virtually everything, so the feature was about useless
for me.
But that does mean that if mdev or whatever creates similar /dev/disk/by-
*, that mount and friends should use it just as they would with udev,
since all they're doing is a dumb string match and symlink deref.
It'a also worth noting that the kernel's root= line can take a number of
these (I'm not sure if it can take them all), including partlabel,
according to information someone posted on the btrfs list (which I was
following at the time, before I decided btrfs was too unstable still and
that I'd wait until next year to try again). I was going to try it, but
lost interest when I found I couldn't use it with fstab for my mdraid-
based gpt partitions anyway. So all I can say is that it was reported to
work on the btrfs list, and no one contradicted it, so...
>> a) SD does not re-calculate it's deptree/services when exiting from
>> rescue shell, it still try to start the "virtual" services as fstab
>> would have never modified, a reboot is needed
>
> systemctl --system daemon-reload ?
I've not tried systemd yet nor have I yet researched it (I have the
research vaguely scheduled for next year, sometime), but thanks to both
of you for these details. Based on past experience, I expect I'm
collecting the pieces even tho I don't have context to assemble them in,
but as a result, when I /do/ research it and get that context, the pieces
I already have thanks to discussions like this, will fall into place, and
it'll be far easier to get upto speed than it would have been had I tried
going into it "cold turkey".
So while I could guess, I'll just shutup and listen for this part.
> I just work with the files on disk. The only time I use tools is if
> systemd is running and needs to get told about updates. I don't think
> there are any files that are not plain text, so I don't think any tools
> are actually required.
Useful to know. =:^)
> If there's a way to boot into a shell prompt, even if it is just bash
> running as pid 1, then any system can be fixed. It requires knowing a
> lot about how the system works though, so a lot about systemd if the
> system uses systemd. Ie. knowing what files to change how in order to
> accomplish desired results.
FWIW, I actually have a set of grub2 menu entries with init=/bin/bash,
for troubleshooting. =:^)
But I think his point (valid or not) was that systemd's closing this
avenue off as it's simply too monolithic to get information out of or to
trial-start individual services even when not run as init, as is possible
with openrc, for instance.
With openrc, if you boot with init=/bin/bash, then try to start an openrc
initscript, it'll protest that it's not init and that results may not be
as intended due to lack of dependency tracking, etc, but it'll let you
override and try anyway, you just have to manage the service deps
manually or deal with the fallout if you screw it up.
He appears to be saying that this doesn't work with systemd. If it's not
init, it refuses to do /anything/ with its unit-file initscript
substitutes. That /does/ sound like just the sort of complaint (of
serveral) I've seen about systemd, but is it accurate?
If it is, then yes, booting to init=/bin/bash (or from live-rescue media)
and troubleshooting systemd problems from there *IS* going to be more
difficult than doing the same thing from openrc, because openrc has the
ability to override and one-off, while if this is correct, openrc doesn't.
> I don't understand this at all. Even if we go with what you write, then
> I expect that some providers will start to offer an ecosystem of
> systemd-optimized experiences for those who want it - but I do not
> believe for a second that those would somehow be exclusive to other
> systems.
In all these systemd threads, someone posted a link to gregkh's take on
gentoo as posted on google+. In the comments that followed, Ted T'so and
Kay S. had a rather interesting ping-pong in which one of them mentioned
the concern that Red Hat and an init implementor for them had about all
of this at the enterprise level. For those interested in such things,
it's worth going back and looking at that if you skipped it (either find
the link here or just go back and look at gregkh's G+ from ~April). I
knew there were enterprise implications, but that was the first time I
realized that RH wasn't necessarily 100% onboard with the full systemd
thing, addressing it "upstream" since AFAIK Lennart is a RH employee as
well.
>From that, it looks like they're more or less waiting for things to
settle down as well, and they plan on some perhaps major patches being
necessary for the first few RH releases with systemd. Of course, even
assuming those patches eventually make it upstream, Red Hat's release
cycle is long enough and their paying customers generally conservative
enough, that it may be some time before they actually have to worry about
supporting systemd in a deployed release.
And of course, Ubuntu's continuing to stick to upstart for the time
being, AFAIK. And CentOS and ScientificLinux being RH offshoots, they'll
follow RH.
In practice, I think that means that remote-hosted servers shouldn't have
to worry about systemd issues for another couple years, anyway, gentoo or
not. Of course if they run fedora, it might be a problem rather sooner.
But people running fedora should be used to dealing with such leading
edge issues, so no big deal for them either, really.
And given enterprise support terms, I guess we're looking at something
approaching a decade before folks are actually FORCED to systemd, by
falling off the end of the support train.
Meanwhile, that gives plenty of time for other "entrprisish" parties to
wait for redhat to decide what it's doing, then come up with their own
solutions once a bit more about the ultimate target is known. And until
then, except for those choosing to run fedora or the like, the existing
live-media-style remote rescue solutions should continue to work as they
have.
And in particular for gentoo users with remote hosts to worry about,
since it's already clear that for at least the near term (say a year or
two), gentoo's going to continue to default to openrc, there shouldn't be
a problem for at least /that/ long. And by the time any such problem
/were/ to appear, it's very likely that solutions for it will be
available as well... or given the day jobs of various gentoo devs,
there'd certainly be sufficient interest in continuing systemd-
alternative gentoo support, since they have similar issues themselves.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
