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, 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

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