Date: Sat, 23 Aug 2014 12:00:40 -0700 From: Craig Rodrigues <rodrigc@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: mkimg used to create gpt image, problem booting Message-ID: <CAG=rPVes3Eq87hOE6W135yGvzRiAzHTbCGSxiyd0JBAs2ufqmA@mail.gmail.com> In-Reply-To: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> References: <CAG=rPVeucq%2BsMxe_NPe3Og939o=Sg4WGfYL7PjA1uXGU8uL=8g@mail.gmail.com> <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 22, 2014 at 1:45 PM, Marcel Moolenaar <marcel@xcllnt.net> wrote:
>
>> If I mdconfig the foo1.img disk image, and do a gpart show, I see:
>>
>> => 3 1784944 md0 GPT (872M)
>> 3 32 1 freebsd-boot (16K)
>> 35 1784912 2 freebsd-ufs (872M)
>>
>> Any idea what I am doing wrong?
>
> To the best of my knowledge, qemu is the thing you're
> doing wrong :-)
Hi,
I transferred foo1.img to a Mac with VirtualBox, converted it to VMDK
with "VBoxManage convertfromraw --format VMDK", and tried to boot it
in VirtualBox.
I got the same error as in QEMU. It looks like /boot/loader runs,
but I cannot do "ls" to see the root file system.
I created another disk image with a GPT layout, but this time
using the FreeBSD bsdinstall inside a bhyve VM.
I noticed the following:
WORKING IMAGE BOOTS IN QEMU, CREATED WITH BSDINSTALL
=============================================
=> 34 10485693 md0 GPT (5.0G)
34 128 1 83bd6b9d-7f41-11dc-be0b-001560b84f0f (64K)
162 9959296 2 516e7cb6-6ecf-11d6-8ff8-00022d09712b (4.7G)
9959458 524288 3 516e7cb5-6ecf-11d6-8ff8-00022d09712b (256M)
10483746 1981 - free - (991K)
DOES NOT BOOT IN QEMU, CREATED WITH MKIMG
===================================================
=> 3 1784944 md1 GPT (872M)
3 32 1 83bd6b9d-7f41-11dc-be0b-001560b84f0f (16K)
35 1784912 2 516e7cb6-6ecf-11d6-8ff8-00022d09712b (872M)
I ran the following crazy experiment, just to see what would happen:
dd if=/dev/md1s2 of=/dev/md0s2 bs=8192
I then tried to boot the first image with QEMU, and it booted successfully,
with my UFS file system that I had previously created with makefs.
I'm not sure where to look for the problem. I notice that
in the non-working image, the offset starts at block 3,
while in the working image, the offset starts at block 34.
Is that enough to make things not boot?
--
Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG=rPVes3Eq87hOE6W135yGvzRiAzHTbCGSxiyd0JBAs2ufqmA>