Re: [gentoo-dev] Questions about SystemD and OpenRC
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.) > 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 ? > b) since it does not work even after reboot, there must be something else, > but what? this bring us to the point I'm not contesting that there is a problem with your systemd setup, and maybe it is a problem with systemd, but unless you know for sure maybe it's premature to say that "it" is systemd? I would investigate what the problem really is. > SD has mainly two things to debug boot `systemctl dump` and > `systemd-journal` Hm, debug boot like how? I mean: what problem did you want to resolve when you say that you were debugging boot? > impossible even to understand WHAT failed to start, not to mention WHY There are no logfiles for the individual services? > the magnificient binary log^W^W journal is kept on tmpfs (in ram) so > it's not even available at boot in different situation. I'm not sure what the purpose of the binary log is, maybe it makes sense to have it per session, but in any case I guess the services should be doing some logging of their own? > every try needed many minutes because SD wait for a long timeout before > going to the rescue shell I would be interested in understanding why there was a long wait, I mean: what was systemd waiting for? > - SD does not see anything else than systemd for boot. > Interaction with SD from a livecd, is difficult, almost all tools don't > work because SD is not running. 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. > transported on remote server administration this is a *nightmare* 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. > various provider offer livecd like system which don't offer SD. > so no easy migration, no easy first install, every failure is > definitive, a no go 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. > - the journal will never become simpler, can only grow, debugging things in > the shell will be nearly impossible for excess of data (and lack of useful > one if it continue this way) Configure it to write into files? > - virtual/autogenerated services are and will be difficult to cope with, > impossible to disable Hm, do they matter? > - every change in the early boot procedure will require reboot Is that different from another pid 1? > - which sum to: SD will work until it work, when something does not will be > a royal pain to solve _and_ nothing else other than SD will be available to > alleviate the pain This does not match my experience at all. I don't know what you did wrong though, your email wasn't very specific. :\ //Peter
Re: [gentoo-dev] SRC_URI in metadata.xml
On 11/08/2012 15:43, Alec Warner wrote: > If you want metadata.dtd patched; please file a bug against www@ and > someone will look at it (you may have to poke us a few times... ;)) Can we have xmlschema instead? You know so that things like broken email addresses in can be caught... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Questions about SystemD and OpenRC
Il 07/08/2012 14:47, Sylvain Alain ha scritto:
Hi everyone, for a couple of months now, I see on the list some of
activities about OpenRC been ported to FreeBSD or OpenRC to Debian and
other stuff related to SystemD.
I have some basic questions about all that :
1. The SystemD and Udev projetcs are merged now, so what is the impact
on the Gentoo on a short term period ?
The answer is in the hand of others, I sincerely hope someone will fork
2. I saw on some lists that Gnome/Kde and Xfce plan to use some
SystemD API, so does it means that we will need to install SystemD
aside of OpenRC ?
It's not possible at the moment. systemd break non-systemd setups.
3. In a long term vision, can OpenRC still exist on a Gentoo
box(OpenRC might be able to boot the box then give the control to
SystemD/Udev for the rest of the boot process) or we will need to
migrate to SystemD to be able to use Gnome/Kde or Xfce ?
PID 1 has some own properties, but systemd can work at user privileges,
maybe
4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps
related to SystemD ? I don't understand why these desktops want to
depend on a specific Sysint
Because starting daemons it's much more error prone than everyone
thinks, at least everyone which didn't become involved in coding for it.
And now my personal rant with some considerations, from memory, may be
not totally accurate.
Tried systemd (SD from now) the other day, as everyone knows it need to
rebuild some part of the system with the "systemd" use flag.
These things broke when not started by SD, for example pulseaudio, had
problems also with auto-mount possibly more not even noticed.
This box has 3 disk:
sda) ssd on sda for gentoo whole disk (not partitioned)
sd{b,c}) /home /srv /boot md raid 1
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.
After putting in fstab the real /dev paths (something really old siecle)
manually mount them with systemctl --ignore-deps (the name of the option
is different please bear with me) works but the dependancies are not
satisfied, for two reasons:
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
b) since it does not work even after reboot, there must be something
else, but what? this bring us to the point
SD has mainly two things to debug boot `systemctl dump` and
`systemd-journal` but the very much magnified advantages of the binary
log^W journal are totally invisible in this case because it's
difficult^W nearly impossible even to understand WHAT failed to start,
not to mention WHY
the magnificient binary log^W^W journal is kept on tmpfs (in ram) so
it's not even available at boot in different situation.
every try needed many minutes because SD wait for a long timeout before
going to the rescue shell, gave up after few hours of try, upgrading
Vista SP0 to current needed less reboot and time.
But this has been beneficial because I've now realized few important
things that will be probably never disappear from SD and will be there
forever, things that make me think this stuff is really dangerous.
List of problems that will _never_ be fixed
- SD does not see anything else than systemd for boot.
Interaction with SD from a livecd, is difficult, almost all tools don't
work because SD is not running.
transported on remote server administration this is a *nightmare*,
various provider offer livecd like system which don't offer SD.
so no easy migration, no easy first install, every failure is
definitive, a no go
- the journal will never become simpler, can only grow, debugging things
in the shell will be nearly impossible for excess of data (and lack of
useful one if it continue this way)
- virtual/autogenerated services are and will be difficult to cope with,
impossible to disable
- every change in the early boot procedure will require reboot
- which sum to: SD will work until it work, when something does not will
be a royal pain to solve _and_ nothing else other than SD will be
available to alleviate the pain
difficult to accept for the desktop, impossible for the server.
written by someone which like _some_ of the SD stuff.
Re: [gentoo-dev] SRC_URI in metadata.xml
On Sat, Aug 11, 2012 at 1:55 PM, Corentin Chary wrote: > On Fri, Aug 10, 2012 at 10:12 PM, Diego Elio Pettenò > wrote: >> On 10/08/2012 13:05, Corentin Chary wrote: >>> Right, our proposal is not here to replace SRC_URI, it's here to fix >>> the cases where SRC_URI can't be sanely used to guess new upstream >>> versions (strange mangling rules, unbrowsable directories, etc...). >> >> Yes I guess Jeroen was just saying why we shouldn't abandon it as Gilles >> proposed. >> >> FWIW for the rest it feels right to me. Although this starts to add up >> to the reasons why at least metadata.xml should be validated by schema, >> and not DTD. > > Maybe .. We plan to use http://euscan.iksaif.net";> to > avoid editing metadata.dtd (for now). > What do you think about format propositions ? Current format looks > like what was given in the examples, but mgorny feels that something > more xmlish would be better. If you want metadata.dtd patched; please file a bug against www@ and someone will look at it (you may have to poke us a few times... ;)) > > -- > Corentin Chary > http://xf.iksaif.net >
Re: [gentoo-dev] RFC: virtual/libudev
On Sat, Aug 11, 2012 at 8:29 PM, Michał Górny wrote: > On Sat, 11 Aug 2012 20:11:18 +0200 > Peter Alfredsen wrote: > >> This outcome was just super. Systemd was bumped to -188 today. Udev is >> still at -187. Instead of actually listening to upstream[1], which >> would be easy with a virtual, we're now stuck with one part of the duo >> being at one version and the other part of the duo another. And when I >> login to X with this combo, my display is /upside-down/. > > What was your previous state? Were you using older systemd with newer > udev? No, I was using the integrated package -187. Downgrading fixed the problem. /Peter
Re: [gentoo-dev] RFC: virtual/libudev
On Sat, 11 Aug 2012 20:11:18 +0200 Peter Alfredsen wrote: > This outcome was just super. Systemd was bumped to -188 today. Udev is > still at -187. Instead of actually listening to upstream[1], which > would be easy with a virtual, we're now stuck with one part of the duo > being at one version and the other part of the duo another. And when I > login to X with this combo, my display is /upside-down/. What was your previous state? Were you using older systemd with newer udev? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: virtual/libudev
This outcome was just super. Systemd was bumped to -188 today. Udev is still at -187. Instead of actually listening to upstream[1], which would be easy with a virtual, we're now stuck with one part of the duo being at one version and the other part of the duo another. And when I login to X with this combo, my display is /upside-down/. And I don't know if it's because our hackery on the tarball has left out some vital part, because disabling stuff in the one ebuild (gudev in systemd) and enabling it in the other is going to cause some non-trivial problem, or if it's simply a bug upstream. But that's okay, because gentooers are powerusers and we're supposed to have the time to debug this stuff, right? This is disgusting. Really. Virtuals are simple. This stuff is freaking *hard*. Whoever it was that forced this on systemd in gentoo should have a big *object* stuck in *place* and be forced to *action* as penance for the time I'll have to waste fixing this. [1] "And what we will certainly not do is compromise the uniform integration into systemd for some cosmetic improvements for non-systemd systems. (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.)" http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html Meaning: For now, you're allowed to have udev without systemd but mixing-and-matching udev versions and systemd versions will be unsupported and patching udev will probably break systemd at some point. TL;DR: This is a sucky situation you've put all users of udev in.
Re: [gentoo-dev] SRC_URI in metadata.xml
On Fri, Aug 10, 2012 at 10:12 PM, Diego Elio Pettenò wrote: > On 10/08/2012 13:05, Corentin Chary wrote: >> Right, our proposal is not here to replace SRC_URI, it's here to fix >> the cases where SRC_URI can't be sanely used to guess new upstream >> versions (strange mangling rules, unbrowsable directories, etc...). > > Yes I guess Jeroen was just saying why we shouldn't abandon it as Gilles > proposed. > > FWIW for the rest it feels right to me. Although this starts to add up > to the reasons why at least metadata.xml should be validated by schema, > and not DTD. Maybe .. We plan to use http://euscan.iksaif.net";> to avoid editing metadata.dtd (for now). What do you think about format propositions ? Current format looks like what was given in the examples, but mgorny feels that something more xmlish would be better. -- Corentin Chary http://xf.iksaif.net
