linux - How to add a new kernel entry in grub2?

06
2014-04
  • nitin

    Please anybody help me!

    I am building kernel from source code downloaded from http://kernel.org. 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 System.map 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!

  • Answers
  • TheCompWiz

    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).

  • Nikolay

    How about you rename your bzImage to kernel-${version} or vmlinuz-${version} then grub2-mkconfig should pick it up automatically.

    As for the other things if you want to make a custom entry you should probably look into the files in /etc/grub.d/ specifically the XX_custom

    You can re-use the UUID it belongs to the partition and not the kernel. Same with root(hd0,msdos6) it is a notation for designating to grub where to load the kernel from, and you are just adding a kernel so it can be re-used

    The initial ramdisk is created via appropriate tools, easiest is probably the distro specific way, you will need to refer to Ubuntu documentation on this.


  • Related Question

    linux - How to load previous kernel via ssh?
  • Aamir

    I work remotely on my work computer. I am also the root of the workstation that I am sharing with my colleague. Yesterday, I upgraded the kernel to 2.6.31-17 when asked by the update manager but refrained from restarting because I knew my NVIDIA and several other kernel modules wouldn't work. Unfortunately my colleague who is a linux noob restarted the machine and here I am :(

    I am thinking of changing the symlinks /initrd.img and /vmlinuz to the previous kernel image and use kexec. Please tell some better way to load the 2.6.31-16 release of kernel from ssh and not the grub boot menu. I am using Ubuntu Karmic.


  • Related Answers
  • quack quixote

    You can't select it from SSH.

    You could use SSH to

    • a) check the Grub settings to make sure your previous kernel is still an option in the Grub menu,

    • b) set Grub to automatically boot to that option,

    • c) and finally reboot the system.

    This is very similar to a boot-once solution -- I wrote up instructions with Grub v1 in this answer on ServerFault.

    If you're using Grub2, you'll have to do some investigating to find the right configuration -- apparently the grub-set-default command doesn't work in Karmic. See "Grub 2 - 5 Common Tasks" on UbuntuForums -- #2 deals with modifying the default entry; option 3 in that talks about modifying that through the Grub2 configuration files:

    You can see the current "menuentry" items listed in the /boot/grub/grub.cfg by running this command:

    grep "menuentry" /boot/grub/grub.cfg
    

    Counting starts with zero (0). The first "menuentry" item is "0", the second is "1", etc. The third visible "menuentry" would be 2.

    Determine the number you wish to make the default, and enter it in /etc/default/grub. Make the change and save the file.

     sudo nano /etc/default/grub
    

    The user can also select "saved" as an option, which will use the last successfully booted kernel/OS as the default selection.

     # Example: 
     DEFAULT="saved"
    

    Save the file, then update the menu:

     sudo update-grub
    

    You'll need to locate the entry for your older kernel. Once you've changed the default entry to your older kernel and updated Grub, you should be able to reboot the system (sudo reboot now) -- after waiting for it to come back up, you should be running the old kernel.

  • Aamir

    I found out there is also a GUI editor for Grub2 in universe repository called startupmanager. I used it actually.