Bug 481455
Summary: | ppc32 can't boot with newer rawhide kernels | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kevin Fenzi <kevin> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | jarod, kernel-maint, quintela, tony |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | powerpc | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-12 22:12:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Kevin Fenzi
2009-01-25 03:30:21 UTC
So... kernel-2.6.29-0.69.rc3.fc11.ppc boots just fine on my powerbook, which has a fully updated F10 + the aforementioned rawhide kernel on it. Could be some bad interaction between the rawhide kernel and rawhide lvm though, guess I should go raw-er on my powerbook... Whoops, meant to add myself to the cc list... I've got a sacrificial G4 tower in the office I'll try to reproduce on, hopefully tomorrow... Strange. Just rebooted into 2.6.29-0.99.rc4.git1.fc11.ppc and it worked. All I can figure is that it was some unspecified rawhide breakage that got fixed. ;( Should we try and track it down more? or just be thankfull and move on? Either is fine with me. Turns out there was a ppc32-smp-specific bug biting me, in addition to some apparent video hardware related issues tripping up plymouth... But I finally have a rawhide kernel booting on my dual 800 G4 tower, after adding a patch jwb pointed me at: http://patchwork.ozlabs.org/patch/22887/ Going to tack that onto rawhide in a sec, but I suspect it'll get into linus' tree RSN. Never mind, its already in linus' tree, we'll just pick it up from the next git snap rebase. So yeah, lets just chalk this up to development kernel churn and close it for now... |