On 06/23/2014 06:28 AM, Adam Williamson wrote:
On Mon, 2014-06-23 at 05:03 +0200, poma wrote:
Not only LightDM, but all tested display managers refuse to work. There might be a general strike on i686 avenue. :)
Already reported, diagnosed and fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1110968 . I expect jwb will backport the patch on Monday.
Thanks for info. Yeah, as Lubomir stated "vdso=0" works with broken ones, and 3.16.0-0.rc2.git0.3.fc21.i686 PASSED
BTW, Adam, there are people running & testing Rawhide on i686! :)
poma
On Mon, Jun 23, 2014 at 19:13:36 +0200, poma pomidorabelisima@gmail.com wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode.
So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest.
On 06/23/2014 07:36 PM, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 19:13:36 +0200, poma pomidorabelisima@gmail.com wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode.
So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest.
I don't use ConsoleKit, nor do I need it. And is it supposed to be depreciated & outdated?
You're talking about systemd-214-3.fc21(2014-06-23), right?
I'm spinning md1, what worries you there?
poma
On Mon, 2014-06-23 at 12:36 -0500, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 19:13:36 +0200, poma pomidorabelisima@gmail.com wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
What services exactly are you talking about?
I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode.
What desktop are you using? It'd be good if you could file the bug for this, filing SELinux denials via sealert is pretty fast.
So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest.
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
On Mon, Jun 23, 2014 at 20:10:32 +0200, poma pomidorabelisima@gmail.com wrote:
You're talking about systemd-214-3.fc21(2014-06-23), right?
systemd-214-2.fc21
I haven't tested systemd-214-3.fc21 yet to see if the problem is still there.
I'm spinning md1, what worries you there?
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
Something is creating ones during boot since about a month ago. They are in a scratch location that gets recreated each boot.
What services exactly are you talking about?
Plague is one example.
I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode.
What desktop are you using? It'd be good if you could file the bug for this, filing SELinux denials via sealert is pretty fast.
XFCE.
So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest.
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem.
The one affecting raid has been filed. The other one is a crash early in boot, and I thought I had heard there were some nouveau regressions and that could affect that machine. I need to get netconsole setup again to capture the crash dump, but have given it lower priority because it seems like something others are likely to run into. The raid thing is weird in that it affects only one of my raid devices. And there may be something odd about the superblock, that gets checked more carefully in 3.16, than 3.15. Though I didn't see any commits that indicated a change in md raid superblock checking recently. I have an upstream bug filed for that as well.
Am 23.06.2014 20:52, schrieb Bruno Wolff III:
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
Something is creating ones during boot since about a month ago. They are in a scratch location that gets recreated each boot
you talk about static services and generators
they are created since way longer than one month ago and becoming more and more - most of them you can overrid with "systemctl mask whatever.service" but if you don't be careful the systemd won't boot after that
On 23.06.2014 20:44, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 20:10:32 +0200, poma pomidorabelisima@gmail.com wrote:
You're talking about systemd-214-3.fc21(2014-06-23), right?
systemd-214-2.fc21
I haven't tested systemd-214-3.fc21 yet to see if the problem is still there.
I'm spinning md1, what worries you there?
# mdadm --examine /dev/sd[az][0-9]|grep 'Level|'^\ *State''|awk '{print $1,$3,$4}'|sort|uniq Raid : raid1 State clean
# uname -r 3.16.0-0.rc2.git0.1.fc21.x86_64
poma
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
I'm seeing it, at least appear, to do something like this. There's a new binary, at least since systemd-208 in F-20 (sorry, shitty hotel wifi makes it too hard to do wider triage) called:
/usr/lib/systemd/system-generators/systemd-sysv-generator
What services exactly are you talking about?
I'm seeing the following style of messages in dmesg. The following is a sample but wc tells me there's 343 entries:
[44437.200793] systemd-sysv-generator[24124]: Could not find init script for radvd.service [44437.200810] systemd-sysv-generator[24124]: Could not find init script for ebtables.service [44437.200814] systemd-sysv-generator[24124]: Could not find init script for oddjobd.service [44437.200818] systemd-sysv-generator[24124]: Could not find init script for spice-vdagentd.service [44437.200822] systemd-sysv-generator[24124]: Could not find init script for livesys-late.service [44437.200826] systemd-sysv-generator[24124]: Could not find init script for tcsd.service [44437.200831] systemd-sysv-generator[24124]: Could not find init script for livesys.service [44437.200837] systemd-sysv-generator[24124]: Could not find init script for radvd.service
I can dig further if necessary in the next few days, I'm travelling at the moment and $dayjob is a bit intense so time is limited in the short term :(
Peter
On Wed, 2014-06-25 at 00:11 +0100, Peter Robinson wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
I'm seeing it, at least appear, to do something like this. There's a new binary, at least since systemd-208 in F-20 (sorry, shitty hotel wifi makes it too hard to do wider triage) called:
/usr/lib/systemd/system-generators/systemd-sysv-generator
What services exactly are you talking about?
I'm seeing the following style of messages in dmesg. The following is a sample but wc tells me there's 343 entries:
[44437.200793] systemd-sysv-generator[24124]: Could not find init script for radvd.service [44437.200810] systemd-sysv-generator[24124]: Could not find init script for ebtables.service [44437.200814] systemd-sysv-generator[24124]: Could not find init script for oddjobd.service [44437.200818] systemd-sysv-generator[24124]: Could not find init script for spice-vdagentd.service [44437.200822] systemd-sysv-generator[24124]: Could not find init script for livesys-late.service [44437.200826] systemd-sysv-generator[24124]: Could not find init script for tcsd.service [44437.200831] systemd-sysv-generator[24124]: Could not find init script for livesys.service [44437.200837] systemd-sysv-generator[24124]: Could not find init script for radvd.service
I can dig further if necessary in the next few days, I'm travelling at the moment and $dayjob is a bit intense so time is limited in the short term :(
Huh, well that's interesting. I guess I'll look into it.
On Tue, 2014-06-24 at 16:13 -0700, Adam Williamson wrote:
On Wed, 2014-06-25 at 00:11 +0100, Peter Robinson wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
I'm seeing it, at least appear, to do something like this. There's a new binary, at least since systemd-208 in F-20 (sorry, shitty hotel wifi makes it too hard to do wider triage) called:
/usr/lib/systemd/system-generators/systemd-sysv-generator
What services exactly are you talking about?
I'm seeing the following style of messages in dmesg. The following is a sample but wc tells me there's 343 entries:
[44437.200793] systemd-sysv-generator[24124]: Could not find init script for radvd.service [44437.200810] systemd-sysv-generator[24124]: Could not find init script for ebtables.service [44437.200814] systemd-sysv-generator[24124]: Could not find init script for oddjobd.service [44437.200818] systemd-sysv-generator[24124]: Could not find init script for spice-vdagentd.service [44437.200822] systemd-sysv-generator[24124]: Could not find init script for livesys-late.service [44437.200826] systemd-sysv-generator[24124]: Could not find init script for tcsd.service [44437.200831] systemd-sysv-generator[24124]: Could not find init script for livesys.service [44437.200837] systemd-sysv-generator[24124]: Could not find init script for radvd.service
I can dig further if necessary in the next few days, I'm travelling at the moment and $dayjob is a bit intense so time is limited in the short term :(
Huh, well that's interesting. I guess I'll look into it.
So, I looked, and found:
http://cgit.freedesktop.org/systemd/systemd/commit/src/sysv-generator?id=95e...
if I'm reading that correctly, I think this is basically the way systemd is now handling legacy sysv initscripts - by generating systemd units for them in a transient directory (/run/systemd/generator.late) on the fly at boot time.
That particular error is from the set_dependencies_from_rcnd function. I'm finding myself too dumb to figure out exactly what the generator is trying to do at that point, but I do notice that on my Rawhide system - which is pretty old, old enough to have been sysv at one point - I have a whole ton of dangling symlinks to old initscripts in /etc/rc*.d/, and at a glance, the "Could not find init script for foo.service" messages in my logs map quite nicely to all those dangling symlinks. I suspect if I cleaned them all up, the messages would go away.
I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug. That's my reading on the situation anyway. You should find the generated .service files match the remaining sysv services you have in /etc/init.d ; that's the case for me:
[adamw@adam isos]$ ls /etc/init.d/ functions livesys-late network vboxadd vboxadd-x11 livesys netconsole README vboxadd-service
[adamw@adam isos]$ ls /run/systemd/generator.late/ livesys-late.service network-online.target.wants vboxadd-service.service livesys.service network.service vboxadd-x11.service netconsole.service vboxadd.service
On Tue, Jun 24, 2014 at 16:30:59 -0700, Adam Williamson awilliam@redhat.com wrote:
I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug. That's my reading on the situation anyway. You should find the generated .service files match the remaining sysv services you have in /etc/init.d ; that's the case for me:
Thanks, that helped me get rid of extraneous boot output.
I used: rm -vf `find -L /etc/rc.d -lname '*'` to remove these sym links.
However this didn't solve my concern about some services attempting to start that shouldn't. But now I'm thinking there might be some other old config around that I should look for. I'm going to start with plague-server since I never actually used that, but might have had to disable it in the past.
On Mon, Jun 23, 2014 at 13:52:10 -0500, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem.
3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two other issues.
The one affecting raid has been filed. The other one is a crash early
It looks like this one might be elsewhere in the I/O stack. When I got a live image to boot, dd reported /dev/sda3 as zero size which would explain why the superblock was bad. blkid returned info about the device so this seems really odd. And it only seems to happen on this one partition.
On Tue, 2014-06-24 at 19:48 -0500, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 13:52:10 -0500, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem.
3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two other issues.
Well, it's a pretty early one, so this isn't surprising. The 'special' thing about the vdso bug is it was, AFAICT, more or less a complete showstopper for the i686 kernel, regardless of hardware: it happened on any system you tried to boot an i686 kernel on.
The one affecting raid has been filed. The other one is a crash early
It looks like this one might be elsewhere in the I/O stack. When I got a live image to boot, dd reported /dev/sda3 as zero size which would explain why the superblock was bad. blkid returned info about the device so this seems really odd. And it only seems to happen on this one partition.
Yup, file the bugs and hopefully they'll be fixed rapidly :)
On Wed, Jun 25, 2014 at 3:24 AM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2014-06-24 at 19:48 -0500, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 13:52:10 -0500, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem.
3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two other issues.
Well, it's a pretty early one, so this isn't surprising. The 'special' thing about the vdso bug is it was, AFAICT, more or less a complete showstopper for the i686 kernel, regardless of hardware: it happened on any system you tried to boot an i686 kernel on.
The one affecting raid has been filed. The other one is a crash early
It looks like this one might be elsewhere in the I/O stack. When I got a live image to boot, dd reported /dev/sda3 as zero size which would explain why the superblock was bad. blkid returned info about the device so this seems really odd. And it only seems to happen on this one partition.
Yup, file the bugs and hopefully they'll be fixed rapidly :)
We're seeing the same issue with ARM booting, we filed bug 1109603 [1] but it's some what intermittent.
Peter
kernel@lists.fedoraproject.org
-
Adam Williamson -
Bruno Wolff III -
Peter Robinson -
poma -
Reindl Harald