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
On Sun, 27 Mar 2011 13:17:02 +0530 "KESHAV P.R." skodabenz@gmail.com wrote:
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
Hi Keshav, thanks for this overview.
My notes: - grub-legacy is tricky to setup (from an aif POV, not from a user POV) - I accept patches for grub2 if they are reasonably sane/elegant
From your overview, as well as Pierres first thread (and the responses to that), it seems all 3 bootloaders have something about them that makes them more suited for specific use cases, and less so for other cases. So none is clearly superior or inferior then the others, it all depends on the circumstances.
So, for the AIF perspective, I would say "which should be the default?" is an irrelevant question, the important thing is, we support two (and later maybe 3) and the user can choose.
So, maybe this is a question that should be answered by the package maintainers: because the order in which we list bootloader selection (i.e. which is at the top, the "default") will probably steer -to some extent- package usage and bug reports; which bootloader do you feel most comfortable with maintaining? The answer is very likely syslinux. Allan, Thomas, other maintainers/developers?
Dieter
On Sun, Mar 27, 2011 at 15:01, Dieter Plaetinck dieter@plaetinck.be wrote:
Hi Keshav, thanks for this overview.
My notes:
- grub-legacy is tricky to setup (from an aif POV, not from a user POV)
- I accept patches for grub2 if they are reasonably sane/elegant
From your overview, as well as Pierres first thread (and the responses to that), it seems all 3 bootloaders have something about them that makes them more suited for specific use cases, and less so for other cases. So none is clearly superior or inferior then the others, it all depends on the circumstances.
Yes, it depends on use case and personal opinion. KISS=syslinux all-in-one functionality and exotic configurations=grub2 . I did not include LILO in this list since i have never used it.
So, for the AIF perspective, I would say "which should be the default?" is an irrelevant question, the important thing is, we support two (and later maybe 3) and the user can choose.
So, maybe this is a question that should be answered by the package maintainers: because the order in which we list bootloader selection (i.e. which is at the top, the "default") will probably steer -to some extent- package usage and bug reports; which bootloader do you feel most comfortable with maintaining?
This is really question about users who do not care about what bootloader they have in their system and simply select the 1st one in the menu. Especially true in case of newbies (most of them).
Definitely syslinux and grub2 are here to stay. The question is about grub-legacy. We should ask Ronald (pressh) whether he is ready to maintain grub (now that the last fork of it is being abandoned) and bug-fix and maintain patches for it. I am sure once fedora jumps to grub2, no one will care about grub and there wont be any patches from anyone for any feature/bugfix. I am sure of this because fedora is moving to btrfs as default rootfs and its the reason they are (finally) deprecating grub-legacy, instead of adding btrfs support to it (like they did for ext4).
My suggestion is if the grub-legacy maintainer is not ready to continue maintaining it and if no other dev wants to maintain it, bring out a news announcing no more bug-reports (aka dev support) for grub-legacy and move it to community or AUR. I know it is strange for a package to go from core directly to AUR, but the official upstream for grub-legacy never existed for four years. If any user want to use it, they can take it from AUR and I am sure some user will maintain it for foreseeable future while the devs can be relieved off the job.
The answer is very likely syslinux. Allan, Thomas, other maintainers/developers?
My 2nd question - GPT as default. This requires moving from cfdisk to sgdisk/parted usage in the installer.
I tried looking in aif for adding grub2 support and i thought of copying relevant code from archboot and modifying it to use libui-sh . But there are few other issues like partition alignment, bios boot partition (grub2-bios in GPT) and EFI system partition (for any efi bootloader including grub2-efi - only GPT) which require use of gnu parted over sfdisk/cfdisk. Anyway I cant promise a time frame for coming out with patches. I am not so well versed in git for that matter. I was actually thinking of merging archboot's /arch/setup features and fixes into aif and make archboot use aif (where archboot uses initramfs type iso and archiso uses squashfs type iso). Archboot setup has all the partitioning and bootloader fixes requires but too bloated and seems almost impossible to port to libui-sh and aif.
Regards.
Keshav
On Sun, 27 Mar 2011 18:31:13 +0530 "KESHAV P.R." skodabenz@gmail.com wrote:
This is really question about users who do not care about what bootloader they have in their system and simply select the 1st one in the menu. Especially true in case of newbies (most of them).
I don't care if users break their install if they act like a retard during the installation. In fact, I'm getting pretty tired of this continued discussion about how we can best spoonfeed such people. It is just _impossible_ to make any bootloader the "default" for all use cases.
Imho we should just try to list concisely what the options are, and if package maintainers ask me to discourage use of a specific package, I'll do that. But anything beyond that is optional (and right now, not worth my time) We could list them something like:
* grub (supports ext*, vfat, reiserfs, xfs. MBR. chainloading) * syslinux (supports ext*, vfat, btrfs. GPT/MBR. LVM. no chainloading)
My 2nd question - GPT as default. This requires moving from cfdisk to sgdisk/parted usage in the installer.
If I want to support GPT I will need decent utilities from upstream. I know about parted and sgdisk but I need a toolset for: - interactive partitioning - scripted partitioning (for auto-installs) - the input format for the scripts should be similar/the same whether you use MBR or GPT.
Basically, if the kernel guys (util-linux) don't care about GPT, I don't think I should either. I'd rather avoid turning to Gnu (parted) or more obscure (gdisk) upstreams. Actually I don't get why there is no GPT support yet it util-linux. Am I missing something?
I tried looking in aif for adding grub2 support and i thought of copying relevant code from archboot and modifying it to use libui-sh . But there are few other issues like partition alignment, bios boot partition (grub2-bios in GPT) and EFI system partition (for any efi bootloader including grub2-efi - only GPT) which require use of gnu parted over sfdisk/cfdisk. Anyway I cant promise a time frame for coming out with patches. I am not so well versed in git for that matter. I was actually thinking of merging archboot's /arch/setup features and fixes into aif and make archboot use aif (where archboot uses initramfs type iso and archiso uses squashfs type iso). Archboot setup has all the partitioning and bootloader fixes requires but too bloated and seems almost impossible to port to libui-sh and aif.
Yeah, archboot is tied to a certain "way of doing things" that's pretty hard to untangle, I think. Tobias and I have talked about that before, it's definitely not trivial, but it's surely possible.
Dieter
On Sun, Mar 27, 2011 at 19:31, Dieter Plaetinck dieter@plaetinck.be wrote:
On Sun, 27 Mar 2011 18:31:13 +0530 "KESHAV P.R." skodabenz@gmail.com wrote:
This is really question about users who do not care about what bootloader they have in their system and simply select the 1st one in the menu. Especially true in case of newbies (most of them).
I don't care if users break their install if they act like a retard during the installation. In fact, I'm getting pretty tired of this continued discussion about how we can best spoonfeed such people. It is just _impossible_ to make any bootloader the "default" for all use cases.
Imho we should just try to list concisely what the options are, and if package maintainers ask me to discourage use of a specific package, I'll do that. But anything beyond that is optional (and right now, not worth my time) We could list them something like:
- grub (supports ext*, vfat, reiserfs, xfs. MBR. chainloading)
- syslinux (supports ext*, vfat, btrfs. GPT/MBR. LVM. no chainloading)
Agreed. Arch is a DIY distro. So no need to spoon-feed. But automated installer?
This discussion is really outside the scope of default bootloader. If grub-legacy is removed from repos, it leaves only syslinux in aif, until grub2 is implemented. If you are not bothered about what the maintainer says, you can simply change the order in the menu.
My 2nd question - GPT as default. This requires moving from cfdisk to sgdisk/parted usage in the installer.
If I want to support GPT I will need decent utilities from upstream. I know about parted and sgdisk but I need a toolset for:
- interactive partitioning
- scripted partitioning (for auto-installs)
Basically, if the kernel guys (util-linux) don't care about GPT, I don't think I should either. I'd rather avoid turning to Gnu (parted) or more obscure (gdisk) upstreams.
I know gdisk is one-man show but it is one of the best tools for GPT. Rod Smith is maintaining it very well and being used by almost all distros now (and a plus is it is available for multi-OS unlike fdisk). About util-linux fdisk family I don't know what they are planning about GPT. But why not GNU Parted. For interactive use fdisk (not cfdisk) and gdisk. For scripting parted is actually good.
- the input format for the scripts should be similar/the same whether you use MBR or GPT.
That might be a problem. But for now we have to rely on different tools from different projects.
Actually I don't get why there is no GPT support yet it util-linux. Am I missing something?
I tried looking in aif for adding grub2 support and i thought of copying relevant code from archboot and modifying it to use libui-sh . But there are few other issues like partition alignment, bios boot partition (grub2-bios in GPT) and EFI system partition (for any efi bootloader including grub2-efi - only GPT) which require use of gnu parted over sfdisk/cfdisk. Anyway I cant promise a time frame for coming out with patches. I am not so well versed in git for that matter. I was actually thinking of merging archboot's /arch/setup features and fixes into aif and make archboot use aif (where archboot uses initramfs type iso and archiso uses squashfs type iso). Archboot setup has all the partitioning and bootloader fixes requires but too bloated and seems almost impossible to port to libui-sh and aif.
Yeah, archboot is tied to a certain "way of doing things" that's pretty hard to untangle, I think. Tobias and I have talked about that before, it's definitely not trivial, but it's surely possible.
Like we discussed in irc few days back. Tobias prefers a initramfs type system while archiso uses squashfs type system. Irrespective of the rootfs in both the cases, both use /arch/setup to launch the installer. Archboot uses /arch/setup as it is, all-in-one file. In archiso it redirects to aif. In that way, archboot can be made to use aif like archiso does. I am actually more concerned about merging archboot's setup script changes (atleast partitioning and bootloader parts alone) into aif rather than how they are used finally in the respective isos. The merging work seems to be mammoth task as of now.
Regards.
Keshav
Excerpts from Dieter Plaetinck's message of 2011-03-27 10:01:35 -0400:
If I want to support GPT I will need decent utilities from upstream. I know about parted and sgdisk but I need a toolset for:
- interactive partitioning
Because I was not too happy with doing interactive partitioning with parted, I started a project [cparted][1]. I thought it was going to be ready for use soon, but then realized it has some issues (alignment wrong, fixing alignment had other unwanted side effects), and am not sure how soon they will be fixed. But this brings up a couple questions. If cparted is in good working order, would it be considered for use with AIF? Is having Python and [pyparted][2] as dependencies OK?
[1]: https://github.com/davekong/cparted [2]: https://fedorahosted.org/pyparted/
- scripted partitioning (for auto-installs)
You can run parted in --script mode.
- the input format for the scripts should be similar/the same whether you use MBR or GPT.
The input format would be the same.
On Sun, 27 Mar 2011 17:06:57 -0400 David Campbell davekong@archlinux.us wrote:
Excerpts from Dieter Plaetinck's message of 2011-03-27 10:01:35 -0400:
If I want to support GPT I will need decent utilities from upstream. I know about parted and sgdisk but I need a toolset for:
- interactive partitioning
Because I was not too happy with doing interactive partitioning with parted, I started a project [cparted][1]. I thought it was going to be ready for use soon, but then realized it has some issues (alignment wrong, fixing alignment had other unwanted side effects), and am not sure how soon they will be fixed. But this brings up a couple questions. If cparted is in good working order, would it be considered for use with AIF?
Maybe, if the project has become really big. For stuff like this I really would like a reliable upstream which I can trust will produce high-quality software. We're talking about tricky and important stuff which is hard to debug. And we're talking about stuff that every distribution needs, so I'm inclined to wait for a solution supported by the kernel guys (i.e. something in util-linux would be nice)
Is having Python and [pyparted][2] as dependencies OK?
I would try hard to avoid python. There were times I wished I wrote aif in python (then it obviously be okay), but at this point I would rather just depend on some commonly available binary programs.
- scripted partitioning (for auto-installs)
You can run parted in --script mode.
Hmm, and does it have a proper UI in ncurses or something? to replace cfdisk in aif? I know about the newt-based nparted but I'm told it's badly maintained.
Dieter
Excerpts from Dieter Plaetinck's message of 2011-03-28 12:06:21 -0400:
Hmm, and does it have a proper UI in ncurses or something? to replace cfdisk in aif?
It will when cparted is proper. Whether cparted will be ported to use libparted directly, rather than using Python bindings, is yet to be seen. I certainly prefer writing/maintaining Python code over C though, and I don't see any benefit to translating it into C other than avoiding Python as a dependency.
I know about the newt-based nparted but I'm told it's badly maintained.
As far as I could tell, nparted is dead.
arch-releng@lists.archlinux.org