Re: mkimg used to create gpt image, problem booting

2014-08-23 Thread Craig Rodrigues
Hi,

I did some more experiments, and found that after /boot/loader runs,
if I break into the loader prompt and type "lsdev", I would get this:

(1)  GPT Disk image which boots under QEMU, made by bsdinstall
==
View from loader

OK lsdev
cd devices:
disk devices:
  disk0:BIOS drive A:
  disk1:BIOS drive C:
 disk1p1: FreeBSD boot
 disk1p2: FreeBSD UFS
 disk1p3: FreeBSD swap
pxe devices:


View from gpart, after we mdconfig the disk image

=>  34  10485693  md0  GPT  (5.0G)
34   1281  freebsd-boot  (64K)
   162   99592962  freebsd-ufs  (4.7G)
   99594585242883  freebsd-swap  (256M)
  10483746  1981   - free -  (991K)


(2)  GPT Disk image which fails to boot under QEMU, made by mkimg
===
View from loader

OK lsdev
cd devices:
disk devices:
  disk0:BIOS drive A:
  disk1:BIOS drive C:
pxe devices:

View from gpart, after we mdconfig the disk image


=>  3  1784944  md1  GPT  (872M)
3   321  freebsd-boot  (16K)
   35  17849122  freebsd-ufs  (872M)



This leads me to believe that there is logic in /boot/loader,
which is not in GEOM, that fails to parse the GPT produced by mkimg.


I did some further debugging inside the loader by doing the following.
  -> I added "CFLAGS += -DPART_DEBUG" to sys/boot/common/Makefile.inc
  -> I added DEBUG() statements all over sys/boot/common/part.c

I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
that in this section:

305 ent = (struct gpt_ent *)tbl;
306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
307 MAXTBLSZ * table->sectorsize);
308 for (i = 0; i < size / hdr.hdr_entsz; i++, ent++) {
309 if (uuid_equal(&ent->ent_type, &gpt_uuid_unused, NULL))
310 continue;

ent->ent_type is all 0's, which matches gpt_uuid_unused, so it bails
out of the loop and never adds the gpt partitions to the list of partitions
that the loader can access.

I'm not familiar with the GPT format, nor am I familiar with the
gpt code inside the loader, and how it differs from GEOM.

Do you have any further ideas of where to hunt for the root cause of
the problem?

Thanks.

--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: gbde destroy doesn't match man page?

2014-08-23 Thread Poul-Henning Kamp

In message <20140820215522.ga92...@bewilderbeast.blackhelicopters.org>, "Michae
l W. Lucas" writes:

>Playing with GBDE for my FreeBSD disk book, on:
>
># uname -a
>FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 
>11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC  amd64
>
>According to the man page, I should be able to destroy all copies of
>the key with gbde destroy  -n -1. It's in the examples. When I
>try it I get:

I think that is an oversight in the code.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: mkimg used to create gpt image, problem booting

2014-08-23 Thread Craig Rodrigues
On Sat, Aug 23, 2014 at 12:11 PM, Marcel Moolenaar  wrote:
>
> Could be. Try the -P option to mkimg. It sets the
> underlying (unexposed) physical sector size while
> still working with the visible 512 bytes sectors.
> The net effect is that for the GPT scheme things
> get aligned to the physical sector size and that
> it also causes the image size to be rounded.
>
> You can also try emitting vmdk directly to see if
> that makes a difference. vmdk also has the side-
> effect of rounding the image to the grain size.


I tried the following experiments:

mkimg -v -f vmdk -s gpt -b test1/boot/pmbr -p
freebsd-boot:=test1/boot/gptboot -p freebsd-ufs:=/tmp/file.img -o
/tmp/foo1.vmdk

When I tried to boot the image in QEMU, I had the same problem as before.
It looks like it started writing the image on block 3, same as before.


I also tried adding the -P flag, with different values like 2048 and 4096.
I ran into the same problem.

Hmm.

--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: mkimg used to create gpt image, problem booting

2014-08-23 Thread Marcel Moolenaar

On Aug 23, 2014, at 12:00 PM, Craig Rodrigues  wrote:
> 
> 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?

Could be. Try the -P option to mkimg. It sets the
underlying (unexposed) physical sector size while
still working with the visible 512 bytes sectors.
The net effect is that for the GPT scheme things
get aligned to the physical sector size and that
it also causes the image size to be rounded.

You can also try emitting vmdk directly to see if
that makes a difference. vmdk also has the side-
effect of rounding the image to the grain size.

-- 
Marcel Moolenaar
mar...@xcllnt.net




signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: mkimg used to create gpt image, problem booting

2014-08-23 Thread Craig Rodrigues
On Fri, Aug 22, 2014 at 1:45 PM, Marcel Moolenaar  wrote:
>
>> If I mdconfig the foo1.img disk image, and do a gpart show, I see:
>>
>> =>  3  1784944  md0  GPT  (872M)
>>3   321  freebsd-boot  (16K)
>>   35  17849122  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   1281  83bd6b9d-7f41-11dc-be0b-001560b84f0f  (64K)
   162   99592962  516e7cb6-6ecf-11d6-8ff8-00022d09712b  (4.7G)
   99594585242883  516e7cb5-6ecf-11d6-8ff8-00022d09712b  (256M)
  10483746  1981   - free -  (991K)

DOES NOT BOOT IN QEMU, CREATED WITH MKIMG
===
=>  3  1784944  md1  GPT  (872M)
3   321  83bd6b9d-7f41-11dc-be0b-001560b84f0f  (16K)
   35  17849122  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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot

2014-08-23 Thread Adrian Chadd
I thought there was a recent discussion about this.

Would you mind filing a bug so this gets looked at?


-a


On 23 August 2014 02:42, Joel Dahl  wrote:
>
> 23 aug 2014 kl. 09:17 skrev Matthew D. Fuller :
>
>> On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of
>> Joel Dahl, and lo! it spake thus:
>>>
>>> Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot
>>> on my IBM T43 laptop but encountered some problems. The memstick
>>> installation went fine and I pretty much used default values
>>> everywhere, but upon reboot I got ”Boot loader too large”. Nothing
>>> more. Any ideas?
>>
>> The freebsd-boot partition is bigger than five hundred twenty-mumble
>> k.  It'll be OK if you squeeze it down to 512.  Somthing like 'gpart
>> resize -i 1 -s 512k ada23' (untested, sub your disk).
>
> Yes, gpart fixed it. Thanks.
>
> But it’s annoying. Why is manual tinkering required here? Why isn’t it set to 
> 512k by default?
>
> I checked the handbook (2.6.3), and it says ”the freebsd-boot partition 
> should be no larger than 512K due to current boot code limitations” ...
>
> Joel
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot

2014-08-23 Thread Joel Dahl

23 aug 2014 kl. 09:17 skrev Matthew D. Fuller :

> On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of
> Joel Dahl, and lo! it spake thus:
>> 
>> Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot
>> on my IBM T43 laptop but encountered some problems. The memstick
>> installation went fine and I pretty much used default values
>> everywhere, but upon reboot I got ”Boot loader too large”. Nothing
>> more. Any ideas?
> 
> The freebsd-boot partition is bigger than five hundred twenty-mumble
> k.  It'll be OK if you squeeze it down to 512.  Somthing like 'gpart
> resize -i 1 -s 512k ada23' (untested, sub your disk).

Yes, gpart fixed it. Thanks.

But it’s annoying. Why is manual tinkering required here? Why isn’t it set to 
512k by default?

I checked the handbook (2.6.3), and it says ”the freebsd-boot partition should 
be no larger than 512K due to current boot code limitations” ...

Joel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Recent vt(4) broke moused when hw.vga.textmode=1

2014-08-23 Thread Xin Li
On 8/23/14 12:42 AM, Jean-Sébastien Pédron wrote:
> On 23.08.2014 08:38, Xin Li wrote:
>> Fatal trap 12: page fault while in kernel mode
> 
> And the crash is fixed in r270390.
> 
> Thank you for reporting this!

I have verified and r270390 have fixed the crash, thanks for the prompt fix!

Cheers,

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Recent vt(4) broke moused when hw.vga.textmode=1

2014-08-23 Thread Jean-Sébastien Pédron

On 23.08.2014 08:38, Xin Li wrote:

Fatal trap 12: page fault while in kernel mode


And the crash is fixed in r270390.

Thank you for reporting this!

--
Jean-Sébastien Pédron
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot

2014-08-23 Thread Matthew D. Fuller
On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of
Joel Dahl, and lo! it spake thus:
> 
> Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot
> on my IBM T43 laptop but encountered some problems. The memstick
> installation went fine and I pretty much used default values
> everywhere, but upon reboot I got ”Boot loader too large”. Nothing
> more. Any ideas?

The freebsd-boot partition is bigger than five hundred twenty-mumble
k.  It'll be OK if you squeeze it down to 512.  Somthing like 'gpart
resize -i 1 -s 512k ada23' (untested, sub your disk).


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze

2014-08-23 Thread Jean-Sébastien Pédron

On 23.08.2014 07:16, O. Hartmann wrote:

On different platforms with different graphics hardware, recent CURRENT
r 270386 shows a screen filled with question marks when booting,


The '?' filling screen issue is fixed in HEAD as of r270388.

Again, sorry for that. Thank you for reporting the problem!

--
Jean-Sébastien Pédron
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot

2014-08-23 Thread Joel Dahl
Hi,

Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot on my IBM 
T43 laptop but encountered some problems. The memstick installation went fine 
and I pretty much used default values everywhere, but upon reboot I got ”Boot 
loader too large”. Nothing more. Any ideas?

Joel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"