On Sun, Mar 27, 2011 at 19:31, Dieter Plaetinck <dieter@xxxxxxxxxxxx> wrote: > On Sun, 27 Mar 2011 18:31:13 +0530 > "KESHAV P.R." <skodabenz@xxxxxxxxx> 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
