I am trying to install arch in a dual boot configuration with an existing windows 7 partition. I have everything from the beginner's guide done but the bootloader. When I run grub-install it tells me that core.img is too big.
Some googling tells me that this is relatively common with btrfs, and it seems the only work around is to switch to gpt mode and use a grub bios partition. But the info I've seen indicates that I need to use MBR mode to dual boot windows.
Is it safe to do this with windows? Is there another workaround? Or will I have to settle for ext4?
Last edited by jorenko (2013-06-09 03:53:24)
This is pretty sparse information. What is the exact error output that grub-install is giving you? Are you booting windows 7 in UEFI or bios mode (which will determine how your system is partitioned as well). If you are using UEFI with windows, you ahve GPT, and in this case, did you make a small grub boot partition?
I cannot think of a reason why btrfs would be a factor here. Unless you have extended btrfs across a whole disk and are trying to install a bootloader there, then it should make no difference. The btrfs partition should still start at sector 2048 as usual, meaning the exact same amount of space would be available whether you are using btrfs or ext4 or whatever. What is the exact reasoning "that this is relatively common with btrfs"?
Welcome to the forums, I hope you enjoy your stay. But you need to start trying to be much more explicit in how you ask questions if you want real help.
I'm pretty sure it's BIOS mode -- I have a traditional BIOS for changing boot order and enabling motherboard features, etc. And windows says that my disk's Partition Style is MBR.
# grub-install --recheck /dev/sda /usr/bin/grub-bios-setup: warning: your core.img is unusually large. It won't fit in the embedding area. /usr/bin/grub-bios-setup: error: filesystem `btrfs' doesn't support blocklists.
# fdisk -l /dev/sda Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0xc223c223 Device Boot Start End Blocks Id System /dev/sda1 * 63 1319467007 659733472+ 7 HPFS/NTFS/exFAT /dev/sda2 1319467008 1953525167 317029080 83 Linux
Well there's your problem, your first partition starts at sector 63. With recent versions of windows and fdisk (and every other partitioning tool I can think of off the top of my head) things now align themselves correctly. Also because there is now GPT, the first partition typically starts later as the GPT partition table will typically sit between the MBR and the first partition.
On a MBR partitioned system, grub2 will actually use the first 446 bytes like normal, but will then also use the space that is empty where GPT would sit. This is why when you have a GPT partitioned system, it will require you to create a 1-2MB grub boot partition, as it needs somewhere else to put its bloat. GPT actually still uses the MBR section, but simply creates one large partition covering the whole disk. This is so that tools that are not GPT aware will not think that they have a whole free disk to use as they please.
For comparison, here is whe I get from fdisk:
# fdisk -l /dev/sda sudo fdisk -l /dev/sda [sudo] password for curtisshima: WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: gpt # Start End Size Type Name 1 2048 2099199 1G EFI System EFI System 2 2099200 252166798 119.2G Linux filesyste arch-btrfs-1 3 252168192 488397134 112.7G Linux filesyste arch-btrfs-3
Note that I do use GPT. But that is not the point here. What I am trying to show is where my first partition starts. This is also where fdisk will start partitions these days. This is to ensure compatibility with 4k advanced format disks.
If you are not dead set on Grub2, you could try using syslinux. I really like it much better, though if you are booting more than one Linux, you need to either employ chainloading to various partition boot records, or have a shared /boot. Having a windows partition doens't really matter, as you are simply chainloading to that funky reserved partition anyway.
The other option is to use grub-legacy, which can still be found in the AUR. I actually liked the orginal Grub, as it provided a nice feature set, but was still configurable by hand and it actually fit into the MBR.
Well, syslinux worked perfectly. That's a perfectly reasonable solution. Thanks a bunch, WonderWoofy!
I was stuck with the same problem recently. I want to use Grub2 just because I am more acquainted with it. I was initially using cfdisk which would always start partition from 63 instead of 2048. So, I used fdisk to partition which started at 2048 and it solved the problem.