It would appear that on Jun 12, Heiko Baums did say:
Am Sat, 11 Jun 2011 23:07:00 -0400 schrieb "Joe(theWordy)Philbrook" <jtwdyp@ttlc.net>:
Actually It's been a long time since I had actual boot failures with Arch... And if memory serves it wasn't the updated kernels fault, though I no longer remember what I'd done...
You see, those cases in which a kernel update leads to a boot failure are very rare. ;-)
I myself never doubted that. It's one of the reasons why it's currently my default boot choice. But as I've long been on a shoe string budget that does not allow me to be very selective with my hardware, I can't always be sure that my hardware won't be incompatible with some future change. Sometimes I manage to find a deal on used equipment. But I can rarely afford to be choosy. My current desktop was a gift from my brother in law who had just upgraded to something newer.
And Arch Linux kernels are usually tested in [testing] and are only moved to [core] if there are no bigger issues found.
And I think they do a pretty durned good job of it too...
Well I call it grub legacy because that's what gnu.org is calling it now...
That's what it's called.
According to them the old grub has been replaced with a new version. Though I don't see it as an improvement. I think the only Distro I've got installed that really likes "grub 2" is Ubuntu, But since I didn't let it use ext4, I can still even boot that with the classic grub. ☻
Which bootloader you need depends on your installation and hardware, not on the distro. There are at least 3 bootloaders (grub legacy, grub2 and syslinux) which have different capabilities and can't easily be replaced in any case. But all of them can handle ext4.
Hmmnnn... Ah yes I see now, there have been patches etc... since I last looked at it. I notice that the instructions to use the patched ubuntu grub to boot an ext4 system seems to require adding the kernel option: rootfstype=ext4 Would that be required with the grub installed to Arch as well? I also note that: https://ext4.wiki.kernel.org/index.php/Ext4_Howto Says something about a Google Summer of Code project (from opensuse) under the topic of "Booting from an ext4 filesystem" and that it also mentioned that "Ubuntu 9.04 and later includes a patch" So I'm thinking that I might which version of grub I use might make a difference...
I guess you would either call it just a "grub partition" Or perhaps you would have said "boot partition" without specifying which boot loader is installed there.
I guess you meant the /boot partition. ;-)
It is not that uncommon among multi-Linux-Distro, multi-booters to have a separate bootloader installed to the MBR from the ones each distro installed to their root partitions. Though the others I've heard about usually just select the appropriate chainloader entry for the Linux they want to boot, which in turn usually has a very short timeout before it automatically boots it's default entry.
I myself rarely bother with the chainloader entries. They are mostly only there in case I goof when I edit the entries I normally boot from. This configuration also makes it easy to use a supergrub disc in the event that my normal boot partition gets corrupted as each installed Linux has it's own boot loader so all I'd need to tell supergrub is to boot the appropriate partition...
I would completely remove the chainloaders.
Make one /boot parition for every distro, but only install one bootloader from your main distro into the MBR. Don't let the other distros install a bootloader and just configure the one bootloader to boot the other distros, too. That's the easiest way which should always work.
Yeah, if I wanted any distro to have control over the booting of the others. I let each distro maintain it's own (root partition based) grub installation so that I can simply (and easily) see what they think is the best way to boot their Linux. Sometimes they auto detect the other Linux. and sometimes the grub entries they add for the other Linux even work. But I like to keep control over the primary boot loader that I like to be able to chain load their boot loaders in case I want to confirm that some issue I'm having with one isn't a goof in my menu.lst configuration. Also,this way I don't need to bother maintaining fallback/recovery/nurse/etc... entries, If I need them I just use the ones their package manager installed to their chainloaded bootloader...
Btw., if you let every distro install a bootloader into the MBR, the previously installed one will be overwritten. There won't be two different bootloaders in the MBR.
It's been a long time since I had to set up my /boot partition. I'm not even sure which distro I used to do so. But basically I started with all the distro's using the /boot of their root partition, and all but one configured to install it to the first superblock of that partition. Then I tweaked the one I let install to the mbr until I was happy with how it worked for all the distros... Then I mounted the intended /boot partition on /mnt. Next I did: "cd /mnt" then a: "ln -s . boot, and copied everything from /boot to /mnt, edited the /mnt/grub/menu.lst so that where there were lines that said things like: root (hd0,6) it now said: root (hd0,1) next I unmounted the intended /boot from /mnt and mounted it on top of /boot and reinstalled grub to the MBR. after which I unmounted it which exposed the original contents of /boot, and reinstalled that one to the superblock. From them on I had a seemingly stand alone /boot partition that none of my Linux mess with even when there is a kernel upgrade, And all of my Linux have their own functional bootloader installed to their superblocks... I'm not sure, But I think that I might have to redo this if I should ever uninstall whichever Distro it was I used to do this. But other than that it seams to work great...
Depending on what you are doing with your multi-boot system, you probably should consider using virtualization.
Then what happens if I hose the system hosting the others??? My, time flies... Gotta go. SeeYa -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp@ttlc.net>>