[kde-linux] grub and grub2

[Duncan]

Doug posted on Tue, 13 Aug 2013 22:30:06 -0400 as excerpted:

> I have Win 7, PCLOS, and Korora on a machine here. PCLOS boots off of
> original grub, but Korora boots off of grub2. I installed Korora last,
> and the boot order shown at power up has Korora first.
> 
> I like the PCLOS boot screen. Can I just boot into PCLOS and run redoMBR
> and have everything boot off of original grub? I know how to modify
> menu.lst to change boot order.
> 
> If not, what must I do to at least change the boot order in the Korora
> grub2 setup? (I'd like to have it show Windows first, then PDLOS, then
> Korora.)

Not really on topic for a KDE list, but ehh... simple enough to answer.

* First, when dealing with a bootloader, it's wise to have a backup boot 
method, just in case something goes wrong.  If you have a second hard 
disk, most BIOS setups allow you to select which one to boot, and it can 
be convenient to setup and configure an independent bootloader on each, 
just in case the one gets screwed up.  What makes this particularly easy 
is that as long as you make very sure you're installing to the CORRECT 
hard drive, you're not touching the already setup one when you do it, so 
if things go wrong, you can always simply boot the one that you know 
works and try again.

FWIW, that's actually how I upgraded from grub1 to grub2, here.  Leave 
the grub1 installation on one disk alone until I was totally comfortable 
with the grub2 installation on the other one, and had it both working and 
configured to my liking.  Then, and ONLY then, did I blow away the 
original grub1 on the first disk, setting it up with grub2 using a 
similar configuration as the second disk (the first with grub2).  With a 
raid1 setup (actually btrfs raid1 now, but it was md raid1 when I 
originally did the grub2 upgrade) a backup root filesystem image updated 
when I know the system is working well, and an independent grub2 setup on 
each disk, each grub installation can boot either the primary rootfs or 
the backup, with the BIOS selecting the grub installation, and the grub 
installation selecting primary or backup rootfs.  Further, with both 
primary and backup rootfs as raid1, if necessary I can boot "degraded" to 
the remaining good disk, if the other one goes bad.

If you don't have a second hard disk to play around with, a bootable USB 
thumbdrive works as the second grub installation.  Grub (either 1 or 2) 
doesn't take a lot of room...

So first off I'd recommend setting up a second grub install (1 or 2 your 
pick, but 2's more powerful and thus easier to work with when things go 
bad and you need to use it to recover), either on a second hard drive, or 
on a bootable USB stick, and testing that it works.  Once you have tested 
that you can boot to it, and from it to whichever distro you select, 
*THEN* you can fool around with your primary grub installation, without 
having to worry that if you screw things up you'll be left without a way 
to boot. =:^)

Now to answer your questions...

Can you boot to PCLOS and just redo the grub1 mbr?

It depends. =:^\

/Possibly/, but there's at least three ways grub1 can be installed to the 
disk, and at least five for grub2 (altho it's unlikely you're using EFI 
mode unless it's a quite new machine, and MS Windows 7 hints that it's 
not /that/ new, so that leaves four), and some of them aren't as easily 
repaired as (and/or are easier to screw up than) others. =:^(

That's where your already setup and tested reserve grub installation on 
the second disk or bootable thumb drive comes in if things go bad... 

With grub1, the ideal setup is with stage-1.5 (if necessary) in the slack-
space between the MBR and the start of the first partition, if there's 
space available for it to fit there, with the rest of the configuration 
and stage-2 in /boot.

With grub2, this is actually a middle setup; the preferred setup (for 
BIOS not EFI) would be with GPT partitions instead of MBR, with a small 
dedicated BIOS-reserved partition for grub2 to stick its core (comparable 
to grub1's stage-1.5) in, and again with everything else in /boot.  This 
is **FAR** more reliable, both because GPT itself is far more reliable 
(unlike MBR, the partition tables are checksummed and there's two of 
them, in case one goes bad, and there's no having to worry about primary 
vs. secondary vs. logical partitions, as GPT has space for 128 partitions 
by default, all at the same level), and because with the reserved BIOS 
boot partition for grub2 to use, the chances of anything else screwing 
things up are MUCH smaller.

And of course grub2's modular nature is far more powerful, flexible and 
easier to work with as well, as the core is configured at installation 
with the modules it needs to read /boot, and it can load further modules 
as needed from there, once core is loaded and /boot is readable.
means if you're lucky
Meanwhile, FWIW, grub1 has patches to let it work with GPT as well, altho 
it's possible PCLOS doesn't use them and even if it does, those patches 
just let it read GPT, they don't let it use the reserved BIOS boot 
partition, as grub2 does.  Similarly, I *THINK* MSWindows7 did GPT, but 
only if it was setup for it at installation.  (That's from what I've 
read.  I don't do Windows or servantware in the context of my sig any 
more, not even Flash or nVidia servantware kernel modules altho I do 
still load non-CPU firmware, having switched when the eXPrivacy thing 
came along as I simply wasn't going to let MS force-feed me that!  So 
while I ran IE betas and helped out on the MS newsgroups back in the day 
and could at that point have been considered an expert, I've been off it 
over a decade now and I no longer consider myself anything close to an MS 
expert.)

But given the MSWindows7, grub1/PCLOS and grub2/Korora triple-boot, it's 
unlikely you have GPT, and your mention of MBR would seem to confirm that.

Which probably means, (0) installation to the MBR (grub1 stage1 or grub2 
stub), with grub1 stage-1.5 and grub2 core installed to the slack-space 
before the first partition, if any.

The other alternatives would include (1) installing grub to a secondary 
partition... I'm not actually sure how that works, OR (2), installation 
of grub1 stage 1.5 and grub2-core direct into the filesystem in /boot.  
However, the latter possibility is rather unreliable with many 
filesystems, as there is only room in the MBR for a direct disk address 
to the next stage, not anything intelligent, and filesystems sometimes 
move the file around, leaving the MBR pointer pointing at the wrong 
thing!  So installation directly to the /boot filesystem is normally only 
done as a last resort.

So here's the deal.  Just redoing the grub1 MBR will work ONLY if the 
grub1 stage-1.5 (if necessary) or stage-2 (if 1.5 wasn't necessary) 
remains at the location the grub1 stage-1 pointer points at.  If it has 
moved, or if there's something else (like grub2) in that location now, 
you're going to have problems.

If that pointer is directly into the filesystem, which as I said, is 
normally a last-resort installation, then it should work, assuming the 
PCLOS /boot filesystem hasn't been disturbed.  If the installation was 
actually into a partition, NOT to the whole disk, then it MIGHT work -- I 
don't actually know enough about that case to say.

*BUT*, the preferred grub1 installation, and the MBR-preferred (in the 
absence of GPT and a dedicated BIOS boot partition) grub2 installation, 
would use the slack-space before the first partition for the grub1 
stage-1.5, or grub2 core.  Assuming your partitions were setup with such 
slack-space available (the default for most installers, certainly in the 
MBR era before GPT with its dedicated BIOS boot partition), the most 
likely case is that the grub2 installation overwrote not only grub1's 
MBR, but also its slack-space installation, and simply repairing the MBR 
will thus leave an unbootable system... unless of course you have a 
backup grub installation on a second disk or thumb drive, as I suggested 
above.


That addresses the first half of the question, what about the second 
half?  What do you need to do to change the boot order in the (grub2) 
korora setup?

A punt answer would simply refer you to the korora documentation or user 
forums... and that's still your best bet as that way you'll get an answer 
specific to the distribution and any distro specific tools or 
configuration it uses.  However, there's a more generic answer that 
should apply to all grub2 installations...

As I already stated (twice I think, so this makes three), grub2 is vastly 
more powerful and flexible than grub1.  However, this does make it more 
complex as well.

There's actually two different methods for configuring grub2.  One is 
real dumbed down and simple, simpler than grub1, thus making it both 
harder to screw up and harder to do anything complex with, the other MUCH 
more powerful than grub1, but also a bit more difficult to learn... tho 
not really much harder than grub1 configuration for those who are already 
familiar with it, just a bit different, particularly if you choose to 
stick to subset of configuration commands that parallel those in grub1.  
There are a a few more powerful commands available if you want them tho, 
with conditional logic and variables that will be a familiar concept to 
anyone at all comfortable at a borne-compatible CLI (command-line 
interface) shell.

As might be expected for a gentooer, I prefer grub2's advanced 
configuration method, editing /boot/grub/grub.cfg directly, as I found 
the dumbed-down simple interface too hard to work with to get it to do 
what I wanted it to do, while it was easy with the advanced config 
interface. =:^)

So I'm actually going to punt for now after all, and refer you to the 
various grub2-config-simple-method-howtos available on the web, if you 
want to do that.  OTOH, if you're up for learning the advanced method, 
just say so and I'll be happy to help you with it. =:^)

That said, at a rather handwavy general level, simply editing the simple 
indirect-config files to change the boot menu order shouldn't be 
difficult at all.  Those files are normally found in /etc/grub.d/*, along 
with /etc/default/grub.  Once you're thru editing them, you'd run
grub-mkconfig (on some distros it might be grub2-mkconfig), which 
actually writes the grub.cfg file grub2 itself uses to boot.

I should also warn you, if you choose the advanced method, directly 
editing grub.cfg yourself, you may wish to remove the grub-mkconfig 
executable, or otherwise ensure that it doesn't get run (maybe turn of 
its executable permissions), since some distros will try to run it 
automatically when they update the kernel, etc, and will thus overwrite 
your custom direct-edited grub.cfg with the configuration still found in 
the /etc/grub.d/* files.  Here on gentoo, I setup an install-mask for 
that executable, so when I update my grub package, that file is actually 
removed from the installation automatically, so it CAN'T be accidentally 
run, overwriting my painstakingly done custom config!

Meanwhile, it's likely that the grub info file is installed along with 
the grub2 package on your system, and you can read up on the grub2 
documentation at the command line using:

info grub

Alternatively, you can browse the same information as HTML online, or 
download it as a PDF for ASCII text file:

http://www.gnu.org/software/grub/manual/

Finally, other unofficial documentation (including "simple-method" 
tutorials) can be found listed here:

http://www.gnu.org/software/grub/grub-documentation.html

Or just google grub2 documentation:

https://www.google.com/search?q=grub2+documentation&ie=UTF-8


As I said, if you want to try the advanced direct grub.cfg edit method 
and have questions about it after reading the various documentation (I 
certainly did, said documentation was frustratingly imprecise in spots, 
to the point that with several things I actually ended up trying it 
several different ways until I figured out exactly what grub actually 
expected!), I'll be happy to help!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman