On Sat, May 29, 2010 at 11:46 PM, Stan Hoeppner <s...@hardwarefreak.com> wrote: > Tom H put forth on 5/28/2010 10:55 PM: >> On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner <s...@hardwarefreak.com> >> wrote: >>> Roger Leigh put forth on 5/28/2010 11:39 AM: >> >>>> For the most part, grub is a vast >>>> improvement over LILO, and except for the odd corner cases which >>>> grub doesn't cover, >>> >>> In what way is it a vast improvement over LILO? I've never had a problem >>> with >>> LILO. It's always "just worked", which is what a bootloader should do. So >>> how exactly would grub be a better choice for me? >> >> The reverse argument can be made too. Both grub1 and grub2 just work. >> Unless you are continually installing dual- and triple-boot this or >> that, you are not going to be changing you config continually no >> matter what bootloader you use and you will therefore not be >> interacting with it that much. So, except for Stephen P's case, what's >> the big deal? > > I frequently roll new kernels from kernel.org source using the Debian > installation method, once every couple of months. I'm very comfortable with > using LILO for this. I've pretty much zero experience with Grub (any > version). If something goes wrong converting from LILO to Grub2, I'm screwed. > And I'll probably have an unwanted and unneeded learning curve while > continuing my current practice of rolling kernels frequently. > > Please don't debate the merits of customs kernels. I have very valid reasons > for doing so. Let's focus on why or why not Grub2 will work for my needs, and > not hose my systems either during the migration from LILO to Grub2, or > installing custom kernels after the fact.
I have absolutely no problem with custom kernels. (What I don't understand is people who jump up and down on various lists when someone says that he/she compiles custom kernels!) I haven't used lilo for nine-ten years but I don't see how adding a custom kernel to grub rather than lilo should affect your kernel compilation. I don't use the Debian tools so after "make install", I run "update-initramfs ..." and "update-grub", and I'm done. I don't see how, if I were using lilo, I would have to follow a different procedure, except for setting editing lilo.conf and running lilo after update-initramfs. Am I missing something? As I said in my previous post, I would install Squeeze's grub2 on a Lenny box and reboot to check that it is working before the upgrade to Squeeze. I have gone through various big changes in OSs, WinNT to Win2k, OS9 to OSX (although I was a Sol-Lin admin too so it wasn't as great a shock as for Mac-only admins [1. see OT anecdote below]), Sol8 to Sol10 and they created more dislocation than a bootloader change. At the risk of sounding like a late-night infomercial (!), a smooth transition from lilo to grub2 is just a question of being positive (the un-unwanted and un-unneeded of above) - and putting in some work (the learning curve of above) of course. grub2 basics--> Setup Although grub2 sources a file in /usr/lib/grub when creating its config, the files that matter are /etc/default/grub and /etc/grub.d/*. You set various variables like the kernel options, the default entry, whether to create entries with "single" appended, ... in /etc/default/grub. When you run update-grub (which is a script that runs "grub-mkconfig -o /boot/grub/grub.cfg"), the grub2 menu's configuration, /boot/grub/grub.cfg, is built by running the scripts in /etc/grub.d/. I don't really like what the /etc/grub.d/ scripts do, so I "chmod 644" them except for the last one, 40_custom, and I write my grub.cfg there. It is a script of the form: cat << EOF my grub2 config EOF so my /boot/grub/grub.cfg ends up exactly like 40_custom except for the first two lines and the last one. The disadvantage of using this method is that I have to add and remove kernels manually to 40_custom, whereas the standard way is that the 00_header, 10_linux, and 30_os-prober scripts populate the grub2 menu automagically. The initial run of update-grub, after you install grub2, will give you a good base to create 40_custom if that is the way that you want to go. Unsurprisingly, since all that a bootloader does is point to and loads an initrd and kernel, /boot/grub/grub.cfg basically looks like lilo.conf (for a reference lilo config file, I am looking at Stephen P's kernel compilation page, which, btw, is included in the documentation of kernel-package) with a different syntax. There are "global options" (default entry, grub root partition, console or gfxterm, timeout, ...) and "per-image options" where menuentry corresponds to label, linux to image, and initrd to initrd. As an added twist, grub2 is modular so both (possibly redundantly but I have never tested this) the global and per-image sections have "insmod" invocations for filesystems, raid, lvm, framebuffer, ... Recovery You only have to net-boot or cd-boot a grub2 install to correct it if its first stage loader in the MBR is dead. If you net-boot or cd-boot to re-write to the MBR, you have to mount and chroot your install and run grub-install to re-populate the grub directories from /usr/lib/grub/i386-pc/ and to re-create grub2's loaders, boot.img and core.img. If grub2's boot.img in the MBR is OK but the next stage, core.img isn't, you're dumped to a "grub rescue" prompt from which you have to identify and set the grub root partition, "insmod /boot/grub/normal.mod" to go the the normal grub prompt, load the kernel and initrd, and boot. (I've been meaning to overwrite core.img with zeroes and reboot to go through the motions but haven't done so yet). If grub2's grub.cfg is missing or incorrect, you are dumped to a grub prompt from which you have to load the kernel and initrd and boot, by passing the same commands as a menuentry stanza does (with tab completion). 1. I was on a night shift with a Mac admin who was teaching himself OSX when v10.2 or v10.3 was first out. He asked me for help because his box had rebooted unexpectedly. He had run a command that he'd found on the net. The command? "rc.boot", OSX's BSD rc script! That is a real learning curve! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiklb9wywfuoxmvnbsngnr-0vqetu4hx64fdw...@mail.gmail.com
