Talk:Unified Extensible Firmware Interface
ESP mount point /boot <-> /boot/efi
I think we should decide on a standard here. This article (and others) always use /boot/efi/, but:
- the gummiboot setup tool expects it to be mounted to /boot by default (this is only available in the [testing] package atm). Considering that the setup tool is called in post_install/post_upgrade, this will simply not work for people using /boot/efi.
- the next systemd version has a nice feature, as it will automatically create an automount unit to mount the ESP partition to /boot (it knows the ESP from the bootloader, see http://freedesktop.org/wiki/Software/systemd/BootLoaderInterface )
- Does using /boot/efi actually provide any kind of benefit? The boot partition has always been mounted to /boot and I don't see any reason to change that.
- This sounds like a sensible approach. Would it be worth adding a section on migrating; just to ease the pain?
- Jasonwryan (talk) 19:58, 5 March 2013 (UTC)
- For reference, there is still a long discussion about this here: https://bbs.archlinux.org/viewtopic.php?pid=1241590
- 65kid (talk) 19:02, 8 March 2013 (UTC)
>=512 MiB for the UEFISYS partition?
I was never told to make it 512 MiB or more, and right now it's 47.86 MiB and it works fine. Are there any other particular reasons for making it that relatively big? /// (t) 18:27, 26 July 2012 (UTC)
Microsoft Documentation mentions the minimum partition size for FAT32 to be 512 MiB. UEFI Spec. in some places mentions just FAT but in some places specifically mentions FAT32. Combining both the cases, having a >=512 MiB FAT32 (not FAT16/FAT12) partition UEFISYS is the best bet for all fimrwares out there, some of which may not support <512 MiB and/or FAT16 partition. -- Keshav P R (talk) 16:18, 20 October 2012 (UTC)
Where do you have this information from? See my post, where I give links to the only resources that I found which give a minimum size for FAT32 (and which is much smaller). --Calestyo (talk) 23:35, 30 June 2013 (UTC)
There is at least one long forum thread about this. The wiki was updated to recommend minimum of 512M because a smaller partition does not work with some firmware (e.g. mine) if Fat 32 is used and there is no guarantee that Fat 16 will work since it is not part of the UEFI specification. In many cases, a smaller partition may work but in some the firmware will simply respond that there is no OS on the machine at all. --cfr (talk) 23:40, 6 September 2013 (UTC)
Buhman has totally changed the steps to create a bootable UEFI USB. Persaonlly, I find the new steps to be much more comples than before, and to a pretty terrible job helping the user understand what is actually being achieved. Buhman's first edit says that he "excommunicated the 7z crap" or something like that. Wouldn't it be better to leave a perfectly usable option and make note of alternate methods rather than "excommunicating" what is there? I vote that these instructions should be reverted, or at the very least (heavily) commented. Thoughts anyone? -- Curtis (talk) 20:00, 16 Dec 2012 (UTC)
- I'm sorry I don't really have the time to revise those edits now, but the policy on the ArchWiki is to always let the end user choose which method to use in order to do something, never hiding anything, so if you really feel that the previous procedure was better, please add it back in a separate section. -- Kynikos (talk) 12:03, 18 December 2012 (UTC)
- I think that the line in the Bootable UEFI USB section that says "Install refind-efi" is ambiguous. Does this mean chroot to the filesystem and then install it? The reason I'm trying to setup the bootable USB is because I don't have an arch install running. Or, should I boot the media using some other means and then install the package? A list of commands would be more helpful. -- Framps (talk) 23:09, 17 January 2013 (UTC)
Faulty command in Remove_UEFI_boot_support_from_ISO
I am the developer of xorriso. A few weeks ago i came to https://bbs.archlinux.org/viewtopic.php?pid=1280444 Although the user reported no success with my proposal i still think that this option is wrong from the view of the combination of bash and xorriso:
I believe it should be
so that xorriso sees something like /home/thomas/archiso.iso and not ~/archiso.iso.
If the normal shell of archlinux is supposed to resolve "~/archiso.iso" rather than passing it to the started program, then this bug report is invalid, of course. One can simply try: echo "~/some_file" and look what will be printed to stdout. Scdbackup (talk) 12:34, 1 August 2013 (UTC)