[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:

> vivo75@×××××.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