On Sun, Dec 06, 2009 at 01:21:46AM -0800, David Miller wrote: > > Robert, the set of objects used to build grub-mkdevicemap on > sparc64-ieee1275 is not the same as those used on other architectures. > So this change was not correct: > > 2009-11-26 Robert Millan <rmh.g...@aybabtu.com> > > * conf/common.rmk (sbin_UTILITIES): Add `grub-mkdevicemap'. > ... > * conf/i386-coreboot.rmk (sbin_UTILITIES): Remove `grub-mkdevicemap'. > (grub_mkdevicemap_SOURCES): Remove. > ... > * conf/sparc64-ieee1275.rmk: Likewise. > > In particular, we use a special implementation devicemap.c on > sparc64-ieee1275 so that openfirmware device nodes are emitted instead > of "hd0" et al. > > So when you moved the build rule into common.rmk you broke this. > > This is probably the primary reason that the current tree works for > nobody on sparc64 :-) > > Before I found this problem, I tested with an existing devicemap and > config file on a Niagara LDOM Linux guest and current trunk worked as > well as it did when I was last active several months ago and I was > able to boot Linux kernels with it.
We're actually in the process of getting rid of device.map; in fact the "hd0" names you see have no real effect on i386-pc, they're just ignored. We now have more robust code that doesn't hardcode drive names. grub-setup now accepts plain system devices as arguments, even if they're not listed in device.map. grub-mkconfig generates a grub.cfg that relies on UUIDs instead of hardcoding, etc. But I might have missed some detail. Is there a peculiarity of sparc64-ieee1275 that makes this approach unpractical? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
