Can't boot -- can't load 'kernel' (Grub2)

I have a dual boot set up with Arch linux. My disk setup is MBR/BIOS with the following scheme:

/dev/sda1 >> /boot (ext2, Arch Linux)
/dev/sda5 >> / (ext4, Arch Linux)
/dev/sda6 >> SWAP (Arch Linux)
/dev/sda2 >> extended partition (Arch Linux)

Because I am using MBR/BIOS, I can only have 4 primary partitions. This is "important" because I am later going to triple-boot with Windows7 for gaming. Anyway, I want to get FreeBSD 9.0-STABLE amd64 installed, but I'm having some issues.

When I install FreeBSD I create a new slice (something like ad0s3a for / and ad0s3b for swap). Once I reboot, I can see that the FreeBSD (BSD label) is seen by Arch as /dev/sda3 so I have edited my GRUB2 .cfg file as such:

Code:
menuentry "FreeBSD 9.0-STABLE" {
     set root=(hd0,3)
     chainloader +1
}

As far as I can tell, this is correct. GRUB2 recognizes the slice and even realizes that this is a UFS2 filesystem (I don't need to add "insmod UFS2") and it begins to boot the entry. However, once it hands control over to the BTX loader (FreeBSD/x86 bootstrap loader) I get the following error:

Code:
can't load 'kernel'
Type '?' for a list of commands, 'help' for more detailed help.

The output of lsdev is:

Code:
OK lsdev
cd devices:
disk devices:
   disk0:  BIOS drive C:
      disk0s1: ext2fs
         disk0s3a:  FFS
disk0s3b: swap
      disk0s5: ext2fs
disk0s7: Linux swap
pxe devices:

Output of ls is:
Code:
OK ls
open '/' failed: input/output error

Anyone thoughts on this? By the way, I cannot use EFI because my board is BIOS and I cannot even use BIOS/GPT because Windows7 x64 will only support GPT with EFI.
 
--EDIT--

I have checked out some other threads regards this issue. This one suggests changing the BIOS option from RAID to ATA. My BIOS is set to use AHCI, though it has both options for RAID and IDE. I could try out IDE, but I would really like to keep AHCI for performance reasons (and I only have 1 drive so RAID seems silly).

Another post describes something about changing /boot/loader.conf settings after a freebsd-update that breaks booting. My system is a clean installation from 9.0-STABLE memstick so I don't think this is the issue. Besides that, I wouldn't know how to modify that configuration file because it doesn't seem to exist if I exit to shell right after installation.
 
Why not install FreeBSD in a VirtualBox instead of having to reboot to a different OS?

Not a bad suggestion, but it isn't the same. I mentioned that I want to keep as much performance as I can, so this is not an acceptable solution for me. Additionally, I am curious what the problem is with the bootloader at this point -- I do not seem to be the only one with this problem.

Even though I am using GRUB2, it is chainloading to the BTX bootloader, correct? Does BTX have some limitation to how far into a disk the partition it wants to boot is? FreeBSD 9.0 begins at around ~1.5TB into my HDD. Perhaps this is why it cannot find the kernel?
 
I think you have error in mounting FreeBSD partitions, best suggestion I can tell is to chose Single mode user (fourth choice from the FreeBSD boot menu), then type:
Code:
ls /dev
Try to mount partitions one by one, and each time check see if /etc/fstab exists, if so open it, ex:
Code:
mount /dev/ad0s1 /mnt
ls /mnt/etc/fstab
ls: /mnt/etc/fstab: No such file or directory
umount /mnt
mount /dev/ad0s2 /mnt
ls /mnt/etc/fstab
/mnt/etc/fstab
cat /mnt/etc/fstab
Now compare the content of the fstab file with the mounted partition, if you mount /dev/ad0s2 and this partition is /etc, you should find it in fstab like this:
Code:
[FILE]/dev/ad0p2  /etc  ufs   rw  2  2 [/FILE]
Verify all the partitions, correct the wrong partition in the fstab file, unmount mounted partitions, then reboot. Next boot, the system should be booting correctly.
 
Try to use the msdos qualifier in the partition:

Code:
menuentry 'freebsd 9.0' {
        set root=(hd0,msdos3)
        chainloader +1
}
 
Sorry to leave you all hanging :p I had a problem with my motherboard and got a shiny new one from the RMA!

Anyway, I'm thinking about trying the direct OS boot since FreeBSD is supported by GRUB2

T-Daemon said:
You could try a direct kernel boot, instead of chainloading. But first check if you have set root properly. Drop into GRUB's
command line
and call ls. Before making the entry permanent, you can edit the GRUB menu during boot and test it.


With my new setup things are largely the same. The output of ls is (from GRUB2)
Code:
(hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)
My FreeBSD root partition is on gpt3. I can also call this device "hd0,3" and GRUB can see it.

I'm trying to use the configuration that T-Daemon's link to the Ubuntu help pages provided

Code:
menuentry "FreeBSD 8.0 direct" {
        insmod ufs2
        set root='(hd0,gpt3)'
        search --no-floppy --fs-uuid --set 4c0029f407b3cd1d
        kfreebsd /boot/kernel/kernel
        kfreebsd_loadenv /boot/device.hints
        set kFreeBSD.vfs.root.mountfrom=ufs:ada0p3
}

Please note that I am using the device's actual UUID and not the one shown above. I only used it because I didn't write it down! The module line for splash images was removed and I changed other device names. Still, when I try to boot I get an error like "invalid argument" or something.

I should note that I am now using an EFI/GPT scheme with the new motherboard. GRUB2 is installed to the EFI System Partition. I'm aware that FreeBSD bootloader does not fully support EFI booting yet, but that's why I'm trying to use GRUB2! The partitioning scheme is still largely the same.

Also of note is that FreeBSD detects devices /dev/ada0 and /dev/ad4p3. These are the same partitions, but I believe the ada0 device is the AHCI driver, which I intend to use as stated before.

Ok, so maybe folks can help me tweak the direct bootloader menu entry. I figure this is a starting point. If there is any more information about my partition scheme or devices that people want I can post it.
 
I found that I need to include a new option to boot

Code:
menuentry "FreeBSD" {
        insmod ufs2
        set root='(hd0,gpt3)'
        search --no-floppy --fs-uuid [B]--set=root[/B] 4c0029f407b3cd1d
        kfreebsd /boot/kernel/kernel
        kfreebsd_loadenv /boot/device.hints
        set kFreeBSD.vfs.root.mountfrom=ufs:ada0p3
}

The change is that =root seems needed for GRUB2. Now when I boot I do not receive any "no argument specified" error. Instead, it seems to begin booting but goes to a blank screen and eventually restarts.
 
You said you were using MBR BIOS, but it seems that your hard disk has GTP partitions. Very confusing because you already had /, swap and /boot and the extended partition. How did you add a FreeBSD slice? You already had 4 primary partitions.
 
ahavatar said:
You said you were using MBR BIOS, but it seems that your hard disk has GTP partitions. Very confusing because you already had /, swap and /boot and the extended partition. How did you add a FreeBSD slice? You already had 4 primary partitions.

Right sorry to confuse. I did have BIOS/MBR on my old motherboard. As I mentioned in the last post I now have EFI/GPT (I wanted to use UEFI on my new motherboard). And, actually, I only had the /boot partition originally as root and swap were logical partitions (under the extended). I'm still having the same issue booting, though.

The new partition scheme is basically
/dev/sda1 --> fat32, EFI System Partition (this is where GRUB2 resides)
/dev/sda2 --> btrfs, Arch linux /
/dev/sda2 --> UFS2, FreeBSD 9.0 (FreeBSD sees this as /dev/ada0p3 with AHCI or /dev/ad4p3)
 
If I remember correctly, Grub2 settings and installations method are different for UEFI/GPT and MBR/DOS systems, and it seems that you try MBR/DOS method on EFI/GTP system?
 
ahavatar said:
If I remember correctly, Grub2 settings and installations method are different for UEFI/GPT and MBR/DOS systems, and it seems that you try MBR/DOS method on EFI/GTP system?

Not so. I wouldn't be able to make calls to the EFI firmware in that case, would I?

Code:
# efibootmgr BootCurrent
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0004,0000,0001
Boot0000* SATA1:SAMSUNG HD204UI         
Boot0001* IBA GE Slot 0200 v1321
Boot0003* GRUB2
Boot0004* Built-in EFI Shell

The only problem I see here is that I may want to change the bootorder a little. That was a good point, though, I did make sure to install the correct GRUB2 package!


This is my current 40_custom file:

Code:
menuentry "FreeBSD boot" {
        insmod ufs2
        set root='(hd0,gpt3)'
        kfreebsd        /boot/loader
}

menuentry "FreeBSD root" {
        insmod ufs2
        set root='(hd0,gpt4)'
        search --no-floppy --fs-uuid --set=root 4f55953a783b1ac8
        kfreebsd        /boot/loader
}

menuentry "FreeBSD direct root" {
        insmod ufs2
        set root='(hd0,gpt4)'
        search --no-floppy --fs-uuid --set=root 4f55953a783b1ac8
        kfreebsd /boot/kernel/kernel
        kfreebsd_loadenv /boot/device.hints
        set kFreeBSD.vfs.root.mountfrom=ufs:ad0p4
        set KFreeBSD.vfs.root.mountfrom.options=rw
}

menuentry "FreeBSD direct boot" {
        insmod ufs2
        set root='(hd0,gpt3)'
        kfreebsd /boot/kernel/kernel
        kfreebsd_loadenv /boot/device.hints
        set kFreeBSD.vfs.root.mountfrom=ufs:ad0p3
        set KFreeBSD.vfs.root.mountfrom.options=rw
}

menuentry "FreeBSD, way of shotgun boot" {
    set root=(hd0,gpt3)
    chainloader +1
}

menuentry "FreeBSD, way of shotgun root" {
    set root=(hd0,gpt4)
    chainloader +1
}

Upon installation, FreeBSD created the freebsd-boot partition at /dev/ada0p3 and the freebsd-ufs partition at /dev/ada0p4/file]. If I try booting the first entry I get an error that says can't load kernel from the BTX booloader.

If I try booting from the next 3 GRUB goes directly to a black screen.

If I try booting the last 2 (chainloader's) I get an error that says invalid EFI file path
 
1. Separate issue but valid: Why do you have two different swaps? FreeBSD can use the linux-swap!
2. If you get to the BTX loader, Grub has done it's job basically (with some exceptions). You need to explore the BTX command prompt a little. "?" will give you list of commands. ls will list folders, etc. Read loader(8)()
Is your vfs.root.mountfrom setting in /boot/loader.conf correct?
Find the correct path to the /boot/kernel/ with ls and at btx prompt and tell btx to boot:
[CMD=">"]boot /boot/kernel[/CMD]

I can't be more help because I need more specifics of your problem from btx output.
 
Beeblebrox said:
1. Separate issue but valid: Why do you have two different swaps? FreeBSD can use the linux-swap!
2. If you get to the BTX loader, Grub has done it's job basically (with some exceptions). You need to explore the BTX command prompt a little. "?" will give you list of commands. ls will list folders, etc. Read loader(8)()
Is your vfs.root.mountfrom setting in /boot/loader.conf correct?
Find the correct path to the /boot/kernel/ with ls and at btx prompt and tell btx to boot:
[CMD=">"]boot /boot/kernel[/CMD]

I can't be more help because I need more specifics of your problem from btx output.

Unfortunately, the BTX loader seems to be frozen. It only gives me the can't load kernel error and does not register any keypresses. Is this possibly because I'm running EFI? From GRUB's CLI I can see /boot/kernel/kernel and /boot/loader --> do I need to manually edit the loader file after a clean installation?

I'd really like to try out directly booting the kernel from GRUB if possible as this method seems to bypass the FreeBSD bootloader with EFI issue. However, the only thing that I'm really adamant about is that I want to use GRUB2 (instead of some combination of rEFIt, eLILO, and whatever else) because it is what I am familiar with and the most flexible for me. I don't mind destroying and recreating partitions though... but I'd like to keep the linux ones as that is where I have moved my data during this process.

Again, this should be all the relevant information (placing it here so people that are just coming in can more easily find the details):
****************************************************************************************************************************************

Partition Scheme
Code:
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.2

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1188BEF2-7D18-467B-A5ED-0E7A37229F9E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 128-sector boundaries
Total free space is 341051509 sectors (162.6 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            4096          823295   400.0 MiB   EF00  EFI System
   2          823296      3146551295   1.5 TiB     8300  Linux filesystem
   3      3146551296      3146551423   64.0 KiB    A501  
   4      3146551424      3565981687   200.0 GiB   A503  DAEMON

GRUB2 Command Line Information
Also note that GRUB can see /boot/loader and /boot/kernel/kernel on (hd0,gpt4).
Code:
grub> ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd0,gpt4)

Proof of EFI mode
Code:
# efibootmgr BOOT
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0004,0000,0001
Boot0000* SATA1:SAMSUNG HD204UI         
Boot0001* IBA GE Slot 0200 v1321
Boot0003* GRUB2
Boot0004* Built-in EFI Shell

GRUB configuration
Also note that it seems that the second menuentry is the only one that gets me to the BTX loader. The chainloader methods produce [cmd=]Invalid EFI file path[/cmd] and the direct kernel boot methods go directly to a blank screen that halts indefinitely
Code:
menuentry "FreeBSD boot" {
        insmod ufs2
        set root='(hd0,gpt3)'
        kfreebsd        /boot/loader
}

menuentry "FreeBSD root" {
        insmod ufs2
        set root='(hd0,gpt4)'
        search --no-floppy --fs-uuid --set=root 4f55953a783b1ac8
        kfreebsd        /boot/loader
}

menuentry "FreeBSD direct root" {
        insmod ufs2
        set root='(hd0,gpt4)'
        search --no-floppy --fs-uuid --set=root 4f55953a783b1ac8
        kfreebsd /boot/kernel/kernel
        kfreebsd_loadenv /boot/device.hints
        set kFreeBSD.vfs.root.mountfrom=ufs:ad0p4
        set KFreeBSD.vfs.root.mountfrom.options=rw
}

menuentry "FreeBSD direct boot" {
        insmod ufs2
        set root='(hd0,gpt3)'
        kfreebsd /boot/kernel/kernel
        kfreebsd_loadenv /boot/device.hints
        set kFreeBSD.vfs.root.mountfrom=ufs:ad0p3
        set KFreeBSD.vfs.root.mountfrom.options=rw
}

menuentry "FreeBSD, way of shotgun boot" {
    set root=(hd0,gpt3)
    chainloader +1
}

menuentry "FreeBSD, way of shotgun root" {
    set root=(hd0,gpt4)
    chainloader +1
}

What I'm trying to do
I really want to use EFI/GPT on my new motherboard. I need to use GPT in order to deal with >4 Primary Partitions for my multiboot environment and I need to use EFI in order to be able to boot Windows 7 x86_64 from a GPT drive.
I prefer to use GRUB as my bootloader and, if possible, I want to boot the FreeBSD kernel directly with GRUB instead of chainloading. Apparently, GRUB2 supports FreeBSD for this method.
I have considered using a virtual machine for FreeBSD, but that is not what I want to do. Besides, I'm very curious why this is not working at this point! If anything, I need to have an answer for academic purposes!
 
If you use UEFI/GPT, you have to make seperate GPT partitions for FreeBSD boot, /, swap, /usr, etc.

However, you said that you made a slice. I have no idea how you did that. A slice (e.g. ad0s3a) is for MBR/DOS partition scheme as far as I know. So where is your FreeBSD boot partition that UEFI can recognize?
 
ahavatar said:
If you use UEFI/GPT, you have to make seperate GPT partitions for FreeBSD boot, /, swap, /usr, etc.

However, you said that you made a slice. I have no idea how you did that. A slice (e.g. ad0s3a) is for MBR/DOS partition scheme as far as I know. So where is your FreeBSD boot partition that UEFI can recognize?

I DO NOT have that partitioning scheme any longer. It went with the old (BIOS) motherboard. The FreeBSD installer created /dev/ada0p3 and /dev/ada0p4] which correspond to (hd0,gpt3) and (hd0,gpt4), respectively. These are outlined in my last post which describes the new partition scheme and I have mentioned the new partition scheme AND the change to EFI/GPT previously. The error that I receive while booting, however, remains the same. All things being equal, I think the problem is the way that my GRUB2 menuentries are set up and I am looking for help regarding this.

Now, the installed made /dev/ada0p3 the "freebsd-boot" partition and /dev/ada0p4 is "freebsd-ufs" mounted on "/"

I'm am not aware of any documentation that states that separate partitions are needed for /usr, /var, or any other directories.
 
I don't know if this works and it's ugly,

1. On your FreeBSD, run
# gpart bootcode -b /boot/pmbr -g /boot/gptboot /dev/ada0
this makes only FreeBSD bootable, right?

2. On your Linux (rescue CD if already installed), copy mbr to /ada0.mbr
# dd if=/dev/ada0 of=/ada0.mbr bs=512 count=1

3. Install Grub2 on your Linux with
menuentry "FreeBSD, way of shotgun root" {
set root=(hd0,gpt4)
chainloader (hd0,gpt5)/ada0.mbr
}
where gpt5 is the root of your Linux and gpt4 is the root of your FreeBSD.
 
I'm not sure what those commands are meant to accomplish. Clearly, GRUB2 can already see the FreeBSD partitions and I am not using MBR. I do not wish to destroy my partition table so why would I try those commands?
 
It does not destroy your GPT partition table. It just writes in the protective mbr and the freebsd-boot partition. As far as I know, Grub2 for FreeBSD GPT system disk has no clean solution yet. If you come up with a better solution, let me know. Good luck!
 
I think I found similar information in here (FreeBSD GPT howto).

And from here (rodbooks)

The FreeBSD installer did not seem to have any issues recognizing the GPT table that was already in place. However, I did find it strange that it created a separate partition for the gptboot as both guides made it seem that the GPT /boot was not an actual partition and it really just resides in root.

However, the Handbook (see section on Standard FreeBSD GPT Partitions) indicates that the "freebsd-boot" partition is a real partition for GPT that holds the bootcode (this would be the gptboot?), except that it does not seem to have a mountpoint according to the Handbook. Anyway, the installer did create this 64kB "freebsd-boot" partition, but exists after the linux partitions (which is 1.5TB into the drive).

If I created a new partition scheme that was:
Device----------------Mount Point-----------Name
/dev/ad0p1---- /boot/efi--------- (EFI System Partition of 400MB)
/dev/ad0p2------------------------- (FreeBSD "freebsd-boot" of 64kB)
/dev/ad0p3---- /--------------------- (FreeBSD root of 200GB)
/dev/ad0p4---- /--------------------- (Linux root of 1.5TB)

Do you think that this would function? The only difference from my current scheme would be that the "freebsd-boot" partition would come immediately after the ESP. I am also curious if I could just tell EFI where to find a FreeBSD boot.efi, if any such such exists for FreeBSD. That way, I could avoid using GRUB altogether. Though, to be honest, I do enjoy using GRUB for its flexibility.
 
The problem of the current state of FreeBSD and Grub2 is, to my understanding, that there is no boot manager that can reside in the EFI System Partition. What this means is that if you need to boot only FreeBSD GPT disk, that's fine. You can even use Grub2 as you wish.

But if you want a multi-boot Grub2 setting, there is no easy and clean method for GPT system disk. Windows 7 and Linux have boot managers that reside in the EFI System Partition so you can multi-boot Windows and Linux GPT system disk easily with Grub2.

That's my understanding and that's the reason to use kludge for multi-booting FreeBSD GPT disk with Grub2.
 
That's not the greatest news. I'll try the workaround you've suggested about messing with the pmbr and gptboot files.

As a side note, I almost thought for second that "kludge" might be the name of some crazy bootloader. Hah. My only remaining question is whether there is any ongoing effort to port the ia64 efi bootloader to the i386/amd64 platforms?

I checked out Revision 206376 so I know there's some interest in this, but not anything for amd64 yet. This thread also seems to indicate interest.
 
Try this if, for instance, /boot/efi artition is (hd0,gpt2) in grub's ls:
Code:
chainloader (hd0,gpt2)/efi/boot/BOOTx64.efi
 
if you want to load it via EFI you need to make sure your BOOTx64.efi is copied on that "msdos" (=fat) partition you're using. You can obviously share that with our Archlinux. Then something:

menuentry "FreeBSD" {
insmod part_gpt
insmod fat
set root='hd0,gpt1'
chainloader /EFI/BOOT/BOOTX64.EFI
}

should work. Whereas gpt1 is the fat formatted "EFI" partition.
 
Back
Top