[PLUG] Device ID in Grub

Elliott Mitchell ehem at m5p.com
Sun Feb 11 06:51:58 UTC 2007


>From: John Jason Jordan <johnxj at comcast.net>
> 1) Although I booted back to my usual installation, the boot screen
> went through pages of stuff, including a lot of error messages. It was
> too fast to read any of them, but there was a lot. It never used to do
> that. 

Run the program `dmesg`, that will retrieve those messages. You'll likely
want to pipe it through `more` or `less` in order to view them. Error
messages on startup are generally bad, don't ignore it when your system
screams.

> 2) More important, and possibly related to the first question,
> apparently the long-ass string of numbers identifies someplace on the
> hard disk where Grub is to find the boot folder. (I did copy it down
> faithfully so I can put it back if necessary.) But why use something
> that humans can't understand when /dev/hda2 works as well. Or does it
> work as well? 

The problem is that device identifiers can change. If a disk is added or
moved, everything can change. While the UUID is supposed to be completely
unique to the filesystem, therefore even if the device moves around you
can still uniquely identify the filesystem.

You can retrieve the UUID with `tune2fs -l` on the device, and ensure the
grub config has the right thing.


>From: Carlos Konstanski <ckonstanski at pippiandcarlos.com>
> I always wonder why people prefer debian knock-offs to the real McCoy.
> With straight-up debian you don't get kernel package management; you
> have to download them from www.kernel.org and build them yourself (if
> this has changed in the last 2 years since I've moved away from
> debian, then my apologies).

That method works with any distribution, but it isn't the Right Way(tm).
With Debian and derivatives the Right Way(tm) is to use the
"kernel-package" script to wrap the kernel build and produce a Debian
package you can install with `dpkg`. This keeps everything nice and tidy,
though a small number of kernels aren't difficult to handle by hand.

> Is there no mechanism in apt to protect config files of your choosing,
> like gentoo portage has?  In portage, you just add a CONFIG_PROTECT
> variable and value to /etc/make.conf.

John, hopefully you're still reading.

There are three control files for kernel-package. The first is
/etc/kernel-pkg.conf, which can be overridden by a .kernel-pkg.conf file
in your home directory. This controls build-time settings, such as what
config target to use. Then there is /etc/kernel-img.conf, this controls
behavior on installation of the packaged kernel. Such as whether the
bootloader installation program gets rerun, whether the boot loader
config is modified to boot the new kernel, etc.

John, look at the man page for kernel-img.conf to find out all the
wonderful settings you can play with (notably disable). Carlos, the main
program for kernel-package is `make-kpkg`. The key advantage is it gives
you a very nice way to /uninstall/ old kernels.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/





More information about the PLUG mailing list