lilo removal in squeeze (or, "please test grub2")
in [Debian]
|
From: Mark on 30 May 2010 18:10 On Sun, May 30, 2010 at 1:50 PM, Stephan Seitz < stse+debian(a)fsing.rootsland.net <stse%2Bdebian(a)fsing.rootsland.net>> wrote: > > I would say, the default bootloader should be grub1, expert installation > can offer grub2 as well. Lilo should be in the distribution as well, so > people can switch after installation. At least for the next release. > > I have a question related to this: recently the screen on a dual boot (XP/Lenny) laptop got busted pretty badly (almost to the point where grub1's blue splash screen menu is not visible at all), and since the primary purpose of this laptop is now to boot to XP to use Netflix's Microsoft Silverlight-based movie player while connected to an hdtv for on-line movie watching, I just booted to Lenny, changed the "default=0" value to "default=3" in /boot/grub/menu.lst so it now boots to XP by default. My limited experience with grub2 in Squeeze didn't appear to have this ability, so what would I have done in this case? Would I be fscked? Thanks, Mark
From: Brian Marshall on 30 May 2010 18:20 On Sun, May 30, 2010 at 03:02:23PM -0700, Mark wrote: > I just booted to Lenny, changed the "default=0" value to > "default=3" in /boot/grub/menu.lst so it now boots to XP by default. My > limited experience with grub2 in Squeeze didn't appear to have this ability, > so what would I have done in this case? Would I be fscked? It's still there, just moved. Edit /etc/default/grub, change GRUB_DEFAULT to 3 and run update-grub. Brian
From: Mark on 30 May 2010 18:20 On Sun, May 30, 2010 at 3:12 PM, Brian Marshall <bmars(a)sdf.lonestar.org>wrote: > On Sun, May 30, 2010 at 03:02:23PM -0700, Mark wrote: > > I just booted to Lenny, changed the "default=0" value to > > "default=3" in /boot/grub/menu.lst so it now boots to XP by default. My > > limited experience with grub2 in Squeeze didn't appear to have this > ability, > > so what would I have done in this case? Would I be fscked? > > It's still there, just moved. Edit /etc/default/grub, change > GRUB_DEFAULT to 3 and run update-grub. > Very helpful, thank you Brian.
From: Andrei Popescu on 30 May 2010 18:30 On Sun,30.May.10, 22:50:44, Stephan Seitz wrote: > On Sun, May 30, 2010 at 07:11:19PM +0200, Sven Joachim wrote: > >The main problem with grub1 is the same as with lilo: there is no > >upstream maintainer, and crucial parts of the code are undocumented > >and not understandable¹. > > But at least grub1 is working in a wider field than grub2. And lilo > is still working, too. Maybe not with the current Debian kernel, but > it works for people building their own kernel. > > >So which bootloader should be the default? Grub1 is also lacking > >important features, albeit different ones than grub2 (e.g. ext4 > >support). > > Maybe, but ext4 support is not really crucial. Simply make /boot ext2. Having /boot on a separate partition for robustness, security or advanced features (encrypted LVM and stuff) is one thing, but having it because the default bootloader doesn't support current (ext4) and future (btrfs) filesystems seems like a hack to me. > I would say, the default bootloader should be grub1, expert > installation can offer grub2 as well. Lilo should be in the > distribution as well, so people can switch after installation. At > least for the next release. Is it just me or does this sound like the KDE3 -> KDE4 debate all over again? Don't get me wrong, I've had my part of headaches with grub2 (I switched quite early), but most are fixed, so grub2 does almost everything *I* need. Also, the config has become so complicated you need another config file (/etc/default/grub) to configure how it will be generated :( I read grub2 is still missing features (like simultaneous display on a serial console and VGA), and it is (still?) incompatible with some software (Stephen's case), but we have to face it: * LILO is not developed anymore * Grub1 is not developed anymore Unless there are people interested in further developing those code bases they will be gone sooner or later. And my feeling (as a non-programmer) is that they have become unmaintainable, or at least it has become too much work compared to writing something from scratch (grub2, extlinux, ...). AFAICT, the only thing that we as users can do (short of putting up bounties) is to push for the missing features to be implemented and the bugs to be fixed. But none of this will happen unless we are at least willing to *test* the new stuff. At least the regulars on this list should know how to recover from an unbootable system, or not? Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
From: Tom H on 31 May 2010 02:10
On Sat, May 29, 2010 at 11:46 PM, Stan Hoeppner <stan(a)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 <stan(a)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-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/AANLkTikLB9wYWFUoxMvNbsngnr-0VQEtU4HX64FDw7Pe(a)mail.gmail.com |