Ha! That's quite clever, a nice way to compartmentalize/abstract the boot process. But you still have the fundamental problem of hardcoded sectors, you're just moving them down a level in the hierarchy. It makes it harder for any individual OS to screw up the others, but it's still pretty easy to hose up any of the OSes you have installed. And for the typical, single-OS case, I'm not sure you're actually gaining anything from this approach. Am I missing something? You're rewriting the PBR, instead of the MBR, but I don't see that this is particularly useful if you have only one OS?
As I see it, LILO has two big problems: people forget to re-run it after updating kernels (or if the kernel moves on disk), and it can't load any kernel that's not hard-coded in. That is, if you add Kernel B and remove Kernel A (which is stupid, but people do it anyway), and forget to run LILO before rebooting, it's rescue disk time, because LILO has absolutely no way to boot Kernel B. With GRUB, as long as menu.lst got updated, you're good. If you forgot to do that, you're still stuck at the bootloader screen, but you can at least manually boot Kernel B. You have a shovel to dig out of the hole with. It's a pretty intimidating shovel for a newbie, but at least it's something. Another spot where GRUB is extra-useful... Windows NT's bootloader doesn't, as far as I know, chain to PBRs automatically. You have to install LILO or GRUB in the PBR, and then DD the PBR to a file, and then copy the file to a spot where NT's bootloader can see it. Before NTFS write support, this was extra-painful, involving either a floppy or a FAT32 partition somewhere, and a couple of reboots. If you're using GRUB, you only have to do that once, because the boot sector doesn't change. I see LILO's main strengths as being the ability to deal with any filesystem that a big, complex program (the installer) can understand, and ease of installation. I see GRUB's main strengths as being flexibility and resilience against some kinds of user error. But GRUB is much harder to install the first time, largely due to a combination of rather annoying documentation and a fairly poor command-line interface. It offers the same tradeoff that's so common in the open source world... in exchange for more upfront time setting it up, you get lower maintenance and better flexibility. I think a lot of people are probably put off by the primitive installation tools, and never see the strengths of the actual bootloader. Unless I have a really compelling need for some other approach, I always boot from ext3 and use GRUB, and save my exotic filesystem types for non-system partitions. On Soekris hardware with flash drives, I just stick with ext3 period, because the disk is slow as crap anyway, and I'll be trying to hit it as little as possible. Just doesn't seem sensible to carry the extra memory and process load for non-ext3 filesystems when there's so little to be gained. Bill Maas wrote: > Hello Ron, > > [IMHO] in an less confusing and slightly pedantic world, a piece of code > living inside the MBR that can load a partition boot record would be > called a Boot Manager (whether it could load boot sectors from multiple > partitions or not), and the code in the PBR would be called the [OS] > Boot Loader. The BL would hide all OS specifics from the BM, and both > would be handled separately, i.e. would be installed by separate > programs. OpenBSD does this, using fdisk(8) for the MBR code vs. > installboot(8) for the PBR code. > > If you're used to boot loaders like Lilo or GRUB, the OpenBSD > terminology can be quite confusing at first: > > MBR "MBR bootcode" > PBR "first-stage bootstrap" > /boot "second-stage bootstrap" > > "First stage" and "second stage" have different meanings here than with > the average boot loader such as GRUB or Lilo: the FSB can never be > installed in the MBR, because the PBR and MBR code are two different > things. All the MBR code can do, is to load a[n OpenBSD] PBR, and all > that the PBR code does is load "/boot". With most other boot loaders, > the two functionalities are merged into a single piece of code, which > can be installed either in the MBR or the PBR (with Lilo at least, I'm > not familiar enough with GRUB to be certain about that one). By the way, > OpenBSD's second stage boot loader is mildly fs-aware as well, because > it needs to access /etc/boot.conf. > > Anyway, from the BM/BL point of view, GRUB displays the correct > behaviour, and what Lilo does is no less than horrible. At least not > when it is used the way that almost everyone does. But Lilo's maker > wrote a much more modular and very flexible program than the majority of > existing documentation suggests. Here's a Lilo setup that adheres to the > "BM/BL standard", and can be useful if you have more than one Linux > installation on a single disk. > > > Per-partition lilo.conf: > ------------------------------------------------------------------- > boot=/dev/ROOTDEVICE > install=text > map=/boot/map > default=LABEL > > image=/vmlinuz > label=LABEL > read-only > root=/dev/ROOTDEVICE > initrd=/initrd.img > ------------------------------------------------------------------- > > Usage: > - copy the thing to /etc/lilo.conf > - subsitute the keywords with their real values > - run 'lilo' > > > > Global lilo.conf.mbr (example): > ------------------------------------------------------------------- > boot=/dev/sda > map=/boot/map > install=menu > prompt > timeout=80 > ignore-table > password="" > > default=kubu > > # Recovery section > #image=/mnt/MOUNTPOINT/vmlinuz > # label=LABEL > # read-only > # root=/dev/ROOTDEVICE > # initrd=/mnt/MOUNTPOINT/initrd.img > > other=/dev/sda6 > label=kubu > > other=/dev/sda7 > label=ubu > > other=/dev/sda2 > label=rescue > > other=/dev/sda12 > label=puppy > > other=/dev/sda4 > label=obsd > ------------------------------------------------------------------- > > > Here, "kubu", "ubu", "rescue" and "puppy" are all Linuxes, booted from > "other" sections. This will cause the Lilo MBR code to load PBRs i.o. > kernel images. > > The "recovery section" can be used temporarily to make an installation > bootable whose PBR is corrupted or (at install time) not recognized. > > If you store lilo.conf.mbr on a shared partition that is/can be mounted > from all Linux installations, you can run lilo with this config from > each Linux installation with no fuss. > > Usage: > - optional: store lilo.conf.mbr on a shared partition > - Run 'lilo -p -C /path/to/lilo.conf.mbr' (the '-p' is for the password) > > Note that both 'lilo' commands above can be executed from the same > partition without interfering with each other (and also note the speed > with which the MBR code is written..). > > > Advantages: > > - multibooting is set up in a more modular way, and modular == good > after all. > - having bootable code inside each PBR adds an extra recovery option > (it's never a bad idea to install Lilo - or GRUB, possibly - inside > the PBR as well as in the MBR). > - the MBR boot code that is actually executed is small, simple, and > therefore more reliable. > - because all OS-specific data is hidden behind the PBRs, the Lilo MBR > code can be replaced with some other boot manager without problems, > which again makes recovery a lot less trouble. > - a practical advantage: the annoying phase of being warned about files > not found, and subsequently having to mount all Linux partitions and > run lilo again (pffff...), is no longer there. > > And there probably are a few more.. All in all, this setup will make > Lilo run like a very well-behaved Boot Manager / Boot Loader combo. > Almost "Grand and Unified";). > > > Bill > _______________________________________________ Soekris-tech mailing list [email protected] http://lists.soekris.com/mailman/listinfo/soekris-tech
