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
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.
2011/1/25 Adam Williamson awilliam@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.
2011/1/25 cornel panceac cpanceac@gmail.com
2011/1/25 Adam Williamson awilliam@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.
2011/1/26 Kyle McMartin 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?
On 01/26/2011 05:22 PM, cornel panceac wrote:
2011/1/26 Kyle McMartin <kyle@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
2011/1/26 "Jóhann B. Guðmundsson" johannbg@gmail.com
On 01/26/2011 05:22 PM, cornel panceac wrote:
2011/1/26 Kyle McMartin 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.
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!
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 =)
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@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
On Wed, Jan 26, 2011 at 08:26:36 +0000, ""Jóhann B. Guðmundsson"" johannbg@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.
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@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
On Wed, Jan 26, 2011 at 13:49:41 +0000, ""Jóhann B. Guðmundsson"" johannbg@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.
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
On Wed, Jan 26, 2011 at 13:49:41 +0000, ""Jóhann B. Guðmundsson"" johannbg@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.
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@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
On Wed, 26 Jan 2011 15:14:40 +0000 "Jóhann B. Guðmundsson" johannbg@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@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
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@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@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
On Wed, Jan 26, 2011 at 17:42:17 +0000, ""Jóhann B. Guðmundsson"" johannbg@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.
2011/1/26 Bruno Wolff III bruno@wolff.to:
On Wed, Jan 26, 2011 at 08:26:36 +0000, ""Jóhann B. Guðmundsson"" johannbg@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....
On Wed, Jan 26, 2011 at 15:56:48 +0000, mike cloaked mike.cloaked@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.
-
Adam Williamson -
Bruno Wolff III -
cornel panceac -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Kyle McMartin -
mike cloaked