Re: [kde-linux] grub and grub2
- Date: Wed, 14 Aug 2013 14:00:56 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] grub and grub2
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
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
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
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)
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
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
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:
Alternatively, you can browse the same information as HTML online, or
download it as a PDF for ASCII text file:
Finally, other unofficial documentation (including "simple-method"
tutorials) can be found listed here:
Or just google grub2 documentation:
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
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.