The Refind Binary File Is Missing Aborting Installation Artists

Thanks, guys, appreciate the nice comments. After a 40-hour writing week, though, I'm not sure I feel I've made any unique or creative contributions yet. It's too soon in this game, not enough out on it, and the product isn't even finished yet to tell where this might go. Still some quirks, bugs, incomplete parts, I think. Maybe we'll all just become crafty menuentry writers, pushing the grub-update button, and that would be OK, too, as long as it works. This sure as heck is a work-in-progress.

The GRUB 2 Manual is not even close to being finished (based on what's published). I also notice that there may be several versions of GRUB 1.xx that we are all using, as some experiments seem to go for some users, while other experiments fail. I'm using 8.04.3 with whatever 1.96x came down through apt-get install, no updates offered yet. Way too early for all this, but I wanted to block out something. I'm hoping for a good job done on the official Manual with some verbiage explaining more about the design of GRUB 2, how it works, and examples/tips and tricks and basic trouble-shooting tips. Much of GRUB Legacy applies to GRUB 2, and all of Linux command usage does.

Gentoo Linux Howtos: Portage - >Browse Portage. Ebuild name: sys- libs/binutils- libs- 2. Core binutils libraries (libbfd, libopcodes, libiberty) for external pa. Added to portage. Share Li-Cor 2008 - LI-6400XT-v6.1 Embed size(px) start on Link Report Description Text Using the LI-6400 / LI-6400XT Portable. Lightscribe Software Downloads Lightscribe Labeler - Hack Springfield Halloween 2013 - Wwe Superstar Rock Song Free Download - The Refind Binary File Is Missing Aborting Installation Definition - Api 2201 Fifth Edition - B &Amp; G Hydra 330 Manual.

In fact, it's all so new, new language, new notation (scripts), new rules, and is sort of high-sounding, but not really all that earth-shattering for the average user: you edit a default file, edit/create a script file, do an update-grub, and that's it. A sudo grub-install /dev/sdx gives you a brand new ride. Of course, we'll need good specific examples for a variety of special applications.

From the user's perspective, I have the feeling that GRUB 2 is fairly straightforward, the main difference being how the configuration menu is treated. The trick lies in having good solid script files in /etc/grub.d, especially the 10_linux and the 30_os-prober, scripts we can rely on to get everything generated just right without a hitch, and in having grub-install work right, as well as update-grub. I also feel, for the first time, that good a GUI makes sense (finally) for configuring the (inputs to the) boot menu. I can't imagine helping newcomers through the logistics of some of the editing required to get certain boot menu's going. That said, it's all there in the how-to, as well as that of drs305 (kinda hard to beat what he has done--really good, knockout job he's done--and I hope he continues and expands his how-to's). I reserved Reply #1 in case it's needed, and I would guess that would be for specific applications/examples. If anyone learns something new, discovers something, has a neat use of the bootloader, a better way, a better view, a trick (no ponies, please), whatever, I hope they will post it.

Depending, I may reference it and/or package it (and/or copy it), with full reference and credits to the OP, maybe stick it in somewhere, e.g., in Reply #1. A quasi-wiki? I have a feeling that for the average PC user, or someone dual booting a dozen or so OSs on a few drives on a standard PC, nothing is very much changed.

I like the new design. It's clean, elegant, and fairly straightforward, at least conceptually. Just use what you know from GRUB Legacy to (creatively) rig up menuentries, format them as script files, run update-grub, and go, possibly with a grub-install now and then. I do hope that the OS prober thinger, well, does its thing very well.....:) As for dual-booting, I think it's about the same as for GRUB Legacy. The trick will be relying on the OS probe-thing to gather up all the OSs.

Otherwise, you'd simply have to rig up a custom boot script file (in /etc/grub.d) for the OS that was missed. My probe-thing missed sidux, which is why I had that as an example of a custom boot entry. May have to lean on symlinks a lot for awhile, or chainoader, doing an extra sudo grub-install /dev/sdxn here and there. Configfile may not always go (as I found out), probably because of a mismatch between the GRUBs.

Update 9-20-09 My first DRAFT of this how-to was written using 8.04.3 and the GRUB 2 1.96x from the 8.04.3 repositories, and many things didn't work or worked but not very well. After trying 9.10 Alpha 6 with GRUB 2 1.97 Beta3, I find that most things work very well.

This update (9/20/09) is based on further testing done in Kubuntu 9.10 Alpha with the newer GRUB 2 version. Somewhat extensive today. Lots of copyediting (punctuation, spelling, and some formatting). And the following items were improved/modified: -- The Table of Contents -- Section 3, Fixing Things Added: To see or to hide the boot menu -- Section 3: Key Rescue Method: Re-installing GRUB 2 using Live CD I included another method from Live CD based on some testing I did this morning. -- Section 4, grub>GRUB's CLI From the Boot Menu; the 'c' key I added some comments about using the boot command at the grub>(but that it is not necessary in grub.cfg).

-- Section 4, dedicated GRUB partition: >Modified steps to include setting the boot flag on the GRUB partition using GParted Live CD. >Gave a better (and fully tested) example of making your own dedicated GRUB partition grub.cfg file.

>IMPORTANT NOTE ABOUT KERNEL UPDATES: how they do not apply to your dedicated GRUB 2 partition. -- Section 4, booting methods I added another way to do symlinks (using root=/dev/sdxN instead of root=UUID=yyy). ------------- To Do: Lots of things, over time. Review everything. Better organizing, tighten it up here and there, add new topics as appropriate, do more testing, see what the (final) official Manual has to say about all this, review the Cheat Sheet, and do more copyediting, etc. Update 9-22-09 Again, rather major. More cleaning up, checking, tightening, copyediting.

New topics (e.g., Troubleshooting Outline, GRUB 2 flash drive, working at the grub>to boot an OS). Expanded treatment of some important topics (grub-install, grub>ls, etc.) SECTION 1: Introduction Cleaned up a lot.

SECTION 2: Key Facts About the Boot menu, grub.cfg Much improved; material added; better formatting. SECTION 3: Fixing Things Cleaner, neater. Continuing from yesterday. Much improved cheat sheet (actually 2 pages in 12-pt. Type if printed): SECTION 4 Cheat sheet: GRUB 2 Practical Reminders: listing of key files, commands, methods and much improved SECTION 4 4 ways to boot an OS: configfile, symlinks, direct booting, chainloader (just in case someone is reading this stuff and wants to track changes) EXTRA--EXTRA Did you know? Grub>ls (hdx,y) tells you about partition (hdx,y) INCLUDING its UUID.

(that is, you did notice the GRUB 2 prompt, right? =>UUIDs available in the GRUB shell now). GPT: GUID Partition Table =>Testing GRUB 2 on your GPT-partitioned flash drive See Reply #1 to the GRUB 2 how-to: GPT: GUID Partition Table.

New stuff It appears that update-grub has been replaced by grub-mkconfig. I have made the switch throughout the how-to (in the first post of this thread). Notes about some of the new GRUB 2 commands Included: chainloader, ls, grub-emu, grub-mkconfig (many tips!), root, rootnoverify (is gone), grub-setup =>=>See Reply #1 above. I ran out of room in the original GUIDE (exceeded the 100,000 character limit) and so for now I put the new material in Reply #1. There's some good stuff to look at, esp on grub-mkconfig, but also some other technical details. General: Still working on this, getting new info on GRUB 2.

I intend to clean up the how-to, make it tighter, better, and do something about organizing it better. This is important enough to make note of a correction here. I went through the how-to changing update-grub to grub-mkconfig. However, when actually used as a command, update-grub does not require an argument, whereas grub-mkconfig does (to change grub.cfg). I think I caught all the corrections, but will be working on this some more, and for now note this post and specifically: Note: update-grub The command update-grub generates a new grub.cfg file and replaces the existing grub.cfg with the newly generated grub.cfg (by default). But, as explained next, you must specify the output file when using grub-mkconfig.

Using grub-mkconfig correctly: -o option, or --output=FILE grub-mkconfig --help tells you. Note that sudo grub-mkconfig prints its output to the screen (default = stdout). To print to the grub.cfg, use sudo grub-mkconfig -o /boot/grub/grub.cfg or sudo grub-mkconfig --output=/boot/grub/grub.cfg. The edits are all incorporated into either the original post or Reply #1. However, I'm still working on it. I made some changes/corrections, but this is still in-progress. I have tested everything on my PCs (and sometimes failed, like with the chrooting method for Live CD GRUB re-install--but my other 'Method 1' works OK).

I've spent hours studying the grub-devel posts to get new/more info. We have not yet seen any official Manual. But I think my how-to is in pretty good shape, EXCEPT it needs some editing, re-organizing, tightening, and more additional/new topics as they arise. Yeah, the device naming. Most every other field of application starts hard drives at zero, so that's kinda fixed. But those partitions should start at 1. Except, now, you're right, since we're used to GRUB Legacy, it's going to take some getting used to partly because of this now-obvious mismatching of hd's and partition numbering.

As for a GOOD GUI (one that works in all or most cases), I agree. It is needed. Editing scripts or making them in the first place, is a bit too much to ask most users to mess with. Upgrades will keep grub legacy That's a weight off my mind:) Yep. I expect some issues with grub2 initially, like everything else.

I am testing kubuntu-netbook Karmic on my Dell Mini, installed on a USB stick for now. I had a weird situation where grub2 would not boot, and a quick google took me to a workaround from a bug report in launchpad. Also, even after the workaround, there is a 10 second delay between the time I choose a kernel and the time it starts to load. Of course we are still at the beta stage, so you expect things to break a bit here and there. But I think I'll wait a few weeks after Karmic release to have a real install of kubuntu on the Mini (still running Ubuntu 8.04.2, Dell version).

Thank you very much for this howto! I did not find it yesterday when I was desperately searching for ways to get my system up again after a failed install of grub2. The installation of grub2 is still not as polished as it could be. In my opinion, the installation really needs to be foolproof and if the user forgot to make a choice, the installation should stop and ask for it. This is one of those situations where I think a well laid out graphical installer would be a good tool. One can never get too careful with an installation that has the potential of bricking your system.

Actually, a nice interface that first showed you what you have now, then listed the options for grub2 and allowed you to make appropriate changes would be nice. Maybe combined with the partition manager? Customizing the boot menu Editorial (mine) I don't think we all should be editing the scripts that drive GRUB 2 configuration. Script writers, of course, excepted.

Furthermore, if you re-install GRUB 2 (sudo grub-install /dev/sdX), any custom edits you made will be overwritten and you'll have to re-do or restore your edits (e.g., copy/paste from backups). I think the devs should eventually develop GRUB 2 to include easy-to-use facilities for making a reasonable set of custom edits to your boot menu.

That could be done through /etc/default/grub. Or, perhaps, someone could come up with a Very Reliable (TM) GUI. End of editorial comments.:) Now, on to business. As explained in the how-to, grub.cfg determines the boot menu you see on the screen, and it is generated by files in /etc/default/grub and the scripts in /etc/grub.d.

The script 10_linux generates menuentries for kernels on the same partition as the current (default) OS (the partition where the grub.cfg is located that controls the boot menu). The script 30_os-prober controls the menuentries of OSs (Linux and Windows) located on other partitions. One way you can customize the boot menu is to simply disable the execution of the automatic scripts in /etc/grub.d, then build your own custom grub.cfg. The tools for doing that are straightforward and are covered by the how-to, or see: GRUB 2 Basics.

Another way to customize the boot menu is by editing the script files in /etc/grub.d. That is covered by a new how-to, also by drs305: Grub 2 Title Tweaks, by drs305 Highlights 1 Quote: 'This thread offers tweaks to the Grub 2 10_linux and 30_os-prober files in /etc/grub.d.

The purpose is to change the way Titles are displayed on the Grub 2 menu.' 2 Quote: 'To inhibit the display of recovery options on the primary partition, uncomment or add this line to /etc/default/grub: GRUB_DISABLE_LINUX_RECOVERY=true' 3 Quote: To inhibit the display of memtest86+ entries from the main partition, make the /etc/grub.d/memtest86+ file non-executable by running this command: sudo chmod -x /etc/grub.d/20_memtest86+ 4 Quote: D. Removing MEMTEST+86 and Single User Entries (from other partitions) Grub 2 provides the ability to hide memtest86+ and recovery mode (single user) entries for the default partition (see below). I have not found a similar ability to inhibit the display of these entries found by 30_os-prober on other partitions. To tweak the files to hide memtest86+ and recovery modes for other partitions: [etcetera -- see the Tweaks how-to] 5 Quote: E. Removing a Specific Kernel (from other partitions)* [found by 30_os-prober on other partitions, etcetera -- see the Tweaks how-to]. I tried to add a background image and change resolution of grub and following the instructions in this thread it was really easy.

A little image editing tip for those with widescreen monitors: I checked what resolutions my graphics card supported and was actually a little surprised to see that 1024x768 was the highest resolution. And as I have a widescreen monitor on my laptop running at 1280x800 images would look a bit weird unless you use this trick: Open the image you want to use and crop it to 1280x800. In Photoshop you can easily do this by setting a specific resolution for the crop tool. The ppi setting is not important, in fact you can set it to any number you want. It does not change anything (only for printing):-) Then go to resize the image.

In the dialogue box, you need to turn off the function that keep the image proportions correct. Often marked by a little chain between the with and the height numbers of pixels. Click on it to 'break' it. The just type in 1024 and 768 in their respective boxes and resize it. You will now have an image that is slightly squeezed horizontally. But when your boot menu shows, it will be stretched across the whole monitor and look just like it should. Nice work Oceanwatcher:) For now, as we get organized with the new GRUB 2, I added in Section 4: Boot menu: Background image editing tip for those with widescreen monitors and then in the text of Section 4, I cited & referenced your post.

Boot menu graphics seems to be a popular topic. Maybe someone should do a how-to on it for GRUB 2. We have one for GRUB Legacy, by dibl: Grub Splash Image, how-to, dibl I'm not sure how to use that one in such a way that people clearly see the GRUB 2 application. I'll leave this whole thing to your guys to do if anyone cares to!;).

Dual booting, 2 HDDs Wow, it _did_ work. Wow, I got the 'GRUB Loading _' message for 60-90 seconds while my hard drive was active, until I got the grub.cfg boot menu on the screen!!! -- D915GAVL Intel board -- 2 HDDs -- SATA sda: Windows XP and an unused GRUB partition -- SATA sdb: 15 partitions, several OSs -- First BIOS boot drive: sda -- GRUB 2: Installed from 9.10 on sdb3 to the sda MBR (= the first BIOS boot drive) -- grub.cfg (in sdb3): Perfect; all OSs present and accounted for (and several copies of Memtest!) So, it works OK on my machine, but something is amiss with the long loading time for GRUB 2 boot.img -->core.img? Just an fyi, is all.

Not too big a deal right now, probably just a bit buggy at the GRUB 2 beta 3 stage. Anyone else notice this? EDIT 10-16-09: Bug #420933 https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/420933/?loggingout=1.

There is a delay for me on a USB drive, maybe around 15 seconds? It isn't while loading grub, but rather, from the time I select a kernel and the time it appears to be loading it. Although, this could be just that the kernel is loading but there is no feedback to the user.

But I thought, even if this is a real issue, it is an issue with USB media: (Kano is a Debian dev). This is scary. I googled for 'slow grub-2' for my issue and I didn't find any obvious fix or workaround in general for this. FWIW: I am not customizing grub2 at all. I've gota try the setting of Image for Grub.

Since redoing my machines, I miss my grub background. I do have to make note about GRUB2. Initially it did not detect my WINXP on my second (and not primary) HD. After a recent kernel update, it did, and here is the kicker that I like, it actually handled WINXP 'wanting to be the first HD/partition' crap.

That was nice. I didn't even have to edit anything. The old GRUB had the 'KGRUBEditor' tool, which was very nicely written.

Hope someone can do that for GRUB2. Updates Added to Reply #1: Dual booting, Windows on non-first HDD Dual booting: How to set it up Installing two or more Linux operating systems RECOMMENDED METHOD PROBLEMS Messing up the booting -- fixing GRUB without re-installing Kubuntu Windows topics Installing XP (or 7? Or Vista?) & Kubuntu: How to set up dual booting (recommended outline) Re-installed XP and now can't boot Kubuntu XP on a non-first hard drive: (hdx,y), x >1 Booting XP on a non-first hard drive The drivemap command in GRUB 2 @MoonRise Thanks for that info about how GRUB 2 automatically configured Windows on non-first hard drive (drivemap command in grub.cfg). Good to know. In fact, one could try running grub-mkconfig and/or grub-install and see if that might work to generate the proper boot entries for Windows on a non-first HD before going to all the work to do it manually. Good tip -- thanks again! @MoonRise Thanks for that info about how GRUB 2 automatically configured Windows on non-first hard drive (drivemap command in grub.cfg).

Good to know. In fact, one could try running grub-mkconfig and/or grub-install and see if that might work to generate the proper boot entries for Windows on a non-first HD before going to all the work to do it manually. Good tip -- thanks again! It definitely tries. At least to detect other Linuxes. On my USB install, it detected the Kubuntu on an SDHC and the Ubuntu on the SSD (I didn't try to load those, and the USB drive had a corruption on the partition table so I can't test it quickly).

There is a function that I loved in MacOS (not sure if OSX has it. Never tried!). Back in the days of PowerMac's etc. I used to have at least one external harddrive with a separate OS installation.

This way, I could use the control panel to tell the system what harddrive to boot from next time. Of course, it was SCSI then, not USB or eSATA. I am wondering if it would be possible to install a distro to a USB drive, and then use the UUID in the boot menu so it does not matter what USB port I plug it into, or how many other USB devices that are plugged in? That mean I could have a couple of extra harddrives just for testing other distros. I do have VirtualBox installed, but I think it is better to have a full installation of the OS to really get a feel for it. Any thoughts on this?

Will an installer allow you to install on a USB drive? There is a function that I loved in MacOS (not sure if OSX has it. Never tried!). Back in the days of PowerMac's etc. I used to have at least one external harddrive with a separate OS installation.

This way, I could use the control panel to tell the system what harddrive to boot from next time. Of course, it was SCSI then, not USB or eSATA. I am wondering if it would be possible to install a distro to a USB drive, and then use the UUID in the boot menu so it does not matter what USB port I plug it into, or how many other USB devices that are plugged in? That mean I could have a couple of extra harddrives just for testing other distros. I do have VirtualBox installed, but I think it is better to have a full installation of the OS to really get a feel for it. Any thoughts on this?

Will an installer allow you to install on a USB drive? Yes, you can definitely install onto a usb drive, which is slow as hell (particularly the writes), unless you buy a really expensive, performance drive. Grubn (at least legacy) can use the disk UUID when you specify the root filesystem. The only connection dependent thing (Qqmike, pls correct me if I am wrong) is the specification of the boot partition, which is of hte form (hd1,0). But that, you can edit the grub entry and try the only few combinations (hd0,0), (hd1,0), etc In fact, a much easier way is to install a bootloader in the usb drive, and just boot from there.

Most mobo's these days have a special key to press at boot time, which will show you a menu of existing drives, and choose where to boot from. On the Dell Mini you press 0. Actually, there is a message indicating that, while the BIOS is being loading on start up. Hope this helps! I did some experiments once, and as I recall, a given USB flash drive got assigned a UUID that stayed fixed and stayed with that flash drive, no matter what. You might try a few simple experiments to see how exactly it works. Yes you can install a full Kubuntu to a USB flash drive.

When the PC boots from the flash drive, it is, of course, seen as hd0 and your other drives get shifted. So hd0 becomes hd1, hd1 becomes hd2, etc. (Unless adrian 15 develops a usbshift function for GRUB 2 Super Grub Disk--which he may very well do soon). Thus, if you also want to use the grub.cfg on that flash drive to boot other OSs, you must take this drive shifting into account.

There's a lot of this (good:) ) stuff in another of my how-to's and the Replies to it: -- How To Make GRUB Thumb Drive You might use ext2 to minimize wearout of the flash drive (though I've never read of anyone having that problem, it is possible over time). As a backup, I always clone a flash drive using dd. For that, another how-to:) -- dd Command See the Experiments in reply 1. One of my links/references is Grub 2 Basics, by drs305 It focuses on the grub.cfg.

The name has just been changed to The Grub 2 Guide Looks like topics will be expanded beyond grub.cfg to more general GRUB 2 subjects. I have not read this last update but plan to today sometime. If you're hungry for more reading, there's some, updated 4 hours ago.

Herman has not yet done anything more (since 8-1-09), nor is there anything new (or substantial) in the official Manual yet. It looks to me that Herman is shooting for a comprehensive, encyclopedic 'manual' of sorts. I was hoping that the official Manual would do that (e.g., with links to all the man pages, lists of all the files, etc.). Best to pick a few of these, perhaps half a dozen (as they develop), read them all, and get unique tidbits and twists from each. I believe mine has been/is being translated for the Greek Ubuntu forum (not sure the status of that).

Of course, it would be best if we get a good Manual and especially a good GUI! Happy reading (if this happens to be your hobby, that is). Thanks for the feedback, lmilano. 'It might be handy to have the cheat sheet on the top.' That's also how I'd like to see things and thought about it before, but I hate to scare folks away with that sort of rather technical summary. Let's see how all this goes as GRUB 2 lands and evolves and we see the official Manual (although I'm beginning to have my doubts about the Manual appearing, down to the wire here). I'd like to see the cheat sheet on top.

I copied to OOo Writer and printed one out and keep it next to the PC (on a pile of other 'must-have's.' GRUB 2 how-to's, status I'm still playing with GRUB 2 and will be adding to my GRUB 2 Guide as we go along (see the first and second posts of this thread). Lately, I'm looking at some live iso boot issues. I'd say between what I've done and what the following guys have done, you have a pretty decent source of help on GRUB 2 as Karmic hits the scene.

The Grub 2 Guide, drs305 (formerly Grub 2 Basics), updated 3 hr ago Tip: Very good on the grub.cfg! Good on /etc/default/grub options. Recently, he added booting from live iso. I'm in touch with the author, and he's been doing a very nice job explaining GRUB 2 to beginners. GNU GRUB 1.97, updated 10-26-09 Tip: Especially strong on graphical aspects--boot menu, colors, splash images. Also contains a fairly complete cataloging and classifying of commands. HOWTO: Booting LiveCD ISOs from USB flash drive with Grub2, by JustRon.

Kind of specialized, but also kind of neat. Comment live iso booting -- Looks to me like the following author started this topic for GRUB 2: MultiBoot USB with Grub2 (boot directly from iso files) Somehow, he figured out the linux kernel boot options, and since then others are repackaging his work, adjusting and fine-tuning to special use cases. This is interesting stuff.

You can put a bunch of iso's on a flash drive and boot them. I'll be posting such a how-to at some point, but for now, you can put it together yourself from panticz and JustRon links. EDIT: No substantial work has been done on the official Manual for quite some time, although it says 10-10-09 last edit. New special topic added to Reply #1; easily extended to other use/applications. (Table of contents in both the original post and in Reply #1 modified to include this topic.) Boot From ISO -- use of GRUB 2 loopback Boot your Kubuntu Live CD ISO from your flashdrive GRUB 2 includes a new command, loopback.

Use loopback to make a device from a file. We'll put the Kubuntu Live CD iso file on a USB flash drive and boot the live OS from the iso on the flash drive. So, when done, you will boot your PC from the USB flash drive, get a boot menu, select an option corresponding to your Kubuntu Live CD iso file (which will be located on your flash drive), and you will then be booted into a Live Kubuntu session (corresponding to that iso). Read on in Reply #1).

Just when you think you have it made in the shade. Two HDDs, GRUB 2 runs the show from 9.10 OS on the 2nd HD. Various OSs on both HDDs.

=>Typical (or, at least, not atypical) setup. With GParted Live CD, just now doing routine partition work: simply created a FAT32, 40 GB DATA partition from unallocated space on sda. Up comes my very slow-to-boot GRUB 2 (because there's a known GRUB 2 bug with 2 HDD dual boot--see posts above). OK, no big deal, sitting there reading 'GRUB Loading.' Instead of eventually booting me to a GRUB 2 boot menu. 'No such disk.' Grub rescue>Boom.

I tried everything at that GRUB 2 rescue prompt, nothing worked, all got 'Unknown command.' Not even help or reboot or quit or exit or normal (mode). Nada, nothing worked. Well, needless to say, very much needing to get into my OS to finish some work, I did a hard reset of the PC and rebooted into 8.04 Live CD session, where I re-installed GRUB Legacy (read: Good Old GRUB) to run the boot show for awhile.

Nothing felt better than to be in 8.04.3 with GRUB legacy and trusty Konqueror file manager that knows how to identify my partitions and get them mounted as needed. I can't recall a situation where GRUB Legacy ever once failed to boot after creating a simple, independent data partition. GRUB Legacy doesn't care what's in your fstab or not, or on your disks, as long as you've installed some boot machinery and _something_ to boot into (or for that matter, nothing to boot into).

Normally I'd say, 'Of course this is easy to fix.' But then, WHAT broke?! GRUB 2 shouldn't care about my partitions; it should just probe them. The only possible fix I can think of would be to re-install GRUB 2. When I have time to play around, I'll try that.

(Conjecture: something in GRUB 2 about UUID is broken.? ) This is a sloppy way to release a new bootloader, and with no official documentation (i.e., guidance on the workings). But when these things happen, there is GRUB Legacy as another choice. And the bug reporting system seems responsive. Just gotta bear in mind for now that GRUB 2 is not yet ready for general use and is, in fact, still in testing. My experimentation with grub2 and a new Intel mac is not going so well.

It's compounded by the fact EFI is a lot different than the classic MBR approach I'm used to. I have a native install of Karmic with grub2-pc installed in the MBR of the partition itself. I compiled the latest grub2 from subversion with EFI support. It displays 1.97 in the grub shell when I boot it from USB. I ran grub-mkimage to create a grub.efi boot image file and copied it to a USB drive and blessed it.

Blessing volumes was new to me until I started this experiment. It basically does on a Mac what grub-install does on a PC. I had some initial problems with the image I created missing some modules but I'm pretty sure I have everything I need now. I can get to the grub shell and run commands.

I don't think it reads the grub.cfg file I created in the blessed directory on my USB. I can see my linux and OS X partitions but so far I can't get grub2-efi to boot either one. I have tried to chain load OS X and get a read error. I also tried to start Karmic and it locks up after boot.

I might need to issue some additional commands or add some options and maybe it will work. Below is what I tried and nothing happens after I type boot. Grub-sh>set root=(hd2,3) grub-sh>linux /boot/vmlinuz-2.6.31-14-generic grub-sh>initrd /boot/initrd.img-2.6.31-14-generic grub-sh>boot I found out from devs on IRC grub-efi can only chain load other efi files so it can't handle the grub in my Linux partition. They said something about appleloader but I can't find a whole lot of information on it. If I get this working it will likely be from the grub shell.

I'm not sure the config file is found even though it's there I'm never presented a menu. Well, you're beyond me. My experiments with GPT were quite limited and quick w/GRUB 2, and no experience with EFI. I did notice grub-sh>linux /boot/vmlinuz-2.6.31-14-generic Do you not have to pass to the kernel the location of the root file system (of the OS)? Grub-sh>set root=(hd2,3) is a message to GRUB 2 (telling it where the controlling GRUB 2 files are). That's different from telling the kernel where the OS root filesystem is.

Something like: grub-sh>set root=(hd2,3) grub-sh>linux /boot/vmlinuz-2.6.31-14-generic root=/dev/sdXn grub-sh>initrd /boot/initrd.img-2.6.31-14-generic grub-sh>boot For example, if the Kubuntu root filesystem is also on (hd2,3), and if (hd2,3) = sdc3, then you'd have grub-sh>linux /boot/vmlinuz-2.6.31-14-generic root=/dev/sdc3 ro as an example (ro = the kernel is to mount sdc3 read only, which I think is the default anyway). And, of course, you know the list command grub>ls which helps you make sure you have the right kernel files and such. (my how-to in OP talks about ls, I think under SECTION 3). Let us know how you do with this, if you wish. I created an image with the following modules: part_gpt, hfsplus, fat, ext2, normal, sh, chain, boot, configfile, linux and appleldr.

According to the devs on IRC you need the normal and sh modules for grub.cfg file support. I have those included but still no luck displaying the boot menu. I have the grub.cfg file in my blessed directory (/efi/grub on my USB as suggested on the WIKI). I still can't get past the grub shell. Initially I'd settle for the grub.cfg file being read and the menu presented instead of going directly to the shell. I'm always presented with 'sh:grub>6_' when I boot. I'm also not sure how to interpret my drive geometry in grub.

It sees it as (hd0) (hd1) (hd2,1), (hd2,2) and (hd2,3). My laptop boot drive is seen as the third hard drive. My USB is formatted HPS+ with one partition. I expected to see (hd0,1), (hd1,1), (hd1,2) and (hd1,3) or maybe the USB with two partitions but not (hd0), (hd1) and (hd2.).

I'm still confused by that result. I'm not able to browse (hd0) or (hd1) from the grub shell and no partitions are shown. I can browse (hd2) no problem, all my Karmic files are on (hd2,3) and I can see them from the grub shell. I tried root=/dev/sda3, root=/dev/sdb3 and root=/dev/sdc3 for good measure and it always hang on boot. That's where I'm at as of today. I might just create a bloated image with all the modules.

I counted 99 mod files in my grub build directory. Well, as you know, I have no clue about the EFI business. Nor why the geometry came out so weird. Certainly, as an extreme-case test scenario, I would load all the modules just to see if it will go right (and then tracing down the helpful module(s) might be fun).

Those 99 files don't take up a whole lot of space (I'm forgetting the MBs and am not in that system right now to check, was it 10 MB or 30 MB?). *****************EDIT Just one note: The boot drive is always seen as hd0, right? That is, the drive you actually boot the PC from for the current session will be seen by BIOS as hd0 (and seen also by GRUB as hd0). Are we in the twilight zone, or just plain confused, or lost? Dual booting OSs on two or more hard drives using the FINAL Kubuntu Live CD Desktop installer.

I have no problems doing it. The final step (Summary) of the Manual partitioning option allows for placement of GRUB 2 in any MBR or in any partition of my system. No problem on my system. However, Vinny has tested it on his system and found (using the Advanced button in the Summary step) that he did not have the option of putting GRUB 2 on sda--only option was on sdb (of a 2-HD system). Reply #87: 236 Even more confusing, the kubunuguide says this: Installing multiple OS on a single computer Warning: Kubuntu Desktop edition installer no longer allows a custom installation of GRUB, and it now uses GRUB2, which allows very little customization. DO NOT USE the Karmic Koala Desktop edition if you use a boot partition, use multiple OS (more than 2), or chainload bootloaders. The Kubuntu installer will overwrite your Master Boot Record and you will later be forced to recreate it.

This is a serious flaw in Karmic Koala. Use the Ubuntu Server edition instead (and then later add the kubuntu-desktop).

If you want to install more than 2 operating systems on a single computer, check out these tips. [End quote] 'These tips' are here: ->->Yet, again, I have no problems doing what it says can't be done. I have no clue what's going on.

But I do believe that some users are experiencing various issues like the above. Are these problems specific to Kubuntu? (and not to Ubuntu?) I don't know--again, my time to test and troubleshoot and investigate is limited. - - - - - - - - - - - - - - - - - - - - Another bug is supposed to be fixed now (again, sorry, I haven't had time to test the fix): Current grub-pc takes several minutes to show menu Applies again to a dual-boot/multi-disk setup. (This has been added to References at the end of the OP.) GRUB 2 Bugs and Questions “grub2” package in Ubuntu Bugs: Questions, Open Questions - - - - - - - - - - Fixed: Current grub-pc takes several minutes to show menu (slow boot times with multiboot, mutlidisk) Fixed (in PPA): See #77 & #80. It had not really sunk in until I spent a few hours today playing with USB sticks and ISO images and Grub 2: You gotta have major parts of a complete unix filesystem (/boot, /etc/default, /etc/grub.d) before you're going to get a USB stick/partition booting with Grub 2. I was working with an E-Live CD ISO, which uses a very abbreviated, CD-centric filesystem for the Live CD (think 'autorun.bat').

I gave up before I tried setting up the required /etc directories and files -- I dunno if I ever would have got it booting or not. One reason to keep a legacy Grub-based Live CD handy, I guess. What I know about GRUB 2 capability 'boot from iso' is in Reply #1 of this thread, a brief experiment where I confirmed it seemed to work (for me) (from iso on flash drive), one I did so long ago I've forgotten all details (except I recall there were some quirks).

(with references) But, as of today, there do appear to be some problems. From a respectable source, Booting from a LiveCD ISO This section [14] is under construction. Although I have been able to successfully mount the 64-bit Karmic desktop ISO the results among the other releases is not consistent enough to post. Hi Mike, I've been looking into grub2 myself recently, and decided to write up what I figured out. The info is not so much for 'end users', more sysadmins or developers beginning with grub.

I'll pretty-format the info later, but there is a draft available here in case anyone here is interested: Is this manual you are preparing going to be just a Kubuntu thing, or also available elsewhere? If it's a general-purpose OSS manual, then I'd be happy for any of this text to be reused if you wish - just let me know. Oh, and any corrections very welcome! I have a problem???

I'm trying to translate a grub legacy stanza to grub2. Thing is, we have two win98 and one win95 C:/ disks. Before booting any one of them the other two have to be hidden. In grub legacy this could be done with hide/unhide.

I've googled a bit but no joy. Sooo, over to Qqmike:D Before I commit grub2 to a friend's system who is obviously _rather_ conservative in his choice of OS and he wants to install Ubuntu I would like to know how to hide/unhide different root file systems using the latest sdg disk, i.e.

Command line grub2. I've scanned the six pages of this thread, so it is not for the lack of trying:o Here the setup: hd (0,0) - win98 English hd (0,1) - win95 hd (0,2) - win98 German hd (1,0) - ubuntu hd (1,1) - free (root) partition hd (1,2) - free (root) partition hd (1,3) - free (root) partition hd (1,4) - extended partition hd (1,5) - first logical (/home) hd (1,6) - second logical (/empty) hd (1,5) - third logical (/backup). Okay, the following solved it on GRUB2 CLI. To boot the third hidden C disk of a paradigm of win9x go to GRUB2 CLI, press 'c' for command line: parttool hd0,1 hidden+ boot- parttool hd0,2 hidden+ boot- parttool hd0,3 hidden- boot+ set root=hd0,3 chainloader +1 boot Now I wonder how to have a separate boot partition for grub2 seeing that essential boot records are placed in /etc/ which is of course OS dependent. Homework to do, 'cos I'm sure there must be a simple answer (such as reading this thread, perhaps?):).

I did manually edit for a while but I no longer need to or do. The files that your supposed to edit are /etc/default/grub and the rest are in /etc/grub.d. I have found that as long as I'm using the same version of GRUB2 in my installs and my default/grub and 40_custom files are the same, I can run update-grub from any of my installs without problems. Of course, when you do a new install you have to be careful not to overwrite GRUB2 unless you know for a fact it's the same version (just to avoid possible incompatibilities). I think soon we will be able to have a new install option of 'use the GRUB currently installed' rather than re-install GRUB every time or install with no boot loader.

If I'm not sure of what version of GRUB the new install uses, I install GRUB to the install partition, then once I'm sure the versions are the same; manually add the GRUB mount point to the new installs fstab. To directly answer your questions: /boot/grub/grub.cfg is the file that contains the boot menu and sets the GRUB parameters. If you needed to do manual edits you can do them and they will not be overwritten until you run update-grub. The files you're supposed edit that will insert your choices into grub.cfg during updating grub are: /etc/default/grub /etc/grub.d/00_header /etc/grub.d/05_debian_theme /etc/grub.d/40_custom In theory, if all your installs have the same version of GRUB and all these file match then you should get the same results from running update-grub regardless of which install you run it from. Also note my experience with GRUB2 is only with (K)Ubuntu. Yes, Qqmike is pretty amazing:) By the way, is this a known bug or something? Grub2 is autodetecting another partition with Kubuntu perfectly, but it assigns the root directory wrong.

Here goes an example: search --no-floppy --fs-uuid --set fff011a2-5131-4ba5-a1ea-f8c18b3a3859 linux /boot/vmlinuz-2.6.32-21-server root=UUID=e1c15c83-23cf-4bfb-a043-ba ro quiet splash acpi_enforce_resources=lax /boot/vmlinuz-2.6.32-21-server is effectively in fff011a2-5131-4ba5-a1ea-f8c18b3a3859, and the root directory should be set to that same partition. However, it is being set to e1c15c83-23cf-4bfb-a043-ba, which is the partition where update-grub is being run from.

Any clues anyone off the top of your head? This is important enough to make note of a correction here. I went through the how-to changing update-grub to grub-mkconfig. However, when actually used as a command, update-grub does not require an argument, whereas grub-mkconfig does (to change grub.cfg). I think I caught all the corrections, but will be working on this some more, and for now note this post and specifically: Note: update-grub The command update-grub generates a new grub.cfg file and replaces the existing grub.cfg with the newly generated grub.cfg (by default). But, as explained next, you must specify the output file when using grub-mkconfig. Using grub-mkconfig correctly: -o option, or --output=FILE grub-mkconfig --help tells you.

Note that sudo grub-mkconfig prints its output to the screen (default = stdout). To print to the grub.cfg, use sudo grub-mkconfig -o /boot/grub/grub.cfg or sudo grub-mkconfig --output=/boot/grub/grub.cfg Thanks Q!:D Had to redo GRUB after reinstalling with 10.10 and just couldn't remember. Great to have this How To! I did a total re-installa couple of weeks ago and my laptop is now running better than it ever has. And as I used 10.04 as the basis for the re-install I am running GRUB 2 (I assume:-) ).

I had some questions a long time ago in this thread regarding the way you could (at least earlier) assign a different bootdisk in MacOS. I would love to see this functionality in Kubuntu - you go to the System settings, click on something called Boot (should probably be under 'Startup and Shutdown') and choose what should be the harddisk to boot from. This way, you could have different partitions and install a different version of Kubuntu on each of the partitions/harddisks and switch between them in a very easy way. No need to edit any configuration files etc. Just an interface with an icon for each partition and a green checkmark on the current boot partition. We did not use USB then, it was mostly external SCSI drives and it was great to be able to swap version of the os and versions of the installed programs by using this function. These days it is not too interesting to do this as long as one has a computer with enough power and RAM.

Setting up VirtualBox is not difficult and can be used to run a variety of operating systems. Last time I checked even OSX server was supported! Few tools to edit (mess?) your grub 2 >Grub2 Kcm (Description: This Kcm module manages the most common settings of Grub2. It uses the KAuth authorization system to gain root privilegies and is thus well integrated in system settings, under startup/shutdown. >GRUB2 Bootloader KCModule (Description: A KCModule for configuring the GRUB2 bootloader. This is just a preview release.

Maybe with the Kubuntu OO ( >DevelopmentCodeNames () there is a KDE Grub editor from the official repositories. And no need to wait to the OO - ubuntu/natty kcm-grub2 0.3.0-0ubuntu1 (Accepted) (kcm-grub2 (0.3.0-0ubuntu1) natty; urgency=low * Initial release LP: #745524 Description: kde-config-grub2 - Configuration module for the GRUB2 bootloader Launchpad-Bugs-Fixed: 745524 The LP: #745524 was >FFE: kcm-grub2 is a configuration module for grub2 that is integrated into KDE (The package name is kde-config-grub2 Description: Configuration module for the GRUB2 bootloader This is a configuration module for System Settings for configuring the GRUB2 bootloader. Homepage: Bugs: Origin: Ubuntu.

Edits to the GRUB 2 Guide, January 2014 & some rambling Went through it, Posts #1 and #2, editing for typos, wording, content. Pretty sure I fixed most of the old or broken links.

I added some new tips here and there. I also re-tested a few things, at the grub>prompt, trying the new Super Grub2 Disk, built a quick GRUB 2 flash drive, etc. There's a lot of somewhat decent material there, but sometimes difficult to navigate through without links within between text items.

Big one I caught was this: It should be /etc/default/grub; but in a few places I had written it as /etc/grub/default. Update-grub vs grub-mkconfig: it should be the latter, but people are still successfully using the former as well, and that's OK; but I did make a comment about it. The Manual does not mention update-grub. Update-grub is nice, faster, for example after removing old kernels and such.

Sudo grub-install --root-directory=DIR, VERSUS sudo grub-install --boot-directory=DIR The Manual has switched to mentioning only the newer second way; some say that the first way --root= won't work in 12.04; both ways work for me; many writers still use the root= way. You decide, or try whatever does work for you. I tried to insert them both at several places to show alternatives. Added topics: -- How to search the Kubuntu forums using google (site:kubuntuforums.net). -- How to remove old kernels (quoting many of you on it).

-- Included a list of GUI GRUB 2 help-repair-editing packages (but I have not yet tried them myself, but it appears others have done so successfully). -- Edited installing GRUB 2 from a live CD. -- Although I have not yet experimented with UEFI or Secure Boot, I made more mention of it, linking specifically to the new sub-forum: 'UEFI issues, links: note the subforum started by Steve Riley: UEFI Assistance: (You'll find excellent tutorial material on UEFI, GPT, Secure Boot, other boot managers (UEFI will boot your Kubuntu OS; you don't need GRUB to do the booting; GRUB is also a boot manager, though; however, there are also other boot managers you can use instead of GRUB; etc.), legacy issues, and just about everything else you might want to know as you get started with UEFI.' -->Question I would have for experts. To check out some of the chrooting methods for installing GRUB 2 via live CD. I gave two links, but there are several on the Internet. Making sense of them?

Why does one need to chroot? Is it so you can also run sudo grub mkconfig to generate a boot menu? I'm not clear on the whole thing with chrooting. And the how-to's don't seem to provide much tutorial-level guidance. I suppose the present how-to is fairly Ok-good, better than some, got a lot of special topics; but each how-to I found includes material you won't find in other how-to's. None of them is particularly tutorial; mine may be somewhat more than others; dedo's is known to be for the basics (but the advanced topics are limited); drs305's work is definitely tutorial but he has mostly stopped his and instead his material has been placed in the official Ubuntu documentation/Wiki, and again, deferring to the offical Manual. Herman has some neat special topics, he also has deferred to the Manual, his last update being one or two years ago.

The official GRUB 2 Manual is expanding in content, but it is certainly not very tutorial unless you already know what you are doing; but, thankfully, they are developing the Manual over time. I also noticed that the how-to's are not as well developed for GRUB 2 as they were for GRUB Legacy, and the how-to's are sometimes years out of date, not kept up, having limited topics, the authors deferring to the official Manual.

I don't sense the enthusiasm I had enjoyed among the GRUB legacy writers. I'm not as enthused. Not about GRUB 2 as I was about Legacy.

It's just not as fun. Unless you might be a programmer/dev/scripting expert.

Let's face is: about all an average user can do is run grub-install and grub-mkconfig, or edit the etc/default/grub file, hope, cross your fingers, and see what happens. Or copy a script someone else has written. With GRUB legacy, almost anyone could get in deep, experimenting, trying this and that, almost randomly trying out config edits, and you'd have a fair amount of successful boots. Well, I'm not an expert at any of this; I'm only an experienced Legacy user.

The only reason I wrote the present GRUB 2 Guide was because I felt like I should! That you guys needed a how-to here at Kubuntu, Grub 2 being new at the time, a bit buggy, and me being the GRUB 1.97 guy. Thankfully, I've noticed that many of you stepped in, taking over the Grub work, starting back in 1.97 with dibl, MoonRise, toad and others, and recently in Grub 2 with SteveRiley, Vinny, oshunluvr, Detonate, Snowhog, GreyGeek, and--thankfully--way too many others to list here. I've also simplified my play. Down to maintaining simpler personal systems, one or two OSs, 8.04 and now replacing with 12.04--both work perfectly and without effort on my part, one or two disks, nothing elaborate (like chainloading off a thumb drive to a hard drive to configfile a 2nd hard drive to., but gosh it used to be fun!). Not real sure how much more work I want to put into this how-to.

I'll try to at least incorporate any new commands or changes to commands. Thankfully, Post #1 is at it's word-count limit! (OS: Let's keep that at 100,000 characters!;-) ). Forgot to mention something else. Not a big deal, but I'd be curious. For GRUB tinker-ers messing around. While checking the how-to, I quickly repeated some of the experiments, and frankly, experienced some bugginess (or something) at the GRUB prompt grub.

In fact, three times it froze up and would not accept any input from the keyboard (a standard, $20 Logitech, wired), not even Esc. Sometimes a command would argue with me, sometime Tab completion seemed moody. I did, finally, get some things to go. I suspect there is some bugginess in GRUB 2, but since I have not been following the dev communications, I can't tell.

I have read things that suggest GRUB 2 may have some rough edges. For example, cautions to match up the same GRUB versions (e.g., GRUB on a Live CD with the same GRUB 2 version on the GRUB HDD installation you are trying to repair); or, some people--apparently--finding that grub-install root= may not work after a certain Kubuntu version (10.xx); in one of the black-and-white diagnostics scrolling by as I'd get hung up, some mention was made about my keyboard input being slow or some such thing, but, as I say, I was not trying to be scientific, I was simply ripping through some standard command-checking on standard PC hardware). If any of you play with this, I'd be curious how things go for you.

Sorry I didn't systematically perform and record the experiments, I was assuming what I was doing was routine stuff and would fly unquestionably. I will play with this as I have more time. For example--if you want to play--build a quick bootable flash drive (FAT 32.

Then follow the how-to instructions to install GRUB 2 to it) that will give you a GRUB 2 prompt upon booting your machine, grub. No need to have any grub.cfg on the thumb drive. Or, just boot your machine normally, get your GRUB 2 boot menu, click the 'c' key, to get your GRUB 2 prompt grub. Then, at the grub prompt grub>, experiment with the '4 ways to boot an OS': direct booting, symlinks, configfile, and chainloader. See what happens, see if you are able to freely get around. I actually did build my GRUB 2 thumb drive with the same GRUB 2 I was attempting to play on as I rebooted the machine to a grub>, so that wasn't the problem I was having: same GRUB 2 on the thumb drive that was on the HDD I was trying to boot to.). I edited the Study Guide (Post #109 above) to include two more references, the first of which you may find very interesting (the second one is very good, also, just somewhat technical to Fedora but gives insight into UEFI default booting behavior): AdamW: UEFI boot: how does that actually work, then?

(Peter Jones: The EFI System Partition and the Default Boot Behavior (http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/). Dual Booting Kubuntu 14.04 and 15.04, in UEFI mode ---------- Added 5/30/15: For solutions to some of the issues raised here, see the application of GRUB-EFI in SECTIONS 3 & 6 here: Post #121: UEFI for Kubuntu--simplified. Some dual-booting tips for Kubuntu -->SECTION 3: GRUB 2 (for EFI) -->SECTION 6: Dual/multi-booting: Know what to expect.

And how to deal with GRUB ---------- To date, the Internet articles are somewhat discouraging on dual-booting with UEFI--See the section on this below, and the links cited there. I am somewhat disappointed after conducting a little experiment of my own. Bottom-line I was successful setting up a dual boot in UEFI+GPT with Kubuntu 14.04 and Kubuntu 15.04, but it was not the way I had hoped for or the way I would prefer.

Bottom-line, more detailed In Experiment #1, I installed Kubuntu 15.04 to available space on a disk that had 14.04 installed. It worked for a dual boot, but the GRUB from 15.04 took over the booting of the PC (I had hoped they would, somehow, be independent, the setup for 14.04 and that for 15.04). In Experiment #2, I created a second ESP and had hoped the Kubuntu installer and the ASUS firmware would use both ESPs--one to set up 14.04 and one to set up 15.04. This failed: The Kubuntu installer didn't even use the second ESP--it was left empty.

The dual boot worked, but it worked exactly as in Experiment #1. Added (5-11-15): Experiment #3 Post #116 Experiment #3 As in Experiment #2, I created a second ESP and had hoped the Kubuntu installer and the ASUS firmware would use both ESPs--one to set up 14.04 and one to set up 15.04. Rockwell Arena 12 Crack Download.

This time, during the installation of 15.04, I explicitly chose the new--the second--ESP partition as the target for grub to be installed. This also failed: The Kubuntu installer didn't use the second ESP--it was left empty. The dual boot worked, but it worked exactly as in Experiment #1. I knew, or I had read, that in UEFI mode, specifying a target partition for grub is pointless as the installer will do its proper UEFI thing in any case.

I was hoping, though, that by using that choice in the Kubuntu installer, that it would work to activate the second ESP partition for the use of 15.04 grub booting files. Experiment #4 A second drive was added. Again, this was disappointing. With two ESPs--one on the HDD, one on the flash drive--I failed to populate a useful ESP on the flash drive. A successful setup doing so would have to be set up and configured manually, so it seems. Experiments #1, #2, #3 were done on a system having one HDD.

For experiment #4, I plugged in a 16 GB USB 3.0 flash drive, kept it there, using it as one would use a HDD. So, we have: My regular desktop PC's HDD is sda; on sda is sda1 = the ESP for the HDD. Kubuntu 14.04 is installed to sda2. The flash drive is sdb; on sdb is sdb1 = the ESP for the flash drive. Kubuntu 14.04 is installed to sdb2. (The Kubuntu installation is a regular, 64-bit, permanent installation; i.e., the flash drive is NOT a live Kubuntu UFD.) Result: -- GRUB 2 from the Kubuntu 14.04 on the flash drive took over everything! -- The ESP on the flash drive is empty--unused--even though during the installation of Kubuntu I directed sdb1 to be used as the ESP and the installer indicated it was '.installing [grub] to sdb1.'

In the progress indicator. -- GRUB 2 installed itself to the ESP on sda1: /boot/efi/EFI/ubuntu, overwriting the setup that was there previously. It wrote a new grub.cfg that showed Kubuntu on sda2 and Kubuntu on sdb2, listing sdb2 (the flash drive) first. -- Upon re-booting and entering ASUS UEFI BIOS setup (by pressing F2), the boot menu changed to show the flash drive first; the rEFInd on sda2 is listed second; and so on. Previously (before using the flash drive at all), rEFInd was first in boot order and controlled everything on the HDD sda. -- Upon re-booting, if you don't enter the ASUS UEFI BIOS setup (by pressing F2), you will boot by default to Kubuntu 14.04 on the flash drive, sdb2.

-- Upon re-booting, if you enter the ASUS UEFI BIOS setup (by pressing F2), you can select whatever you need from the Boot Override menu--everything on both drives (HDD and flash drive) is listed. If you select rEFInd, you can boot directly to the kernel located on the flash drive, sdb2, and thus boot into Kubuntu 14.04 on the flash drive sdb2.

-- I booted into Kubuntu on the flash drive and installed rEFInd from there. REFInd installed itself NOT to the ESP on the flash drive (sdb1), but to the ESP on the HDD at sda1. It did, however, set itself up as #1 in the boot order (the NVRAM variables in the ASUS UEFI firmware). =>Thus, it all works. You can boot into anything on either drive--the HDD sda or the flash drive sdb. But it is all controlled by the ESP files on the HDD sda; the ESP on the flash drive sdb1 is empty.

GRUB 2, when installed in the Kubuntu on the flash drive truly did take over the show and wrote its boot files and grub.cfg to the ESP on the HDD sda1. And rEFInd seemed to follow. The ESP on the flash drive sdb1 remains empty, unused. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Setup Motherboard/firmware: ASUS H-97 Plus One HDD Partitions: Number Start (sector) End (sector) Size Code Name 1 20 500.0 MiB EF00 2 106047 29.3 GiB 8300 3 62466047 97.7 GiB 8300 4 267234047 15.6 GiB 8200 5 300074047 29.3 GiB 8300 6 361474047 97.7 GiB 8300 Partition sda1 is my existing ESP (EFI System Partition). Partition 2 is the root partition for Kubuntu 14.04. Partition 3 is the /home partition for Kubuntu 14.04. Partition 4 is swap.

Partitions 5 and 6 are empty and available for installing Kubuntu 15.04 (root / and /home). The ESP, /dev/sda1, is mounted (as seen by Kubuntu 14.04) as /boot/efi. Best Of Platinum Edition Dj Otzi Sweet there. There, you see /boot/efi/EFI/ubuntu, where EFI is the main directory of the ESP, and where ubuntu contains these four files: mike@mike-desktop:~$ ls -l /boot/efi/EFI/ubuntu total 3416 -rwxr-xr-x 1 root root 126 Mar 6 17:30 grub.cfg -rwxr-xr-x 1 root root 956792 Mar 6 17:30 grubx64.efi -rwxr-xr-x 1 root root 1178240 Mar 6 17:30 MokManager.efi -rwxr-xr-x 1 root root 1355736 Mar 6 17:30 shimx64.efi This is pretty much standard stuff, nothing unusual, it's the way the Kubuntu 14.04 installer sets things up with GRUB 2 (for UEFI) on the ESP. Note that the grub.cfg here is simple. It is a configfile command pointing at the full grub.cfg for my Kubuntu 14.04 at /boot/grub/grub.cfg (the UUID is for /dev/sda2 = hd0, GPT partition 2, which is where my Kubuntu 14.04 root file system is). The grub.cfg at /boot/efi/EFI/ubuntu/grub.cfg is simply: search.fs_uuid 127fc14b-aa8a-4c00-b781-0a70a88cf07c root hd0,gpt2 set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg Experiment #1: Simply try to add Kubuntu 15.04 to my HDD containing 14.04.

This worked but with a caveat. Backup: Before installing Kubuntu 15.04, I made a backup of the four files in /boot/efi/EFI/ubuntu, I placed them in a folder I called my_Kubuntu_backups, and I stored that folder at /boot/efi/EFI/ my_Kubuntu_backups, also a copy on my Desktop (14.04), and a copy on a flash drive. I had used GParted to make partitions 5 and 6 for the new Kubuntu 15.04 OS, so I ran the 15.04 live flash drive installer and installed 15.04 that way. During installation, I selected the Manual method (was that called 'something else'? I don't recall), and for 'Device for bootloader,' I selected simply /dev/sda (I believe for UEFI the GRUB installer scripts ignore any such device paths--they are used for legacy BIOS setups).

(Btw, I chose not to install updates or 3rd party software, I went slowly, read everything, took a few notes by hand, and the installation took just 16 minutes--I could do it again in, probably, 13 minutes, I think.) Re-booting the PC now, I got a GRUB boot menu showing options for booting into the new 15.04, the existing 14.04, Recovery modes for each, and System Setup (which takes me to the ASUS UEFI configuration menus in firmware). (1) I note that the GRUB boot menu is from the 15.04 OS root partition, /boot/grub/grub.cfg in partition 5; thus, the GRUB in 15.04 took over the booting from the GRUB in 14.04. (2) My ESP was simply re-used: The contents of /boot/efi/EFI/ubuntu looked the same, containing the same-named four, standard files as were there before installing 15.04: grub.cfg, grubx64.efi, MokManager.efi, and shimx64.efi. (The previous four files were either changed or they were overwritten completely by the new 15.04 installation of GRUB 2.) The file /boot/efi/EFI/ubuntu/grub.cfg now pointed at (using configfile) the grub.cfg file in the 15.04 OS: /boot/grub/grub.cfg.

Thus, the booting of the PC is now controlled by the GRUB setup by 15.04. If I delete Kubuntu 15.04, my PC will not boot (until I use a live rescue DVD or USB to fix things). Restoring the ESP backup and restoring boot control to GRUB 2 of Kubuntu 14.04: Since I view 14.04 as my main OS, and 15.04 as my 'testing' OS, I prefer the booting to be controlled by my GRUB in 14.04. So, I simply deleted the contents of /boot/efi/EFI/ubuntu, and restored my previous backup files from my_Kubuntu_backups, re-booted, and everything works as it worked before this experiment. However, to include 15.04 in the boot menu (of the GRUB 2 in 14.04), I first had to run (from Konsole in 14.04): sudo grub-mkconfig -o /boot/grub/grub.cfg Experiment #2: Repeat Experiment #1, installing Kubuntu 15.04, this time pointing the Kubuntu installer at a second ESP partition, hoping the installer will use it, and hoping that 14.04 and 15.04 would be installed independently, that their GRUBs would act independently, one ESP controlling 14.04, and the other ESP controlling 15.04. (Details: First, I used GParted to re-format the partitions for 15.04, thus essentially 'deleting' the existing 15.04 from Experiment #1-- this was partitions 5 &6 -- and I used GParted to create a new, a second, ESP as sda7--as FAT32, 500 MB, tagged as boot.

I also restored the first original ESP to its original state, using my ESP backup.) Bad news: It didn't work the way I had hoped. Good news: The Kubuntu installer DID, however, detect the new partition I had made for the second ESP and it DID offer me the capability for marking it as 'Use EFI System Partition.'

Result: As it turned out, the final installation of 15.04 looked exactly like the result of Experiment #1: The original (first) ESP was re-used, the GRUB 2 from 15.04 controlled the boot menu and booting of both 14.04 and 15.04; and, in fact, the newly created ESP, the second ESP, was left empty! Not used at all. The output of sudo efibootmgr -v showed the same boot order (in firmware) as for Experiment #1. The blame for the failure of Experiment #2 could go to either or both the Kubuntu installer (and GRUB installer scripts) or the ASUS UEFI firmware design. Caution, warning, notice Everything done here was specific to my firmware (ASUS H-97 Plus motherboard and firmware), and specific to the operating system and installer Kubuntu 15.04 (and 14.04). Change either the firmware maker and/or the OS, and your experience may change--for better or for worse. Recommendation To dual boot two or more Linux OS, do what I did here, Experiment #1.

Know how to use GRUB 2 commands so you can make the booting controlled by whatever OS you wish the booting to be controlled. You might try using two ESPs to dual boot two Linux OSs, see if it would work for you. Try Rod Smith's boot manager rEFInd. See how it would work in this context (dual-booting). I have not tried it yet. Others here at Kubuntu forums have tried it.

Perhaps they know and can report or experiment and report. I am not clear how it works with GRUB 2, the logistics. I'm also not clear on how to run it to set up a dual boot: I presume you could install rEFInd, install your OS(s), perhaps one-by-one, and after each installation, letting GRUB 2 (for UEFI) do whatever it does, you could then do a 'refresh' of rEFInd (? ) to generate a good boot menu?

Use the Arch links below to figure out how to set up a dedicated GRUB partition or GRUB ESP (a GRUB directory in the ESP) that would act as a boot manager. I may return to this subject later. I'm just glad I didn't permanently ruin my existing setup.

The Literature is a Bit Discouraging (my comments, as of 5-6-15) To date, the Internet articles are somewhat discouraging on dual-booting with UEFI. Note the first answer is from Rod Smith. He recommends using separate ESP partitions (which didn't work for me); or using some other boot loader and/or boot manager, like his rEFInd (probably a very good idea).

-->Perhaps I could get it to work with two ESPs if I did a custom installation/configuration of GRUB 2 to each of the two ESPs. The Arch how-to's on using UEFI and GRUB 2 could be helpful (see links below). Here's another one: And here's Adam W, who is real clear on his experience with it: UEFI boot: how does that actually work, then? The following are AdamW’s General Recommendations On Managing System Boot, offered with absolutely no guarantees of accuracy, purity or safety. If you can possibly manage it, have one OS per computer.

If you need more than one OS, buy more computers, or use virtualization. If you absolutely must have more than one OS per computer, at least have one OS per disk. If you absolutely insist on having more than one OS per disk, understand everything written on this page, understand that you are making your life much more painful than it needs to be, lay in good stocks of painkillers and gin, and don’t go yelling at your OS vendor, whatever breaks. Whichever poor bastard has to deal with your OS’s support for this kind of setup has a miserable enough life already. And for the love of cookies, don’t mix UEFI-native and BIOS-compatible OS installations, you have enough pain to deal with already.

Source: See these references for more help, more ideas, more tools Linux on UEFI: A Quick Installation Guide (Rod Smith: and see his entire listing of articles for UEI, GRUB, rEFInd, UEFI issues) GRUB (excellent ideas on GRUB 2 for UEFI, customizing) Unified Extensible Firmware Interface https://wiki.archlinux.org/index.php/UEFI. Added 5/30/15: For solutions to some of the issues raised here and in the above post, see the application of GRUB-EFI in SECTIONS 3 & 6 here: Post #121: UEFI for Kubuntu--simplified. Some dual-booting tips for Kubuntu -->SECTION 3: GRUB 2 (for EFI) -->SECTION 6: Dual/multi-booting: Know what to expect. And how to deal with GRUB ---------- Original text of this post: And so, what's my point?

I started by thinking there should be an easy way for a casual user to set up a basic dual boot for two or more Kubuntu OSs, a way that uses only the Kubuntu installer, GRUB 2, and the UEFI firmware (especially ASUS firmware, which seems very well done and user friendly). To date, setting up even a basic dual boot in UEFI requires some manual configuration. This is not different from the standard GRUB 2 for PCs or from GRUB Legacy on BIOS+MBR machines. I was hoping because of the UEFI setup that dual-booting might be easier, in some way. There are three factors that come into play: the computer's UEFI firmware; GRUB 2 installer scripts for UEFI setups; and the Kubuntu installer (which, in part, of course, calls on the GRUB installer scripts). Between the three of them, we would hope a clear solution might be possible. Here's a simple thing to think about: take the directory /boot/efi/EFI/ubuntu.

Why could there not also be a directory /boot/efi/EFI/ubuntu-2? Why couldn't GRUB 2 UEFI be auto-configured to not only load each ubuntu OS, but also serve as the boot manager? Could it not (automatically) go into the ESP in a separate directory?

Many writers have remarked how complex GRUB 2 is, and I must agree. I don't understand it from any programming standpoint, but as a user it sure as h*ll is more complicated than was GRUB Legacy, for which almost anyone with a sense of adventure could guess at a bootable menuentry. Now, it's difficult to even read and partly understand the grub.cfg file.

As Experiment #1 shows, there is an easy way for the casual user to install two versions of Kubuntu in dual boot; however, the devil being in the details, should that user damage or delete or replace the second Kubuntu installation, she/he would lose their boot menu for booting the first Kubuntu installation and would then have to fix it manually or run Boot Repair. It seems, as of this date, most users wanting to dual boot must be prepared for some manual configuration work. Especially so if you were to design your own GRUB 2 partition or GRUB 2 ESP directory (and then, how about updates to the GRUB software, how would they find their target?). Continuing, in Experiment #3 As in Experiment #2, I created a second ESP and had hoped the Kubuntu installer and the ASUS firmware would use both ESPs--one to set up 14.04 and one to set up 15.04.

This time, during the installation of 15.04, I explicitly chose the new--the second--ESP partition as the target for grub to be installed. This also failed: The Kubuntu installer didn't use the second ESP--it was left empty.

The dual boot worked, but it worked exactly as in Experiment #1. I knew, or I had read, that in UEFI mode, specifying a target partition for grub is pointless as the installer will do its proper UEFI thing in any case. I was hoping, though, that by using that choice in the Kubuntu installer, that it would work to activate the second ESP partition for the use of 15.04 grub booting files.

Again, imo, both GRUB 2 (UEFI) and the Kubuntu UEFI installer could do a better job and help make this work. (Btw, again, nothing seen in the ASUS UEFI boot setup menus; and nothing from efibootmgr -v.). REFInd A solution to many dual-booting issues is a good boot manager. If your PC's UEFI boot manager is a good one, you have a solution there, assuming you don't mind pressing the keys necessary to access your system's UEFI boot menu. So I can easily reference this topic to help people solve some booting problems on the forum, I want to make a brief post on rEFInd at this spot, in line with the above experiments on dual booting two Linux OSs. Read a discussion with SteveRiley about rEFInd here: The maintainer of rEFInd is Rod Smith.

Here's his page: You may also read his other pages on UEFI, His main page: On installing rEFInd, I made some notes for Kubuntu, I clipped and pasted those notes here: Setting up booting in Kubuntu (Assumes you have GRUB 2 installed. If you wish to remove GRUB 2 from your PC, please post questions in the general kubuntuforums and someone will advise you.) Install Kubuntu. (Ignore this if you have a Kubuntu OS installed.) Let it install GRUB 2 and set up the usual /boot/efi/EFI/ubuntu directory, populated by the GRUB boot files.

Make a backup of this directory and contents, call it something like my_ubuntu_backups_dated, store it on flash drive. If rEFInd is already installed, re-boot, let it run, hit the proper key (ESC) to refresh its boot menu. If rEFInd is not already installed, install rEFInd: Install rEFInd; click on Personal Package Archive >rEFInd link and open this: Follow all instructions shown: sudo add-apt-repository ppa:rodsmith/refind # add his PPA repository sudo apt-get update sudo apt-cache search refind sudo apt-get install refind and it ended saying, Installing it! REFInd has been set as the default boot manager. Creating //boot/refind_linux.conf; edit it to adjust kernel options. Setting default boot options based on //etc/default/grub Installation has completed successfully.

Note: The PPA can be added to your system manually by copying the lines below and adding them to your system's software sources, /etc/apt/sources.list, make sure you have this in your /etc/apt/sources.list file (which you must edit as root): # PPA for Rod Smith's rEFInd deb trusty main deb-src trusty main But, it doesn't look like that takes care of the signing key & etc. Thus, as above, I did the sudo add-apt-repository ppa:rodsmith/refind Note: Example: Signing key: 4096R/9122E0C2; Fingerprint: CE52DE32F3C29122E0C2 Then check it out: Check /boot/efi/EFI/refind to see how it got installed Then do: sudo efibootmgr -v # to see your boot order (the NVRAM variables) Then do: tree /boot/efi Then re-boot to try it. Configure /boot/efi/refind/refind.conf (open as root to edit this file). Continuing, in Dual Booting Kubuntu 14.04 and 15.04, in UEFI mode (Experiment #4: A second drive was added. Again, this was disappointing. With two ESPs--one on the HDD, one on the flash drive--I failed to populate a useful ESP on the flash drive. A successful setup doing so would have to be set up and configured manually, so it seems.

Experiments #1, #2, #3 were done on a system having one HDD. For experiment #4, I plugged in a 16 GB USB 3.0 flash drive, kept it there, using it as one would use a HDD.

So, we have: My regular desktop PC's HDD is sda; on sda is sda1 = the ESP for the HDD. Kubuntu 14.04 is installed to sda2. The flash drive is sdb; on sdb is sdb1 = the ESP for the flash drive.

Kubuntu 14.04 is installed to sdb2. (The Kubuntu installation is a regular, 64-bit, permanent installation; i.e., the flash drive is NOT a live Kubuntu UFD.) Result: -- GRUB 2 from the Kubuntu 14.04 on the flash drive took over everything! -- The ESP on the flash drive is empty--unused--even though during the installation of Kubuntu I directed sdb1 to be used as the ESP and the installer indicated it was '.installing [grub] to sdb1.' In the progress indicator. -- GRUB 2 installed itself to the ESP on sda1: /boot/efi/EFI/ubuntu, overwriting the setup that was there previously. It wrote a new grub.cfg that showed Kubuntu on sda2 and Kubuntu on sdb2, listing sdb2 (the flash drive) first.

-- Upon re-booting and entering ASUS UEFI BIOS setup (by pressing F2), the boot menu changed to show the flash drive first; the rEFInd on sda2 is listed second; and so on. Previously (before using the flash drive at all), rEFInd was first in boot order and controlled everything on the HDD sda. -- Upon re-booting, if you don't enter the ASUS UEFI BIOS setup (by pressing F2), you will boot by default to Kubuntu 14.04 on the flash drive, sdb2. -- Upon re-booting, if you enter the ASUS UEFI BIOS setup (by pressing F2), you can select whatever you need from the Boot Override menu--everything on both drives (HDD and flash drive) is listed.

If you select rEFInd, you can boot directly to the kernel located on the flash drive, sdb2, and thus boot into Kubuntu 14.04 on the flash drive sdb2. -- I booted into Kubuntu on the flash drive and installed rEFInd from there.

REFInd installed itself NOT to the ESP on the flash drive (sdb1), but to the ESP on the HDD at sda1. It did, however, set itself up as #1 in the boot order (the NVRAM variables in the ASUS UEFI firmware). =>Thus, it all works. You can boot into anything on either drive--the HDD sda or the flash drive sdb. But it is all controlled by the ESP files on the HDD sda; the ESP on the flash drive sdb1 is empty. GRUB 2, when installed in the Kubuntu on the flash drive truly did take over the show and wrote its boot files and grub.cfg to the ESP on the HDD sda1.

And rEFInd seemed to follow. The ESP on the flash drive sdb1 remains empty, unused. Fix UEFI+GPT with Testdisk & gdisk -- Deleted partitions & damaged GPT structure Summary For a UEFI+GPT setup, if you damaged your GPT structure, or if you accidentally lost/damaged your partitions, you may be able to use TestDisk and gdisk to recover. One goal here is to see how TestDisk worked on GPT. Good news: It recovers deleted partitions.

But: I could not use TestDisk to repair either the Partition Header or the Partition Table entries. For those two tasks, I used gdisk. I did five experiments. There are references included along the way for everything. (If you can use TestDisk to fix the damage described in experiments 4 & 5, let us know.) Set-up ASUS UEFI+GPT system, desktop PC /dev/sda: HDD: Kubuntu 14.04 /dev/sdb: USB 3.0 flash drive, set up for this test, contains 5 partitions, including ESP, bootable Kubuntu 14.04, /home, /swap, and an ext4 data partition.

All experiments were applied to the flash drive. The flash drive setup First, for reference, here's what the flash drive looks like before the experiments: sudo gdisk -l /dev/sdb GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. UEFI for Kubuntu--simplified. Some dual-booting tips for Kubuntu Reviewed, edited for improvements, additions: 7-14-15; 8-23-15, 9-25-15, 9-27-15 UEFI Simplified -- a quicker version This is intended to be a quicker version (more to-the-point) of the present tutorial (where you are at now): 'UEFI for Kubuntu--simplified. Some dual-booting tips for Kubuntu.' If you prefer this more-to-the-point version, see: /////////////////////////////////////// The Simplified Formula;-) Accept the new technology of firmware/partition table: UEFI+GPT replaces BIOS+MBR.

Fix in your mind a picture of the GPT and UEFI setup. Install your Kubuntu properly in UEFI mode. (To prepare for that, optionally, you can do the partitioning of your HDD first.) Accept, for now, that most users will use GRUB 2 (for EFI) as a boot loader. Use rEFInd alongside GRUB. Know a few basic things about how your UEFI firmware works to boot your computer. Know what to expect when you set up dual/multi-booting, and how to fix it.

Have some tools, facts, tips, and references handy: a Cheat Sheet. What follows is an expanded version of this simple formula, along with all the details you'll probably ever need to manage your UEFI booting in K(U)buntu. - - - - - - - - - - Starting again from the top.Oops, I left out something from that title.

Toss is one or two of these emoticons:;-) and a sense of humor to boot (pun intended). This is a work-in-progress, and it is based on only my experience experimenting, only with Kubuntu on ASUS firmware, and a lot of reading.

I even broke my machine once (had to reset the CMOS and lost all my firmware settings); also encountered the dreadful 'failed: sdxy does not look like an ESP' (yep, it was accidentally an ext4 instead of FAT32--not thinking). This should apply to Kubuntu, Ubuntu derivatives, and probably is in line with general Debian. Bear in mind, with the new-ish UEFI+GPT, three things determine your experience: the firmware from the computer manufacturer (which may be quirky or buggy), how GRUB2-EFI handles UEFI, and the K(U)buntu installer. Terms: The new way: (U)EFI+GPT. The old way: BIOS/CSM/legacy-mode+MBR.