I hit 'Alt' at startup, select the Fedora 17 installer (it's on a USB stick), and it boots the kernel. I see boot progress including Started udev Kernel Device Manager Failed to start Remount API VFS See 'systemctl status systemd-remount-api-vfs.service' for details. Started Media Directory ... Starting udev Wait for Complete Device Initialization... Starting Remount Root FS... It's been stuck there for a few minutes now; I don't think it's going to do anything more. (I'm not sure how I was supposed to point it at my local Fedora mirror, either. I used to be able to sort that out from within the installer, but now I think that's regressed and I have to add 'inst.repo=nfs:...' on the command line? How do I do that when booting via EFI?)
(In reply to comment #0) > I hit 'Alt' at startup, select the Fedora 17 installer (it's on a USB > stick), and it boots the kernel. To what menu you get by hitting 'Alt'? And how did you create the Fedora 17 USB stick? Did you use liveusb-creator?
(In reply to comment #1) > (In reply to comment #0) > > I hit 'Alt' at startup, select the Fedora 17 installer (it's on a USB > > stick), and it boots the kernel. > To what menu you get by hitting 'Alt'? No menu. That's how you get the MacBook firmware to let you choose the boot device. > And how did you create the Fedora 17 USB stick? Did you use liveusb-creator? It was one I had lying around; probably created with 'dd if=boot.iso of=/dev/sdc' I'll try 'macboot.img' and see if that helps.
macboot.img starts grub, but the kernel doesn't appear to boot. I don't see anything but the grub screen with the cursor in the top left-hand corner — so if it's working, it's got no graphics. The boot.iso did better than that.
macboot.img doesn't include a kernel. But holding down alt and using the Fedora option should still boot grub and you should be able to edit the kernel command line there - are you not seeing that?
Yeah, I can edit the command line, so that fixes my aside in parens in my original post. I'd forgotten that I had the option to edit options in grub. But edited or no, it still doesn't boot completely. See http://david.woodhou.se/P1000724.JPG http://david.woodhou.se/P1000725.JPG which are two different boots from boot.iso; the first on USB and the second on a CD. I know there are problems with Radeon, but since I *do* have video I was assuming that wasn't the problem here? I *have* Fedora installed on this system; installed some time ago and updated to Fedora 17. Perhaps it would be possible to reconfigure it to boot via EFI, but it seemed simpler just to reinstall...
For the boot that claimed to have started a shell on tty2, had it actually started a shell on tty2?
Not as far as I could tell. But maybe it got as far as the pictures above, then started using the *other* graphics card for some reason. Maybe if I toggled the display output, I'd see what it's currently doing. It *does* seem to be alive, and I'm able to do a VNC install while it sits at a screen like the P1000725.JPG above. Once it's installed and I can hopefully boot to text mode, I'll play with some of the outb commands listed at https://help.ubuntu.com/community/UEFIBooting#Selecting_the_graphic_card
Ok, this *is* a graphics problem. It's not hung, it's just that I'm seeing the output on the Radeon (also EFIFB) display, and the kernel is actually using the *Intel* device. I managed to complete the install with vnc, since this machine has a static IP address. If I switch outputs using a tool like the one at http://ubuntuforums.org/showpost.php?p=11279555&postcount=669 then it *ought* to work, but in fact I think I'd need to do that *before* loading i915.ko, which means rebuilding the initrd which is painful. So I hacked the kernel to add this at the end of x86_64_start_kernel(): + outb(1, 0x728); + outb(2, 0x710); + outb(2, 0x740); + outb(0, 0x750); Now, with i915.lvds_channel_mode=2 on the command line, the F17 3.5.0-2 kernel boots and works with the internal graphics. It even survives suspend/resume, probably because I'd also applied the patch at http://www.codon.org.uk/~mjg59/tmp/gmux_switcheroo.diff which will restore the output configuration at resume... although I *expected* that to give me a /sys/kerne/debug/vga_switcharoo and it doesn't. So I'm mostly functional now with an EFI boot. I can live without the Radeon until we sort out the BIOS handling for it. However, I don't have *external* display working. When I plug in the analogue VGA adapter, the screen flickers and then xrandr says: VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 connected 1024x768+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0* 800x600 60.3 56.2 848x480 60.0 640x480 59.9 But I see no output on the display. If I plug in the external DVI adapter, the machine becomes unresponsive as something eats CPU time, xrandr says: HDMI1 disconnected (normal left inverted right x axis y axis) DP1 connected 1280x720+1920+0 (normal left inverted right x axis y axis) 697mm x 392mm 1280x720 50.0*+ 60.0 1920x1080 60.0 50.0 50.0 30.0 25.0 1680x1050 59.9 1680x945 60.0 1400x1050 59.9 1600x900 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1366x768 60.0 1360x768 60.0 1280x800 59.9 1280x768 60.0 1024x768 60.0 1024x576 60.0 800x600 60.3 56.2 720x576 50.0 848x480 60.0 720x480 59.9 640x480 59.9 59.9 and dmesg shows a lot of [ 1076.439623] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
Oh, backlight doesn't work from GNOME either. It's using an acpi_video0 backlight, which doesn't work, although there is also the gmux_backlight which does when I poke at it manually in /sys/class/backlight.
Right, this is the kernel misidentifying the correct active video device in vgaarb. There's code in efifb to handle this, but it fails because the firmware reports lies to us. I just posted a patch to LKML ("x86, EFI: Calculate the EFI framebuffer size instead of trusting the firmware") but it depends on using the UEFI boot stub. Can you grab git master, apply the patches I posted to LKML and then use that? grub supports chaining a UEFI executable but doesn't support passing any command line options, so you'll either need to build everything in (including the command line) or use grub2. Bear in mind that the kernel and initrd will then need to be on a partition that the firmware can read, but linux-3.5.0+.efi initrd=blah root=/dev/blah should then work correctly.
I now have graphics output, and even vga_switcheroo is almost working. Thanks. Full status for the record at: https://lkml.org/lkml/2012/7/28/81 https://lkml.org/lkml/2012/7/28/83