[SOLVED] Is it possible to not create GRUB during installation or kernel change?

[agmg]

I have a two-disk setup in my laptop.

First disk is my new SSD which has my everyday KDE installation with its own /home folder.
Second disk is my old mechanical one, which has Windows7, a test KDE MiniME install, a test05 KDE install and a NTFS partition for data.

I have a GRUB installed on the first disk (/dev/sda) which I have edited to be able to boot in all installations.

Code: [Select]

timeout 5
color black/cyan yellow/cyan
gfxmenu (hd0,0)/boot/gfxmenu
default 0

title PCLinuxOS Main
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=9e539c71-a3ad-4cac-a9fc-f0cb06437805 quiet nokmsboot vmalloc=256M acpi=on resume=UUID=b5886c86-eb08-41f8-b671-be61dba22918 splash=silent vga=791
initrd (hd0,0)/boot/initrd.img

title PCLinuxOS Main Safemode
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=failsafe root=UUID=9e539c71-a3ad-4cac-a9fc-f0cb06437805 quiet nokmsboot failsafe vmalloc=256M acpi=on
initrd (hd0,0)/boot/initrd.img

title PCLinuxOS Test32
kernel (hd1,5)/boot/vmlinuz BOOT_IMAGE=PCLinuxOS_Test32 root=UUID=7f13f01c-b46f-48b2-a6c2-8b12ea58518d quiet nokmsboot vmalloc=256M acpi=on resume=UUID=8ed9523a-5e20-423e-9147-47dd96861b16 splash=silent vga=791
initrd (hd1,5)/boot/initrd.img

title PCLinuxOS Test32 Safemode
kernel (hd1,5)/boot/vmlinuz BOOT_IMAGE=PCLinuxOS_Test32_Safemode root=UUID=7f13f01c-b46f-48b2-a6c2-8b12ea58518d quiet nokmsboot failsafe vmalloc=256M acpi=on
initrd (hd1,5)/boot/initrd.img

title PCLinuxOS Test64
kernel (hd1,7)/boot/vmlinuz BOOT_IMAGE=PCLinuxOS_Test64 root=UUID=93d02159-2a16-452f-a12f-81b2abc5ad61 quiet nokmsboot vmalloc=256M acpi=on resume=UUID=8ed9523a-5e20-423e-9147-47dd96861b16 splash=silent vga=791
initrd (hd1,7)/boot/initrd.img

title PCLinuxOS Test64 Safemode
kernel (hd1,7)/boot/vmlinuz BOOT_IMAGE=PCLinuxOS_Test64_Safemode root=UUID=93d02159-2a16-452f-a12f-81b2abc5ad61 quiet nokmsboot failsafe vmalloc=256M acpi=on
initrd (hd1,7)/boot/initrd.img

title memtest-4.20
kernel (hd0,0)/boot/memtest-4.20 BOOT_IMAGE=memtest-4.20

title Windows
rootnoverify (hd1,0)
map (hd1) (hd0)
map (hd0) (hd1)
makeactive
chainloader +1
The second disk contains only the Windows bootloader. If I select the second disk as first boot device from BIOS, I can only boot to Windows.
I know it's not ideal because in case the first disk fails, I won't be able to boot in my test installs. It's OK, I can fix it if this happens.

I want to ask a couple of things.

How can I avoid re-editing my main GRUB or the creation of a new GRUB on the second disk (/dev/sdb), every time I:
1. Install a new kernel for testing?
2. Wipe and reinstall one of my test installs?

[Old-Polack]

I have a two-disk setup in my laptop.

First disk is my new SSD which has my everyday KDE installation with its own /home folder.
Second disk is my old mechanical one, which has Windows7, a test KDE MiniME install, a test05 KDE install and a NTFS partition for data.

I have a GRUB installed on the first disk (/dev/sda) which I have edited to be able to boot in all installations.

Code: [Select]

timeout 5
color black/cyan yellow/cyan
gfxmenu (hd0,0)/boot/gfxmenu
default 0

title PCLinuxOS Main
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=9e539c71-a3ad-4cac-a9fc-f0cb06437805 quiet nokmsboot vmalloc=256M acpi=on resume=UUID=b5886c86-eb08-41f8-b671-be61dba22918 splash=silent vga=791
initrd (hd0,0)/boot/initrd.img

title PCLinuxOS Main Safemode
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=failsafe root=UUID=9e539c71-a3ad-4cac-a9fc-f0cb06437805 quiet nokmsboot failsafe vmalloc=256M acpi=on
initrd (hd0,0)/boot/initrd.img

title PCLinuxOS Test32
kernel (hd1,5)/boot/vmlinuz BOOT_IMAGE=PCLinuxOS_Test32 root=UUID=7f13f01c-b46f-48b2-a6c2-8b12ea58518d quiet nokmsboot vmalloc=256M acpi=on resume=UUID=8ed9523a-5e20-423e-9147-47dd96861b16 splash=silent vga=791
initrd (hd1,5)/boot/initrd.img

title PCLinuxOS Test32 Safemode
kernel (hd1,5)/boot/vmlinuz BOOT_IMAGE=PCLinuxOS_Test32_Safemode root=UUID=7f13f01c-b46f-48b2-a6c2-8b12ea58518d quiet nokmsboot failsafe vmalloc=256M acpi=on
initrd (hd1,5)/boot/initrd.img

title PCLinuxOS Test64
kernel (hd1,7)/boot/vmlinuz BOOT_IMAGE=PCLinuxOS_Test64 root=UUID=93d02159-2a16-452f-a12f-81b2abc5ad61 quiet nokmsboot vmalloc=256M acpi=on resume=UUID=8ed9523a-5e20-423e-9147-47dd96861b16 splash=silent vga=791
initrd (hd1,7)/boot/initrd.img

title PCLinuxOS Test64 Safemode
kernel (hd1,7)/boot/vmlinuz BOOT_IMAGE=PCLinuxOS_Test64_Safemode root=UUID=93d02159-2a16-452f-a12f-81b2abc5ad61 quiet nokmsboot failsafe vmalloc=256M acpi=on
initrd (hd1,7)/boot/initrd.img

title memtest-4.20
kernel (hd0,0)/boot/memtest-4.20 BOOT_IMAGE=memtest-4.20

title Windows
rootnoverify (hd1,0)
map (hd1) (hd0)
map (hd0) (hd1)
makeactive
chainloader +1
The second disk contains only the Windows bootloader. If I select the second disk as first boot device from BIOS, I can only boot to Windows.
I know it's not ideal because in case the first disk fails, I won't be able to boot in my test installs. It's OK, I can fix it if this happens.

I want to ask a couple of things.

How can I avoid re-editing my main GRUB or the creation of a new GRUB on the second disk (/dev/sdb), every time I:
1. Install a new kernel for testing?
2. Wipe and reinstall one of my test installs?

The last kernel installed automatically becomes the default kernel that boots from the first boot entry, so no need to edit /boot/grub/menu.lst. If you remove an installation you do need an edit. On the other hand, if you have chainloader boot stanzas with the partition as the title, any new installation that has its grub installed to the partition boot sector will show its own boot screen when the master grub's chainloader stanza for that partition is chosen. You can then install and delete installations at will and keep the same stanzas in the master menu.lst.

[DeBaas]

Example Linux xxxxxx on sdb8 with bootloader on its own partition

This is the stanza in your master Grub1 (legacy)
 
title Linux xxxxxx
root (hd1,7)
chainloader +1

Where it makes no difference if Linux xxxxxx uses Grub1  or Grub2

[agmg]

On the other hand, if you have chainloader boot stanzas with the partition as the title, any new installation that has its grub installed to the partition boot sector will show its own boot screen when the master grub's chainloader stanza for that partition is chosen. You can then install and delete installations at will and keep the same stanzas in the master menu.lst.

I see. So, you suggest that I use Grub on each installation's partition boot sector and just chainload that Grub to the master one.
Plus, the Windows bootloader as it is now. I had that kind of setup with only one disk.

What I wanted to avoid was to have to pass 2 Grub screens during boot
I guess it's easier to set the secondary Grub's timeout to 0 than to have to re-edit the master Grub every time I perform an installation or kernel change.

[agmg]

Example Linux xxxxxx on sdb8 with bootloader on its own partition

This is the stanza in your master Grub1 (legacy)
 
title Linux xxxxxx
root (hd1,7)
chainloader +1

Where it makes no difference if Linux xxxxxx uses Grub1  or Grub2

Thanks DeBaas!
I had a similar setup before with only one disk.
Windows and two test installs were chainloaded to the main installation's Grub.
I was just wondering if I could skip the bootloader of each test installation with an easy way

[Old-Polack]

Example Linux xxxxxx on sdb8 with bootloader on its own partition

This is the stanza in your master Grub1 (legacy)
 
title Linux xxxxxx
root (hd1,7)
chainloader +1

Where it makes no difference if Linux xxxxxx uses Grub1  or Grub2

Thanks DeBaas!
I had a similar setup before with only one disk.
Windows and two test installs were chainloaded to the main installation's Grub.
I was just wondering if I could skip the bootloader of each test installation with an easy way

You get a choice. Either chainloader stanzas in the main menu.lst, and extra boot screens, or no chainloader stanzas, with frequent edits to the master menu.lst involved.

If you skip installing the boot loader, the proper initrd image for the installed kernel will not be created, and you'll get a kernel panic when trying to boot. You need to install it somewhere, so the partition boot sector is as good a place as any. You can use it or not, but at least you'll have a proper initrd image created.

[Just17]

The last kernel installed automatically becomes the default kernel that boots from the first boot entry, so no need to edit /boot/grub/menu.lst. If you remove an installation you do need an edit. On the other hand, if you have chainloader boot stanzas with the partition as the title, any new installation that has its grub installed to the partition boot sector will show its own boot screen when the master grub's chainloader stanza for that partition is chosen. You can then install and delete installations at will and keep the same stanzas in the master menu.lst.

This is not always the case .......  if the menu.lst file has been edited (haven't bothered to find the specific edit, but suspect it has to do with the title) ...... the new kernel entry is added to the end of the boot list.

Just a 'heads-up' if you are inclined to edit the menu.lst (as I am  )

[agmg]

Thanks for the input guys! Much appreciated!

I think I'll stick with chainloading as it the easiest and safer

Marking as [SOLVED]

[Old-Polack]

The last kernel installed automatically becomes the default kernel that boots from the first boot entry, so no need to edit /boot/grub/menu.lst. If you remove an installation you do need an edit. On the other hand, if you have chainloader boot stanzas with the partition as the title, any new installation that has its grub installed to the partition boot sector will show its own boot screen when the master grub's chainloader stanza for that partition is chosen. You can then install and delete installations at will and keep the same stanzas in the master menu.lst.

This is not always the case .......  if the menu.lst file has been edited (haven't bothered to find the specific edit, but suspect it has to do with the title) ...... the new kernel entry is added to the end of the boot list.

Just a 'heads-up' if you are inclined to edit the menu.lst (as I am  )

It's a dual process. The new automatic edit to menu.lst is at the end of the boot list, but also the links vmlinuz and initrd.img, in /boot, are deleted, then recreated to point to the last kernel installed. The edit, (adding a new stanza) is for later, in case you install yet another kernel, but still want the ability to boot to the previous one. The original default Stanza then always points to the last kernel installed, without any edits to it, because it calls the links, rather than the actual kernel and initrd images directly.

[Just17]

OK, I will try to be more specific ......

Install a second kernel.

Edit the title of the generic boot stanza from "linux" to anything else ....  try "linux_default"

Boot into the second kernel to ensure all is ok.

Now reboot into the first kernel.

Uninstall the second kernel.

Now the vmlinuz link points to a non-existant kernel, and the "linux_default" entry will not boot.

[Old-Polack]

OK, I will try to be more specific ......

Install a second kernel.

Edit the title of the generic boot stanza from "linux" to anything else ....  try "linux_default"

Boot into the second kernel to ensure all is ok.

Now reboot into the first kernel.

Uninstall the second kernel.

Now the vmlinuz link points to a non-existant kernel, and the "linux_default" entry will not boot.

Now, install another kernel. The links will be reset to that kernel and the linux_default entry will again work. The links are reset with the addition of a new kernel, but not reset with the removal of a kernel, even if it was the last kernel installed. I would guess an additional script could be written to check for the newest existing kernel after a kernel removal, and if the links do not point to it, then remove them and recreate them so that they do.

The whole point of the links being changed to the newest kernel installed is to make it easier for someone with little knowledge of how the boot process works to add a new kernel and not have to do any manual editing because of it. Most people don't go out of their way to remove a newly added kernel, just to see if it breaks anything. If someone does remove the last kernel installed, for cause, they also usually then install a different newer kernel, then reboot, so probably never notice the links not being proper during the interim.

Be glad we don't use the SUSE method, where new kernels are treated as an upgrade, and the old kernel is removed as soon as the newer one is installed. If the new kernel doesn't like your hardware, you are just screwed, because there is not older backup kernel to boot to. I dealt with that for eight years, and had some slick tricks to be sure I did have backup kernels, with all their needed modules and such, before rebooting.

[Just17]

OK, I will try to be more specific ......

Install a second kernel.

Edit the title of the generic boot stanza from "linux" to anything else ....  try "linux_default"

Boot into the second kernel to ensure all is ok.

Now reboot into the first kernel.

Uninstall the second kernel.

Now the vmlinuz link points to a non-existant kernel, and the "linux_default" entry will not boot.

Now, install another kernel. The links will be reset to that kernel and the linux_default entry will again work. The links are reset with the addition of a new kernel, but not reset with the removal of a kernel, even if it was the last kernel installed. I would guess an additional script could be written to check for the newest existing kernel after a kernel removal, and if the links do not point to it, then remove them and recreate them so that they do.

The whole point of the links being changed to the newest kernel installed is to make it easier for someone with little knowledge of how the boot process works to add a new kernel and not have to do any manual editing because of it. Most people don't go out of their way to remove a newly added kernel, just to see if it breaks anything. If someone does remove the last kernel installed, for cause, they also usually then install a different newer kernel, then reboot, so probably never notice the links not being proper during the interim.

Be glad we don't use the SUSE method, where new kernels are treated as an upgrade, and the old kernel is removed as soon as the newer one is installed. If the new kernel doesn't like your hardware, you are just screwed, because there is not older backup kernel to boot to. I dealt with that for eight years, and had some slick tricks to be sure I did have backup kernels, with all their needed modules and such, before rebooting.

I was but pointing out that things can get screwed up a bit 

The other point is that there are quite a number of suggestions on the forum to try out a kernel from testing "and if it doesn't work boot into the old kernel and uninstall the testing one again" or words to that effect.

Doing this can cause a problem.

It is best that users are aware of that possibility.

[Old-Polack]

OK, I will try to be more specific ......

Install a second kernel.

Edit the title of the generic boot stanza from "linux" to anything else ....  try "linux_default"

Boot into the second kernel to ensure all is ok.

Now reboot into the first kernel.

Uninstall the second kernel.

Now the vmlinuz link points to a non-existant kernel, and the "linux_default" entry will not boot.

Now, install another kernel. The links will be reset to that kernel and the linux_default entry will again work. The links are reset with the addition of a new kernel, but not reset with the removal of a kernel, even if it was the last kernel installed. I would guess an additional script could be written to check for the newest existing kernel after a kernel removal, and if the links do not point to it, then remove them and recreate them so that they do.

The whole point of the links being changed to the newest kernel installed is to make it easier for someone with little knowledge of how the boot process works to add a new kernel and not have to do any manual editing because of it. Most people don't go out of their way to remove a newly added kernel, just to see if it breaks anything. If someone does remove the last kernel installed, for cause, they also usually then install a different newer kernel, then reboot, so probably never notice the links not being proper during the interim.

Be glad we don't use the SUSE method, where new kernels are treated as an upgrade, and the old kernel is removed as soon as the newer one is installed. If the new kernel doesn't like your hardware, you are just screwed, because there is not older backup kernel to boot to. I dealt with that for eight years, and had some slick tricks to be sure I did have backup kernels, with all their needed modules and such, before rebooting.

I was but pointing out that things can get screwed up a bit 

The other point is that there are quite a number of suggestions on the forum to try out a kernel from testing "and if it doesn't work boot into the old kernel and uninstall the testing one again" or words to that effect.

Doing this can cause a problem.

It is best that users are aware of that possibility.

But that's why we're here... to wipe their noses and dry their tears, then show them how to fix the boo boo.

[Just17]

 

now I know what you live for .......  using wipes of various types

[pclinmike]

now I know what you live for .......  using wipes of various types

Re...now I know what you live for .......  using wipes of various  Colors