Re: GRUB/LILO

Post #68,764 by rickmoen 12/13/02 5:04:39 PM Reply	Re: GRUB/LILO Scott wrote: Alternatively, I once messed with my boot files before/after reading LILO documentation, shot myself in the foot, and therefore now use a boot manager that allows me to shoot myself in the foot and gracefully recover without rebooting/editing/trying it all again... ;-) I like that. The main problem with lilo isn't with lilo intrinsically, but rather with the usual default configuration: If (like most people) you have a lilo.conf that lacks a fallback stanza for a known-good kernel, it's an accident waiting to happen, the first time you experiment with new kernels or with changed boot configurations. In the worst-case scenario, it's your only computer, one that you dual-boot. You're new to Linux, you've finally mustered up the courage to compile a new kernel, everything seemed to go well, you tried to reboot, and... "LI", followed by a system halt. You're temporarily frozen out of both Linux and your legacy-proprietary OS, until you figure out how to use either a maintenance floppy or a maintenance CD to fix lilo. Which might be easy, except you now have no manpages and no access to /usr/share/doc/, because your one and only system can't boot. Whereas, if you're an experienced user, you have a fallback stanza in lilo, and already know how to do "/sbin/lilo -r /mnt" from a floppy well enough to do it in your sleep. Which means messed-up lilo is a trivial problem if you're experienced, but a traumatic catastrophe if you aren't. Anyhow: The advantage you cite for GRUB amounts to "it can read the filesystem". The attached disadvantage is "it must be able to* read the filesystem": (1) If /boot is even slightly corrupted, you may not be able to boot. This wouldn't faze lilo, because at boot-time it operates solely from memorised physical locations of objects, and doesn't read the filesystem at all. (2) Wish to have /boot on a new and fancy filesystem type that GRUB doesn't yet know how to read? Sorry, you can't. Even use of ReiserFS necessitates the "notail" mount option. Omit that on /boot, and you're likely to have serious problems. (3) Because GRUB not only can read the filesystem but also must do so, you can't leave /boot normally unmounted. All of my systems do the latter, as a (admittedly minor) precaution against root-user mishap. (The /etc/fstab entry has a "noauto" option.) I mount /boot only when updating boot files, then umount it again. So: I have no problem with people preferring GRUB, but they almost invariably are gravitating that way almost entirely because they never used lilo competently. Rick Moen rick@linuxmafia.com If you lived here, you'd be $HOME already.
Post #68,766 by admin 12/13/02 5:10:42 PM Reply	Whether you have a fallback stanza or not It's a timewaster to have to boot the OS just to change the mistake. Current situation: I'm trying to get a particular kernel to work, and doing a LOT of compiling/configuring/rebooting. Several times I've forgotten to add a particular parm I wanted to try or the like. Even with a fallback stanza in lilo, I'd be wasting considerable amounts of time rebooting everytime to fix a mistake. With GRUB, I just edit the menu entry right then and there and boot from it. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #68,767 by drewk 12/13/02 5:16:46 PM Reply	Ahh, the philosophical difference Lilo method seems to favor always being recoverable (assuming you've got the fallback stanza -- is that typical in a Debian install BTW?) at the expense of requiring a little more care from the user. Grub favors more user-friendlyness while doing the install. And when people criticize the Debian install, isn't one of the constant refrains that that is something you almost never have to do? Rick seems to favor the method that will always work, and will accept the minor inconvenience of waiting longer for it to reboot when tweaking kernels, because you don't really do that too often anyway. === Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=38978\|Andrew Grygus]
Post #68,775 by rickmoen 12/13/02 5:44:06 PM Reply	Re: Ahh, the philosophical difference drew wrote: Lilo method seems to favor always being recoverable (assuming you've got the fallback stanza -- is that typical in a Debian install BTW? Last I checked, no. I've been meaning to file a bug in the Debian Bug Tracking System about that, but have been a lazy git. Besides, as you say, it's something one fixes once, almost absent-mindedly, and then never has to worry about again. Re: the rest of your post - nicely stated. Rick Moen rick@linuxmafia.com If you lived here, you'd be $HOME already.
Post #68,800 by kmself 12/13/02 9:36:38 PM Reply	Fallback stanza: yes ...at least through one cycle of kernel updates. vmlinuz and vmlinuz-old are both present. Meaning if you've updated to a new kernel, your old kernel should be available. Note that the vmlinuz & vmlinuz-old symlinks are automatically updated, so with two installs, you're now potentially SOL. In which case, you would want to add a "failsafe" stanza pointing to a known-good kernel and config, preferably booting single-user mode. \r\n\r\n That said, I prefer GRUB for its configurability and realtime recovery features. \r\n --\r\n Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com]\r\n [link\|http://kmself.home.netcom.com/\|http://kmself.home.netcom.com/]\r\n What part of "gestalt" don't you understand?\r\n [link\|http://twiki.iwethey.org/twiki/bin/view/Main/\|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n \r\n Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
Post #68,801 by kmself 12/13/02 9:38:10 PM Reply	Fallback stanza: yes ...at least through one cycle of kernel updates. vmlinuz and vmlinuz-old are both present. Meaning if you've updated to a new kernel, your old kernel should be available. Note that the vmlinuz & vmlinuz-old symlinks are automatically updated, so with two installs, you're now potentially SOL. In which case, you would want to add a "failsafe" stanza pointing to a known-good kernel and config, preferably booting single-user mode. \r\n\r\n That said, I prefer GRUB for its configurability and realtime recovery features. \r\n --\r\n Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com]\r\n [link\|http://kmself.home.netcom.com/\|http://kmself.home.netcom.com/]\r\n What part of "gestalt" don't you understand?\r\n [link\|http://twiki.iwethey.org/twiki/bin/view/Main/\|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n \r\n Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
Post #68,770 by rickmoen 12/13/02 5:33:16 PM Reply	Re: Whether you have a fallback stanza or not Yes, having to reboot a lot of times to test not-quite-working kernels would suck. I've never faced the situation you described. I've had cases where some aspect of my newly compiled kernel was wrong such that it required many recompile cycles to get right, but the kernel was working well enough to support the recompile process. And I've made bonehead errors that rendered the kernel completely unusable (the classics: omit console support; omit support for your HD host adapter), but that took only one fallback reboot, recompile, and reboot to correct. If I had a non-usable kernel that I was trying to fix through iterative boot-attempt cycles, I'd probably install GRUB for the duration, for the reasons you cited. Or VMware. But then I'd switch back to lilo when I was done. Not a huge thing, just a Works for Me[tm] one. Rick Moen rick@linuxmafia.com If you lived here, you'd be $HOME already.
Post #68,773 by admin 12/13/02 5:40:49 PM Reply	VMWare I wish. I've already got Debian running there. :-P Seems the trick is getting this kernel to load on the real box, not the virtual one. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #69,170 by Another Scott 12/16/02 4:13:18 PM Reply	Isn't this a clue? If you can install and run the Debian OS on VMWare and have success, but it fails on the real hardware, then isn't this a clue? How does your hardware differ from what VMWare assumes? Could you have a jumper issue with your HD, or some obscure BIOS setting that Debian isn't liking? Hope this sparks something useful. Good luck! Cheers, Scott.
Post #69,175 by admin 12/16/02 4:26:58 PM Reply	Re: Isn't this a clue? As just noted elsewhere, solved. The initrd was hosed. I need to track down why (Greg intimated that it's a problem with 2.4.19). Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!