Hi all, I wanted to share my views on this whole discussion. Many people don't know the actual features and problems with individual boot-loaders. GRUB-Legacy - Kinda KISS (actually syslinux is more KISS) - Easy to setup and configure - Simple config file - text file based - Multi-partition support (can load kernels from diff partitions - multi-linux systems) - Supported by AIF and Archboot X Does not support newer filesystems like BTRFS, NILFS2 etc. X No GPT and non-MBR partition tables support X No LVM, RAID etc.. (I may be wrong here) X No jpeg, png images support (not that it matters for arch users - mainly for users wanting eye-candy stuff) X No partition search support, needs hardcoding partition number in grub.conf X Supports only BIOS and MBR systems X Upstream deprecated X Difficult to maintain patches X The only fork of grub-legacy (Fedora's - http://git.kernel.org/?p=boot/grub-fedora/grub-fedora.git) (Arch does not use this) is also planning to stop development - http://fedoraproject.org/wiki/Features/Grub2#Benefit_to_Fedora GRUB2 (will be grub according to upstream once released as stable) - Modules support - Virtually all open source filesystems and few proprietary ones like ntfs, hfs - All-in-one bootloader - Setting up is actually easy - just lack of docs for that - All eye-candy stuff - Almost all partitioning systems - you can even use Archlinux in Amiga partitioning or Apple Partition Map with grub2 - loopback support for booting isos - Maintained by upstream - LVM, RAID and other stuff supported - Supports partition searching at runtime (using search command) - UUID support (with search) - Multiple firmwares support (independent of partitioning scheme) like Coreboot, UEFI etc. - Scripting support in grub.cfg with env variables etc. , useful for some users (for me atleast). - Configuration can be edited directly (its a common misconception regarding uneditable grub.cfg) - Rescue mode - Can manually load grub-legacy config file and supports converting from grub.conf (or menu.lst) to grub.cfg format - grub-menulst2cfg in grub2-common package BTRFS support in the works. Its actually completed but there are few issues with copyright (with Oracle) and licensing issues (BTRFS is GPL2 , GRUB2 is GPL3, both are not GPL2+) so its not there in release versions and bzr trunk right now. X Not KISS X Takes more steps (!=complex) to setup X Configuration may be difficult to understand (its basically a shell script like language rather than simple text based) X Requires dedicated space for embedding core.img (first 32KB in case of MBR or BIOS Boot partition in case of GPT) X Lack of proper and complete documentation - This is the main reason for users abandoning grub2 (it is NOT complex to setup, simply more steps) X Not yet stable The funny thing is grub-legacy is regarded as stable when it was actually designated as alpha by upstream (not even beta, it never reaches 1.00 version) so I think grub2 can be used in place of grub-legacy. SYSLINUX - KISS - Actively maintained - GPT, MBR and unpartitioned (whole disk) (not other partitioning systems) - Easy to setup - Kinda modular (though not to the extent of grub2) - LVM (RAID?) - png., jpeg etc - Simple config file - ISO bootloading apart from HDD - NO dedicated embedding space - Supported by AIF and Archboot X No multi-partition multi-OS systems support (loading kernels directly) (not chainload) X No rescue mode (I had an experience with this - http://syslinux.zytor.com/archives/2010-December/015875.html) X Few filesystems spported - no reiserfs, xfs etc. X No UEFI or other firmware support I personally like grub2 (but testing syslinux right now just for fun - in GPT, not in MBR). These views are my own and not of the upstream devs or arch devs. In any case grub-legacy should be deprecated since it is difficult to maintain according to pressh and there is no plan to switch to fedora maintained fork since that may also go off once fedora implements grub2 in its installer (Anaconda). I propose shifting completely to syslinux including automatic installer. On a side note, I think it is also useful to have GPT partitioning as default now since it is way superior to MBR (see logical partitions linked-list info) and supports multiple primary partitions. Please free to provide any comments regarding my views and finally sorry for such a long mail. We can take this discussion to the forum if needed. Regards. Keshav