Bug 833585 - Cannot boot with Fedora 17 kernel
Summary: Cannot boot with Fedora 17 kernel
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: first=3.4.0-1 tested=3.4.2-1
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-19 20:09 UTC by David Woodhouse
Modified: 2013-01-10 08:30 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-10-08 15:18:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot (3.38 MB, image/jpeg)
2012-06-19 20:09 UTC, David Woodhouse
no flags Details

Description David Woodhouse 2012-06-19 20:09:13 UTC
Created attachment 593062 [details]
screenshot

MacBookPro 8,3, booting via legacy BIOS since I've never managed to get working video when booting for VAI.

The 3.3.7-1 kernel which was installed before I upgraded from F16 is still booting OK, thankfully. Although they end up panicking on reboot due to initrd weirdness AFAICT, but I can cope with that.

The new kernels just seem to stop half-way through the graphical boot. I tried booting without 'rhgb quiet' on the command line... which was hard because grub is broken and the editing of long lines on a large (1920x1200) screen seems to end up putting the cursor in odd locations and then crashing grub. But I did it by editing the grub2 config file from the working kernel.

Next attempt, the F17 kernel appeared to stop at
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver

So I added 'blacklist=radeon nomodeset' to the command line too, and then it got a bit further. First it takes about a minute to find the file system:


[   10.029123] scsi 2:0:0:0: Direct-Access     Generic  STORAGE DEVICE   9833 PQ: 0 ANSI: 0
[   10.112069] sd 2:0:0:0: Attached scsi generic sg2 type 0
[   10.113399] sd 2:0:0:0: [sdb] Attached SCSI removable disk
[   75.118319] device fsid beeee8f6-c7df-4ff8-8ec1-d4e195919603 devid 1 transid 760952 /dev/sda4
[   80.848298] dracut: Checking btrfs: /dev/disk/by-uuid/beeee8f6-c7df-4ff8-8ec1-d4e195919603

(These messages appear at 7, 7, 7, 12 and 17 second respectively in 3.3.7-1.fc16)

... and then, after spending another 100 seconds doing $DEITY knows what, it finally seems to start running userspace stuff. And ends (or at least I waited for too many minutes and was bored by now, so killed it) with

Starting Recreate Volatile Files and Directories...

Final screenshot attached at the point I killed it.

Comment 1 David Woodhouse 2012-06-19 20:11:15 UTC
This seems to be the same with both 3.4.0-1.fc17 and 3.4.2-4.fc17 kernels.

I also tried booting from EFI but that was differently broken. ISTR I didn't get any video at all in that case.

Comment 2 Josh Boyer 2012-06-19 20:20:25 UTC
Which kernel was the original report against?  The kernel that came with F17 GA (3.3.4-5.fc17)?

Comment 3 David Woodhouse 2012-06-19 20:38:48 UTC
I never got 3.3.4-5.fc17; my f16 installation already had 3.3.7-1.fc16 so that would have been a downgrade. The original report was against both kernels mentioned in comment 1.

Comment 4 Justin M. Forbes 2012-09-12 14:57:49 UTC
Is this working for you now with 3.5.3?

Comment 5 Josh Boyer 2012-10-08 15:18:26 UTC
David has since moved on to 3.6 and judging by the commit he made over the weekend it's working at least in part.


Note You need to log in before you can comment on or make changes to this bug.