Alright. I've installed all my files on the disk. Now I'm trying to get it to boot. When I start my pc, I get some sort of a "no bootable devices found" thing from the bios. Here's what I got:
GPT disk with 4 partitions: bios_grub: 1MB, /boot: 500MB, /home: 50GB, root: 100GB
BIOS (not uefi-capable).
amd64 cpu arch. 64-bit linux installed.
According to http://wiki.gentoo.org/wiki/GRUB2, BIOS/GPT booting with grub2 is possible, but I'm not sure about the table they posted in that article. It shows that on an amd64 architecture, the only 64-bit config that works is with either the efi platform or the emu platform. Any way around this? I'd very much prefer to use GPT over MBR.
BIOS, GPT, amd64, grub.
Message
Use the table from here
This wiki is specifically for doing a multivolume btrfs setup, but it does sucessfully use grub2 with a gpt scheme.
http://wiki.gentoo.org/wiki/Btrfs_native_system_root
If you have a simple root (single partition, non-btrfs or default volume) you don't need to do the initramfs thing.
http://wiki.gentoo.org/wiki/Btrfs_native_system_root
If you have a simple root (single partition, non-btrfs or default volume) you don't need to do the initramfs thing.
Figured it out. Booting now.
So, using gdisk or parted, make a 1-2MB partition and give it type ef02 in gdisk or set "bios_grub on" for that partition in parted. Then open up cfdisk (it will complain about being a gpt disk. just ignore that) and toggle the bootable flag ON for that partition. Then follow the standard instructions for installing grub, given by: http://wiki.gentoo.org/wiki/GRUB2. Apparently you can ignore that table I mentioned, which says it can't run the PC platform on an amd64 arch with a 64-bit OS. Because I just did it.
So, using gdisk or parted, make a 1-2MB partition and give it type ef02 in gdisk or set "bios_grub on" for that partition in parted. Then open up cfdisk (it will complain about being a gpt disk. just ignore that) and toggle the bootable flag ON for that partition. Then follow the standard instructions for installing grub, given by: http://wiki.gentoo.org/wiki/GRUB2. Apparently you can ignore that table I mentioned, which says it can't run the PC platform on an amd64 arch with a 64-bit OS. Because I just did it.
Don't recall having to toggle bootable
I don't remember ever being forced to do that with a grub2-install, and it's even more telling that cgdisk doesn't have that in the options
Be aware: "that partition" that you changed in cfdisk is not the same partition that you created in gdisk or parted. Part of GPT is an MBR partition table that contains a "protective partition" that spans the entire disk. The idea is to keep MBR-unaware utilities from messing with the disk, since such tools will see the disk and think it's fully-allocated to an unknown OS. When you launched cfdisk, you saw and changed this protective partition. This helped because some EFIs (and perhaps some BIOSes) will boot in BIOS mode only if the disk has an MBR partition that's marked as bootable. I have a Web page on this subject if you care to read more.skiwarz wrote:So, using gdisk or parted, make a 1-2MB partition and give it type ef02 in gdisk or set "bios_grub on" for that partition in parted. Then open up cfdisk (it will complain about being a gpt disk. just ignore that) and toggle the bootable flag ON for that partition.
Incidentally, this makes me think that you may have an EFI, not a BIOS, so you may have been able to install in EFI mode. If the computer/motherboard was introduced more recently than mid-2011, chances are you've got an EFI. It may be set to BIOS/CSM/legacy-mode booting by default, though. OTOH, it's also possible that you really do have a BIOS with this limitation.
Nope. I do not have EFI. Believe me I'd love to have it; this whole thing would've been much easier. Yes, "that partition" is a "protective partition." Toggling the boot flag lets the BIOS know that the partition (ie the whole disk) is bootable and executes the boot code in the protective mbr. That boot code then loads the GRUB code in that 1-2MB partition I created, which then presents the standard grub prompt. Correct me if I'm wrong. I just learned all this over the past week.srs5694 wrote:Be aware: "that partition" that you changed in cfdisk is not the same partition that you created in gdisk or parted. Part of GPT is an MBR partition table that contains a "protective partition" that spans the entire disk. The idea is to keep MBR-unaware utilities from messing with the disk, since such tools will see the disk and think it's fully-allocated to an unknown OS. When you launched cfdisk, you saw and changed this protective partition. This helped because some EFIs (and perhaps some BIOSes) will boot in BIOS mode only if the disk has an MBR partition that's marked as bootable. I have a Web page on this subject if you care to read more.skiwarz wrote:So, using gdisk or parted, make a 1-2MB partition and give it type ef02 in gdisk or set "bios_grub on" for that partition in parted. Then open up cfdisk (it will complain about being a gpt disk. just ignore that) and toggle the bootable flag ON for that partition.
Incidentally, this makes me think that you may have an EFI, not a BIOS, so you may have been able to install in EFI mode. If the computer/motherboard was introduced more recently than mid-2011, chances are you've got an EFI. It may be set to BIOS/CSM/legacy-mode booting by default, though. OTOH, it's also possible that you really do have a BIOS with this limitation.
Also, is it possible to load a 64-bit kernel in a sort of 32-bit mode? That might explain my discrepancy with the grub2 gentoo wiki about not being able to load a 64-bit os with my configuration.
*edit*: My motherboard is supposed to support efi, but apparently it's broken or something. I think it was one of the first ones to have that capability, and intel never got around to implementing it properly in the bios code. Thus, it's broken despite being designed to have that capability. Intel DP35DP. Just fyi
No, a 64-bit kernel will run only on a 64-bit CPU. That said, BIOS-mode GRUB is written in 16-bit code, and can load both 32- and 64-bit kernels.skiwarz wrote:Also, is it possible to load a 64-bit kernel in a sort of 32-bit mode? That might explain my discrepancy with the grub2 gentoo wiki about not being able to load a 64-bit os with my configuration.
Your board's manual is dated April of 2007. FWIW, I've got an Intel DG43NB motherboard with a manual dated June 2006. That board definitely uses EFI. The manual only mentions EFI once (in a features table), and the firmware setup utility hides the one and only EFI option amongst the boot options, IIRC, and I think it's only mentioned as a value to an option that doesn't include the string "EFI" in the description. It's possible that your board does have EFI support, but you've simply overlooked this option in the firmware.*edit*: My motherboard is supposed to support efi, but apparently it's broken or something. I think it was one of the first ones to have that capability, and intel never got around to implementing it properly in the bios code. Thus, it's broken despite being designed to have that capability. Intel DP35DP. Just fyi
Like I said, it's supposed to have efi support. But the code is broken. Trust me, I've done my research. And with the 32/64-bit kernel, I meant that on a 64-bit machine and a 64-bit kernel, is there an option to start the kernel in a 32-bit only mode. I guess that wiki article is probably wrong then.
The kernel is built either as 32-bit or 64-bit, but cannot mode switch between the two at boot time because that would affect the layout of all data structures. You can have a 64-bit kernel that provides a compatibility layer to allow 32-bit user programs to run, but such a kernel runs as a 64-bit kernel and coerces fields up/down as needed to let the 32-bit user program see what it expects to see. This is what multilib distributions do.skiwarz wrote:I meant that on a 64-bit machine and a 64-bit kernel, is there an option to start the kernel in a 32-bit only mode.
