Date: Tue, 31 Jan 2006 10:21:02 -0800 From: Luigi Rizzo <rizzo@icir.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: current@freebsd.org Subject: Re: boot block differences between 4.x and 6.x ? Message-ID: <20060131102102.B57192@xorpc.icir.org> In-Reply-To: <20060131.085804.96587431.imp@bsdimp.com>; from imp@bsdimp.com on Tue, Jan 31, 2006 at 08:58:04AM -0700 References: <20060131061812.A53329@xorpc.icir.org> <43DF77B7.4050800@samsco.org> <20060131.085804.96587431.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 31, 2006 at 08:58:04AM -0700, M. Warner Losh wrote: ... > : The big difference is that the boot blocks grew significantly to > : support UFS2. > > And boot1/boot2 were merged into boot... ok problem solved, thanks for the pointers. For the records (and the list archives): the old-style picobsd script would do image[0..511] = boot1[0..511] image[1024..8191] = boot2[512..7679] counting on a 512-bytes hole which is taken, for the first 0x114 = 276 (dec) bytes by the label. The new boot blocks, however have code immediately after the label so the offset for copying boot2 (or the equivalent part of /boot/boot) must be set to 276 on the source and 276+512 = 788 on the destination: image[0..511] = boot1[0..511] image[788..8191] = boot2[276..7679] don't know how much of a hack it is to hardwire the disklabel size into the script, but given that this approach of explicit constants is used in all the related pieces of code, i guess there is no better way around... cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060131102102.B57192>