Simple:
1. Make sure that there is a 2MB post-MBR gap.
1b. If there is not, adjust the partitions so that there is sufficient space. (and remove the GPT BIOS partition for the moment. There’s a 200MB space with just that and some free space. This may be causing grub to install to that partition instead of the MBR)
2. Install grub-bios to the MBR of /dev/sdb. Run all relevant configuration steps.
3. Attempt to select sdb from the Apple Bootloader.
4. Reboot and confirm that th
The above approach is basically BIOS-MBR boot, for which 1 MiB post-MBR gap should be fine, unless you are using LVM or dmraid or btrfs in which you may need 2 MiB gap.
I think I have a bootable flag set on “/boot” partition (/dev/sdb2), and I will confirm this is the case.
Grub does not care about bootable flag. That is used by syslinux. Grub follows a different approach (stage1 -> core.img -> prefix dir with modules). The 1 MiB gap is for embedding core.img and that file has grub specific FS drivers that allow grub to access the partition containing the grub modules and grub.cfg . This partition info is embedded by grub-install (actually grub-bios-setup) automatically and boot flag is no where read (neither by grub-install while setup, nor by core.img during runtime).
Not as simple:
1. Using gdisk, convert /dev/sdb back to GPT from MBR.
2. Also using gdisk, make a small parititon /dev/sdb1 (which is presently empty) to a BIOS Boot partition, type code=‘EF02’ for cgdisk (source)
3. Make sure that I am using grub-bios, and Install grub2 to /dev/sdb1 (the new bios partition). Run appropriate configuration steps. ?Include noefi flag in the grub.cfg Arch linux boot option?
4. Attempt to boot into sdb.
I suppose you mean BIOS-GPT boot. If that is the case step 1 should be conversion from MBR to GPT, not vice-versa. Step 2 is correct. Make the EF02 partition about 2 MiB just to be on the safe side.
In step 3, you DO NOT point grub-install to /dev/sdb1, you point it to /dev/sdb . The device parameter instruction grub where to install the stage 1 boot code (440-byte MBR boot code). grub-install (grub-bios-setup) will automatically detect whether the disk is GPT, and if so it will automatically determine the EF02 partition and embed its core.img there.
You do need to create a /boot/grub/grub.cfg file (either manually or using grub-mkconfig). No need for "noefi" flag since you do will boot only in BIOS mode so EFI ARCH mismatch should not be an issue.
In both the cases I do not know how to finally boot /dev/sdb from Apple boot chooser (either EFI or BIOS mode) since I do not have a Mac (never used one).
]]>I am posting my present plan of action at the end, having read all of the relevant wiki pages very carefully.
Just to be clear, you tried installing GRUB to the MBR of sdb (i.e. /dev/sdb) and not one of the partitions (e.g. /dev/sdb1)?
This is correct. I once I get back to work, I will confirm this, and make sure that I have done that correctly. I may have forgotten a post-MBR gap.
Bro, you seriously need to read the whole GRUB2, UEFI, UEFI_Bootloaders and GPT wiki pages to understand how all these work together
I agree on this point. Until now, I have not had time to read every piece of documentation, because I was at work doing many, many other things. I appreciate all the help that everyone has been able to provide, and I never ask for help until I have exhausted every resource I know of, and I try not to waste people's time. I may have misrepresented my timeline, as this was during the day that I performed my last actions, and have not been around to work on it since.
it seems to me that his/her best shot would be to use an MBR partitioning scheme on sdb, and install grub (bios) to the MBR, as one normally would for a single boot BIOS system. Then the OP can use the Apple Startup Manager to select which drive to boot. The hope being that the firmware would fall back to BIOS mode when it detected a bootable disk with an MBR.
I have tried this approach, and the apple boot loader (and boot selector from Mac OS X) did not recognize the disk at all. The reason is presently a mystery to me. The rEFInd liveCD also did not locate the boot partition correctly as far as I was able to determine.
Your code should be something like
set root=(hd1,2) # Should be your /boot partition in grub's naming scheme, the partition containing the kernel and initramfs files linux /vmlinuz-linux ro root=UUID=xxxx # Should be your "/" root partition, in kernel's or blkid or udev naming scheme, not in grub's naming scheme initrd /initramfs-linux.img # Correct filename is important boot
Thank you, this has been incredibly helpful, as well as the rest of what you have said. This was my first experience with grub console, without any configuration files or informaiton beyond what I could find online. I did all of this on a grub2 console, so everything I did was a learning experience on its own, reading through the grub2 manual. My memory is not perfect, so my seeming disregard for filenames is an artefact of that, since I was using tab completion to find the file names that I needed.
I think perhaps you're in a rush to get this working, and as a result are skimming through the wiki and forums for quick answers. (I know, I've been there.)
This is exactly what I've been doing, and I have lost a lot of time with this. I have read more than 10 guides on similar use situations, but each of them has failed for various reasons.
Note: It appears that I have made a small error in making my disk layout, and need to rectify this. per the UEFI Wiki Page. It appears that I may have forgotten to add a post MBR gap when converting to MBR, so GRUB2 was unable to properly do anything.
After reading through these guides, and collecting as much data as I had available, my plan of action is as follows. I am open to critique or suggestion before I start.
I have two possibilities, and I will try the simpler one first.
Simple:
1. Make sure that there is a 2MB post-MBR gap.
1b. If there is not, adjust the partitions so that there is sufficient space. (and remove the GPT BIOS partition for the moment. There’s a 200MB space with just that and some free space. This may be causing grub to install to that partition instead of the MBR)
2. Install grub-bios to the MBR of /dev/sdb. Run all relevant configuration steps.
3. Attempt to select sdb from the Apple Bootloader.
4. Reboot and confirm that th
I think I have a bootable flag set on “/boot” partition (/dev/sdb2), and I will confirm this is the case.
Not as simple:
1. Using gdisk, convert /dev/sdb back to GPT from MBR.
2. Also using gdisk, make a small parititon /dev/sdb1 (which is presently empty) to a BIOS Boot partition, type code=‘EF02’ for cgdisk (source)
3. Make sure that I am using grub-bios, and Install grub2 to /dev/sdb1 (the new bios partition). Run appropriate configuration steps. ?Include noefi flag in the grub.cfg Arch linux boot option?
4. Attempt to boot into sdb.
Hopefully one of these works.
]]>Sorry to be frank, but if you did not know the above things then Arch is not for you, as these are the bare minimum any do-it-yourself distro like Arch requires its users to be proficient in.
Or, at least be willing to do your homework and learn them. Of course, if you have specific questions about GRUB, or there is a particular section of the wiki that isn't clear, then I'm sure someone will be willing to give you a "leg up".
I think perhaps you're in a rush to get this working, and as a result are skimming through the wiki and forums for quick answers. (I know, I've been there.) The problem is, this usually generates way more confusion that it eliminates. Calm down, get a cup of coffee (or tea), sit back, and carefully read the wiki articles the.ridikulus.rat mentioned. You already know that you cannot use EFI boot for your system (due to the mismatched 32 bit firmware and 64 bit OS), so start by getting your head wrapped around GRUB, MBR partitioning, and the BIOS boot process. (Yes, technically you can use GPT with BIOS via GRUB 2, but considering the difficulties you're having, I would keep it simple for now.) Then, move on to understanding EFI and the nuances of Apple's firmware. By this point, you should have a good working theory as to how to boot linux from your second drive.
EDIT: spelling/grammer
EDIT: Another piece of advice: avoid trying random things. Reflect on what you know, build a hypothesis, cross check with what other's have done, and systematically test it in a way that gives informative feedback.
]]>Super grub 2 disk found something resembling an MBR boot loader, with no menu options available, so using some grub2 command line, I was able to almost get the system to boot. Procedure as follows:
set root=(hd1,3) set root=(hd,1,2) #I don't know why, but changing the root from "/" to "/boot" helps later.
Grub's "set root=" command has nothing to with linux kernel "root=" command. The "set root=" tells grub which partition to find files which are called by commands after the "Set root=" command. When grub comes to "linux /vmlinuz-linux" internally grub considers it as "linux <set root= value>/vmlinuz-linux". So it should be your /boot partition, nt your "/" partition (since you seem to have both as separate partitions).
linux /vmlinuz-linux initrd /initramfs.img #Don't remember the full name of this, and its mostly irrelevant boot
Your code should be something like
set root=(hd1,2) # Should be your /boot partition in grub's naming scheme, the partition containing the kernel and initramfs files
linux /vmlinuz-linux ro root=UUID=xxxx # Should be your "/" root partition, in kernel's or blkid or udev naming scheme, not in grub's naming scheme
initrd /initramfs-linux.img # Correct filename is important
boot
The filename of initrd is also relevant as it contains the kernel modules required by the kernel to detect and load the rootfs. Without the required FS modules, the kernel will not be able to boot into "UUID=xxxx" partition. So not only is the filename important, but you also did not pass any "root=" parameter to the kernel, and this it fails with the "Cannot mount" error message.
Sorry to be frank, but if you did not know the above things then Arch is not for you, as these are the bare minimum any do-it-yourself distro like Arch requires its users to be proficient in.
]]>f you are going the EFI route, use grub-efi-i386 and use bless to make it appear in your Mac's boot menu/chooser/whatever its called. If you are going the BIOS route (bootcamp), then use grub-bios. In both cases read the whole GRUB2 wiki page.
You can perfectly use pure GPT even for BIOS booting with grub2 or syslinux. Hybrid gpt/mbr is required only for Windows booting and not required for Linux booting.
In your case I suggest not going the EFI route if you find it to difficult to setup because (i) the iso and bootloaders are more tuned to work in a proper UEFI system, (ii) 32-bit EFI Macs are too old to support linux efi booting, even recent 64-bit EFI Macs have problems booting linux in efi mode.
]]> set root=(hd1,3)
set root=(hd,1,2) #I don't know why, but changing the root from "/" to "/boot" helps later.
linux /vmlinuz-linux
initrd /initramfs.img #Don't remember the full name of this, and its mostly irrelevant
boot
At this point, the system loads a crippled kernel, with a message something like 'Cannot mount "" to "/new_root" '
So, at first I couldn't figure how to fix this one when there was no working /dev, but the second time I tried this, the /dev appeared on the tree.
So I did the following:
mount -t ext4fs /dev/sdb3 /new_root
mount -t ext2fs /dev/sdb2 /new_root/boot
mount -t ext4fs /dev/sdb4 /new_root/home
exit
I can't remember if I needed type codes at the time or not.
This got the kernel to start loading including some of the mesa graphics drivers, but the system hung and dropped into maintenance mode because it said that it could not get something mounted correctly. I mounted it, and typed exit, and then the system restarted (which is not what I wanted to happen). Then I had to leave to go home.
My goal is really to make a useable desktop, and I have already lost too much time to this. A simpler method to load a system and use the GUI I want to use is to boot the system into the modified Arch disk from the.redikulus.rat's favorite link and mount all the local partitions that I need everything onto /mnt like I would to install. Then:
arch_chroot /mnt
su [i]user[/i]
startx
This is the nastiest workaround that kind of works for what I need, but I still wish I could load the system from a disk.
Most recently, I tried to install rEFInd to /dev/sda, but nothing changed, and the hooks never got set for it after multiple reboots. I may have to install it to the ///EFI partition to get it to work, because I tried the default way (since it was an older system). Random question, are /EFI and "ESP" the same partition?
I think that my next step will be to change the partition map to hybrid MBR using gdisk, and reinstall grub. If that doesn't work, I'll pull out /dev/sda and see what happens with /dev/sdb as the only disk. I'll need to reconfigure a few things when I do this, but I don't think this will be a problem.
The other question is: Currently, I was using grub2 for x86, with only the OS prober extension. Should I be using grub-efi-i386 to install grub2 to /dev/sdb, or just grub-i386?
]]>I was unaware of the hybrid mbr function of gdisk. I will have to give that a try. I am assured that my data will remain untouched and still available correct?
Yes, definitely. Really what it does is looks at your current gpt layout, and then asks for a comma separated list of the partitions you would like to include in the mybrid mbr. Then it asks if you would like a protective mbr before and after those partitions (assuming you haven't used all four). You do have to keep in mind though that Macs only like it to have one protective mbr in the beginning and must start at block 1. If you put one at the end it is reported to not like it and refuse to boot.
]]>Sorry, I just never switched to rEFInd because...
No need for apologies.
But curious, wouldn't rEFIt/rEFInd only affect the bootloader (Grub) and not directly the Linux kernel when you suggest it ceasing to work?
I guess I was thinking of the kernel stub bootloader, EFISTUB (which is what I'm currently using). But, you're right, the boot manager directly interfaces with the boot loader, which in many cases would be something like GRUB, ELILO, etc. The broader case I was trying to make is that it's generally a good idea to avoid dead projects if there is a suitable alternative out there.
(P.S. Welcome to the Arch Forum.)
]]>rEFIt is a dead project. I think the last update was back in 2010. This doesn't mean that it's unusable. It just means that any outstanding bugs will not likely get fixed, and it may cease to work as the linux kernel continues to evolve. I believe rEFInd (a fork of rEFIt) is now the preferred boot manager for EFI/UEFI systems.
Sorry, I just never switched to rEFInd because I have been using rEFIt since I first tried out Linux with Ubuntu a couple years ago, so I just stuck with what has worked well so far. I suppose it is time I change to it myself. But curious, wouldn't rEFIt/rEFInd only affect the bootloader (Grub) and not directly the Linux kernel when you suggest it ceasing to work?
--
mojojojo, you say you changed the type code from linux to exfat (8300 to 0700)? This seems rather silly and funky to me. I think gptsync is a terrible piece of software, and it actually doesn't suprise me that you have to do this. But I think a much better way to create a hybrid mbr is to simply use gdisk. There is an option to interactively choose the partitions you would like to include, and then whether or not you want to use any potentially remaining partitions for protective mbr areas. It is super simple and much more reliable.
I was unaware of the hybrid mbr function of gdisk. I will have to give that a try. I am assured that my data will remain untouched and still available correct? But yes, following some of the wiki's, I had to change the type codes to 0700 to be able to sync the tables (because gptsync nor rEFIt would touch the tables otherwise) and allow refit to actually find grub. I didn't see a problem with that since I was still able to maintain my ext4 fs despite the change.
]]>