[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Grub question...



>>>>> "SD" == Steve Dunham <dunham@cps.msu.edu> writes:

  SD> "Larry 'Daffy' Daffner" <vizzie@mail.airmail.net> writes:
  >> I do hve a small bit of cleverness though - making a GRUB floppy
  >> with an MSDOS filesystem on it. It took a little bit of nosing
  >> around, but it wasn't too bad. I then use that to put a kernel
  >> on, so I can boot up a kernel off the floppy and use a Zip drive
  >> (id 5) as the root FS, just for emergencies. :) Email me if you
  >> want the gory details :)

  SD> It's not that difficult.  (I usually use a raw GRUB disk and
  SD> boot with a kernel and root off of the hard drive.)

I mean with an actual MS-DOS filesystem and grub on the same floppy
:). Sure, it's not too difficult to do, but I was generally pretty
clueless on how, and it's not documented at all.

  SD> Sorry about not updating the package, I'm trying to decide how
  SD> to handle upgrades, because it will change the stage2 file.
  SD> (Hence the boot sector needs to be reinstalled.)

Well, it's working fine for me. No urgent need to mess with it at the
moment :) One suggestion I would like to make, is to install it into
/usr/lib/grub/stage{1,2} and let a setup program copy them to the
appropriate places - That way, the 'pure' copies will always be
available if needed.

  SD> My current idea:

  SD>  * make grubinst more flexible, so the user can specify stage1,
  SD> stage2, menu file, and install location.

Do you really need to record the location of the menu file? Isn't it
automatically assumed to be in the same directory as the stage2? I'm
not entirely sure HOW it works, just that it does :)

Just make sure it knows how to install itself on the root filesystem -
I like to have it set up that way just in case.

  SD>  * store the command line for "grubinst" somewhere, so the
  SD> install script can do it automatically next time.

Good plan, that :)

  SD> Some extra twists:

  SD> I have patches to get the GRUB build to generate e2fs_stage1_5
  SD> and fat_stage1_5, they are a little big though (just over 8k).

  SD> Basically, this means that if the user has more than 16
  SD> heads/track, he has the option to install stage1 and stage1_5 on
  SD> a partition and can change the stage2 file.  I'm not sure if
  SD> this is useful or not, though.  (The stage1_5 stuff gives grub
  SD> the ability to read the filesystems when looking for the stage2
  SD> files.)

I'm still not quite sure what the stage 1.5 buys you here.. All I know
is on my system (large HD, LBA), it works correctly to have the stage
1 go directly to the stage 2, and let the stage 2 take care of the
details. Or something like that :)

  SD> My current ideas for an install program:

  SD>   grubinst [options] stage1file stage2file device [menu file]

  SD> With checks and warnings for screwing stuff up, backups of boot
  SD> blocks to /boot (like lilo), and for options I'm thinking:

This sounds pretty sane. Not sure if you have to be paranoid about the
boot block, but I suppose it can't hurt to be paranoid :)

Overall, sounds good, though. I did it via floppy this last time,
because I couldn't figure out how to work grubinst. It would be nice
if there was some reasonable docs for grubinst. I don't generally
blindly put trust in something that has a high possibility of making
my system unbootable if I screw it up :)

Thanks steve :)

-Larry

-- 
  Larry Daffner        |  Linux: Unleash the workstation in your PC!
  vizzie@airmail.net / http://web2.airmail.net/vizzie/
It's better to be silent and be thought a fool than to speak and remove all
doubt.  --Abraham Lincoln


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: