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