[SLL] Ubuntu Kernel files...always the same name per kernelupdate...

[Paul Allen]

On Mon, 2007-10-22 at 12:18 -0700, xeno at eskimo.com wrote:
> I was obviously unclear.  Per kernel update the kernel files are the same, so
> I have a bunch of things for i386, Amd64, etc called:
> 
> vmlinuz-2.6.22-14-generic, initrc.img-2.6.22-14-generic

Perhaps a better way to say it would be that for a given kernel version,
the name of the kernel file in /boot will be the same for each 
architecture.  Ditto for the initial ramdisk file, the System.map file,
and whatever else.  So the files for the various architectures fall on
top of each other if you simply copy them all into one /boot.

> They are called that no matter if they are for AMD64, or KDE AMD64, or Ubuntu
> i386.  It's not clear that other distributions do anything else, but I would
> expect they should.  On my CentOS server it has vmlinuz-2.6.18-8.1.14.e15.  It's
> not clear to me that there is any architecture specific information in that file
> name either.

OpenSuSE 10.2 does the same thing.  The names of the files in /boot have
embedded version numbers, but not architecture names.

> My main point is it would be nice to have a common /boot/grub directory.  I'd
> like to change the boot preference at boot time by editing or selecting a
> different grub.conf file before executing reboot rather than messing with the
> grub menu itself.  However, without the common /boot directory, it's not clear
> the grub config would be available as it would need to be mounted.  I could
> distribute to all the grub subdirectories on my system when I make the changes,
> but that's messy and ugly and makes me feel like grub is grubby.

You should be able to set up a single /boot and rename all the various
distributions' files to make them unique, assuming that you craft a 
grub.conf or menu.lst to match.  I'm not sure how you'd do this without
initially installing each distribution's /boot separately and then
manually combining them.  And then you'd have to manually update the
combined /boot after each kernel update.  Does the gain out-weigh the
complexity risk?

Wouldn't it be a lot simpler to just give each distro its own /boot
inside its / and have all the boot loaders (except the first distro's)
installed on / instead of on the MBR?  Grub knows how to pass control 
to another bootable partition, right?

Paul Allen