Hi all
I'm putting together a new system. The new motherboard is an ASUS Sabertooth 990FX which comes with a UEFI BIOS.
I'm also adding an OCZ Vertex 3 SSD to the setup.
Now, I have devil's very detailed blog post about how to set up the SSD for optimal performance, so I don't think I'm going to have any problems there. Here's the link to devils blog post if your interested:
http://siduction.org/index.php?module=news&func=display&sid=78&lang=en
My only concern is with the UEFI setup. It seems that installing using UEFI is problematic. At least it is when using Fedora. Since the new box isn't built yet (all the pieces are here, I'm just waiting for the time) so I haven't been able to experiment with either Fedora or siduction yet, I'm hoping to get some feedback here.
Using Debian/siduction installers, has anyone done a UEFI boot installation, and, was it accomplished out of the box, or, am I going to need some tricks and tips in order to do it successfully?
Any advice or links would be appreciated.
Thanks
Tom
It looks like there might be some useful information here (https://help.ubuntu.com/community/UEFIBooting).
Like most folks who like to build their own systems, I am dreading UEFI, so I hope you will share your experience here.
Thanks dibl, and, yes, I will be sharing what I'm doing, since, every link, including the one from Ubuntu, is more general than specific.
I've read that Fedora uses a modified legacy grub to install UEFI, which, I'm hesitant to use. Damn, I just got used to Grub2. Then again, that was in Fedora 16, so, I don't know if Anaconda has progressed to a different method with F17. Since documentation is at a minimum till F17's release, I can only experiment when the hardware is set up.
The newer kernels have a EFI stub loader built in (at least that's what I've read), and to me, that would be the method I would like to use, so, I'm going through every blog post I can find to see if I can figure out the correct way to partition the SSD so the EFI System Partition and the /boot partition are created correctly. At this pont, from what I can see, in order to use the kernel's EFI stub loader I'm going to have to create an ESP partition (possibly FAT32) and a separate /boot partition, although I'm confused as to why I would need a FAT32 partition unless that was the BIOS manufacturers choice.
At this point my head is spinning from all the different explanations, so I may just start building the machine and come back to this later. I'm still hoping there is an answer for this in Grub2, since, the capabilities are built in, unfortunately, not well documented.
The Ubuntu link you gave me, actually gave me hope that grub2 is an option, even though other posts say it isn't as reliable as other methods.
Do I sound confused? Heh, YUP. I'm still hoping to make this work with siduction, so I can leave my 32 Fedora installs alone.
Edit: BTW - This is the closest I can get to detailed instructions: http://www.rodsbooks.com/efi-bootloaders/installation.html
the computer-magazine ct from germans heise-Verlag tested UEFI last week and the result was, that the most promising bootmanager for UEFI is actually grub2. Lilo an grub-lagacy wern't able to boot from it.
Unfortuantly the article is not online:
http://www.heise.de/ct/inhalt/2012/11/174/
I would try with newest LTS Ubuntu at first: Canonical has one of the most active grub2 upstream fixing guy (who is also Debian maintainer). Other distros can be installed later and without grub, only one is needed. You can then install Debian sid from ubuntu using debootstrap.
efi-Fat32 is in the standards specification as a starting partition. It is not the same as the fat32 specification, uefi-fat32 can be different, there was a bug about that distro maintainers were thinking wrong.
Here is instructions specificaly for debian: http://tanguy.ortolo.eu/blog/article51/debian-efi
greetz
devil
@devil, that blog is more like a wild guess, it has very unstructured hints, at least i dont understand ...
@devil Thanks, I did come across that link before, actually, I think it passed by in my Google+ stream. The one good thing about that link is that it shows how to convert an existing MBR to UEFI.
Part 3 in that link is the one I'm interested in though. It uses grubx64.efi to install UEFI using grub2. If you're interested this link goes into the grub2 scenario: http://www.rodsbooks.com/efi-bootloaders/grub2.html
I also have a similar thread running in the fedoraforum. That's where I met the author of that last link. From what I can see Rod Smith knows a whole lot about UEFI, probably from trying to get it to boot on a MAC when it first appeared. I haven't read all of his stuff yet, it starts here: http://www.rodsbooks.com/efi-bootloaders/index.html for those that are following.
OK, got sidetracked, let's see where I am.
Well, with both devil's article (Part 2.1) and confirmation from Rod Smith, I guess having the FAT32 partition is a must. Actually, now that things are clearing up in my head, Part 2.1 seems to be the best method. Since I'm already playing with the set up of the SSD, using the partitioning in that portion of the article sounds like a plan. I do want to check out ralul's efi-FAT32 vs. FAT32 though.
Edit: I'm also being told that Grub2 is, at present, the least reliable of the boot loaders when using UEFI, so, even though I still like the Debian way from the Tanguy article, I'm still looking at different methods.
Here is a recent writeup on a SSD installation with UEFI: http://www.kubuntuforums.net/showthread.php?57778-How-I-(sort-of)-conquered-UEFI&p=290708&viewfull=1#post290708
@GoinEasy, efi-FAT32 is a FAT32 but more or less constraints from its standards. Because you asked, I just wanted to emphasize what you already looked up:
An efi-FAT32 at the begining of the disk is standard.
What I dont know yet:
Is this efi-FAT32 partition usable as an ordinary /boot partition hosting your kernels?
One question regarding your statements:
Grub2 really is less reliable using with efi? Because fedora people do have more experience using other boot managers, because they rejected grub2 in beta state?
@dibl Very interesting ending to that article. Could the Ubuntu/Kubuntu installer actually work using Grub? And with the SSD?
I'm starting to think I might leave the SSD out of the equation while testing and just experiment using the HD. Once I find a preferred method, then I'll use the SSD.
It's funny, but even Linus had an "I hate EFI" post on Google+ yesterday.
https://plus.google.com/102150693225130002912/posts/QLe3tSmtSM4
One of the links in that thread leads to Matthew Garrets experience trying to get Fedora working on a MAC. Actually I think Fedora's main focus with getting GPT and EFI working was due to getting it working on MACs. I find very little while searching that points to Fedora getting U/EFI working in order to take advantage of newer features, it seems all related to MACs.
@ralul The reliability of Grub2 with EFI comment didn't come from Fedora dev discussions but from Rod Smith, who seems to be quite the prolific author of Linux books ( http://www.rodsbooks.com/books/index.html ). His supplying of links to me has given me my basic understanding of U/EFI.
It's still a mystery to me why Fedora left grub legacy in their distro for so long, as they seem to be the first to throw every unfinished bit of new technology into a new release before it's ready. I liked the fact that they held off on Grub2 until it matured a bit, but, this is not their MO. As to why they decided to hack legacy grub in order to make it work with EFI? Well, I guess that's what Fedora was using when the "It won't work on MAC" complaints started rolling in.
Edit: Sorry I hit submit instead of preview.
I was about to say that my first attempt will probably be the Debian Way from the article devil linked to. Fedora 17 and the Anaconda installer aren't doing very well, even though it's due for release soon. The newest TC3 won't boot on 32 bit and there are complaints about how it won't install over older GPT partitions. That, and the fact that I believe they are still using the legacy grub hack for EFI, I may skip F17 all together.
Anyway, back to building the machine.
@GoinEasy9, Rod Smith tends to write over complicated, perhaps to emphasize his site the only point of clue? Perhaps he is also over critical towards Grub2, because Grub2 claims to be the future one and only boot system ...
If you have a new and empty system, why not be experimental? And have a look at Magaia!
Zitat von: "GoinEasy9"@dibl Very interesting ending to that article. Could the Ubuntu/Kubuntu installer actually work using Grub? And with the SSD?
Yep -- Steve Riley is very smart, and if he said he got it working, then it works. I like ralul's idea -- install the Ubuntu grub-efi, then install siduction. (Easy for me to say -- I don't have to make it work!)
I have built a UEFI capable system about 1 year ago, but decided against using UEFI then. I had planned to buy a 2nd SSD which was not in the budget back then. Now this SSD hits the market (OCZ Vertex 4, 64 GByte)and will be available sometime this month.
So then I will set up this box from scratch with 2 SSD and UEFI.
And a note on my SSD tutorial: some things are not needed anymore today. Gparted e.g. can do the alignment correct these days from what I read.
greetz
devil
Yes, fdisk and cfdisk and gdisk are now automatically starting partitioning at sector 2048, so no need to use the calculator.
If you have a main board with UEFI, then it looks to me like you could practice installing on a large USB key, right? Then once you figure out how to make the /boot/EFI installation correctly, you are ready to install on the SSD or hdd.
That should work on a USB 3.0 stick with 32 GB I own.
greetz
devil
Yes, I was thinking even 8 GB or 16 GB would work just for the experiment.
That link mentioned above:
http://www.kubuntuforums.net/showthread.php?57778-How-I-%28sort-of%29-conquered-UEFI&p=290708&viewfull=1#post290708
really is interesting. Beside it is not a manual, more like a journey of errors. But it tells
- Ubuntu is error free able to install grub-efi (*)
- if you learned your lesson efi-gpt is for the better
My question solved: That efi-FAT32 partition can be used as a fully functional /boot partition. Which by the way would solve potential issues using btrfs as /-root. But I would like to see a structured tutorial of this issue. A text the reader is able to differentiate output from input. Not just such a horror story of a personal journey ...
(*) PS: also should Debian sid, if not yet then hopefully soon. Colin Watson normally does merge upstream to Debian in a timely manner.
Well, the systems built. Although I had no POST and had to go through manual diagnosis, reseat all the connections, then find out that one of the DIMMs was bad. Par for the course I guess.
I'm going to have to make a UEFI bootable USB stick, because none of the Linux CD/DVD's are booting. The Fedora 17 Live 64bit KDE CD was actually recognized as UEFI bootable, but, died trying. Which I expected actually, the TC3 release has been a horror show. I always used 32 bit on my installs, so, I don't have a collection of 64 bit iso's handy. I'll have to download 64 bit versions of siduction, Kubuntu and Mageia (Thanks ralul, Mageia is a good idea.) I've also just read that LMDE 12 is able to boot in UEFI mode, so I'll give that a try also.
@devil I bought a USB 3.0 32gb stick also, originally to test usb 3.0 with this system, although I'll probably use one of the smaller sticks for the experiments. I really only need a 4gb stick modified to UEFI for installation.
Also, thanks for the new advice re: your SSD tutorial. I'm still going to leave the SSD out of the picture until I figure out, step by step, how to get the UEFI boot working.
@dibl Thanks for pointing to Kubuntu, I needed to know one distro was up to the task. That link you and ralul posted, those last 2 paragraphs say it all.
Thanks everyone for your advice, I'm sure with all the options I'll be able to come up with a solution. Anyway, enough for today. Seven days straight of work coming up, so, the testing will go slow the next week. I'll post when I have some progress to report.
I luckily have a MSI H67MA Mainboard that supports BIOS and U/EFI. So I had no initial problems.
greetz
devil
There is also a thread on the devel.list from Tanguy Ortolo (I linked his blog on EFI with debian on page 1)with some good general information from e.g. Steve Langasek and many others. Find it attached here (http://lists.debian.org/debian-devel/2012/01/msg00168.html).
greetz
devil
I just lost my post because it asked me to log in again, damn. No time to recreate it, work tomorrow.
Thanks devil for the link, it makes sense from what I've learned so far, and, Kubuntu worked, out of the box. I'll share the details when I get more time.
I think, https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface has good info.
also the UEFI part of https://wiki.archlinux.org/index.php/GRUB2 and https://wiki.archlinux.org/index.php/UEFI_Bootloaders.
I just got my 2nd. SSD and will do a reinstall of my workstation to have a 60 GB SSD for / and a 120 GB SSD (both Vertex 3) for /home.
I have been asking myself for 2 days if I should try EFI or not now. I am a bit reluctant as this is my workstation and I need it up and running by Monday morning sat the latest.
It does not help that my 16 GB USB 3 stick seems to have died yesterday. I was gonna test with that before going on the real iron.
So i am still undecided...
greetz
devil
I think, https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface has good info.
also the UEFI part of https://wiki.archlinux.org/index.php/GRUB2 and https://wiki.archlinux.org/index.php/UEFI_Bootloaders.
I just got my 2nd. SSD and will do a reinstall of my workstation to have a 60 GB SSD for / and a 120 GB SSD (both Vertex 3) for /home.
I have been asking myself for 2 days if I should try EFI or not now. I am a bit reluctant as this is my workstation and I need it up and running by Monday morning sat the latest.
It does not help that my 16 GB USB 3 stick seems to have died yesterday. I was gonna test with that before going on the real iron.
So i am still undecided...
greetz
devil
Let us know how you do -- I'm sure the next system board that I build on will be UEFI.
"I have been asking myself for 2 days if I should try EFI or not now. I am a bit reluctant as this is my workstation and I need it up and running by Monday "
:)
süß
that is exactly what keeps me going on using gpt-hybrid-mbr
:)
Hiya
Well as I said in the last post, Kubuntu worked out of the box. It created the 100Mb Fat32 ESP and used Grub2 as the bootloader. Unfortunately, it blew up when a new kernel came in. I reinstalled, but, typing sudo su bothered me, and, having the Nvidia drivers preinstalled didn't give me the opportunity to use nouveau, so I replaced it with fedora 17.
I used the same partitioning with Fedora, making sure all the partitions were formatted, and, after shutting off SELinux, was able to get it to install in UEFI mode. Seems SELinux couldn't write file contexts to the Fat partition during install, even though it works fine now fully enabled. Fedora still uses grub legacy and during formatting, changed the FAT32 partition that the ESP resides on to a FAT16 format. I didn't even notice till I started looking closer as it works fine and accepts new kernels without error.
One curiosity though. It seems even though I formatted the hard drive completely. The UEFI bios is still listing the Kubuntu install as one of the options for boot. I still haven't found where this info is kept, that is, where it can be retrieved after a hard disk format. So, I'm still searching through documentation etc., trying to figure out how everything works before I move to install it permanently onto the SSD.
efibootmgr shows Kubuntu, as it has files in /sys/firmware/efi/vars/, but, how it retained the info is alluding me at present. Is the bios/cmos holding the information? Still not knowledgeable enough on UEFI to come up with an answer. Even though I've been through Rod's how-to's a couple of times. The next stop will be the Intel UEFI specs.
I still haven't had the time to try the Debian conversion install. Install in MBR, then convert to EFI. I'd like to learn everything that is happening first before I start experimenting.
BTW - Fedora's not using kernel stub support (legacy grub), I'm assuming Kubuntu was, since it was using Grub2. I'd like to take a look and see what difference that makes, if it makes any difference at all (as to what is kept in the config files). F18 already has stub support working (I'd like to try that also), but I'll let that cook for a while. Seems Fedora/Red Hat are considering registering a key for UEFI Secure Boot, and, that has a whole lot of people raging. The mechanism for UEFI and Secure boot have my attention at the moment. One tends to learn a bit when the devs are arguing about it.
BTW2 - I found out I can boot the siduction CD on this motherboard, so, I guess it can do legacy bios. The one strange thing happened though. Just booting the Live CD and then exiting changed the time on the motherboard to German time. That was odd huh?
In january Matthew Garrett from Red Hat spoke in LinuxConf Australia an hour about UEFI problems:
http://www.youtube.com/watch?v=V2aq5M3Q76U
And howto manipulate the starter list, and that there are bugs by which you can make you system unbootable forever. And UEFI is a full OS - the kernel bigger than the linux kernel ....
heh, kano already needed to have his cmos chip reset after playing with efi.
I guess the kernel is bigger because it needs to be static (no initrd).
greetz
devil
I tend to do a traditional BIOS install on GPT and switch that over to efi afterwards. Some more reading today, then installing and converting tomorrow. The risk of not having my workstation on Monday is to high.
greetz
devil
:(
I hoped you would risk to be our "Frontschwein"
(this Agaida would name the hero)
Zitat von: "ralul":(
I hoped you would risk to be our "Frontschwein"
:shock:
The Frontschwein must go to the Schlachthaus! :lol:
Hi, I'm new here, and this is my first post :)
Now that UEFI is upon us and mostly taken over the market for consumer motherboards, I thought there should be much interest in how to deal with this awful situation. I've personally decided that if I'm building my own box, I should go with something that I'm sure is 100% Linux-friendly and not interested in being "Certified for Windows 8." In terms of motherboards and avoiding UEFI, it looks to me like the best solution is to buy a Tyan server motherboard. Doesn't actually have to be Tyan (I hear that Supermicro is also excellent, I'm just a little more familiar with Tyan).
Server motherboards vs standard desktop motherboards - in most respects they are the same, but a few differences. A server motherboard will usually have slots for two processors (most likely to use Intel Xeon processors), and also support ECC memory which is memory with error correction. There is of course support for RAID. Design is slim so that they can be put into a U1 chassis so they can fit on a server rack.
Server boards are designed to be fast and reliable. On the other hand, the onboard graphics are not tweaked to make gamers happy since manufacturers don't expect system administrators to be playing games on a server (most servers run headless anyway).
Cost for server boards is somewhat higher. They can be very expensive for the top-end boards, but it's overkill for desktop use. At the lower end, server boards can be had for around US$200. Here is one example:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813151243
I haven't actually bought a server motherboard yet, but it's on my shopping list for whenever my current computer starts wearing out. I'm currently running on an old ASUS motherboard and it's doing fine, but when it conks out my next purchase will likely be Tyan since ASUS is very anxious to keep in Microsoft's good graces by being "Windows ready."
cheers,
Paraquat
Welcome!
It is an interesting approach, and that looks like a nice motherboard. Two issues that I would note -- (1) I'm not finding Linux support for the onboard AST2150 video chip*, (2) for the same cost you should be able to find a motherboard with USB 3 capability.
I built my desktop system at the end of 2010 just ahead of the UEFI transition, so I haven't had to deal with it yet. But everything I can read indicates that the situation (http://www.linux-magazine.com/Online/News/UEFI-Boot-Fix) is not so bad, today -- all motherboards are supposed to allow you to disable secure boot. I have had good luck with 3 different Asus motherboards in the past few years, so I would not be afraid to buy one if I were building a new system.
*There is something called "open IPMI" that is said to have Linux kernel support. I have never heard of it -- maybe it is OK.
Since I started this thread almost 2 years ago, and since it deals with the same topic, I figured I would post in this thread instead of making a new topic.
After all this time, I found the solution for a simple way of installing siduction in UEFI mode, in the Manual. It's at the bottom of this Manual page link:
http://manual.siduction.org/hd-install-opts#usb-hd
The first time I tried it, it failed, but, after a short format of the 4Gb stick, it succeeded. It's possible some of the flags were not correct on the usb stick, so, the format got rid of all flags except the boot flag and it worked.
The instructions require extracting all the files from the siduction iso and moving them to the root of the usb stick. Then configuring/installing isolinux to boot the stick by executing:
syslinux -i -d /boot/isolinux /dev/sdXN (Where "i" is install and "d" is the directory, and, where "X" is your usb's mount, mine was /dev/sdc and "N" is the partition number, which, on a fresh stick, should be "1").
and then,
install-mbr /dev/sdX
Check it out:
siducer@siduction:~$ su
root@siduction:/home/siducer# efibootmgr -v
BootCurrent: 0007
Timeout: 3 seconds
BootOrder: 0001,0002,0005,0003,0004,0000,0007
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\shim.efi)
Boot0003* Fedora_17 HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\redhat\grub.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .
Boot0005* debian HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\debian\grubx64.efi)
Boot0007* UEFI: Patriot Memory PMAP ACPI(a0341d0,0)PCI(16,2)USB(2,0)HD(1,1f80,776080,00000000)
So, as soon as I make sure there is nothing of value left on the Fedora_17 partitions, I'll use them for siduction. I'm assuming that the installer won't give me the opportunity to mount /dev/sda1 as /boot/efi, so, after the install, I'll have to add an entry in fstab for /boot/efi.
/dev/sda1 /boot/efi vfat umask=0002,utf8=true 0 0 (or use the UUID)
Then, the rest should be fairly easy.
apt-get install grub-efi-amd
grub-install /dev/sdaX (Where "X" is the / partition number)
efibootmgr -c -L siduction_13.2 -d /dev/sda -p 1 -l '\EFI\siduction\grubx64.efi'
"-c" = create
"-L" = Label
"-d" = Disk containing ESP
"-p" = ESP partition
"-l" = bootloader
I don't think I need to chroot, grub-install is installing to the particular partition.
Since I'm probably not going to get to the install until tomorrow, comments would be appreciated. Am I missing something? Am I doing something the hard way, or doing something totally wrong? It would be nice to know before hand.
BTW - Whomever wrote this piece in manual, THANK YOU. I can't believe it took so long for me to find it. I wanted to post it in this thread so others can find it.
OK, until tomorrow. Thanks in advance for any hints. I'm so psyched to get siduction on my main machine.
Zitat von: GoinEasy9 in 2012/05/07, 19:56:29
...I'm just waiting for the time...
that's a nice one!
So, I really hate the fact that I have so little time to keep up with things, and, it looks like the devs have been really busy.
I played with the install a couple of times, then, finally realized I could define my own mountpoint, and did so for sda1 (The ESP) as /boot/efi.
Continuing with the install, all efi parts were placed in the right locations, and, a "siduction" choice was added into the UEFI menu.
So, UEFI install was a SUCCESS. All one needs to do is manually add the /boot/efi mountpoint during installation, and it works.
Thank You, you made my day.
root@siduction64kdefx:/home/goineasy9# efibootmgr -v
BootCurrent: 0007
Timeout: 3 seconds
BootOrder: 0007,0001,0002,0005,0003,0004,0000
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\shim.efi)
Boot0003* Fedora_17 HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\redhat\grub.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .
Boot0005* debian HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\debian\grubx64.efi)
Boot0007* siduction HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\siduction\grubx64.efi)
I'll have to clean up Boot0003, and remove /boot/efi/efi/redhat to clean up the ESP, since I used the Fedora_17 partitions. Minor stuff.