Loader, MBR and the boot process

Dan Naumov dan.naumov at gmail.com
Sun Jan 24 15:59:14 UTC 2010


On Sun, Jan 24, 2010 at 5:29 PM, John <john at starfire.mn.org> wrote:
> On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote:
>> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov <dan.naumov at gmail.com> wrote:
>> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. <fwd at gothschlampen.com> wrote:
>> >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote:
>> >>
>> >> Hi,
>> >>
>> >>> I recently found a nifty "FreeBSD ZFS root installation script" and
>> >>> been reworking it a bit to suit my needs better, including changing it
>> >>> from GPT to MBR partitioning. However, I was stumped, even though I
>> >>> had done everything right (or so I thought), the system would get
>> >>> stuck at Loader and refuse to go anywhere. After trying over a dozen
>> >>
>> >> probably this line is the cause:
>> >>
>> >> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s1a skip=1 seek=1024
>> >>
>> >> Unless by "swap first" you meant the on-disk location, and not the
>> >> partition letter. If swap is partition "a", you're writing the loader
>> >> into swapspace.
>> >>
>> >>
>> >> Regards,
>> >> Thomas
>> >
>> > At first you made me feel silly, but then I decided to double-check, I
>> > uncommented the swap line in the partitioning part again, ensured I
>> > was writing the bootloader to "${TARGETDISK}"s1b and ran the script.
>> > Same problem, hangs at loader. Again, if I comment out the swap,
>> > giving the entire slice to ZFS and then write the bootloader to
>> > "${TARGETDISK}"s1a, run the script, everything works.
>>
>> I have also just tested creating 2 slices, like this:
>>
>> gpart create -s mbr "${TARGETDISK}"
>> gpart add -s 3G -t freebsd "${TARGETDISK}"
>> gpart create -s BSD "${TARGETDISK}"s1
>> gpart add -t freebsd-swap "${TARGETDISK}"s1
>>
>> gpart add -t freebsd "${TARGETDISK}"
>> gpart create -s BSD "${TARGETDISK}"s2
>> gpart add -t freebsd-zfs "${TARGETDISK}"s2
>>
>> gpart set -a active -i 2 "${TARGETDISK}"
>> gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}"
>>
>>
>> and later:
>>
>> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2 count=1
>> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2a skip=1 seek=1024
>>
>>
>> Putting the swap into it's own slice and then putting FreeBSD into
>> it's own slice worked fine. So why the hell can't they both coexist in
>> 1 slice if the swap comes first?
>
> I know what the answer to this USED to be, but I don't know if it is
> still true (obviously, I think so, I or wouldn't waste your time).
>
> The filesystem code is all carefully written to avoid the very
> first few sector of the partition.  That's because the partition
> table is there for the first filesystem of the slice (or disk).
> That's a tiny amout of space wasted, because it's also skipped on
> all the other filesystems even though there's not actually anything
> there, but it was a small inefficency, even in the 70's.
>
> Swap does not behave that way.  SWAP will begin right at the slice
> boundry, with 0 offset.  As long as it's not the first partition, no
> harm, no foul.  If it IS the first partition, you just nuked your partition
> table.  As long as SWAP owns the slice, again, no harm, no foul, but
> if there were filesystems BEHIND it, you just lost 'em.
>
> That's the way it always used to be, and I think it still is.  SWAP can
> only be first if it is the ONLY thing using that slice (disk), otherwise,
> you need a filesystem first to protect the partition table.
> --
>
> John Lind
> john at starfire.MN.ORG

This explanation does sound logical, but holy crap, if this is the
case, you'd think there would be bells, whistles and huge red label
warnings in EVERY FreeBSD installation / partitioning guide out there
warning people to not put swap first (unless given a dedicated slice)
under any circumstances. The warnings were nowhere to be seen and lots
of pointy hair first greyed and were then lost during the process of
me trying to figure out why my system would install but wouldn't boot.

- Sincerely,
Dan Naumov


More information about the freebsd-questions mailing list