It would appear that on Jun 11, Heiko Baums did say: > Am Sat, 11 Jun 2011 12:40:36 -0400 > schrieb "Joe(theWordy)Philbrook" <jtwdyp@xxxxxxxx>: > > > OK so lets see if I understand... I already maintain a manually > > configured grub legacy partition where each of my installed Linux > > have both a chainloader menu entry to whichever grub that Linux has > > installed to /boot on it's root partition, AND a regular menu entry > > that specified the initrd & vmlinuz that I routinely copy to MY grub > > partition shortly after any kernel upgrade... > > > > So in the event that the new kernel was effectively broken that on MY > > hardware neither the chainloaded Arch nor the arch fallback menu > > entries were able to boot, I could then boot the not yet replaced > > last known good kernel and initrd directly from MY grub and then from > > a console root prompt: > > > > «assuming that the following tar.xz file is still there» > > > > pacman -U /var/cache/pacman/pkg/kernel26-2.6.38.6-2-x86_64.pkg.tar.xz > > > > And when I next reboot using the chainloader to where arch has it's > > grub installed, and selected "Arch Linux" it should boot that kernel > > with it's initrd AND it's modules would be where it expects them with > > the result that it should be as fully functioning as it was before > > pacman upgraded from it??? > > Principally, yes. Thanks! > But are you really sure that it is the updated kernel package and not > your grub installation or config which causes your boot failures? 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... However I have experienced other Linux that no longer booted properly upon kernel upgrades... When my grub installation fails to properly boot one of my Linux, I immediately use the chainloader entry to get that distro's own grub. Having a back-up in case a new kernel doesn't work for me just feels like the right thing to do. And now I know (and will have notes) how to resolve that problem in the event that an Arch kernel upgrade ever does fail me. Thanks again! > Your description sounds pretty weird to me. Above all, what is a grub > legacy partition and why do you need chainload in grub legacy for > booting a Linux kernel? And are you sure that grub legacy is the right > bootloader for your uefi mainboard? Well I call it grub legacy because that's what gnu.org is calling it now... http://www.gnu.org/software/grub/grub-legacy.en.html http://www.gnu.org/software/grub/manual/html_node/Changes-from-GRUB-Legacy.html «Which incidentally is the kind of grub that Arch is using on my PC» 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. ☻ 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. 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... -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@xxxxxxxx>>
