12:21 p.m.
maybe it's been reported already, but here both f15 kernels crash at boot.
f14 works fine.
# rpm -q kernel
kernel-2.6.35.6-45.fc14.i686
kernel-2.6.38-0.rc2.git0.1.fc15.i686
kernel-2.6.38-0.rc2.git1.3.fc15.i686
processor: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
ram: 2gb
motherboard: Gigabyte M55S-S3
sorry, i can't send smoltProfile:
# smoltSendProfile
Traceback (most recent call last):
File "/usr/bin/smoltSendProfile", line 39, in <module>
import smolt
File "/usr/share/smolt/client/smolt.py", line 54, in <module>
from devicelist import cat
ImportError: No module named devicelist
--
"The beginning is the most important part of the work."
-- *Plato*
1:07 p.m.
On Tue, 2011-01-25 at 20:21 +0200, cornel panceac wrote:
maybe it's been reported already, but here both f15 kernels crash
at
boot. f14 works fine.
This is obviously highly hardware dependent, so your report isn't much
use as is. =) The kernel boots on other hardware (like mine). So it'd be
good to have more details of the crash, your hardware info, and a test
with a 2.6.37 kernel build (I suspect this is likely a 2.6.38
regression). And you should probably file it, at redhat or upstream
bugzilla.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:26 p.m.
2011/1/25 Adam Williamson <awilliam(a)redhat.com>
On Tue, 2011-01-25 at 20:21 +0200, cornel panceac wrote:
> maybe it's been reported already, but here both f15 kernels crash at
> boot. f14 works fine.
This is obviously highly hardware dependent, so your report isn't much
use as is. =) The kernel boots on other hardware (like mine). So it'd be
good to have more details of the crash, your hardware info, and a test
with a 2.6.37 kernel build (I suspect this is likely a 2.6.38
regression). And you should probably file it, at redhat or upstream
bugzilla.
probably the smolt profile (from f14) will be someday available here:
http://www.smolts.org/client/show/pub_6da62aa6-7873-4da2-8803-4e5e6a3c5ff9
right now, the site is in guru_meditation state :)
while the crash info was displayed, i've seen some mentions of plymouthd.
video card is
$ lspci -nn | grep -i vga
02:00.0 VGA compatible controller [0300]: nVidia Corporation G73 [GeForce
7300 GT] [10de:0393] (rev a1)
i'll try disabling the plymouthd service (if there is such thing) and report
back.
2:02 p.m.
2011/1/25 cornel panceac <cpanceac(a)gmail.com>
2011/1/25 Adam Williamson <awilliam(a)redhat.com>
On Tue, 2011-01-25 at 20:21 +0200, cornel panceac wrote:
> > maybe it's been reported already, but here both f15 kernels crash at
> > boot. f14 works fine.
>
> This is obviously highly hardware dependent, so your report isn't much
> use as is. =) The kernel boots on other hardware (like mine). So it'd be
> good to have more details of the crash, your hardware info, and a test
> with a 2.6.37 kernel build (I suspect this is likely a 2.6.38
> regression). And you should probably file it, at redhat or upstream
> bugzilla.
probably the smolt profile (from f14) will be someday available here:
http://www.smolts.org/client/show/pub_6da62aa6-7873-4da2-8803-4e5e6a3c5ff9
right now, the site is in guru_meditation state :)
while the crash info was displayed, i've seen some mentions of plymouthd.
video card is
$ lspci -nn | grep -i vga
02:00.0 VGA compatible controller [0300]: nVidia Corporation G73 [GeForce
7300 GT] [10de:0393] (rev a1)
i'll try disabling the plymouthd service (if there is such thing) and
report back.
yes, the process that crashes the kernel seems to be plymouthd. any know way
to prevent plymouthd from starting? removing rhgb quiet didn't help. also,
once, i've seen something familiar: /proc/device-tree: can't find root, like
in the good old days, when fedora was unable to figure out which of my three
hard drives is first ... but that's another story.
--
"The beginning is the most important part of the work."
-- *Plato*
11:22 a.m.
2011/1/26 Kyle McMartin <kyle(a)mcmartin.ca>
It was a problem with transparent huge pages on 32-bit x86, should
be
worked around in 2.6.38-rc2-git3.2 and fixed properly in the next
snapshot.
thank you very much. so, in a short while, the updates should reach the
repos?
--
"The beginning is the most important part of the work."
-- *Plato*
11:38 a.m.
On 01/26/2011 05:22 PM, cornel panceac wrote:
2011/1/26 Kyle McMartin <kyle(a)mcmartin.ca <mailto:kyle@mcmartin.ca>>
It was a problem with transparent huge pages on 32-bit x86, should be
worked around in 2.6.38-rc2-git3.2 and fixed properly in the next
snapshot.
thank you very much. so, in a short while, the updates should reach
the repos?
If you are impatient and have a working install you can fetch that
http://koji.fedoraproject.org/koji/buildinfo?buildID=215618
JBG
11:43 a.m.
2011/1/26 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>
On 01/26/2011 05:22 PM, cornel panceac wrote:
2011/1/26 Kyle McMartin <kyle(a)mcmartin.ca>
> It was a problem with transparent huge pages on 32-bit x86, should be
> worked around in 2.6.38-rc2-git3.2 and fixed properly in the next
> snapshot.
>
>
If you are impatient and have a working install you can fetch that
http://koji.fedoraproject.org/koji/buildinfo?buildID=215618
JBG
yay! it's booting with
$ uname -r
2.6.38-0.rc2.git3.2.fc15.i686
thank you very much!
3:36 p.m.
On Tue, 2011-01-25 at 21:26 +0200, cornel panceac wrote:
i'll try disabling the plymouthd service (if there is such thing) and
report back.
Just drop 'rhgb quiet' from the boot parameters and you should get a lot
more detail =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:26 a.m.
On 01/25/2011 09:36 PM, Adam Williamson wrote:
On Tue, 2011-01-25 at 21:26 +0200, cornel panceac wrote:
> i'll try disabling the plymouthd service (if there is such thing) and
> report back.
Just drop 'rhgb quiet' from the boot parameters and you should get a lot
more detail =)
I can confirm kernel not working on i386 I'm battling some of those
dragons kyle mentions in comment..
* Tue Jan 25 2011 Kyle McMartin <kmcmartin(a)redhat.com>
2.6.38-0.rc2.git3.2 - [x86] Disable TRANSPARENT_HUGEPAGE for now, there
be dragons there.
So nigthly spins are out for me until kernel-2.6.38-0.rc2.git3.2.fc15
ends up on the nightly spins seriously those nightly spins need to be
composed of whatever are the latest bit's in koji....
JBG
7:23 a.m.
On Wed, Jan 26, 2011 at 08:26:36 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
So nigthly spins are out for me until kernel-2.6.38-0.rc2.git3.2.fc15
ends up on the nightly spins seriously those nightly spins need to be
composed of whatever are the latest bit's in koji....
They are. But there is latency from when builds start to when they get out
there. And sometimes builds fail because of package dependency issues.
7:49 a.m.
On 01/26/2011 01:23 PM, Bruno Wolff III wrote:
On Wed, Jan 26, 2011 at 08:26:36 +0000,
"\"Jóhann B. Guðmundsson\""<johannbg(a)gmail.com> wrote:
> So nigthly spins are out for me until kernel-2.6.38-0.rc2.git3.2.fc15
> ends up on the nightly spins seriously those nightly spins need to be
> composed of whatever are the latest bit's in koji....
They are. But there is latency from when builds start to when they get out
there.
Hum I'm not so sure releng is using koji repo for nightly spins I think
they actually need to get pushed somewhere before they get picked up
what I'm meaning is that when you build something in koji and that build
was successful it will get pulled into on of the nightly spins for that day.
And if you build 10 builds of a package before the schedual cron run to
compose those nightly spin is run it would automatically pull in and use
your latest build in koji..
And sometimes builds fail because of package dependency issues.
As is to be expected to happen on occasion but then the maintainers of
those dependency issue should be notified that their package is halting
the compose process which should have the added bonus affect that
maintainers would quicker fix those dependency issue.
JBG
8:39 a.m.
On Wed, Jan 26, 2011 at 13:49:41 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
Hum I'm not so sure releng is using koji repo for nightly spins
I
think they actually need to get pushed somewhere before they get
picked up what I'm meaning is that when you build something in koji
and that build was successful it will get pulled into on of the
nightly spins for that day.
Currently I believe that the night composes are pulling from the rawhide
repos (so anything built that is tagged for rawhide will be pulled in) and
that the git repo for spin kickstarts is used. After the branch they will
use F15 + the git repo. Very close to the release we may start using the
spin-kickstarts package.
As is to be expected to happen on occasion but then the maintainers
of those dependency issue should be notified that their package is
halting the compose process which should have the added bonus affect
that maintainers would quicker fix those dependency issue.
Good luck with that. I see dependency errors go unfixed for months. If
things remain a problem long enough some jawboning gets done or the help
of a proven packager is enlisted. Packagers already get automatically notified
of dependency errors and are supposed to fix them in a timely manner. Doing
a second automated notification isn't going to add much value.
9:12 a.m.
On 01/26/2011 02:39 PM, Bruno Wolff III wrote:
Good luck with that. I see dependency errors go unfixed for months.
If
things remain a problem long enough some jawboning gets done or the help
of a proven packager is enlisted. Packagers already get automatically notified
of dependency errors and are supposed to fix them in a timely manner. Doing
a second automated notification isn't going to add much value.
True I was not aware that they already received any kind of notification
about deps issue perhaps QA can pressure FESCO or FPC to address this
issue like for instance revoke packages privileges if maintainers are
unable to address this issue in timely manner?
JBG
8:42 a.m.
On Wed, Jan 26, 2011 at 13:49:41 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
Hum I'm not so sure releng is using koji repo for nightly spins I think
they actually need to get pushed somewhere before they get picked up
what I'm meaning is that when you build something in koji and that build
was successful it will get pulled into on of the nightly spins for that day.
Just as a side note, releng isn't directly responsible for the nightly
composes, it's really under infrastructure. Kevin Fenzi does most or all of
the maintenance. I'm not sure who his backup is for this.
9:14 a.m.
On 01/26/2011 02:42 PM, Bruno Wolff III wrote:
On Wed, Jan 26, 2011 at 13:49:41 +0000,
"\"Jóhann B. Guðmundsson\""<johannbg(a)gmail.com> wrote:
> Hum I'm not so sure releng is using koji repo for nightly spins I think
> they actually need to get pushed somewhere before they get picked up
> what I'm meaning is that when you build something in koji and that build
> was successful it will get pulled into on of the nightly spins for that day.
Just as a side note, releng isn't directly responsible for the nightly
composes, it's really under infrastructure. Kevin Fenzi does most or all of
the maintenance. I'm not sure who his backup is for this.
Somehow it came logically to me that this would fall under releng tasks
I stand corrected..
JBG
11:10 a.m.
On Wed, 26 Jan 2011 15:14:40 +0000
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com> wrote:
On 01/26/2011 02:42 PM, Bruno Wolff III wrote:
> On Wed, Jan 26, 2011 at 13:49:41 +0000,
> "\"Jóhann B. Guðmundsson\""<johannbg(a)gmail.com>
wrote:
>> Hum I'm not so sure releng is using koji repo for nightly spins I
>> think they actually need to get pushed somewhere before they get
>> picked up what I'm meaning is that when you build something in
>> koji and that build was successful it will get pulled into on of
>> the nightly spins for that day.
> Just as a side note, releng isn't directly responsible for the
> nightly composes, it's really under infrastructure. Kevin Fenzi
> does most or all of the maintenance. I'm not sure who his backup is
> for this.
Nightly composes are using rawhide currently.
So, the only difference between that and a koji static repo is that
it's been pushed out in a rawhide. Using koji static repos could result
in some spins using some bits and others using other bits as builds
landed, which I think could be confusing. Also, things that appear in
koji static repos might be broken to the point where they are untagged
and don't appear in rawhide the next day (see perl today), which might
result in some spins building and using them before they are untagged.
So, I think rawhide is the right thing to use. ;)
kevin
11:42 a.m.
On 01/26/2011 05:10 PM, Kevin Fenzi wrote:
On Wed, 26 Jan 2011 15:14:40 +0000
"Jóhann B. Guðmundsson"<johannbg(a)gmail.com> wrote:
> On 01/26/2011 02:42 PM, Bruno Wolff III wrote:
>> On Wed, Jan 26, 2011 at 13:49:41 +0000,
>> "\"Jóhann B. Guðmundsson\""<johannbg(a)gmail.com>
wrote:
>>> Hum I'm not so sure releng is using koji repo for nightly spins I
>>> think they actually need to get pushed somewhere before they get
>>> picked up what I'm meaning is that when you build something in
>>> koji and that build was successful it will get pulled into on of
>>> the nightly spins for that day.
>> Just as a side note, releng isn't directly responsible for the
>> nightly composes, it's really under infrastructure. Kevin Fenzi
>> does most or all of the maintenance. I'm not sure who his backup is
>> for this.
Nightly composes are using rawhide currently.
So, the only difference between that and a koji static repo is that
it's been pushed out in a rawhide. Using koji static repos could result
in some spins using some bits and others using other bits as builds
landed, which I think could be confusing. Also, things that appear in
koji static repos might be broken to the point where they are untagged
and don't appear in rawhide the next day (see perl today), which might
result in some spins building and using them before they are untagged.
So, I think rawhide is the right thing to use. ;)
So how does this work do build get automatically tagged ( good ) which
maintainers then need to untag if they dont want to push it or is it the
otherway around maintainers need to tag builds for rawhide ( bad ) which
then they may or may not forget to do?
JBG
12:12 p.m.
On Wed, Jan 26, 2011 at 17:42:17 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
So how does this work do build get automatically tagged ( good ) which
maintainers then need to untag if they dont want to push it or is it the
otherway around maintainers need to tag builds for rawhide ( bad ) which
then they may or may not forget to do?
If you do a new build for rawhide it gets tagged for rawhide automatically
and will show up in the next rawhide repo. You need to do something special
to keep this from happening. It's not like for updates where you need to
push something in bodhi. Though once we branch the nightlies will be
based on on F15 and people will need to push stuff to updates to get that
stuff into the nightly composes.
9:56 a.m.
2011/1/26 Bruno Wolff III <bruno(a)wolff.to>:
On Wed, Jan 26, 2011 at 08:26:36 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
>
> So nigthly spins are out for me until kernel-2.6.38-0.rc2.git3.2.fc15
> ends up on the nightly spins seriously those nightly spins need to be
> composed of whatever are the latest bit's in koji....
They are. But there is latency from when builds start to when they get out
there. And sometimes builds fail because of package dependency issues.
That explains something I found for my own private builds - I build
both F14 current, as well as rawhide isos from the current development
repo - F14 works fine but for the past week or so I have been unable
to get a successful build of rawhide for my package manifest - I guess
if there are dep problems this might explain it....
--
mike c
10:06 a.m.
On Wed, Jan 26, 2011 at 15:56:48 +0000,
mike cloaked <mike.cloaked(a)gmail.com> wrote:
That explains something I found for my own private builds - I build
both F14 current, as well as rawhide isos from the current development
repo - F14 works fine but for the past week or so I have been unable
to get a successful build of rawhide for my package manifest - I guess
if there are dep problems this might explain it....
If that is the problem the error message should say that. The desktop spin
should be building. I know that raidem is broken for the games spin. I
think it has a gcc dependency. But that's only been a couple of days, so
I am not too worried at this point in the development cycle.
4838
days inactive
4839
days old
20 comments
7 participants
participants (7)
-
Adam Williamson -
Bruno Wolff III -
cornel panceac -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Kyle McMartin -
mike cloaked