On 24.08.2014 19:23, Marcel Moolenaar wrote:
On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
On 24.08.2014 06:14, Craig Rodrigues wrote:
I did some further debugging inside the loader by doing the following.
- I added CFLAGS += -DPART_DEBUG to
On 24.08.2014 20:59, Craig Rodrigues wrote:
Also, in the gptboot man page, it mentions that gptboot can only boot
on systems with 128 partitions or less. This seems like an artificial
restriction.
Does the gptboot code really enforce this? Not that I have a system with more
than 128
On 25.08.2014 03:55, Marcel Moolenaar wrote:
Though, w/ people dd'ing images onto disks, and using growfs to grow
as necessary, we might want to allocate a few more more than the
minimum... I do agree that we want to keep sizes to a minimum...
One thing I can maybe do is simply fill the
On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
On 25.08.2014 03:55, Marcel Moolenaar wrote:
Though, w/ people dd'ing images onto disks, and using growfs to grow
as necessary, we might want to allocate a few more more than the
minimum... I do agree that we want to
On 25.08.2014 18:40, Marcel Moolenaar wrote:
Also, now FreeBSD 11.0 uses different first usable LBA. By default it is
4k aligned. And this creates some incompatibility with older versions.
You can't do `gpart restore` and get the same table, as you had on older
system.
It sounds restore is
Andrey V. Elsukov wrote this message on Mon, Aug 25, 2014 at 19:02 +0400:
On 25.08.2014 18:40, Marcel Moolenaar wrote:
Also, now FreeBSD 11.0 uses different first usable LBA. By default it is
4k aligned. And this creates some incompatibility with older versions.
You can't do `gpart restore`
On 24.08.2014 06:14, Craig Rodrigues wrote:
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
On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
On 24.08.2014 06:14, Craig Rodrigues wrote:
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
On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
Index: head/sys/boot/common/part.c
===
--- head/sys/boot/common/part.c (revision
On Sun, Aug 24, 2014 at 8:23 AM, Marcel Moolenaar mar...@xcllnt.net wrote:
On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
On 24.08.2014 06:14, Craig Rodrigues wrote:
I did some further debugging inside the loader by doing the following.
- I added CFLAGS +=
On Aug 24, 2014, at 9:59 AM, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
Should mkimg be changed to create a partition table with 128
On Sun, Aug 24, 2014 at 12:05 PM, Marcel Moolenaar mar...@xcllnt.net wrote:
On Aug 24, 2014, at 9:59 AM, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
Yes, the problem is in the ptable_gptread() function. I'll commit
Craig Rodrigues wrote this message on Sun, Aug 24, 2014 at 15:37 -0700:
On Sun, Aug 24, 2014 at 12:05 PM, Marcel Moolenaar mar...@xcllnt.net wrote:
On Aug 24, 2014, at 9:59 AM, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru
On Aug 24, 2014, at 4:31 PM, John-Mark Gurney j...@funkthat.com wrote:
With mkimg, you know exactly how many partitions you are creating
, so you don't need to specify 128 as the number of partitions.
Though, w/ people dd'ing images onto disks, and using growfs to grow
as necessary, we
On Fri, Aug 22, 2014 at 1:45 PM, Marcel Moolenaar mar...@xcllnt.net 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
On Aug 23, 2014, at 12:00 PM, Craig Rodrigues rodr...@freebsd.org 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
On Sat, Aug 23, 2014 at 12:11 PM, Marcel Moolenaar mar...@xcllnt.net 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
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
On Aug 22, 2014, at 9:49 AM, Craig Rodrigues rodr...@freebsd.org wrote:
(5) Tried to boot the image with qemu:
qemu-system-x86_64 -m 2048 -hda /tmp/foo1.img
*snip*
If I mdconfig the foo1.img disk image, and do a gpart show, I see:
= 3 1784944 md0 GPT (872M)
3
On 22 August 2014 16:45, Marcel Moolenaar mar...@xcllnt.net wrote:
I have so far not been able to boot an image created
by mkimg with a FreeBSD-hosted qemu.
o VMware and VirtualBox are fine.
o A non-FreeBSD hosted qemu also works fine.
For what it's worth, I have no trouble booting a
20 matches
Mail list logo
