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 ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
