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
> 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
> 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
> > > That means that device detection would take place _before_
> > > update-grub is run, correct?
> > > 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
> > 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
> > 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.
Linux System Administrator