If this is your first visit, be sure to
check out the FAQ. You will have to register
before you can post. To start viewing messages,
select the forum that you want to visit from the selection below.
Please do not use the CODE tag when pasting content that contains formatting (colored, bold, underline, italic, etc).
The CODE tag displays all content as plain text, including the formatting tags, making it difficult to read.
Announcement
Collapse
No announcement yet.
Making GRUB easier for a true multi-boot system -> CONCEPT
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
BTW, I installed that KDE grub GUI but I cannot find it in the menu or in SystemSettings. Where/How does one access it?
"A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
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-grub2you mean?
It's in system-settings > startup and shutdown.
b.r
Jonas
ASUS M4A87TD | AMD Ph II x6 | 12 GB ram | MSI GeForce GTX 560 Ti (448 Cuda cores) Kubuntu 12.04 KDE 4.9.x (x86_64) - Debian "Squeeze" KDE 4.(5x) (x86_64) Acer TimelineX 4820 TG | intel i3 | 4 GB ram| ATI Radeon HD 5600 Kubuntu 12.10 KDE 4.10 (x86_64) - OpenSUSE 12.3 KDE 4.10 (x86_64) - Officially free from windoze since 11 dec 2009
>>>>>>>>>>>> Support KFN <<<<<<<<<<<<<
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".
"A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
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.
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.
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
Code:
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)
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?
;-)
An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
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 ... )
An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
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.
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
Comment