https://wiki.archlinux.org/index.php/Fo … Bumping.22
Just to say: most of what's said about Arch in this thread is no longer true; the problem with which the thread is concerned is (probably) not the real problem and what is (probably) the real problem is now covered in the wiki (although the solution described here also works).
Moreover, this thread was concerned with a fairly specific firmware which differs from the one in ArcherSeven's post so it is unclear either that the problem described in this thread would apply in ArcherSeven's case or that ArcherSeven's suggested solution would work in mine (even now that it is available).
Okay, I'll go with that.
Anyone who needs to, please start a new thread specific to your situation. If you feel it is relevant, link back to this thread.
Thanks.
Closing...
Just to say: most of what's said about Arch in this thread is no longer true; the problem with which the thread is concerned is (probably) not the real problem and what is (probably) the real problem is now covered in the wiki (although the solution described here also works).
Moreover, this thread was concerned with a fairly specific firmware which differs from the one in ArcherSeven's post so it is unclear either that the problem described in this thread would apply in ArcherSeven's case or that ArcherSeven's suggested solution would work in mine (even now that it is available).
]]> # echo "root=/dev/disk/by-label/zyanya-root ro rootfstype=ext4 add_efi_memmap init=/bin/systemd initrd=\\EFI\\arch\\initramfs-linux.img" | iconv -f ascii -t ucs2 | efibootmgr --create --gpt --disk /dev/sda --part 4 --label "Archlinux (EFISTUB systemd)" --loader "\\EFI\\arch\\vmlinuz-linux.efi" --append-binary-args -
and proceeded to boot my system. (Note, I had configured systemd before starting this. Make sure to modify the code above before you run it! Your disk label, partition number, etc are very likely to be different!)
Took me a good 3-4 hours to read all the documentation and figure out what I did wrong a couple times, but I can boot from full-off to login prompt in 12 seconds now.
]]>I ran across an interesting related thread on the Fedora Forums. Not sure if Arch suffers from the same issue.
As far as I know, Arch does not suffer from this issue. Arch's installation makes no attempt to work with GPT partitions. To get Arch installed with GPT, you have to do all the partitioning outside of the installer and then prevent the installer from undoing it or messing with your partioning in anyway. The tools available in the installer itself cannot work with GPT partitions without damaging them.
At least, that was my understanding of the situation. So I didn't do my partitioning from Arch's installer at all.
I've read elsewhere about the issue with Fedora's installer. Note that the "solution" Fedora's developers are considering is essentially already implemented by Arch's installer i.e. only use MS-DOS partition maps. Arch's installation has to be done while booted in BIOS mode if you use the live USB/CD installation method, at least, because it won't boot in UEFI mode that I know of. (Archboot is a different matter.)
None of the problems I experienced were due to Arch's installer. The installer is limited in certain ways - cannot deal with GPT partitions or UEFI booting - but the wiki makes those limitations clear and gives instructions for working around them. Those instructions failed in my case because my firmware refuses to recognise a UEFI partition formatted according to the specifications.
That's very different from the situation with Fedora's installer which is, as I understand it, dangerously buggy.
Ubuntu's installer is also buggy and probably more dangerous than Fedora's since it wipes any existing EFI partition. It also formats the EFI partition it creates as fat16 rather than fat32. That was useful for me but is contrary to the spec as far as I know. On the other hand, it does seem to create a correct GPT partition map although I did not test this.
]]>Does Lenovo have something similar to http://forum-en.msi.com/index.php?topic=153411.0 ?
Do you mean are they filtering in a similar way? I somehow doubt it. At least, I don't think they are filtering on "Windows", for example. The BIOS just seems unable to use a fat32 formatted EFI partition and needs FAT16. Or do you think it was filtering in this way for fat32 but somehow not for fat16? I have no idea how these things work or if that is at all likely. (Also, I would be kind of reluctant to experiment now I have got something booting - it really makes no odds to me if the EFI partition is fat16 so long as I know that's what it wants.)
I'm currently trying to tangle with ASUS UEFI as well and that seems to work completely differently...
I am curious about the Lenovo UEFI, though. Or the TIano - I'm not sure if this is Lenovo specific issue or not.
]]>The OP wrote in the opening post:
So, in few words, when you try to install F16, then Win 7, you get "corrupted" partition table which is msdos in nature but still contains GPT signature and it makes F16 unable to recognize msdos partitions. And you cannot overcome this problem other than remove GPT manually via live cd. It's not good.
http://forums.fedoraforum.org/showthread.php?t=273648
{post #9 by srs5694 is especially interesting and informative}
In reply to srs5694, AdamW, who works for Fedora wrote:
srs: that's actually the conclusion the anaconda devs are coming to, as well. they're certainly considering switching back to MS-DOS by default for <2TB disks on BIOS installs for F17 onwards.
Yes, I verified that I am using a MBR and do not have GPT. I verified in Windows 7: "Computer Management > Disk Management", as well as using the Windows: "DISKPART> list disk" command.
I checked my BIOS configuration menu. It is listed as a UEFI BIOS. It has the option to boot UEFI or Legacy. It is currently set to boot both, but prefer Legacy.
That makes sense. I had no problems with MBR/BIOS. But then I unfortunately read about MBR versus GPT and decided I might as well redo it since I had done nothing beyond a bare install of Arch. It all sounded easy enough at the time in theory!
]]>Interesting. Would I be right in guessing that your disk came with an MBR partition map rather than GPT? I only ask because I couldn't use BIOS to boot once I switched to GPT.
Bear with me, I'm just learning about all this.
Yes, I verified that I am using a MBR and do not have GPT. I verified in Windows 7: "Computer Management > Disk Management", as well as using the Windows: "DISKPART> list disk" command.
I checked my BIOS configuration menu. It is listed as a UEFI BIOS. It has the option to boot UEFI or Legacy. It is currently set to boot both, but prefer Legacy.
]]>cfr wrote:There's no "Launch EFI Shell from filesystem device" option in my UEFI BIOS setup or in the machine's boot/application menus.
That is specific to Asus SandyBridge+ Motherboards with AMI (American Megatrends) firmware.
My AMD E-series + AMI netbook also has this BIOS exact option. Like David Batson my machine shipped with a Win7-MBR disk. I remember the BIOS not doing anything upon trying to use that option. IIRC the machine was also set to prefer UEFI but after seeing that Windows was MBR I simple installed an MBR/BIOS boot.
]]>Note: I never actually booted Windows and I didn't take any notice of the original partitioning. At the time, it didn't seem a matter of any particular interest...
]]>Even more stranger is that I also have Phoenix SecureCore (but not Tiano - pre Tiano, pre UEFI one) I my Dell system in which I boot using grub2 BIOS-GPT without any crazy boot flag etc on the 0xEE protective MBR partition. My UEFI is chainloaded from BIOS http://www.rodsbooks.com/bios2uefi/index.html .
]]>