Re: Loader, MBR and the boot process
On Mon, 2010-01-25 at 09:45 +, Matthew Seaman wrote: > Andriy Gapon wrote: > > on 25/01/2010 04:41 Robert Noland said the following: > >> On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: > >>> offset The offset of the start of the partition from the beginning > >>> of > >>> the drive in sectors, or * to have bsdlabel calculate the > >>> correct > >>> offset to use (the end of the previous partition plus one, > >>> ignor- > >>> ing partition `c'. For partition `c', * will be interpreted > >>> as > >>> an offset of 0. The first partition should start at offset > >>> 16, > >>> because the first 16 sectors are reserved for metadata. > >> Ok, now this has my attention... My gut feeling right now is that this > >> is a bug in geom_part_bsd. I don't understand why the label isn't > >> protected. (Adding -b 16 when adding the swap partition fixes this) > >> Another project to goes on my list... > >> > >> If anyone knows why this is done like this... please share. > > > > I presume that this is for purely historic reasons. > > > > I believe this has been known about since 5.x days: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=72812 > > As far as I recall, sometime around 6.1-RELEASE this should have been > fixed. It certainly seems to be the case that it is harmless to have > a plain swap partition start at offset 0, but anything else, like encrypted > swap or putting a filesystem there needs the 16 sector offset. When the first partition (whatever it is), starts at offset 0, if you dd into that partition you wipe out the label entirely, which just doesn't make sense to me. Trying to manage this in the file system code and the swap pager or whatever other consumer might make use of the partition seems like madness to me. robert. > Cheers, > > Matthew > -- Robert Noland FreeBSD ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: Loader, MBR and the boot process
Andriy Gapon wrote: on 25/01/2010 04:41 Robert Noland said the following: On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: offset The offset of the start of the partition from the beginning of the drive in sectors, or * to have bsdlabel calculate the correct offset to use (the end of the previous partition plus one, ignor- ing partition `c'. For partition `c', * will be interpreted as an offset of 0. The first partition should start at offset 16, because the first 16 sectors are reserved for metadata. Ok, now this has my attention... My gut feeling right now is that this is a bug in geom_part_bsd. I don't understand why the label isn't protected. (Adding -b 16 when adding the swap partition fixes this) Another project to goes on my list... If anyone knows why this is done like this... please share. I presume that this is for purely historic reasons. I believe this has been known about since 5.x days: http://www.freebsd.org/cgi/query-pr.cgi?pr=72812 As far as I recall, sometime around 6.1-RELEASE this should have been fixed. It certainly seems to be the case that it is harmless to have a plain swap partition start at offset 0, but anything else, like encrypted swap or putting a filesystem there needs the 16 sector offset. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Loader, MBR and the boot process
on 25/01/2010 04:41 Robert Noland said the following: > On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: >> offset The offset of the start of the partition from the beginning of >> the drive in sectors, or * to have bsdlabel calculate the >> correct >> offset to use (the end of the previous partition plus one, >> ignor- >> ing partition `c'. For partition `c', * will be interpreted as >> an offset of 0. The first partition should start at offset 16, >> because the first 16 sectors are reserved for metadata. > > Ok, now this has my attention... My gut feeling right now is that this > is a bug in geom_part_bsd. I don't understand why the label isn't > protected. (Adding -b 16 when adding the swap partition fixes this) > Another project to goes on my list... > > If anyone knows why this is done like this... please share. I presume that this is for purely historic reasons. -- Andriy Gapon ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: Loader, MBR and the boot process
On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote:
> In message , Dan
> N
> aumov writes:
> > On Sun, Jan 24, 2010 at 5:29 PM, John 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 wrote=
> > :
> > >> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K.
> > >> > wro=
> > te:
> > >> >> 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=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s1a skip=3D1 seek=
> > =3D1024
> > >> >>
> > >> >> 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=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2 count=3D1
> > >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2a skip=3D1 seek=3D=
> > 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. =A0That'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. =A0SWAP will begin right at the slice
> > > boundry, with 0 offset. =A0As long as it's not the first partition, no
> > > harm, no foul. =A0If it IS the first partition, you just nuked your parti=
> > tion
> > > table. =A0As 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. =A0SWAP 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
> > > [email protected]
> >
> > 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.
>
> >From "man bsdlabel".
>
> offset The offset of the start of the partition from the beginning of
> the drive in sectors, or * to have bsdlabel calculate the correct
> offset to use (the end of the previous partition plus one, ignor-
> ing partition `c'. For partition `c', * will be interpreted as
> an offset of 0. The first partition should start at offset 16,
> because the first 16 sectors are reserved for metadata.
Ok, now this has my attention... My gut feeling right now is that this
is
Re: Loader, MBR and the boot process
In message , Dan N
aumov writes:
> On Sun, Jan 24, 2010 at 5:29 PM, John 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 wrote=
> :
> >> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. wro=
> te:
> >> >> 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=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s1a skip=3D1 seek=
> =3D1024
> >> >>
> >> >> 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=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2 count=3D1
> >> dd if=3D/mnt2/boot/zfsboot of=3D/dev/"${TARGETDISK}"s2a skip=3D1 seek=3D=
> 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. =A0That'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. =A0SWAP will begin right at the slice
> > boundry, with 0 offset. =A0As long as it's not the first partition, no
> > harm, no foul. =A0If it IS the first partition, you just nuked your parti=
> tion
> > table. =A0As 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. =A0SWAP 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
> > [email protected]
>
> 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.
>From "man bsdlabel".
offset The offset of the start of the partition from the beginning of
the drive in sectors, or * to have bsdlabel calculate the correct
offset to use (the end of the previous partition plus one, ignor-
ing partition `c'. For partition `c', * will be interpreted as
an offset of 0. The first partition should start at offset 16,
because the first 16 sectors are reserved for metadata.
> - Sincerely,
> Dan Naumov
> ___
> [email protected] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[email protected]"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
Re: Loader, MBR and the boot process
On Sun, Jan 24, 2010 at 5:29 PM, John 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 wrote:
>> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. 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
> [email protected]
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
___
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
Re: Loader, MBR and the boot process
On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote:
> On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov wrote:
> > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. 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
[email protected]
___
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
Re: Loader, MBR and the boot process
2010/1/22, Dan Naumov : > 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? Similar problem here: I have a full-zfs system in a bsd slice, but I have the zfs-freebsd partition before the swap one. The problem is that the system doesn't seem to detect the swap partition partition (I see "swapon: /dev/ada0s1b: No such file or directory" during boot) % bsdlabel /dev/ada0s1 # /dev/ada0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 530432000 ZFS b: 9883342 53043200 swap c: 629265420unused0 0 # "raw" part, don't edit but to see ada0s1b in /dev/ I have to reload geom_bsd module (loading it at boot time doesn't work). Even though (but this seems to be another problem): % sudo swapon /dev/ada0s1b swapon: /dev/ada0s1b: Operation not permitted Regards, Romain ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: Loader, MBR and the boot process
On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov wrote:
> On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. 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?
- Dan Naumov
___
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
Re: Loader, MBR and the boot process
On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. 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.
- Sincerely,
Dan Naumov
___
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
Re: Loader, MBR and the boot process
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
___
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
Loader, MBR and the boot process
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 different things, it downed on me to change the partition order inside the slice, I had 1) swap 2) freebsd-zfs and for the test, I got rid of swap altogether and gave the entire slice to the freebsd-zfs partition. Suddenly, my problem went away and the system booted just fine. So it seems that Loader requires that the partition containing the files vital to the boot is the first partition on the slice and that "swap first, then the rest" doesn't work. The thing is, I am absolutely positive that in the past, I've had sysinstall created installs using MBR partitioning and that I had swap as my first partition inside the slice and that it all worked dandy. Has this changed at some point? Oh, and for the curious the installation script is here: http://jago.pp.fi/zfsmbrv1-works.sh - Sincerely, Dan Naumov ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
