[arch-releng] grub install not listing partitions

older
[arch-releng] Arch Linux Official...

Dieter Plaetinck

15 Dec 2011 15 Dec '11

9:40 a.m.

Why exactly don't we list partitions anymore? (see https://github.com/Dieterbe/aif/commit/55190c0c81fc76f8b2b3983e790f2c7aacf4e...) IIRC you said it shouldn't be really needed, but turns out it is: https://bugs.archlinux.org/task/25726 see also http://mailman.archlinux.org/pipermail/arch-releng/2011-March/001557.html so we should probably list again all blockdevices (partitions and devices themselves) Dieter

Show replies by date

Thomas Bächler

15 Dec 15 Dec

9:55 a.m.

Am 15.12.2011 10:40, schrieb Dieter Plaetinck:

...

Why exactly don't we list partitions anymore? (see https://github.com/Dieterbe/aif/commit/55190c0c81fc76f8b2b3983e790f2c7aacf4e...) IIRC you said it shouldn't be really needed, but turns out it is: https://bugs.archlinux.org/task/25726 see also http://mailman.archlinux.org/pipermail/arch-releng/2011-March/001557.html

so we should probably list again all blockdevices (partitions and devices themselves)

Last time I tried installing grub into a partition (which is a while ago), it kept complaining a lot and refusing to install. Grub is weird that way. My rationale is this: 1.) You want to chainload grub: There is no need to chainload grub. If you want to use grub from a different system, you can just add Arch to that grub instance manually. 2.) You don't want to chainload grub: Put it in the MBR then. More importantly: Don't use grub, use syslinux (which will always install in the /boot partition).

Heiko Baums

12:36 p.m.

Am Thu, 15 Dec 2011 10:55:50 +0100 schrieb Thomas Bächler :

...

More importantly: Don't use grub, use syslinux (which will always install in the /boot partition).

But syslinux can't handle multi-boot systems. Or is that fixed in the meantime? Heiko

Gerardo Exequiel Pozzi

3:13 p.m.

On 12/15/2011 09:36 AM, Heiko Baums wrote:

...

Am Thu, 15 Dec 2011 10:55:50 +0100 schrieb Thomas Bächler:

...
More importantly: Don't use grub, use syslinux (which will always install in the /boot partition). But syslinux can't handle multi-boot systems. Or is that fixed in the meantime?

Heiko

Yes, since syslinux-3.08 (05/2005) with com32 module mboot.c32 ;) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

Thomas Bächler

3:43 p.m.

Am 15.12.2011 16:13, schrieb Gerardo Exequiel Pozzi:

...

On 12/15/2011 09:36 AM, Heiko Baums wrote:

...
Am Thu, 15 Dec 2011 10:55:50 +0100 schrieb Thomas Bächler:

...
More importantly: Don't use grub, use syslinux (which will always install in the /boot partition). But syslinux can't handle multi-boot systems. Or is that fixed in the meantime?

Heiko

Yes, since syslinux-3.08 (05/2005) with com32 module mboot.c32 ;)

No, mboot.c32 can chainload "multiboot kernels". However, these kernels still need to be on the syslinux home partition! In theory, you could use this to chainload grub2, but it fails for very annoying technical reasons.

Gerardo Exequiel Pozzi

7:43 p.m.

----- Mensaje original -----

...

De: Thomas Bächler Para: arch-releng@archlinux.org CC: Enviado: jueves, 15 de diciembre de 2011 7:43 Asunto: Re: [arch-releng] grub install not listing partitions

...
On 12/15/2011 09:36 AM, Heiko Baums wrote:

...
Am Thu, 15 Dec 2011 10:55:50 +0100 schrieb Thomas Bächler:

...
More importantly: Don't use grub, use syslinux (which will always install in the /boot partition). But syslinux can't handle multi-boot systems. Or is that fixed in

Am 15.12.2011 16:13, schrieb Gerardo Exequiel Pozzi: the

...
...
meantime?

Heiko

Yes, since syslinux-3.08 (05/2005) with com32 module mboot.c32 ;)

No, mboot.c32 can chainload "multiboot kernels". However, these kernels still need to be on the syslinux home partition! In theory, you could use this to chainload grub2, but it fails for very annoying technical reasons.

Yes, multiboot system, also know as multiboot protocol. Reading files from another fs != multiboot system.

Gerardo Exequiel Pozzi

10:52 p.m.

On 12/15/2011 04:43 PM, Gerardo Exequiel Pozzi wrote:

...

----- Mensaje original -----

...
De: Thomas Bächler Para: arch-releng@archlinux.org CC: Enviado: jueves, 15 de diciembre de 2011 7:43 Asunto: Re: [arch-releng] grub install not listing partitions

...
On 12/15/2011 09:36 AM, Heiko Baums wrote:

...
Am Thu, 15 Dec 2011 10:55:50 +0100 schrieb Thomas Bächler:

...
More importantly: Don't use grub, use syslinux (which will always install in the /boot partition). But syslinux can't handle multi-boot systems. Or is that fixed in

Am 15.12.2011 16:13, schrieb Gerardo Exequiel Pozzi: the

...
...
meantime?

Heiko

Yes, since syslinux-3.08 (05/2005) with com32 module mboot.c32 ;) No, mboot.c32 can chainload "multiboot kernels". However, these kernels still need to be on the syslinux home partition! In theory, you could use this to chainload grub2, but it fails for very annoying technical reasons.

Yes, multiboot system, also know as multiboot protocol.

Reading files from another fs != multiboot system.

Anyway this discussion seems to be about multiple boot loaders, not about multiboot. So ignore my two previous messages :) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

Thomas Bächler

3:17 p.m.

Am 15.12.2011 13:36, schrieb Heiko Baums:

...

Am Thu, 15 Dec 2011 10:55:50 +0100 schrieb Thomas Bächler :

...
More importantly: Don't use grub, use syslinux (which will always install in the /boot partition).

But syslinux can't handle multi-boot systems. Or is that fixed in the meantime?

Not if the kernels and initramfs are all on the same partition, no, but you can chainload a syslinux installation.

Desmond Cox

3:24 p.m.

On Thu, Dec 15, 2011 at 4:55 AM, Thomas Bächler wrote:

...

Am 15.12.2011 10:40, schrieb Dieter Plaetinck:

...
Why exactly don't we list partitions anymore? (see https://github.com/Dieterbe/aif/commit/55190c0c81fc76f8b2b3983e790f2c7aacf4e...) IIRC you said it shouldn't be really needed, but turns out it is: https://bugs.archlinux.org/task/25726 see also http://mailman.archlinux.org/pipermail/arch-releng/2011-March/001557.html

so we should probably list again all blockdevices (partitions and devices themselves)

Last time I tried installing grub into a partition (which is a while ago), it kept complaining a lot and refusing to install. Grub is weird that way.

My rationale is this:

1.) You want to chainload grub: There is no need to chainload grub. If you want to use grub from a different system, you can just add Arch to that grub instance manually.

2.) You don't want to chainload grub: Put it in the MBR then.

More importantly: Don't use grub, use syslinux (which will always install in the /boot partition).

Chainloading is useful because it allows each distribution to manage its menu.lst separately. Consider a user running Debian, Ubuntu, and Arch. Debian and Ubuntu both include several past kernels in their menus as well as a handful of other recovery options. By installing one system-wide GRUB instance to the MBR and distribution-specific instances to each partition, the upgrade procedure is greatly simplified. When booting, this user first selects their desired distribution, then selects their desired kernel/fallback/recovery mode. Combining all three into one menu causes clutter. Yes, there are other (better and worse) ways to handle this, but why _remove_ functionality? I never experienced trouble installing GRUB to a partition. -- Des

Matthew Gyurgyik

16 Dec 16 Dec

4:02 a.m.

On 12/15/2011 04:40 AM, Dieter Plaetinck wrote:

...

Why exactly don't we list partitions anymore? (see https://github.com/Dieterbe/aif/commit/55190c0c81fc76f8b2b3983e790f2c7aacf4e...) IIRC you said it shouldn't be really needed, but turns out it is: https://bugs.archlinux.org/task/25726 see also http://mailman.archlinux.org/pipermail/arch-releng/2011-March/001557.html

so we should probably list again all blockdevices (partitions and devices themselves)

Dieter I agree with Thomas.

1.) There are better alternatives to installing grub on a partition (see Thomas' mail). 2.) Listing all the block devices and partitions becomes hard to read. /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sdb /dev/sdb1 /dev/sdb2 /dev/sdc /dev/sdc1 /dev/sdc2 vs /dev/sda /dev/sdb /dev/sdc 3.) Don't use grub-legacy (not supported upstream or maintained). Use syslinux (installer) or grub2 (manually). Installing grub to a partition is an uncommon setup and used by few users, Those who really want to install grub to a partition can do so manually.

Eric Fernandez

9:34 a.m.

2011/12/16 Matthew Gyurgyik :

...

I agree with Thomas.

1.) There are better alternatives to installing grub on a partition (see Thomas' mail).

3.) Don't use grub-legacy (not supported upstream or maintained). Use syslinux (installer) or grub2 (manually).

I appreciate these comments and gather syslinux might be a better solution than grub, and will look into it. However, I would like to point out that grub (legacy) is still the recommended bootloader solution in the beginner's guide, and in the installer isos. Furthermore, grub legacy is the one in core, whereas grub2 is in extra. I think that it is prematurate to cripple the installation of a bootloader just because it is not maintained upstream, until we have a better replacement. If really grub legacy is bad, then we should phase it out and replace it with a better one, which should be the new default. Why not replace grub legacy with grub2 in the core repository and in the installer?

...

Installing grub to a partition is an uncommon setup and used by few users, Those who really want to install grub to a partition can do so manually.

Well, that is against the KISS principle. The fact it is uncommon is irrelevant for a distro like Arch, which is not suppose to hide options for their own good (especially when users report having used the partition installation with no problem). Eric

Dieter Plaetinck

12:14 p.m.

On Fri, 16 Dec 2011 09:34:57 +0000 Eric Fernandez wrote:

...

2011/12/16 Matthew Gyurgyik :

...
I agree with Thomas.

1.) There are better alternatives to installing grub on a partition (see Thomas' mail).

3.) Don't use grub-legacy (not supported upstream or maintained). Use syslinux (installer) or grub2 (manually).

I appreciate these comments and gather syslinux might be a better solution than grub, and will look into it.

However, I would like to point out that grub (legacy) is still the recommended bootloader solution in the beginner's guide, and in the installer isos. Furthermore, grub legacy is the one in core, whereas grub2 is in extra. I think that it is prematurate to cripple the installation of a bootloader just because it is not maintained upstream, until we have a better replacement. If really grub legacy is bad, then we should phase it out and replace it with a better one, which should be the new default. Why not replace grub legacy with grub2 in the core repository and in the installer?

...
Installing grub to a partition is an uncommon setup and used by few users, Those who really want to install grub to a partition can do so manually.

Well, that is against the KISS principle. The fact it is uncommon is irrelevant for a distro like Arch, which is not suppose to hide options for their own good (especially when users report having used the partition installation with no problem).

Eric

my toughts: 1) general rule: don't prevent users from doing dumb things, it also prevents doing them from smart things. it's not our job to impose methods or configurations on users (although we can and should make recommendations) AIF is an "enabler", it should enable users to set up their system how they want it. So even if we are aware that installing grub in partitions can sometimes give issues, that's not a reason to make it extra hard for the user to do it, because apparently it does work for some people. We should just put a recommendation in the selection menu to prefer the device itself instead of a partition, and that the grub install might fail if you do it in a partition. 2) saying "if you want this, do it manually" defeats the point. 3) I understand Thomas' points, but in reality, I agree that having multiple bootloaders (i.e. one in mbr, one in partition), can make it easier to deal with distro's that happily auto-rewrite bootloader or bootloader configs. 4) I disagree with the "Listing all the block devices and partitions becomes hard to read." argument. Anyone who wants to install Arch should be at the very least mentally capable to deal with such a list. Dieter

Dieter Plaetinck

23 Dec 23 Dec

6:24 p.m.

On Fri, 16 Dec 2011 13:14:49 +0100 Dieter Plaetinck wrote:

...

On Fri, 16 Dec 2011 09:34:57 +0000 Eric Fernandez wrote:

...
2011/12/16 Matthew Gyurgyik :

...
I agree with Thomas.

1.) There are better alternatives to installing grub on a partition (see Thomas' mail).

3.) Don't use grub-legacy (not supported upstream or maintained). Use syslinux (installer) or grub2 (manually).

I appreciate these comments and gather syslinux might be a better solution than grub, and will look into it.

However, I would like to point out that grub (legacy) is still the recommended bootloader solution in the beginner's guide, and in the installer isos. Furthermore, grub legacy is the one in core, whereas grub2 is in extra. I think that it is prematurate to cripple the installation of a bootloader just because it is not maintained upstream, until we have a better replacement. If really grub legacy is bad, then we should phase it out and replace it with a better one, which should be the new default. Why not replace grub legacy with grub2 in the core repository and in the installer?

...
Installing grub to a partition is an uncommon setup and used by few users, Those who really want to install grub to a partition can do so manually.

Well, that is against the KISS principle. The fact it is uncommon is irrelevant for a distro like Arch, which is not suppose to hide options for their own good (especially when users report having used the partition installation with no problem).

Eric

my toughts: 1) general rule: don't prevent users from doing dumb things, it also prevents doing them from smart things. it's not our job to impose methods or configurations on users (although we can and should make recommendations) AIF is an "enabler", it should enable users to set up their system how they want it. So even if we are aware that installing grub in partitions can sometimes give issues, that's not a reason to make it extra hard for the user to do it, because apparently it does work for some people. We should just put a recommendation in the selection menu to prefer the device itself instead of a partition, and that the grub install might fail if you do it in a partition. 2) saying "if you want this, do it manually" defeats the point. 3) I understand Thomas' points, but in reality, I agree that having multiple bootloaders (i.e. one in mbr, one in partition), can make it easier to deal with distro's that happily auto-rewrite bootloader or bootloader configs. 4) I disagree with the "Listing all the block devices and partitions becomes hard to read." argument. Anyone who wants to install Arch should be at the very least mentally capable to deal with such a list.

Dieter

okay so i'll change aif again so that you can install grub on a partition, though with a note that we don't recommend it. Btw, does anyone know if you can install grub on a blockdevice (full disk/partition/DM device) which is part of an lvm/softraid setup? Dieter

C Anthony Risinger

24 Dec 24 Dec

2:16 a.m.

I use a similar setup at home (gpt/grub2 -> mdraid-> lvm2). Since I use GPT the booting is different, but I believe the first 1ehm-eye-bee is skipped -- I install the BIOS-GPT piece of grub2 to both disks in my RAID. AFAIK, most tools/schemes/standards following BIOS+MBR simply avoid that area entirely. C Anthony On Dec 23, 2011 12:25 PM, "Dieter Plaetinck" wrote:

...

On Fri, 16 Dec 2011 13:14:49 +0100 Dieter Plaetinck wrote:

...
On Fri, 16 Dec 2011 09:34:57 +0000 Eric Fernandez wrote:

...
2011/12/16 Matthew Gyurgyik :

...
I agree with Thomas.

1.) There are better alternatives to installing grub on a partition (see Thomas' mail).

3.) Don't use grub-legacy (not supported upstream or maintained). Use syslinux (installer) or grub2 (manually).

I appreciate these comments and gather syslinux might be a better solution than grub, and will look into it.

However, I would like to point out that grub (legacy) is still the recommended bootloader solution in the beginner's guide, and in the installer isos. Furthermore, grub legacy is the one in core, whereas grub2 is in extra. I think that it is prematurate to cripple the installation of a bootloader just because it is not maintained upstream, until we have a better replacement. If really grub legacy is bad, then we should phase it out and replace it with a better one, which should be the new default. Why not replace grub legacy with grub2 in the core repository and in the installer?

...
Installing grub to a partition is an uncommon setup and used by few users, Those who really want to install grub to a partition can do so manually.

Well, that is against the KISS principle. The fact it is uncommon is irrelevant for a distro like Arch, which is not suppose to hide options for their own good (especially when users report having used the partition installation with no problem).

Eric

my toughts: 1) general rule: don't prevent users from doing dumb things, it also prevents doing them from smart things. it's not our job to impose methods or configurations on users (although we can and should make recommendations) AIF is an "enabler", it should enable users to set up their system how they want it. So even if we are aware that installing grub in partitions can sometimes give issues, that's not a reason to make it extra hard for the user to do it, because apparently it does work for some people. We should just put a recommendation in the selection menu to prefer the device itself instead of a partition, and that the grub install might fail if you do it in a partition. 2) saying "if you want this, do it manually" defeats the point. 3) I understand Thomas' points, but in reality, I agree that having multiple bootloaders (i.e. one in mbr, one in partition), can make it easier to deal with distro's that happily auto-rewrite bootloader or bootloader configs. 4) I disagree with the "Listing all the block devices and partitions becomes hard to read." argument. Anyone who wants to install Arch should be at the very least mentally capable to deal with such a list.

Dieter

okay so i'll change aif again so that you can install grub on a partition, though with a note that we don't recommend it.

Btw, does anyone know if you can install grub on a blockdevice (full disk/partition/DM device) which is part of an lvm/softraid setup?

Dieter

C Anthony Risinger

2:20 a.m.

On Dec 23, 2011 8:16 PM, wrote:

...

I use a similar setup at home (gpt/grub2 -> mdraid-> lvm2). Since I use

GPT the booting is different, but I believe the first 1ehm-eye-bee is skipped -- I install the BIOS-GPT piece of grub2 to both disks in my RAID.

...

AFAIK, most tools/schemes/standards following BIOS+MBR simply avoid that

area entirely. ... my bad ... prob my second top-post of my life ... I usually copy paste the message inline since I'm on a mobile, but I forgot that time. Please forgive my transgression, kind and just rulers of the list! C Anthony

Dieter Plaetinck

9:22 a.m.

On Fri, 23 Dec 2011 20:20:15 -0600 C Anthony Risinger wrote:

...

On Dec 23, 2011 8:16 PM, wrote:

...
I use a similar setup at home (gpt/grub2 -> mdraid-> lvm2). Since I use

GPT the booting is different, but I believe the first 1ehm-eye-bee is skipped -- I install the BIOS-GPT piece of grub2 to both disks in my RAID.

...
AFAIK, most tools/schemes/standards following BIOS+MBR simply avoid that

area entirely.

... my bad ... prob my second top-post of my life ...

I usually copy paste the message inline since I'm on a mobile, but I forgot that time. Please forgive my transgression, kind and just rulers of the list!

C Anthony

was this supposed to be an answer to my question? it's really not clear what your point is. also what is an 1ehm-eye-bee? Dieter

C Anthony Risinger

10:52 a.m.

On Sat, Dec 24, 2011 at 3:22 AM, Dieter Plaetinck wrote:

...

was this supposed to be an answer to my question? it's really not clear what your point is.

you asked if <insert list of three examples> could be done, i stated i used one of them *right now* ... i was indirectly implying it could be done and offering it forth as a partial answer. of course, i meant grub could be independently/safely installed to each raw device _backing_ a softraid ... but maybe i misinterpreted your 18 words, and you were reeeeally asking if grub could be installed on a blockdevice _resulting_ from the softraid assembly (or, for example, the creation of an LV), in which case the answer is also yes, because virtual machines do exactly this when passed an LV or any other block device (or raw file/etc) for use as a rootfs. does it make sense, generally, at install time, via AIF or any other? not in any useful way i'm aware; BIOS certainly won't find it -- maybe thru some crazy chainload from hell, idk -- but it *could* be safely done, in my understanding. quite frankly, i'm fairly certain you can go right ahead and install grub to whatever you want ... be a normal device, or a partition derived from kpartx scanning a loopback mounted file. i was simply non-authoritatively stating that every tool/scheme/standard/etc i've used from your examples and beyond appear to avoid clobbering the MBR, and i assumed you were speaking of the MBR as that is where the grub would reside ... unless we are talking about UEFI booting here, in which case the (required?) GPT layout sorta guarantees a place for bootloaders? soo ... maybe it's not really clear what your question is? to me, anyway. an entire block device formatted with an FS might be problematic -- IIRC btrfs has an unconditional gap at the start of the FS -- i'm not 100% on that, and i have no idea about other FS -- even `mkswap` will preserve the MBR unless your forcibly tell it otherwise. seems like the "correct" answer could vary, with a heavy lean toward "yes'm, it be ok". alas, if the preceding messages were completely useless in addressing your question, my apologies, for our time is lost forever :-( ... ever ... ever .... [ever] ... [ever] ... [...]

...

also what is an 1ehm-eye-bee?

my overly-exaggerated-and-ultimately-ill-fated attempt at expressionless, text-powered humor ... along with a general desire to avoid being pounced. http://mailman.archlinux.org/pipermail/arch-releng/2011-November/002255.html ... maybe we should start over. Howdy partna! i'm fairly new round these parts, but y'all seem like a nice crew to hang with. -- C Anthony

Dieter Plaetinck

11:24 a.m.

On Sat, 24 Dec 2011 04:52:16 -0600 C Anthony Risinger wrote:

...

On Sat, Dec 24, 2011 at 3:22 AM, Dieter Plaetinck wrote:

...
was this supposed to be an answer to my question? it's really not clear what your point is.

you asked if <insert list of three examples> could be done, i stated i used one of them *right now* ... i was indirectly implying it could be done and offering it forth as a partial answer. of course, i meant grub could be independently/safely installed to each raw device _backing_ a softraid ...

I want to know if you can install grub to _one_ blockdevice backing a device mapper device (softraid/lvm). You installed grub2 to both.

...

unless we are talking about UEFI booting here, in which case the (required?) GPT layout sorta guarantees a place for bootloaders?

at this point no, but GPT/UEFI support will need to be added at some point. to explain where my question is coming from: find_usable_blockdevices() currently always excludes: (1) disks which are partitioned (but their partitions are returned) (2) blockdevices which are part of softraid/lvm devices To give users more possibilities to install grub I'm adding an argument to this function to optionally also return devices in (1), but while I'm at it, I started wondering about (2). I know some people install grub in some weird places, so if this is technically possible and "okay" I might just as well allow this too. Dieter

Eric Fernandez

5 Jan 5 Jan

10:21 a.m.

2011/12/23 Dieter Plaetinck :

...

okay so i'll change aif again so that you can install grub on a partition, though with a note that we don't recommend it.

Btw, does anyone know if you can install grub on a blockdevice (full disk/partition/DM device) which is part of an lvm/softraid setup?

Dieter

Many thanks Dieter. Eric Fernandez

Keshav P R

16 Dec 16 Dec

1:09 p.m.

On Fri, Dec 16, 2011 at 15:04, Eric Fernandez wrote:

...

2011/12/16 Matthew Gyurgyik :

...
I agree with Thomas.

1.) There are better alternatives to installing grub on a partition (see Thomas' mail).

3.) Don't use grub-legacy (not supported upstream or maintained). Use syslinux (installer) or grub2 (manually).

I appreciate these comments and gather syslinux might be a better solution than grub, and will look into it.

However, I would like to point out that grub (legacy) is still the recommended bootloader solution in the beginner's guide, and in the installer isos. Furthermore, grub legacy is the one in core, whereas grub2 is in extra. I think that it is prematurate to cripple the installation of a bootloader just because it is not maintained upstream, until we have a better replacement. If really grub legacy is bad, then we should phase it out and replace it with a better one, which should be the new default. Why not replace grub legacy with grub2 in the core repository and in the installer?

I suggest someone should replace grub-legacy with syslinux as the recomended bootloader in the Beginner's Guide (I do have a wiki account but skeptical about editing the "Guide" wiki article myself). There is already a bug report to remove grub-legacy from base https://bugs.archlinux.org/task/26187 . But if you really want people to stop using grub-legacy (which is logical given that it is surviving with the help of many patches and still doesn't support many newer technologies like GPT, BTRFS etc.), then you should stop providing "grub" as an option in AIF and force them to do it manually similar to grub2, and then drop it from core. Grub2 is not KISS, but technically much better than grub-legacy (upstream considers grub2 1.99 to be more stable than grub-legacy 0.97 minus the patches), with support of virtually all the newer technologies out there. It takes a lot of work to make Grub2 work with AIF. Also the upstream is in high flux (even command options are changing between releases). I know this because I am tracking the grub2 bzr development. Even the extra grub2 packages sometimes use bzr snapshots as source to include upstream bug fixes. So instead of bothering about rapidly changing grub2 and dead grub-legacy, I would suggest making syslinux as the default (and for now the only bootloader) in AIF.

...

Installing grub to a partition is an uncommon setup and used by few users,

...
Those who really want to install grub to a partition can do so manually.

Well, that is against the KISS principle. The fact it is uncommon is irrelevant for a distro like Arch, which is not suppose to hide options for their own good (especially when users report having used the partition installation with no problem).

I don't see any issue with this. Sometimes scripting bootloader installation is a pain compared to directly installing manually. Matthew simply pointed out that supporting grub installation to a partition might be difficult from a shell-scripting/automation point of view (which is what happens in the installer) as compared to telling the user to do it manually (this is my opinion, I haven't used grb-legacy to comment on the difficulty of installing it to a partition, I use grub2-bios). He is not hiding anything. Users by themselves should be able to identify if it is possible to install the bootloader to the partition instead of the MBR (in BIOS systems), and should be able to do it themselves. Not everything (read use-cases) can be done by the installer script itself. I did shell scripting for Archboot installer grub2-bios and grub2-uefi support and it is not so simple to install a bootloader, especially when you have very less/minimum user input, as bootloader, firmware and the partitioning scheme are highly integrated and all of them should be considered. For example in case of grub2-bios in MBR it requires atleast 1 MiB gap after the 512-byte MBR gap, while in GPT it requires a 1 MiB bios_grub partition. In case of grub2-uefi (or any UEFI bootloader) a GPT disk with atleast one >=200 MiB FAT32 UEFISYS partition is required. Supporting grub2 in the installer is much more than running grub-install as these pre-requisites should be satisfied for which proper partitioning tools must be used. For both MBR and GPT GNU Parted is better when compared to util-linux sfdisk/cfdisk which support only MBR. Regards. Keshav

Keshav P R

1:15 p.m.

On Fri, Dec 16, 2011 at 18:39, Keshav P R wrote:

...

On Fri, Dec 16, 2011 at 15:04, Eric Fernandez wrote:

...
2011/12/16 Matthew Gyurgyik :

...
I agree with Thomas.

1.) There are better alternatives to installing grub on a partition (see Thomas' mail).

3.) Don't use grub-legacy (not supported upstream or maintained). Use syslinux (installer) or grub2 (manually).

I appreciate these comments and gather syslinux might be a better solution than grub, and will look into it.

However, I would like to point out that grub (legacy) is still the recommended bootloader solution in the beginner's guide, and in the installer isos. Furthermore, grub legacy is the one in core, whereas grub2 is in extra. I think that it is prematurate to cripple the installation of a bootloader just because it is not maintained upstream, until we have a better replacement. If really grub legacy is bad, then we should phase it out and replace it with a better one, which should be the new default. Why not replace grub legacy with grub2 in the core repository and in the installer?

I suggest someone should replace grub-legacy with syslinux as the recomended bootloader in the Beginner's Guide (I do have a wiki account but skeptical about editing the "Guide" wiki article myself). There is already a bug report to remove grub-legacy from base https://bugs.archlinux.org/task/26187 . But if you really want people to stop using grub-legacy (which is logical given that it is surviving with the help of many patches and still doesn't support many newer technologies like GPT, BTRFS etc.), then you should stop providing "grub" as an option in AIF and force them to do it manually similar to grub2, and then drop it from core.

Grub2 is not KISS, but technically much better than grub-legacy (upstream considers grub2 1.99 to be more stable than grub-legacy 0.97 minus the patches), with support of virtually all the newer technologies out there. It takes a lot of work to make Grub2 work with AIF. Also the upstream is in high flux (even command options are changing between releases). I know this because I am tracking the grub2 bzr development. Even the extra grub2 packages sometimes use bzr snapshots as source to include upstream bug fixes.

So instead of bothering about rapidly changing grub2 and dead grub-legacy, I would suggest making syslinux as the default (and for now the only bootloader) in AIF.

...
Installing grub to a partition is an uncommon setup and used by few users,

...
Those who really want to install grub to a partition can do so manually.

Well, that is against the KISS principle. The fact it is uncommon is irrelevant for a distro like Arch, which is not suppose to hide options for their own good (especially when users report having used the partition installation with no problem).

I don't see any issue with this. Sometimes scripting bootloader installation is a pain compared to directly installing manually. Matthew simply pointed out that supporting grub installation to a partition might be difficult from a shell-scripting/automation point of view (which is what happens in the installer) as compared to telling the user to do it manually (this is my opinion, I haven't used grb-legacy to comment on the difficulty of installing it to a partition, I use grub2-bios). He is not hiding anything. Users by themselves should be able to identify if it is possible to install the bootloader to the partition instead of the MBR (in BIOS systems), and should be able to do it themselves.

Not everything (read use-cases) can be done by the installer script itself. I did shell scripting for Archboot installer grub2-bios and grub2-uefi support and it is not so simple to install a bootloader, especially when you have very less/minimum user input, as bootloader, firmware and the partitioning scheme are highly integrated and all of them should be considered. For example in case of grub2-bios in MBR it requires atleast 1 MiB gap after the 512-byte MBR gap, while in GPT it requires a 1 MiB bios_grub partition. In case of grub2-uefi (or any UEFI bootloader) a GPT disk with atleast one >=200 MiB FAT32 UEFISYS partition is required. Supporting grub2 in the installer is much more than running grub-install as these pre-requisites should be satisfied for which proper partitioning tools must be used. For both MBR and GPT GNU Parted is better when compared to util-linux sfdisk/cfdisk which support only MBR.

I also want to point out the grub2 upstream does not recommend (but supports) installing grub2 to a partition. I don't whether the same applies to grub-legacy. Syslinux by itself is simply installed to a partition with a small code in the MBR which chainloads the syslinux partition. Syslinux does not access files outside the partition in which it was instakked (exceot maybe when chainloading using chain.c32), so ideally grub-legacy in a partition can be replaced by syslinux (minus the MBR code). Users who want a bootloader that can access (directly) files from multiple partitions like grub-legacy does should go for grub2 as syslinux does not support that. Regards. Keshav

Eric Fernandez

2:19 p.m.

2011/12/16 Keshav P R :

...

I also want to point out the grub2 upstream does not recommend (but supports) installing grub2 to a partition.

But is that on a technical basis (like this fails 50% of the time) or just a warning: ok, the feature is there, but its support is not a priority. I never had any issue with grub on a partition, and if I chose to use it, I accept this is my responsibility.

...

I don't whether the same applies to grub-legacy. Syslinux by itself is simply installed to a partition with a small code in the MBR which chainloads the syslinux partition. Syslinux does not access files outside the partition in which it was instakked (exceot maybe when chainloading using chain.c32), so ideally grub-legacy in a partition can be replaced by syslinux (minus the MBR code). Users who want a bootloader that can access (directly) files from multiple partitions like grub-legacy does should go for grub2 as syslinux does not support that.

Regards.

Keshav

The problem is that you cannot chainload syslinux from grub2, as far as I could read on forum discussions this year. So if I have grub2 in the MBR (and for some reason cannot change it), then syslinux is not useable. Eric

Keshav P R

3:25 p.m.

On Fri, Dec 16, 2011 at 19:49, Eric Fernandez wrote:

...

2011/12/16 Keshav P R :

...
I also want to point out the grub2 upstream does not recommend (but supports) installing grub2 to a partition.

But is that on a technical basis (like this fails 50% of the time) or just a warning: ok, the feature is there, but its support is not a priority. I never had any issue with grub on a partition, and if I chose to use it, I accept this is my responsibility.

It is due to the fact that installing to a partition involves storing the sector/block lists of core.img in order to locate it. Since in many filesystems the file sector locations change, this way of booting (using sector/block lists of core.img) to locate the file may fail anytime. Actually the same issue is with syslinux in which ldlinux.sys sector locations should not change. Otherwise it will fail to boot. To ensure this happens, syslinux sets the immutable attribute on ldlinux.sys but this flag may not work with all the partitions. For more info read https://wiki.archlinux.org/index.php/GRUB2#Install_to_Partition_or_Partition....

...

...
to grub-legacy. Syslinux by itself is simply installed to a partition with a small code in the MBR which chainloads the syslinux partition. Syslinux does not access files outside the partition in which it was instakked (exceot maybe when chainloading using chain.c32), so ideally grub-legacy in a partition can be replaced by syslinux (minus the MBR code). Users who want a bootloader that can access (directly) files from multiple

...
like grub-legacy does should go for grub2 as syslinux does not support

I don't whether the same applies partitions that.

...
Regards.

Keshav

The problem is that you cannot chainload syslinux from grub2, as far as I could read on forum discussions this year. So if I have grub2 in the MBR (and for some reason cannot change it), then syslinux is not useable.

Eric

Yes, there seems to be some issue chaninloading syslinux from grub2. We don't know where the issue is (grub2 or syslinux). But grub2 is so feature-rich, if you have grub2 in the MBR, you do not need syslinux at all (even if you are using multibooting across different discs with different partitioning schemes). Regards. Keshav

Eric Fernandez

3:43 p.m.

2011/12/16 Keshav P R :

...

It is due to the fact that installing to a partition involves storing the sector/block lists of core.img in order to locate it. Since in many filesystems the file sector locations change, this way of booting (using sector/block lists of core.img) to locate the file may fail anytime. Actually the same issue is with syslinux in which ldlinux.sys sector locations should not change. Otherwise it will fail to boot. To ensure this happens, syslinux sets the immutable attribute on ldlinux.sys but this flag may not work with all the partitions. For more info read https://wiki.archlinux.org/index.php/GRUB2#Install_to_Partition_or_Partition....

Thank you for the information.

...

Yes, there seems to be some issue chaninloading syslinux from grub2. We don't know where the issue is (grub2 or syslinux). But grub2 is so feature-rich, if you have grub2 in the MBR, you do not need syslinux at all (even if you are using multibooting across different discs with different partitioning schemes).

Regards.

Keshav

The problem is with various distributions that rewrite the grub menu when their kernel is updated. This can become a maintenance issue. Separating the bootloaders in a multiboot config is easier and cleaner in my opinion. Furthermore, chainloading is inevitable with BSD or Windows (as explained in the Arch wiki), so this should be supported by GRUB devs. Kind regards, Eric

Heiko Baums

2:03 p.m.

Am Fri, 16 Dec 2011 18:39:49 +0530 schrieb Keshav P R :

...

I suggest someone should replace grub-legacy with syslinux as the recomended bootloader in the Beginner's Guide (I do have a wiki account but skeptical about editing the "Guide" wiki article myself).

This should only be done if and only if syslinux can completely replace grub-legacy. This is not the case until it doesn't support multiboot systems. Chainloading of different linux distros from different partitions is not possible in syslinux as far as I know. If syslinux will hopefully once support multiboot systems I'll second this. And that grub-legacy is not developed anymore by upstream doesn't mean that it doesn't work anymore. For me it's still stable and has more features than syslinux. Heiko

Keshav P R

3:18 p.m.

On Fri, Dec 16, 2011 at 19:33, Heiko Baums wrote:

...

Am Fri, 16 Dec 2011 18:39:49 +0530 schrieb Keshav P R :

...
I suggest someone should replace grub-legacy with syslinux as the recomended bootloader in the Beginner's Guide (I do have a wiki account but skeptical about editing the "Guide" wiki article myself).

This should only be done if and only if syslinux can completely replace grub-legacy. This is not the case until it doesn't support multiboot systems. Chainloading of different linux distros from different partitions is not possible in syslinux as far as I know.

If syslinux will hopefully once support multiboot systems I'll second this.

And that grub-legacy is not developed anymore by upstream doesn't mean that it doesn't work anymore. For me it's still stable and has more features than syslinux.

Heiko

Well, it may work in your system but does not do so properly in many systems (newer and older both). I agree syslinux is not recommended for multiboot but grub-legacy might be (is?) a maintenance burden for the devs (both the package and in the installer). This decision has to be taken by the devs. If they choose to support it, then threads like this pop up now-and-then asking for a specific feature to be added/dropped/modified and they haave to fix the package/code themselves. If they don't support, its upto the user to find out how to do it. But the truth is grub-legacy is deprecated and not recommended, and the upstream simply refuses to fix any issue or even give advice/suggestions on grub-legacy. Regards. Keshav

Heiko Baums

9:23 p.m.

Am Fri, 16 Dec 2011 20:48:54 +0530 schrieb Keshav P R :

...

Well, it may work in your system but does not do so properly in many systems (newer and older both).

I haven't heard, yet, that grub-legacy doesn't work on some systems.

...

I agree syslinux is not recommended for multiboot but grub-legacy might be (is?) a maintenance burden for the devs (both the package and in the installer).

I don't think so. And grub-legacy has some more advantages over syslinux. It works with a lot more filesystems. Syslinux can only boot from ext2/3/4 and btrfs, but e.g. not from reiserfs. Don't get me wrong. From what I saw I like syslinux principally, and I would prefer it on singleboot systems or on dualboot systems with one Linux and one Windows installation. But as long as these flaws aren't fixed (multiboot and supporting every filesystem) syslinux is just not a replacement for grub. I don't know grub2, but I only read bad things about it so far, like unstable, complicated to configure etc.

...

This decision has to be taken by the devs. If they choose to support it, then threads like this pop up now-and-then asking for a specific feature to be added/dropped/modified and they haave to fix the package/code themselves. If they don't support, its upto the user to find out how to do it.

Do you really think it's the best idea to pin this on the users? Not every user - not even Arch users - are developers and can do this. And as long as grub-legacy is needed for multiboot systems it just can't be removed from [core] and the install CD, and just has to be supported. Why can't you just let the user decide which bootloader he wants to install like it is currently done by AIF? And, btw., the last very long discussion ended in not having a default bootloader but provide both grub-legacy and syslinux parallel in AIF. That was a decission made by the devs.

...

But the truth is grub-legacy is deprecated and not recommended, and the upstream simply refuses to fix any issue or even

No, the truth is that grub-legacy is deprecated, but not unrecommended. I don't know the Beginner's Guide anymore, it's long ago that I read it. But if there has to be changed anything about the bootloaders, both bootloaders (grub-legacy and syslinux) should be described with all of their advantages and disadvantages with an explanation about when it's best using the one or the other. But mentioning syslinux as the preferred one is simply not the right way. Heiko

4494

Age (days ago)

4515

Last active (days ago)

List overview

Download

26 comments

9 participants

participants (9)

C Anthony Risinger
Desmond Cox
Dieter Plaetinck
Eric Fernandez
Gerardo Exequiel Pozzi
Heiko Baums
Keshav P R
Matthew Gyurgyik
Thomas Bächler