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

Re: update-grub



On Thu, Feb 03, 2005 at 01:12:56PM +0100, Frans Pop wrote:
> I've taken a look at your new code now, so I can give a more reasoned 
> reaction. Note: this still needs other ppl to look at.
> 
> The current sequence of actions by grub-installer is:
> 0. Update mtab in chroot to properly reflect mounted partitions
> 1. Install grub package
> 2. Run d-i's os-prober component to locate other OS's for multi-boot
>    configuration
> 3. Ask where grub should be installed (default is MBR of first disk)
> 4. Run grub-install
> 5. Run update-grub to create initial menu.lst
> 6. Add any user parameters in menu.lst and re-run update-grub
> 7. Append extra menu items for other operating systems
> 
> With your new code I think this would change to:
> 0-4: probably unchanged?
> 5. Set user parameters in /etc/grub.conf
> 6. Drop file(s) with menu items for other OS's in /etc/grub/post.d/

if we don't use grub install.

6a. copy files in /lib/grub/* to /boot/grub
6b. run grub in batch mode.   This installs it into the mbr
	root (hd0,0)
	setup (hd0)

> 7. Run update-grub
> 
> > > > The rewrite does not include any device detection code. The idea
> > > > was to put that into the postinst.
> 
> Hmmm. We are talking about the kernel root (device that has /boot), right? 
> For that I think the postinst should be OK.
>
> What about the groot? Would that still have to be passed to grub-install? 
> Are you planning changes to grub-install as well?

I was thinking of doing 5-7 in the postinst. But that will depend on if
it could be disabled when used from the installer.

Things we need are:
1. The grub root device. e.g (hd0,0), which is where every /boot is
2. The kernel root device.  e.g. /dev/hda1

And to do 6b, The place where they want to install grub. e.g. (hd0), the
mbr.

> > > That means that device detection would take place _before_
> > > update-grub is run, correct?

YES.

> > > Where would the results of the device detection be stored?

/etc/grub/kernel.conf or something like that.

> > > How would device detection be triggered again if there are hardware
> > > changes (or even if the user decides to use udev or something like
> > > that)?
> >
> > the new update-grub would read it's device information from
> > /etc/grub/kernel.conf
> 
> Right.
> 
> > But I didn't really think about triggering a redetection. perhaps
> > dpkg-reconfigure grub.
> 
> I feel this will need some consideration. Like trying to identify cases 
> where redetection would be needed, if automatic redetection would be 
> useful and where any checks for a changed configuration should be 
> implemented (maybe there should be some sanity checks in update-grub 
> suggesting to run dpkg-reconfigure if they fail).

This could be as simple as comparing the root device in fstab with the
root device in /etc/grub/kernel.conf and throwing a warning if they are
different.

> > I was thinking that when the grub package was installed it would do
> > some auto detection and then allow the user to modify the results. That
> > way people with corner cases (such as raid) are covered.
> 
> Hmmm. One of the design goals of d-i is to reduce the number of questions 
> as much as possible. For d-i, we would at least have to be able to run 
> the postinst of grub non-interactive.
> It would be nice if auto-detection were as complete as possible and if 
> situations that can not be auto-detected would be signalled in some way 
> (and not fall back to some default like now), so we would be able to ask 
> the questions from within d-i only if needed.

Perfect.

-- 
Jason Thomas
Linux System Administrator
http://www.sage-au.org.au/



Reply to: