Re: [arch-general] [arch-dev-public] Boot loaders in core/base
Am Sat, 20 Nov 2010 11:27:35 +0100 schrieb Pierre Schmitz <pierre@archlinux.de>:
ATM. we have grub1 in core/base and install that by default. The problem is that this project is virtually dead for a long time now and also not available on x86_64. Technically it has to be in the multilib repo.
I'm running a x86_64 system and have grub1 installed without any lib32 dependencies. So, of course it's available on x86_64. Why shall this be moved to [multilib]?
An alternative successor would be extlinux from the syslinux package. It's very simple, easy to configure, actively maintained and reliable. Sure, it only supports booting from ext* and btrfs afaik but to be honest, if you use any other FS you should have a separate /boot even when using grub.
This would be a massive regression because there are several people who are using reiserfs and other filesystems. And what has a separate /boot partition to do with the bootloader and the filesystem? You can use almost every filesystem on the /boot partition. The best would be if every available bootloader would be moved to [core] and supported by AIF, so that the user can decide during the installation which bootloader fits best to him and which bootloader shall be installed, because there's currently no bootloader which can do everything. Depending on the partition scheme and the used filesystem a different bootloader is needed. And simultaneously every filesystem related package incl. btrfs-utils e.g. should be moved to [core] and supported by AIF, too. So that the user can decide during the installation how he wants to partition and format his drives and which filesystem he wants to use.
Summing up my suggestion for some time in the future would be: * move extlinux/syslinux to core/base Good idea.
* move grub1 to extra/multilib and remove it from base group Bad idea and doesn't make much sense until there is a real equivalent alternative. It's still the most used bootloader I guess.
* keep grub2 in extra Should go to [core], too.
* maybe also move lilo to extra Not the best idea, too.
* of course keep all of them on the install cd Good idea again. But on the install CD there are only [core] packages as far as I know which makes sense. So all these packages should be moved to [core].
What do you think about this? At some point it might not be sane/possible to keep grub1 as our default boot loader.
But I don't see this point, yet. It will be sometime in the future when there's a real alternative which can boot from every possible partition scheme and filesystem. Heiko
On 21/11/10 00:25, Heiko Baums wrote:
Am Sat, 20 Nov 2010 11:27:35 +0100 schrieb Pierre Schmitz<pierre@archlinux.de>:
ATM. we have grub1 in core/base and install that by default. The problem is that this project is virtually dead for a long time now and also not available on x86_64. Technically it has to be in the multilib repo.
I'm running a x86_64 system and have grub1 installed without any lib32 dependencies. So, of course it's available on x86_64. Why shall this be moved to [multilib]?
It is not a 64 bit binary as the package has to be built on an 32 bit system... Run "file /sbin/grub".
Am 20.11.2010 15:25, schrieb Heiko Baums:
Am Sat, 20 Nov 2010 11:27:35 +0100 schrieb Pierre Schmitz <pierre@archlinux.de>:
ATM. we have grub1 in core/base and install that by default. The problem is that this project is virtually dead for a long time now and also not available on x86_64. Technically it has to be in the multilib repo.
I'm running a x86_64 system and have grub1 installed without any lib32 dependencies. So, of course it's available on x86_64. Why shall this be moved to [multilib]?
Grub does not build for x86_64. /sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, stripped Technically, this is very un-Arch-way.
An alternative successor would be extlinux from the syslinux package. It's very simple, easy to configure, actively maintained and reliable. Sure, it only supports booting from ext* and btrfs afaik but to be honest, if you use any other FS you should have a separate /boot even when using grub.
This would be a massive regression because there are several people who are using reiserfs and other filesystems.
I don't even know if installing a bootloader on reiser, jfs or xfs is safe. Just because grub does it, doesn't mean it's a good idea.
The best would be if every available bootloader would be moved to [core] and supported by AIF, so that the user can decide during the installation which bootloader fits best to him and which bootloader shall be installed, because there's currently no bootloader which can do everything.
I don't think it's a good idea to maintain that many bootloaders in core. grub-legacy is unmaintained, lilo has a very old-school design and major disadvantages. We could keep grub2, but it seems it isn't really stable yet.
Am Sat, 20 Nov 2010 15:38:33 +0100 schrieb Thomas Bächler <thomas@archlinux.org>:
I don't think it's a good idea to maintain that many bootloaders in core. grub-legacy is unmaintained, lilo has a very old-school design and major disadvantages. We could keep grub2, but it seems it isn't really stable yet.
That's what I mean. There's unfortunately not an allrounder, yet. One old and unmaintained, one still older bootloader, one newer and maintained but still unstable and one newer and maintained with not so many supported filesystems. So I'm not sure if it's the best for now to having every bootloader in [core]. Of, course the best would be if there would be one real good, stable and by upstream actively maintained bootloader so that there's no need for other ones. Heiko
On 20-11-2010 15:15, Heiko Baums wrote:
Am Sat, 20 Nov 2010 15:38:33 +0100 schrieb Thomas Bächler <thomas@archlinux.org>:
I don't think it's a good idea to maintain that many bootloaders in core. grub-legacy is unmaintained, lilo has a very old-school design and major disadvantages. We could keep grub2, but it seems it isn't really stable yet.
That's what I mean. There's unfortunately not an allrounder, yet. One old and unmaintained, one still older bootloader, one newer and maintained but still unstable and one newer and maintained with not so many supported filesystems.
It just needs to know how to read well from /boot which can be quite small (100~200MB) and be whatever filesystem will be supported for years to come, even if the supported filesystems change it's not much of a trouble copying stuff somewhere else, formatting and copying back. Sometimes more is not better if support is flaky. -- Mauro Santos
On 20 November 2010 15:25, Heiko Baums <lists@baums-on-web.de> wrote:
Am Sat, 20 Nov 2010 11:27:35 +0100 schrieb Pierre Schmitz <pierre@archlinux.de>:
ATM. we have grub1 in core/base and install that by default. The problem is that this project is virtually dead for a long time now and also not available on x86_64. Technically it has to be in the multilib repo.
I'm running a x86_64 system and have grub1 installed without any lib32 dependencies. So, of course it's available on x86_64. Why shall this be moved to [multilib]?
An alternative successor would be extlinux from the syslinux package. It's very simple, easy to configure, actively maintained and reliable. Sure, it only supports booting from ext* and btrfs afaik but to be honest, if you use any other FS you should have a separate /boot even when using grub.
This would be a massive regression because there are several people who are using reiserfs and other filesystems.
And what has a separate /boot partition to do with the bootloader and the filesystem? You can use almost every filesystem on the /boot partition.
The best would be if every available bootloader would be moved to [core] and supported by AIF, so that the user can decide during the installation which bootloader fits best to him and which bootloader shall be installed, because there's currently no bootloader which can do everything. Depending on the partition scheme and the used filesystem a different bootloader is needed.
And simultaneously every filesystem related package incl. btrfs-utils e.g. should be moved to [core] and supported by AIF, too. So that the user can decide during the installation how he wants to partition and format his drives and which filesystem he wants to use.
Summing up my suggestion for some time in the future would be: * move extlinux/syslinux to core/base Good idea.
* move grub1 to extra/multilib and remove it from base group Bad idea and doesn't make much sense until there is a real equivalent alternative. It's still the most used bootloader I guess.
* keep grub2 in extra Should go to [core], too.
* maybe also move lilo to extra Not the best idea, too.
* of course keep all of them on the install cd Good idea again. But on the install CD there are only [core] packages as far as I know which makes sense. So all these packages should be moved to [core].
What do you think about this? At some point it might not be sane/possible to keep grub1 as our default boot loader.
But I don't see this point, yet. It will be sometime in the future when there's a real alternative which can boot from every possible partition scheme and filesystem.
Heiko
I'd keep grub legacy in core and I'd add grub 2 to core too. When grub 2 become usable enough it could replace grub legacy completely. And for the other bootloaders: I'd scrap lilo – I don't see any reason why to keep it in core, it's inferior compared to grub (or syslinux). I'm not yet sure about syslinux.
On Nov 20, 2010, at 9:38 AM, "Lukáš Jirkovský" <l.jirkovsky@gmail.com> wrote:
On 20 November 2010 15:25, Heiko Baums <lists@baums-on-web.de> wrote:
Am Sat, 20 Nov 2010 11:27:35 +0100 schrieb Pierre Schmitz <pierre@archlinux.de>:
ATM. we have grub1 in core/base and install that by default. The problem is that this project is virtually dead for a long time now and also not available on x86_64. Technically it has to be in the multilib repo.
I'm running a x86_64 system and have grub1 installed without any lib32 dependencies. So, of course it's available on x86_64. Why shall this be moved to [multilib]?
An alternative successor would be extlinux from the syslinux package. It's very simple, easy to configure, actively maintained and reliable. Sure, it only supports booting from ext* and btrfs afaik but to be honest, if you use any other FS you should have a separate /boot even when using grub.
This would be a massive regression because there are several people who are using reiserfs and other filesystems.
And what has a separate /boot partition to do with the bootloader and the filesystem? You can use almost every filesystem on the /boot partition.
The best would be if every available bootloader would be moved to [core] and supported by AIF, so that the user can decide during the installation which bootloader fits best to him and which bootloader shall be installed, because there's currently no bootloader which can do everything. Depending on the partition scheme and the used filesystem a different bootloader is needed.
And simultaneously every filesystem related package incl. btrfs-utils e.g. should be moved to [core] and supported by AIF, too. So that the user can decide during the installation how he wants to partition and format his drives and which filesystem he wants to use.
Summing up my suggestion for some time in the future would be: * move extlinux/syslinux to core/base Good idea.
* move grub1 to extra/multilib and remove it from base group Bad idea and doesn't make much sense until there is a real equivalent alternative. It's still the most used bootloader I guess.
* keep grub2 in extra Should go to [core], too.
* maybe also move lilo to extra Not the best idea, too.
* of course keep all of them on the install cd Good idea again. But on the install CD there are only [core] packages as far as I know which makes sense. So all these packages should be moved to [core].
What do you think about this? At some point it might not be sane/possible to keep grub1 as our default boot loader.
But I don't see this point, yet. It will be sometime in the future when there's a real alternative which can boot from every possible partition scheme and filesystem.
Heiko
I'd keep grub legacy in core and I'd add grub 2 to core too. When grub 2 become usable enough it could replace grub legacy completely. And for the other bootloaders: I'd scrap lilo – I don't see any reason w hy to keep it in core, it's inferior compared to grub (or syslinux). I'm not yet sure about syslinux.
Is syslinux a 64bit build? Could we use that by default (why/why not)? I use extlinux on all my machines with success. I would check myself but I'm on the interstate. C Anthony [mobile]
participants (6)
-
Allan McRae
-
C Anthony Risinger
-
Heiko Baums
-
Lukáš Jirkovský
-
Mauro Santos
-
Thomas Bächler