On 10 Oct, Grant Parnell wrote:
> Interesting approach. In short I think you'll find GRUB more flexible in
> the long run because you can fixup your mistakes at boot time thanks to
> the command shell. However I have a lilo solution for you too.
I think you're right, once I become adept at grub.
> 1) Your boot partition needs to be first, it should be within the first
> 512 cylinders to be sure of working with old BIOSes. Both lilo and GRUB
> need to be loaded by the BIOS. Lilo uses a map of sectors to load the
> kernel and initrd files, GRUB however understands filesystems and can
> reach beyond the first 512 cylinders (once the stages are loaded) - ie it
> can load kernel and initrd from the outer limits or other partitions.
1st partition is a 200MB primary, currently pretty empty.
> 2) When installing distro's don't have them make /boot a separate
> partition. Have them make a boot floppy to get you up and running the
> first time as a precaution. That way they'll write their own version of
> /boot.
Good tip, thanks.
> 3) Manually format & populate the real /boot partition and mount as say
> /masterboot then put in copies of /etc/fstab and /etc/lilo.conf into
> /masterboot/etc/ and /boot/grub/ into /masterboot/grub/
Uh huh.
> 4) Use lilo -r /masterboot to update lilo with the new configuration. This
> may require copying bits of lilo and libraries it needs because of the
> chroot operation. Alternately if using GRUB just append bits to the
> /masterboot/grub/menu.lst (alias grub.conf) file.
Okay, ldd will be my friend there I suppose.
Or with grub, you mean I should build up a single menu.lst file that
describes all the bootable images off all the partitions, if I'm
understanding you. (Sounds fine.)
> 5) In the distro under test, symlink /etc/lilo.conf to
> /masterboot/lilo.conf if you're confident it won't stuff it up. Similarly
> link /boot/grub/menu.lst and /boot/grub/grub.conf to
> /masterboot/grub/menu.lst and /masterboot/grub/grub.conf
Will that help? It's looking like lilo can't boot images off the big,
2nd drive.
> 6) I don't know if you can get away with symlinking /etc/fstab though,
> probably not because the system won't be able to find it when starting up
Correct. That would be doomed to failure! :-)
> - however you could add to your /etc/rc.d/rc.local in each distro to copy
> /masterboot/etc/fstab to 'update' it, if you're confident that won't mess
> up the distro under test. Also possibly in /etc/rc6.d/ and /etc/rc0.d
> appropriate links to copy a changed /etc/fstab back to
> /masterboot/etc/fstab before the system unmounts /masterboot.
Um, that sounds scary. I was planning to wear the pain of (manually)
making the /etc/fstab in each distro, as similar as I could and just
have to change one line. It's a little painful, but a safe option
I think.
> As a sideline... here's how I install GRUB onto alternate boot media.
> mke2fs /dev/hdb1
> mount /dev/hdb1 /masterboot
> mkdir /masterboot/grub
> cp -a /usr/share/grub/i386-redhat/* /masterboot/grub/
> cp /boot/grub/grub.conf /masterboot/grub/
> edit the new grub.conf file as desired
> check that menu.lst is symlinked to it
> sync
> grub
> grub> find /grub/grub.conf
> (hd0,0)
> (hd1,0) {ours}
>
> grub> root (hd1,1)
> Filesystem type is ext2fs, partition type 0x83
>
>
> grub> setup (hd1)
> Checking if "/boot/grub/stage1" exists... no
> Checking if "/grub/stage1" exists... yes
> Checking if "/grub/stage2" exists... yes
> Checking if "/grub/e2fs_stage1_5" exists... yes
> Running "embed /grub/e2fs_stage1_5 (hd1)"... 16 sectors are embedded.
> succeeded
> Running "install /grub/stage1 (hd1) (hd1)1+16 p (hd1,0)/grub/stage2
> /grub/grub.conf"... succeeded
> Done.
Thanks. That looks very similar to the recipe I followed (if I had
copied in the grub files to go with it). Though looking just now (a
bit silly, after midnight), I see that the grub directory has grub
files dated from May 1st 2002 (from the mandrake 9.1 install, I think),
that is probably causing my problem.
Um, no. Ah well, it's late and I think I'll try again on Wednesday.
> Naturally, if you intend to boot this hard drive you'd need to a) make it
> the master IDE device or b) adjust the BIOS to boot off it (some can, some
> can't, some mess with your device numbers - ie swap hd0 with hd1 but
> /dev/hda and /dev/hdb are still correct). This procedure also works with
> other removable media such as USB keys, compact flash and external drives.
Uh oh. The big 2nd drive is the slave drive, currently.
Do you mean physically swap hd0 with hd1? So that what was /dev/hda
becomes /dev/hdb, and vice versa? I thought it was more a function of
lilo or grub as to whether they can boot from the drive or not: but
where lilo needs the bios to read the kernel image, etc., grub is smart
enough to know how to do that itself (as well as understand a few
filesystems)?
Have I got that wrong?
Thanks, Grant, you've given me lots to think about, anyway.
luke
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
