Re: mkimg used to create gpt image, problem booting
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?
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
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
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
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
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
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
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
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
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
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
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"