http://linuxshellaccount.blogspot.com/2008/08/how-to-manage-your-disk-by-uuid-on.html
Managing disks by UUID lets you specify which disk to use, even if the loader's flavor-of-the-week -- or worse, the hardware -- decides to change it. When the USB gods decide to change your disk's position in the chain at nearly every boot up, this can be a big help if you want to boot off a thumb drive. Managing disks by the /dev/hdxxx model lets you specify which disk _position_ to use, so you can (for instance) swap your second drive in and out, with all the advantages you cite. poe tay toe, poe tah toe. I don't know if Grub can be made to use the /dev/hdxxx notation; I certainly hope it still can. On Thu, April 16, 2009 1:40 pm, Word Wizard wrote: > I noticed that for some reason grub uses UUIDs to determine the location > of the kernel in the menu.lst. For some reason unknown to me, somebody > decided UUIds are preferable to the (hd0) notation I've come know in > Windows boot.ini or the /dev/hda notation of lilo. It appears to me that > UUIds are not fixed attributes (e.g., like a serial number) of a given > piece of hardware or a reliable partition designation but change with > each installation. > > So if I install a new copy of Ubuntu Intrepid then try to put into place > the old / file system I previously tar-ed, there is a mismatch of UUIDs. > This may in fact be part of my difficulties in Intrepid restoring that > originated this thread. I think I may have installed a fresh copy of > Intrepid then tried to restore the previous / system, > > Why did they migrate to UUIDs in grub? What is the advantage? Can you > employ the other device notations in grub? Can lilo be used in Intrepid > instead? Or another boot loader? > > Thanks, > > Word Wizard > > > On Wed, 2009-04-15 at 19:59 -0700, Dwight Hubbard wrote: > >> Grub stores the actual physical locations of the datablocks of it's >> stage 1.5 or stage 2 files in the bootblock. If you restore from a >> tar archive the location of the blocks for the grub stage files will >> almost certainly be different and as a result grub will generate an >> error 15 because it can't find them. >> >> After restoring from a tar archive you need to chroot into the newly >> restored filesystem and run a grub-install to cause the restored >> system to write the grub stage file locations to the boot block. >> >> Or you can restore grub from the grub command. If my memory serves >> the commands would look something like this (assuming your /boot >> filesystem (hd0,1) and you want the boot block on the first hard disk: >> root (hd0,1) >> setup (hd0) > > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Land line: 503.631.7815 Cell: 503.349.8432 _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
