On Wed, 2008-06-04 at 14:07 +0200, Robert Millan wrote: > On Tue, Jun 03, 2008 at 06:03:51PM -0400, Pavel Roskin wrote: > > > > > > > > > > This patch solves the problem by spliting device/drive map[] entry > > > > > registration > > > > > into a separate function, and using that from grub-probe.c to > > > > > register a dummy > > > > > drive that will last during the current execution. > > > > > > Part of what makes grub-probe interesting is that it shares a lot of code > > > with > > > the freestanding GRUB you will run later, so when it is used during > > > grub-install & update-grub, it is very useful to catch possible problems. > > > I > > > think hostfs would defeat that purpose. > > > > Well, then we probably don't want to ignore any errors. When do you > > have the situation that the drive cannot be resolved? > > For example, when the next version of Linux decides to rename all devices (it > tends to do that often) and suddenly none of them match any device.map entry. > > The thing is, for what we're trying to do (-t fs, -t fs_uuid, -t partmap) we > don't care how will GRUB identify those devices when it's running on the BIOS, > so just any string that uniquely identifies them will be enough so we can > run our filesystem / partmap probes.
OK, then the "dummy drive" is not really dummy. Those in device.map are dummy :-) I'm basically fine with anything that gets rid on device.map at least for single-drive installs. -- Regards, Pavel Roskin _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
