F17 with UEFI - Status?

[GoinEasy9]

Hi all

Right now I'm about to put a new machine together with an ASUS Sabertooth 990FX motherboard that comes with the new UEFI Bios. To compound the headache I'm going to also add a OCZ Vertex 3 SSD as the boot drive.

Now I've read back in the forums a few months and have seen the problems folks have had installing Fedora on such a system, and, I'm wondering, has Anaconda matured enough to handle the installation on its own, or, am I going to have to use work arounds like the one here in "docs" for the UEFI install?

https://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Making_Minimal_Boot_Media.html#Making_Minimal_Boot _Media-UEFI

I'm also curious about the SSD drive. One of the "siduction" devs wrote a nice how-to re: setting up the SSD for use with Linux here: http://wiki.siduction.de/index.php?title=Solid_State_Disks_%28SSDs%29_unter _Linux_optimal_nutzen (yes, I know it's in German, but, Google translate does a good job). I know this may be a pipe dream, but, has Anaconda improved enough to recognize the SSD and set it up correctly?

I'm ready to experiment with this setup, but, I was just wondering how much work it was going to be. Searching for SSD in the F17 forum came up with nothing, and, using posts from F16 won't tell me if anyone has had experience using the newest version of Anaconda with this hardware.

Thanks in advance for any advice and/or links that you can help me with. I actually can't wait to start experimenting, it's been a few years since I built my last machine.

[srs5694]

Hi all

Right now I'm about to put a new machine together with an ASUS Sabertooth 990FX motherboard that comes with the new UEFI Bios. To compound the headache I'm going to also add a OCZ Vertex 3 SSD as the boot drive.

Now I've read back in the forums a few months and have seen the problems folks have had installing Fedora on such a system, and, I'm wondering, has Anaconda matured enough to handle the installation on its own, or, am I going to have to use work arounds like the one here in "docs" for the UEFI install?

https://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Making_Minimal_Boot_Media.html#Making_Minimal_Boot _Media-UEFI


The page you referred to seems to be geared toward making a specialized minimal boot image. I can't speak to the necessity of using a different procedure for BIOS vs. EFI systems on that point, but I can say that even Fedora 16 works pretty well for EFI-mode installs, in my experience. The installation process works pretty much like it does on BIOS-based computers, and it installs a heavily modified GRUB Legacy, which works better than the GRUB 2 that Ubuntu uses.

I do advise creating your partitions manually, though. By default, Fedora 16 creates a ridiculously large EFI System Partition (ESP) if installed on a blank disk. A typical size for the ESP is in the 100-500 MiB range. I recommend erring on the high side of that range if you're in doubt. Whatever its size, the ESP should use the FAT32 filesystem. (The spec clearly states it should be FAT32, and Windows flakes out if you try to install Windows to a computer with a FAT16 ESP.)

Also, I recommend using a separate /boot partition for Linux. (Make it ext2fs, ext3fs, or ReiserFS.) Fedora does this by default, although I don't recall what filesystem it uses; but if you were thinking of doing it differently, I recommend re-thinking that. The reason is that there are several different Linux boot loaders and EFI boot managers, and with some of them, having a separate Linux /boot partition can give you extra options for configuration, and some of these options can provide real benefits. Most notably, the combination of the Linux kernel's EFI stub loader, the rEFInd boot manager, and the ext2fs or ReiserFS driver from the rEFIt boot manager can make it possible to drop a new kernel and initial RAM disk in /boot and have the boot manager detect it and give you an option to launch it without touching any configuration file. Of course, if you use the standard Fedora kernels and GRUB Legacy, the system should modify GRUB's configuration files automatically when you install the kernel, so this won't be any simpler. OTOH, if you have problems with GRUB Legacy or if you compile your own kernels, giving rEFInd (or ELILO, for that matter) the ability to read files from /boot can help simplify things.

[STEVE555]

Hi there GoingEasy9,
I too have a Asus Sabretooth Motherboard. I'm currnetly running a dual-boot of fedora 17 with Windows 7 Ultimate. I've had no real issues installing both OS's. The only gripe I had when I came to partition my hardrive manually. I have a a Seagate 1Tb hardrive. The problem I was having was that I could only partition the drive in half!:confused: I couldn't select the ammount of space I wanted Fedora to use. It's not a problem to me as such,but it would've been good to have the option if I wanted it. I'm not sure if it was Annoconda,or the drive itself which would only let me partition the drive in half.

Regards,
STEVE555

[srs5694]

Hi there GoingEasy9,
I too have a Asus Sabretooth Motherboard. I'm currnetly running a dual-boot of fedora 17 with Windows 7 Ultimate. I've had no real issues installing both OS's. The only gripe I had when I came to partition my hardrive manually. I have a a Seagate 1Tb hardrive. The problem I was having was that I could only partition the drive in half!:confused: I couldn't select the ammount of space I wanted Fedora to use. It's not a problem to me as such,but it would've been good to have the option if I wanted it. I'm not sure if it was Annoconda,or the drive itself which would only let me partition the drive in half.

It's not 100% clear to me what you mean by this. It sounds like you're saying that you could only create partitions totalling half your disk's total capacity. If so, that sounds like a bug in Anaconda's partitioner, although there's a chance it's because of MBR issues, if you used MBR partitioning. (That would imply you're not using UEFI mode, though, which is something that the GoinEasy9 definitely does want to use.)

There's no way that the drive itself could impose such a limit. Partitioning is just data stored on the drive, and for a drive to limit how your partitions are laid out would imply that it was interacting with the partitioning software in ways that just aren't possible, given the way such software is written.

If you need more help resolving this problem, I suggest you post the output of "parted -l", typed as root at a shell prompt. It's a bit unlikely that this has anything to do with GoinEasy9's query, though, so you should probably start a new thread if you want to pursue this.

[STEVE555]

Hi there srs5694,
I'm sorry for the confusion caused. As I said earlier I don't have a problem with the way my hardrive is partitioned at the moment. However when That might change around May when Fedora 17 is offcially released and I might want to change the size of my partitions then.

I'll give you the output of "parted -l" anyway for future reference:

Model: ATA ST31000524AS (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 106MB 105MB primary ntfs boot
2 106MB 517GB 516GB primary ntfs
3 517GB 1000GB 484GB primary ext4


Model: WD 5000AAD External (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 32.3kB 500GB 500GB primary ntfs

Regards,
STEVE555

[srs5694]

Hi there srs5694,
I'm sorry for the confusion caused. As I said earlier I don't have a problem with the way my hardrive is partitioned at the moment. However when That might change around May when Fedora 17 is offcially released and I might want to change the size of my partitions then.

I'll give you the output of "parted -l" anyway for future reference:


Parted says you're using "msdos" (aka MBR) partition tables, which means that if Windows is booting on this computer, you're not using EFI mode. Thus, whatever experience you've had with it isn't relevant to a question about how this board works in EFI mode.

What's more, it seems that your disks are completely partitioned; there are no gaps. About half of your first disk is devoted to Windows, though. Re-reading your original post, I suspect you meant that Anaconda would only let you shrink your NTFS partition to half its original size. This could be because of a file that was marked as unmovable at about the mid-point in the partition. Such problems can often be overcome by defragging the disk (perhaps two or three times).

[GoinEasy9]

Hey, thanks for the responses. It's been a long day, but anyway. At least one of my questions have been answered. I know Fedora 17 will boot up on a Sabertooth, whether in UFI mode or not. STEVE555 , my setup that's coming is very similar to yours, but Windows probably decided what mode to install. My install will be all Fedora, so I can make sure UEFI mode is used.

@srs5694 You answered the most important question for me, and that was comfirming that Anaconda has the ability to set up UEFI mode during the install.. Also, that's for the manual partitioning advice, I'll probably refer back to it when I get started. BTW - I've always had a separate /boot partition since starting with F11. I've done quite a few installs. I was really just concerned that this install was going to be more complicated. The link I gave was all I could find about UEFI on docs.fedoraproject.org. Looking at that how-to, and never having used an UEFI machine before, I was confused.

Now, if I could only find out if Anaconda will be able to set up the SSD correctly, I'll be all set. If it doesn"t, I know that I can just follow the instructions in that German link. I know it has worked successfullly for others I know.

Thanks again

[srs5694]

@srs5694 You answered the most important question for me, and that was comfirming that Anaconda has the ability to set up UEFI mode during the install.. Also, that's for the manual partitioning advice, I'll probably refer back to it when I get started. BTW - I've always had a separate /boot partition since starting with F11. I've done quite a few installs. I was really just concerned that this install was going to be more complicated. The link I gave was all I could find about UEFI on docs.fedoraproject.org. Looking at that how-to, and never having used an UEFI machine before, I was confused.

I've written quite a bit about EFI on my Web site and elsewhere. I don't want to overwhelm you, so I'll point you to just a couple of things:


This page (http://www.rodsbooks.com/refind/bootmode.html) will tell you how to determine whether you're booted in EFI mode vs. BIOS mode. You can use this to confirm that Fedora is booted the way you want. (If not, it's easy to switch Linux's boot mode after installing.)
My EFI boot loaders (http://www.rodsbooks.com/efi-bootloaders/) page describes all the major options for EFI boot loaders and boot managers for Linux. Fedora uses GRUB Legacy by default, but if you have problems with it, you can use another boot loader.

[GoinEasy9]

Thanks again srs5694,

All of the links you've given me will be very helpful. Thanks for the last 2 links, especially the way to confirm. The more information I have, the easier it will be. Got everything bookmarked.

Just in case someone wants another reference, but based in Debian, I found this one passing by on Google+:
http://tanguy.ortolo.eu/blog/article51/debian-efi

[powerhouse]

I found your thread searching for Fedora 17 and UEFI. I have a somewhat similar setup:

ASUS Sabertooth X79 MB with latest firmware, running a i7 3930K processor
Sandisk Extreme 120GB SSD for OS(es) etc.
WD 2000 green edition SATA III for data
32 GB RAM
PNY Quadro 600 Nvidia graphics card

I've been trying to install Fedora 16 (and 17) - so far in vain. Some of the issues were my fault, but now I think I've practiced it often enough to do most of the steps while sleeping.

Here the two different approaches I've used:

1. MB BIOS in "BIOS Legacy" mode (i.e. not UEFI)
2. Booting the live CD produces some errors at the beginning but eventually gets me to a graphic desktop.
3. I then install using the "clean disk" mode with following manual adjustments:
- /boot at /dev/sda1 with ext3 (or ext4 - I tried both) - 1GB
- The rest of the disk is formatted as LVM:
- /dev/mapper/ssd-root as / ext4 15GB
- /dev/mapper/ssd-home as /home ext4 20GB
- /dev/mapper/ssd-win7 (not mounted) as ext4 (plan to use a Xen domU for Win7) 60GB
- The rest is unassigned
- /dev/mapper/vol2 (the entire WD drive is a LVM formatted disk) swap 8GB - I put the swap on the WD HD to reduce SSD access since I doubt I will be using much swap with 32 Gig RAM - this is to make Fedora happy (should it be unhappy without swap)

4. The installation carries on installing the system. When finally rebooting it starts grub (or grub2 ???) and then gets stuck once it tries to load the initramfs (blinking keyboard LEDs and everything freezes).

My second approach was this:

1. Switch the MB BIOS setting to UEFI
2. Burn a DVD-ISO on DVD (I booted a Linux Mint 12 LMDE USB Live stick to burn the DVD - the LMDE12 works without a hick, by the way)
3. Boot the PC using the UEFI DVD-drive option in the BIOS boot menu, booting the install DVD
4. The DVD starts without a hick and no serious errors and brings me to the install screen!!!
5. Again I choose to use the entire SSD and let Fedora assign the partitions, but with manual partition adjustments selected.
6. I use the same theme as above, with the following differences:
- Reduce the /boot/efi partition that Fedora automatically creates with nearly 5GB size to a more reasonable 500 MB (it's flagged as "boot")
- Adjust the /boot partition to be formatted ext3 with size 500 MB (I also tried 1GB)
- The rest is like above
7. Reboot in UEFI mode and the Fedora grub screen appears. When the bootloader is supposed to kick in the PC reboots :-(

I haven't managed to to boot Fedora 16 (nor 17) successfully from disk (SSD).

I apologize for posting it here in this thread but I thought it might be relevant. If anyone has any suggestions on how to make it work, I'll be happy to hear.

P.S.: I hope your install goes smooth.

[srs5694]

Powerhouse, I have a couple of comments.

First, in diagnosing your BIOS-mode problems, it might be important to know what those error messages are that you encountered when first booting the installer. Although the installer didn't hang, those error messages might be related to the hang you eventually found, so addressing them might be important.

Second, for your UEFI-based installation, I recommend trying another boot loader. In my experience, the kernel's built-in EFI stub loader is the most reliable, but it's only available in 3.3.0 and later kernels, and to make it practical, you'll need either a flexible firmware boot manager or an add-on boot manager like my rEFInd. (http://www.rodsbooks.com/refind/) You might also try ELILO, (http://elilo.sourceforge.net/cgi-bin/blosxom) which tends to be a bit more reliable than GRUB Legacy on some systems, although it doesn't work at all on a few. See my page on EFI boot loaders (http://www.rodsbooks.com/efi-bootloaders/) for more information on EFI boot loader choices.

[GoinEasy9]

Thanks powerhouse and srs5694, more feedback. I also think that using the kernel's efi stub loader is the way to go. Right now I'm still reading through the links srs5694 has provided and I'm trying to make a plan of action.

I have all the parts for the new machine and willl probably start building it tonight. I wish I knew if F17 has improved its installation of UEFI, or if it is still using legacy grub. I guess the only way to tell will be to experiment once the machine is built. I'm hoping that I don't have to use a FAT32 partition, I would rather Grub2 took care of the ESP so it can reside in /boot.

BTW - Forgive me if it seems that I'm lost, or reading things incorrectly. I've got a long way to go till I understand all of this.

[srs5694]

I have all the parts for the new machine and willl probably start building it tonight. I wish I knew if F17 has improved its installation of UEFI, or if it is still using legacy grub. I guess the only way to tell will be to experiment once the machine is built. I'm hoping that I don't have to use a FAT32 partition, I would rather Grub2 took care of the ESP so it can reside in /boot.

The ESP must be FAT32; its purpose is to provide storage space for boot loaders and related files for the firmware to read. Since most EFI implementations understand FAT but not other filesystems, FAT is the only choice for the ESP. The EFI spec requires that the ESP be FAT32, as well, not some other variety of FAT; however, in practice most systems work fine with any FAT variety. (There are exceptions, but they're rare. The Windows 7 installer tends to flake out if you use FAT16 on the ESP, so if you plan to dual-boot, you should be very careful about this.)

Under Linux, it's become traditional to mount the ESP at /boot/efi; however, that's not absolutely required. One unusual variant that has certain advantages is to mount the ESP at /boot. Since the Linux /boot partition and the ESP have similar functions, this placement eliminates redundancy. It also means that the EFI will be able to read your kernels with EFI stub loader support, which can simplify their use when RPM installs them to /boot. On the down side, you'll be using the ESP in a somewhat non-standard way (placing kernels in its root, perhaps creating a "grub" partition in the ESP, etc.). Furthermore, if you rely on features like symbolic links in /boot, this approach won't work -- or at least, it'll break whatever relies on symbolic links. FWIW, I've only tried this approach on one or two test installations under VirtualBox. It's worked so far, but I haven't been using those installations very heavily, so there could be problems lurking that I've not discovered.

FWIW, in my experience GRUB 2 is the least reliable of the available EFI boot loaders. Thus, I wouldn't advise installing it in Fedora 17 unless they've switched to using it by default, and then only because it would be the default.

One more comment, to powerhouse: Since GoinEasy9 is still working on resolving the original problem, it's probably best if you create your own thread if you need more help with yours. Trying to resolve two problems intermingled in one thread ends up being confusing.

[GoinEasy9]

@srs5694 Thanks again, now I'm getting closer, at least I think I am, and, I'm resigned to having a FAT32 partition. I have a question about FAT32 vs. efi-FAT32 vs. uefi-FAT32, the last two I haven't heard of until a few minutes ago. Do you have knowledge of the differences?

Also, I'd like you opinion of this article, (Link: http://tanguy.ortolo.eu/blog/article51/debian-efi ) actually Part 2.1 of the article where they create a BIOS boot partition first then create an ESP, then install using grub as BIOS, then in Part 3, they switch to Grub UEFI. I work with the siduction distro, so, my experiments will be installing, not just Fedora, but, also siduction, which is Debian Sid. I'm trying to establish a step by step how to that I can share with others who will eventually have this hardware.

I guess what I'm concerned about most at this point is that, during a kernel upgrade, I'm not having to reconfigure the bootloader or move files into the ESP in order to boot into the new kernel. Your post talks about eliminating redundancy by placing kernels in the ESP's root, but seems to come with a cost as grub would now be in a FAT32 partition (Am I reading that right?). I'm trying to get the benefits of UEFI without having to give up the advantages of the Linux bootloader.

BTW - Thanks for all your help and links so far. I don't think I could have got to this point without it.

[srs5694]

The EFI spec (and the UEFI spec after it) says that it uses FAT, but it hedges a bit -- it uses FAT as the EFI spec identifies it. I think the idea is that they don't want to be held hostage to any changes in FAT that might emerge down the road, like the change in the mid-1990s from 8.3 filenames to VFAT long filenames. If there are any important technical differences between FAT as the EFI spec defines it and FAT as created and used by Linux's mkdosfs and the Linux kernel, I don't know what they are. Chances are you'll be fine just ignoring this issue. I can't say you'll definitely be OK, though, since I've run into some flakiness myself, particularly with my Gigabyte GA-78LMT-S2P, (http://www.rodsbooks.com/gb-hybrid-efi/index.html) which has the worst EFI implementation I've seen. (Not that I've seen all that many, but it's hard to imagine a worse implementation, short of something that literally causes the computer to explode.)

Concerning the link to the article about Debian, the last I checked Debian didn't include EFI support in its x86 or x86-64 installers, so to use Debian on an EFI-based system, you have to install in BIOS mode and then switch to EFI mode. (Actually, it's possible to jump through some hoops to get it to install in EFI mode, but that's more work that ends up creating problems because of bugs in the installer.) Fortunately, this switching of boot modes can be done in Linux fairly painlessly; but some EFI implementations make it hard to switch boot modes, so it can sometimes be difficult to do the switching.

There are several ways to minimize the effort involved in kernel upgrades. Which method works best depends on your preferences and what software works best on your computer:


Rely on the distribution's boot loader configuration scripts. This is fine if the distribution's choice of boot loader works well with your hardware. You could run into complications in a multi-boot setup if you need to have one distribution detect another's updated kernels. OTOH, if each distribution has its own boot loader, and they chainload to each other or if you use you firmware's boot loader, rEFIt, or rEFInd to switch between them, then each will be responsible only for its own setup. Most distributions' default EFI boot loaders and associated kernel setup scripts either have their own filesystem drivers or automatically place the kernels on the ESP, so there's little or no extra work if everything functions properly.
Mount the ESP at /boot. This places your kernels on the ESP, making them accessible to ELILO or for use as kernels with EFI stub loader support compiled in. This should work particularly well with rEFInd, which has an option to detect kernels even if they don't have the usual .efi filename extension. (It's "scan_all_linux_kernels".)
Use a separate /boot partition that uses ext2fs, ext3fs, or ReiserFS. There are EFI filesystem drivers for these filesystems (ext3fs works with the ext2fs driver), so by using these drivers, you can give the EFI access to your Linux kernels. This may be desirable if you use ELILO or the kernel's EFI stub loader. It's not necessary if you use GRUB Legacy or GRUB 2, since they both include their own Linux filesystem drivers.
Use ext2fs, ext3fs, or ReiserFS on your Linux root (/) filesystem, make /boot an ordinary directory on that partition, and do not use LVM or RAID. This is just like the preceding; you can give the EFI the ability to read the Linux kernel in this way. Obviously this is less desirable if you need a more modern filesystem on your Linux root, or if you want to use LVM or RAID, but it is an option.


Personally, I've been using the approach of a separate /boot partition using ext2fs or ReiserFS, the kernel's EFI stub loader, and rEFInd on most of my systems, and it works quite nicely. (Of course, I'm biased; I built up rEFInd's capabilities to make it do what I thought seemed sensible in gluing everything else together!) This approach means you don't have to compromise with FAT on /boot, and with the appropriate options, rEFInd can auto-detect new kernels you install from Fedora's package system or that you build and install in the traditional location. At the moment, the biggest problem is that few distributions have upgraded to 3.3.x-series kernels as of yet, so I've been using locally-compiled kernels with them. (This isn't a big deal for me, but it would be for some people.) In time, of course, this problem will go away. With any luck, EFI filesystem drivers for more Linux filesystems will also eventually appear.

[powerhouse]

Powerhouse, I have a couple of comments.

First, in diagnosing your BIOS-mode problems, it might be important to know what those error messages are that you encountered when first booting the installer. Although the installer didn't hang, those error messages might be related to the hang you eventually found, so addressing them might be important.

Second, for your UEFI-based installation, I recommend trying another boot loader. In my experience, the kernel's built-in EFI stub loader is the most reliable, but it's only available in 3.3.0 and later kernels, and to make it practical, you'll need either a flexible firmware boot manager or an add-on boot manager like my bootloader. You might also try ELILO, which tends to be a bit more reliable than GRUB Legacy on some systems, although it doesn't work at all on a few.

Hello srs5694: Thanks for your reply! I delved into some of your instructions on your site and found them very useful and a great place to learn more about UEFI and boot managers.

The boot messages likely relate to the problem later on, but I would have had to photograph them to repeat them here. Some were related to DMA problems.

To make a very long story short: I eventually managed to install Fedora 17 with UEFI boot and it loaded. Unfortunately it didn't give me the setup screen to continue the install, but instead asked me for username and password. Root didn't work, and since I hadn't installed a user yet, I couldn't log in. I fixed this problem by switching to the terminal screen and login as root, create a user and edit the sudoers file to grant privileges.

Once the user was installed I could login and use Fedora 17, BUT things didn't work the way they should. Some applications worked fine, others made troubles or didn't start at all.

It could well be that I missed some settings, or something was wrong with the user privileges. One thing I noticed was that I didn't have any repositories listed. By that time I was so discouraged that I gave up on Fedora - this is not for me. I also didn't feel comfortable with the desktop. The OS install is my first stage of a much longer and no less challenging goal (running Win 7 with VGA passthrough on Xen), so spending days on getting Fedora work is too much for me.

I switched (back) to Linux Mint Debian Edition (LMDE 12) and installed it in less than 2 hours, including a nearly complete Xen environment (dom0 works but needs some more configuration work) as well as LVM (though the / and /home are still on regular partitions).

Back to Fedora and UEFI: I considered installing your boot manager and may still do it on LMDE, but everything so far works practically out of the box with LMDE. It's hard to explain but LMDE live USB just boots and allows me to install on disk, without any ifs. The only challenge is to get it on LVM, which is not supported in the installer and may cause some headache later on. So without changing any BIOS settings (I left it on UEFI), it just works.

I came to the conclusion that Fedora 16 or 17 may be more bleeding edge, but I don't have much more blood left to give it another try. Unless I run into unresolvable problems further down the road, I will try to get it work with LMDE. My past experience with an older version of LM was very good, the only disadvantage I see now is LVM support in the installer.

Thanks again for your help and if I decide to give Fedora another try, I will be glad to come back here.

P.S.: I couldn't post the original reply as it was checked for links and keywords. Hope this time it works.

---------- Post added at 11:14 PM ---------- Previous post was at 10:35 PM ----------

Thanks powerhouse and srs5694, more feedback. I also think that using the kernel's efi stub loader is the way to go. Right now I'm still reading through the links srs5694 has provided and I'm trying to make a plan of action.

I have all the parts for the new machine and willl probably start building it tonight. I wish I knew if F17 has improved its installation of UEFI, or if it is still using legacy grub. I guess the only way to tell will be to experiment once the machine is built. I'm hoping that I don't have to use a FAT32 partition, I would rather Grub2 took care of the ESP so it can reside in /boot.

BTW - Forgive me if it seems that I'm lost, or reading things incorrectly. I've got a long way to go till I understand all of this.

Hello GoinEasy9: I just posted a lengthy reply to SRS... (Rod?) where I explained what happened with my trial to get Fedora 16 or 17 running. To make it short, I've been discouraged using Fedora - at least with my configuration.

The good news for you is, if you try Fedora, that I managed to install and run Fedora 17. But it wasn't easy at all. As mentioned in my previous post I also ran into problems after the install. To get started, you need to burn an installation DVD to get the UEFI kernels, which must be booted in UEFI mode of the motherboard (activate UEFI in the MB Bios AND select UEFI CD-ROM boot option - you'll see it when pressing F8 at boot time). There is also a minimal install USB option, but have to copy the UEFI img to the USB and then boot and get the rest from another device or the Internet - I also tried that but it didn't work.

When you select the UEFI DVD and the disk boots, you should get a screen with the Linux tuxes in a row at the top and the text boot messages output below, then it switches to a graphical installer.

At the disk setup, make sure you select LVM (if you want it) AND manual partitioning. The defaults for the disk sizes are totally screwed (5 Gig for the EFI boot sector) - you don't want that. You need to manually edit the partitions at the next step. See the Fedora 16 documentation for recommended partition sizes. Whatever you do, change the default of the /boot partition from ext4 to ext3 (it's mentioned in the Fedora 16 documentation, though it may have changed with Fedora 17). Your best bet may be to take srs.. (Rod) advice and get his boot manager.

Should you encounter the same problem I had with getting a login screen at your first disk boot, you can use CTRL-ALT-F2 or F3 (don't remember, just hit the keys) to get a terminal login screen, from where you can login as root and setup a user etc. Don't forget the permissions (search the Internet - they are set in the sudoers file which you need to chmod +w before you can edit it).

As I wrote before, I'm trying LMDE now as I've had a lot of obstacles getting Fedora work. The good thing about Fedora 17 is its out of the box support of LVM and some nice new applications (Gimp 2.8, for example).

I hope to read how it worked out for you. Perhaps you get it running with all the bells and whistles and a Win install with GPU support/passthrough.

P.S.: I strongly suggest writing an install guide for yourself to follow while you install. You will need to know a lot of details while installing, and one wrong selection / configuration can ruin the entire effort. I didn't and regret it.

Good luck!

[GoinEasy9]

Well, I finished building the box, but, I spent a whole lot of time diagnosing why it wouldn't POST. One of the DIMMs was bad. Oh well.
The next step is to start experimenting with installs. I'm also going to add rEFInd to the experiement. I read the page on it, and, even though I don't need to dual boot, I still would like to see what it does.
Unfortunately, I have a heavy work schedule for the next week, so, the testing will go a bit slow. I'll post back when I have some progress to report.

BTW - The Fedora 17 64 bit Live KDE CD was recognized as a UEFI medium, but it died while trying to boot. Errors flashed so quick across the screen that I couldn't catch them, but, I'll try again when I resume testing.

@powerhouse Thanks for the news about the DVD install. I only tried the Live CD, so, next time I'll at least look at what the DVD offers. I'm hoping that another TC release will fix some of the problems, I thought they were trying to build one today. I'm also glad you found an solution for yourself. I'm going to experiment with Kubuntu and LMDE myself. Although I don't want to give up on Fedora, eventually I'll make it work.

[fpmurphy]

I came to the conclusion that Fedora 16 or 17 may be more bleeding edge

Fedora is intended to be bleeding edge and experimental. Linux Mint is intended to be easy to install and use.

[powerhouse]

Fedora is intended to be bleeding edge and experimental. Linux Mint is intended to be easy to install and use.

Absolutely. I will try to install Fedora 17 as a guest domU and see how this works. But first I need to install Windows as guest and get my applications running.

---------- Post added at 09:55 PM ---------- Previous post was at 09:47 PM ----------

BTW - The Fedora 17 64 bit Live KDE CD was recognized as a UEFI medium, but it died while trying to boot. Errors flashed so quick across the screen that I couldn't catch them, but, I'll try again when I resume testing.

@powerhouse Thanks for the news about the DVD install. I only tried the Live CD, so, next time I'll at least look at what the DVD offers. I'm hoping that another TC release will fix some of the problems, I thought they were trying to build one today. I'm also glad you found an solution for yourself. I'm going to experiment with Kubuntu and LMDE myself. Although I don't want to give up on Fedora, eventually I'll make it work.

Hello GoinEasy9:

Strange, I could have sworn there was no UEFI life boot. If I remember correctly, the documentation says that the UEFI install must be carried out with the DVD install disk (not live disk) by booting the DVD as UEFI device.
I know the feeling of Fedora dying while trying to boot.

I look forward to read more about your install. Good luck!

[GoinEasy9]

@powerhouse I got Kubuntu to work out of the box. The reason the other iso's were dying was due to the new Nvidia GTX550Ti card. I replaced it with a GT9800 and now things aren't dying. I spotted an EDID error when the Kubuntu CD died and decided to experiment with another card. After replacing the card, everything set up and booted fine. When I have more time I'll retry the Fedora iso's. Just learned that the F17 RC4's were released, so, I may get lucky.

[powerhouse]

@powerhouse I got Kubuntu to work out of the box. The reason the other iso's were dying was due to the new Nvidia GTX550Ti card. I replaced it with a GT9800 and now things aren't dying. I spotted an EDID error when the Kubuntu CD died and decided to experiment with another card. After replacing the card, everything set up and booted fine. When I have more time I'll retry the Fedora iso's. Just learned that the F17 RC4's were released, so, I may get lucky.

Wow, I almost bought the Nvidia 550 Ti. Didn't know it had issues with the open source Nouveau driver. I now run the Nouveau driver but plan to install the Nvidia driver, which requires a patched kernel. LMDE provides a dedicated package for it, but I didn't find one for the Xen hyper visor kernel. While the nouveau driver works ok, it doesn't fully exploit the graphics card. My experience with the proprietary driver has been good until now, but I don't know how the combination with Xen will work.

In this respect AMD (Ati) could be a better choice as they provide open source drivers for many but not all chips. I hope I can get my PNY Quadro 600 to work with the proprietary driver and Xen, hopefully in the dom0. Else I may try an install it as domU, but I don't really have a need for a separate Linux VM.

I don't remember, but are you planing to install Windows as a VM?