Linux – How to add a new kernel entry in grub2?


Please anybody help me!

I am building kernel from source code downloaded from I successfully built it and installed modules. Now i want that my kernel option should come at the boot time and i want to select it. After doing some search on google

i copyed bzImage in /boot folder.
i copyed file in /boot folder

Now i want to make a entry for kernel at boot time. I know that i have to make changes in "/etc/grub.d/" and "/etc/default/grub" after that i will have to run "update-grub" but problem is that how i will set fields.

  1. set root='(hd0,msdos6)'
  2. search –no-floppy –fs-uuid –set=root c291827c-6678-4067-ad09-01481681a9f9
  3. echo 'Loading Linux 3.5.0-45-generic …'
  4. linux /boot/vmlinuz-3.5.0-45-generic root=UUID=c291827c-6678-4067-ad09-01481681a9f9 ro recovery nomodeset
  5. echo 'Loading initial ramdisk …'
  6. initrd /boot/initrd.img-3.5.0-45-generic

These are some of the fields but i do not know how to get value of uuid, what to set in root (like hd0,msdos6), what is its meaning , how to get initial ramdisk image?

Please do not say that this question is similar to this or that question. I have searched it already at google and stack overflow but nothing solved my problem , all i got is 100s of tab opened in my browser.

My Requirements :-

How to get uuid for new kernel image?
what is (hd0,msdos6)? how to get this value for new kernel image?

Plesae help me!

Best Answer

Lets explain a bit of grub... and then explain whats going on with what you're doing. There are 4 parts to booting a linux system:

  1. The Master-Boot record. This is very tiny, and must be located at a very specific sector on the disk. The BIOS is hard-coded to look for this and start execution there.
  2. The Bootlaoder itself. This can be grub, lilo, syslinux, or a variety of other things. In this case, it's grub. Frequently, the MBR (master boot record) and the bootloader are the same file located strategically on the bootable medium. (typically starting at the very first few bytes of the disk) This is not always the case, as you can have one bootloader chainload a second bootloader.
  3. The Kernel itself. Unfortunately, the kernel itself doesn't do much without additional bits. Think of it as a brain. By itself it cannot do much. Throw in some body parts (eyes, legs, circulatory system, etc...) scripts, kernel modules, and you have the beginnings of a proper system.
  4. The Initial Ramdisk Image. This is an image that is small enough to get the whole OS started. It is loaded into RAM, and mounted as the root filesystem. It typically contains everything the kernel needs to actually boot. (Kernel modules, init scripts, etc...) At some point, the initial ramdisk will remount the actual root filesystem in its place, and hand-off further execution to the init-scripts located on that root. You do not always need an initial ramdisk... but you are limited by what you can stuff into the bzImage.

Now, an explanation of the "UUID" values. Personally, I hate UUIDs. I understand why they are used today... but that doesn't make me hate them any less. In the past, we simply defined disks as "/dev/hda1" or "(hd0,1)" which told us that it was the first physical disk (hda, or hd0) and the first partition on that disk. If you decided to add a second drive, would the old drive become hdb or hd1? or would it remain the same? To combat that ambiguity, someone came up with the idea to create a "Universally Unique IDentifier" which would assign a unique value to each disk, that would persist through reboots, and doesn't care what order the disks are detected in. The UUID is written to the disk... and generally remains untouched. The disadvantage is, if you clone the filesystem to another disk... the UUID won't match, and the system won't boot. If you want to stick with UUIDs... just boot the system in a typical live-disk... and look in /dev/disk/by-uuid for the one that points to the drive/partition in question.

The good news is that you don't have to use UUIDs. You can remove the "search" command, and let the root= be the determining factor for what root is. You can also use --label instead of --fs-uuid and specify the disk label (if you set one).