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

Il 12/08/2012 11:43, Duncan ha scritto:
> 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.

exactly my bet, since openrc with the _same_ (not recompiled) udev does work

>
> 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.

seem possible, when bug this bug will be fixed, honestly, I've not tried 
that, also because the bigger delay was added by a timeout not a reboot 
(that take 10 seconds)
https://bugzilla.redhat.com/show_bug.cgi?id=815727
unless we discover that virtual services are too complex to manage and 
SD will always be bugged by similar stuff. Time will tell

>
>> 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. =:^)

All the virtual services don't have a corresponding file on disk, except 
for the radix say ManageDisk@.device which get multiplexed automatically 
(similar to some openrc services does with symlinks, think at net.eth0).
Having those materialized would be of great help in debugging

>
>> 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.
correct, with an addition, even if things are fixable complexity _does_ 
matter, over a certain point of resources needed it really became "too 
difficult" == "unfixable".
Near enough example to this discussion was the initrd used some years 
ago from redhat (before dracut), it was simply plain unmodifiable in 
human time, and this doing something _much_ simpler than SD.
>
>> 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.
permit me to be worried anyway, systemd seem to going the "mutually 
exclusive" route, while enterprise customers benefit from backporting of 
fixes and rarely new versions added, gentoo does not.
>
> 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.
>
hopefully