Making GRUB easier for a true multi-boot system -> CONCEPT

[vinnywright]

So, oceanluver, you ignored the warnings about editing grub.cfg because it will be overwritten by the next kernel upgrade? You'll need to repeat that when your kernel is upgraded, won't you?

no he wont as it's a stand alone grub install with custom menu entrys pointing to the OS's grub install ,,,,,,kinda chane loading the systems grub ,,,so as the system gets a new kernel and an auto update-grub the stand alone grub install dose not care ,,it just loades the newly updated grub of the system (he has several) ya gota go back and read the hole thread to rely get it but it prevents having to reboot 3 times for one kernel upgrade if it's in a second or third OS and not the one controlling grub ..........like say I'm in my Ubuntu install and get a kernel upgrade,but my Kubuntu is controlling grub , now I half to reboot to Kubuntu and run "sudo update-grub" then reboot to be abel to select the new kernel for Ubuntu ,,,,,,,see

VINNY

[GreyGeek]

Ah, thanks for the explanation, Vinny!

BTW, I installed that KDE grub GUI but I cannot find it in the menu or in SystemSettings. Where/How does one access it?

[vinnywright]

Ah, thanks for the explanation, Vinny!

BTW, I installed that KDE grub GUI but I cannot find it in the menu or in SystemSettings. Where/How does one access it?

if you installed the kde-config-grub2 it should be in system settings>startup and shutdown

VINNY

[Jonas]

Ah, thanks for the explanation, Vinny!

BTW, I installed that KDE grub GUI but I cannot find it in the menu or in SystemSettings. Where/How does one access it?

Is it kde-config-grub2 you mean?

It's in system-settings > startup and shutdown.

b.r

Jonas

[GreyGeek]

Ah, so it is. One of the places I didn't look at because I thought the KDE Desktop startup/shutdown wasn't related to the boot process. My assumption was that it would be a separate icon in the "System Administration" section, or part of the "Partition Manager".

[oshunluvr]

So, oceanluver, you ignored the warnings about editing grub.cfg because it will be overwritten by the next kernel upgrade? You'll need to repeat that when your kernel is upgraded, won't you?

No actually, the point of having a separate stand-alone bootable grub is it won't be overwritten by any kernel upgrades. It isn't necessary to update grub.cfg for the stand-alone grub because all it does is point at other grub.cfg files on the computer. Those other grub.cfg's are over-written when their respective kernels are updated.

To clarify a bit more:

The MBR points the bootloader at /dev/sda2.
/dev/sda2 contains only the grub files and a manually created grub.cfg.
The manually created grub.cfg has six stanzas that chainload to the six installs on my system.
Each of those installs has it's own grub install within it's root partition.

When a kernel is updated within any of the six installs, only it's own grub.cfg is updated - not the "master" grub.cfg.

This avoids having to boot into some other install just to update grub.cfg each time one of the OS's has an updated kernel.

[oshunluvr]

Wow, busy thread! five posts beat me to "Post Quick Reply"

[oshunluvr]

GRUB as always been problematic for me but anyway here is something to consider:
?? Why would be need to "update GRUB" . How about a separate text file that contains the stuff to change and then just ">>" in a short script to add the new contents. Error checking could be in the append script.
Just thoughts
Tabok-00

@Tabok-00 : With all the activity, I totally missed this comment - sorry about that.

AFAIK, all update-grub does is edit the grub.cfg file in the way you describe. It takes into consideration any personal changes you desire through /etc/default/grub and the files in /etc/grub.d/. The issue here was the requirement to either do a round-robin of reboots to update your grub.cfg or to manually mount the directory that contains the grub.cfg you're using and update it.

The benefits of this method are:

1. Once set up properly should require very little in the way of manual maintenance.
2. Each install maintains only it's own grub.cfg. No more OS probing.
3. Activating a new kernel or driver module for any install will require only a single reboot, not multiple.
4. Your grub install sits independant of any one install. In the event one or more of your installs gets removed or becomes unbootable, grub will still work for all the others.

[vinnywright]

sweet 8)
I followed ya @oshunluvr ..........BUT did it a bit diferent as I have just 1 HD and it's already in 7 partitions

vinny@Vinnys-HP-G62:~$ sudo parted -l
[sudo] password for vinny:
Model: ATA WDC WD5000BEVT-6 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32.3kB 4195MB 4195MB primary linux-swap(v1)
2 4195MB 26.0GB 21.8GB primary ext4 boot
3 26.0GB 237GB 210GB primary ext4
4 237GB 500GB 264GB extended
5 237GB 268GB 31.6GB logical ext4
6 268GB 300GB 32.0GB logical ext4
7 300GB 500GB 200GB logical ext4

so not wanting to muck about with them I just disabled OS probing with

GRUB_DISABLE_OS_PROBER=true

in /etc/default/grub
added this in /etc/grub.d/40_custom

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.

menuentry 'Ubuntu 12.04' {
set root=hd0,msdos5
configfile /boot/grub/grub.cfg
}

menuentry 'Backtrack' {
set root=hd0,msdos6
configfile /boot/grub/grub.cfg
}

and ran

sudo update-grub

now I still have my plasma lamp grub back ground and selecting Ubuntu or Backtrack gives me their grubs installed in their installs PBR's
now because of OS prober being turned off a kernel update hear in Kubuntu and a auto generated update-grub wont change anything and if the same happens in 1 of the other installs it's grub picks it up and I don't half to worry about doing the reboot sudo update-grub reboot dance

and it's the first time I'v seen that both of their grubs use a debian back ground ........well waddaya know

thanks @oshunluvr for the Idea and inspiration this was fun 8)

VINNY

[Qqmike]

It's coming back to me now, and this stuff is all over the Net.
For GRUB 2, this, for example:

http://aptosid.com/index.php?name=PN...iewtopic&t=119

The issue and the why's (read the warning to see why the devs say it's a bad idea):

# grub-install /dev/sdc10
/usr/sbin/grub-setup: warn: Es wird versucht, GRUB in eine Partition anstelle in den MBR zu installieren. Das ist eine SCHLECHTE Idee..
/usr/sbin/grub-setup: warn: Embedding is not possible.* GRUB can only be installed in this setup by using blocklists.* However, blocklists are UNRELIABLE and their use is discouraged..
/usr/sbin/grub-setup: error: Benutzen Sie --force, wenn Sie wirklich Blocklisten verwenden wollen..

And then, of course, you solve it by force:

# grub-install --force /dev/sdc10
/usr/sbin/grub-setup: warn: Es wird versucht, GRUB in eine Partition anstelle in den MBR zu installieren. Das ist eine SCHLECHTE Idee..
/usr/sbin/grub-setup: warn: Embedding is not possible.* GRUB can only be installed in this setup by using blocklists.* However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.


I don't know who first came up with this dedicated GRUB partition w/configfile/chainload. The old GRUB Legacy manual did hint right at it--and when you tilt your head and hold your tongue just right, and it's plain to see. But I suspect Herman first popularized it (at Bigpond back then); and he may have gleaned it from dev memos at the time, who knows. We all picked up on it (mostly through Herman). Not an issue for GRUB Legacy. Seems to be contentious for GRUB 2 probably because of how the embedding is now done (wrt boot.img and core.img).
All that said, I have not seen anyone's system blow up because of unreliably embedded GRUB files on blocklists, have you?
;-)

[Qqmike]

Btw, and a big btw, btw (as I've twice forgotten to post this thought--you gotta be in your 60's to understand how that can happen) ... I think it's neat--remarkable--that, oshunluvr, you came up with this on your own, independently, not lifting it from another source. I think you have more fun doing it that way, too, and you learn it better and will (probably, unless you are in your 60's) never forget it.

This is a bit OT but not really, as it is the very next thing that suggests itself ...
you can try chainloading to a chainloader;
chainloading to a configfile;
configfile to a configfile;
or, configfile to a chainloader,

and see what happens (and multistage, sequential instances of such calls). If you're a GRUB dev, you might be able to specify when such will or will not work. The rest of us may do it by brute-force experimenting. In my experience, now and then you have configurations where you can do no wrong and anything works for you. But now and then, you try such (e.g., one of the four listed above), and things won't go at all, spinning off cryptic error messages.

When you look at what GRUB can do, it makes Windows bootloaders seem pretty lame in comparison, especially considering GRUB's ease of use.

(Now if I can just figure out what Vinny did in #39 ... )

[oshunluvr]

I think Vinny sort of simplified the idea. Rather than creating a stand-alone grub partition, he's using his main install to host grub and eliminated the round-robin reboot's by using the grub config's of the other OS's rather than the main one to boot them. He also made the editing simpler by using 40_custom to hold the chainload (configfile re-directs) rather than trying to edit grub.cfg directly.

Neat idea Vinny!

[vinnywright]

I think Vinny sort of simplified the idea. Rather than creating a stand-alone grub partition, he's using his main install to host grub and eliminated the round-robin reboot's by using the grub config's of the other OS's rather than the main one to boot them. He also made the editing simpler by using 40_custom to hold the chainload (configfile re-directs) rather than trying to edit grub.cfg directly.

Neat idea Vinny!

correct!! 8)

I didn't half to reinstall/install any thing just turn off grubs OS probing and make the menu entry's in /etc/grub.d/40_custom pointing to each installs /boot/grub/grub.cfg
and run sudo update grub, as soon as you do that all the kernels,recovery-boot's of the other 2 OS's get removed from your boot list (grub.cfg) and just the mane install (Kubuntu)and the menu entry's in /etc/grub.d/40_custom are left 8) and they of course start there own grub's

VINNY