Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Reinstalling boot blocks on a ZFS-only system
6 views
Skip to first unread message
Jeremy Chadwick
May 12, 2013, 4:58:37 PM5/12/13
to
On Sun, May 12, 2013 at 04:50:46PM -0400, Chris Ross wrote:
>
> So, I've long known and it makes sense that when you're booted from a ZFS volume, you can't mess with the boot-loader. And, I know a few months ago I had a set of commands I would use when booted from a CD that would initialize the network and copy the "release/boot" from somewhere else so that I could install bootblocks and boot-loaders from more recent code. Sadly, I didn't _record_ those commands I was using.
>
> What do "people in the know" do when they want to update the bootblocks of a ZFS-boot system? Or, have too few people followed this path so far that they can boot UFS and do it with less difficulty?
The command is "gpart bootcode", however I cannot be bothered to
remember the syntax; I imagine it greatly depends on if you're using GPT
vs. MBR, in addition to what your partition layout look like. Meaning:
there is no "universal standard", it depends entirely on how you set
your stuff up. But the command is definitely "gpart bootcode".
Next, AFAIK there is no need to boot alternate media (CD etc.) to
accomplish this.
You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
"safety measure" / to permit writing to LBA 0; see GEOM(4) and search
for the word "foot".
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
>
> So, I've long known and it makes sense that when you're booted from a ZFS volume, you can't mess with the boot-loader. And, I know a few months ago I had a set of commands I would use when booted from a CD that would initialize the network and copy the "release/boot" from somewhere else so that I could install bootblocks and boot-loaders from more recent code. Sadly, I didn't _record_ those commands I was using.
>
> What do "people in the know" do when they want to update the bootblocks of a ZFS-boot system? Or, have too few people followed this path so far that they can boot UFS and do it with less difficulty?
The command is "gpart bootcode", however I cannot be bothered to
remember the syntax; I imagine it greatly depends on if you're using GPT
vs. MBR, in addition to what your partition layout look like. Meaning:
there is no "universal standard", it depends entirely on how you set
your stuff up. But the command is definitely "gpart bootcode".
Next, AFAIK there is no need to boot alternate media (CD etc.) to
accomplish this.
You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
"safety measure" / to permit writing to LBA 0; see GEOM(4) and search
for the word "foot".
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
Larry Rosenman
May 12, 2013, 8:09:15 PM5/12/13
to
On 2013-05-12 15:58, Jeremy Chadwick wrote:
> On Sun, May 12, 2013 at 04:50:46PM -0400, Chris Ross wrote:
>
> So, I've long known and it makes sense that when you're booted from a
> ZFS volume, you can't mess with the boot-loader. And, I know a few
> months ago I had a set of commands I would use when booted from a CD
> that would initialize the network and copy the "release/boot" from
> somewhere else so that I could install bootblocks and boot-loaders from
> more recent code. Sadly, I didn't _record_ those commands I was using.
>
> What do "people in the know" do when they want to update the bootblocks
> of a ZFS-boot system? Or, have too few people followed this path so
> far that they can boot UFS and do it with less difficulty?
>
> The command is "gpart bootcode", however I cannot be bothered to
> remember the syntax; I imagine it greatly depends on if you're using
> GPT
> vs. MBR, in addition to what your partition layout look like. Meaning:
> there is no "universal standard", it depends entirely on how you set
> your stuff up. But the command is definitely "gpart bootcode".
>
> Next, AFAIK there is no need to boot alternate media (CD etc.) to
> accomplish this.
>
> You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
> "safety measure" / to permit writing to LBA 0; see GEOM(4) and search
> for the word "foot".
Assuming a freebsd-boot type partition, and GPT type partition scheme,
> On Sun, May 12, 2013 at 04:50:46PM -0400, Chris Ross wrote:
>
> So, I've long known and it makes sense that when you're booted from a
> ZFS volume, you can't mess with the boot-loader. And, I know a few
> months ago I had a set of commands I would use when booted from a CD
> that would initialize the network and copy the "release/boot" from
> somewhere else so that I could install bootblocks and boot-loaders from
> more recent code. Sadly, I didn't _record_ those commands I was using.
>
> What do "people in the know" do when they want to update the bootblocks
> of a ZFS-boot system? Or, have too few people followed this path so
> far that they can boot UFS and do it with less difficulty?
>
> The command is "gpart bootcode", however I cannot be bothered to
> remember the syntax; I imagine it greatly depends on if you're using
> GPT
> vs. MBR, in addition to what your partition layout look like. Meaning:
> there is no "universal standard", it depends entirely on how you set
> your stuff up. But the command is definitely "gpart bootcode".
>
> Next, AFAIK there is no need to boot alternate media (CD etc.) to
> accomplish this.
>
> You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
> "safety measure" / to permit writing to LBA 0; see GEOM(4) and search
> for the word "foot".
this is what I
use on my ZFS boot system:
$ cat bin/update_boot.sh
#!/bin/sh
for i in `seq 0 5`
do
echo Disk ${i}
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada${i}
done
$
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
Chris Ross
May 12, 2013, 10:20:26 PM5/12/13
to
On May 12, 2013, at 16:58 , Jeremy Chadwick <j...@koitsu.org> wrote:
> The command is "gpart bootcode", however I cannot be bothered to
> remember the syntax; I imagine it greatly depends on if you're using GPT
> vs. MBR, in addition to what your partition layout look like. Meaning:
> there is no "universal standard", it depends entirely on how you set
> your stuff up. But the command is definitely "gpart bootcode".
>
> Next, AFAIK there is no need to boot alternate media (CD etc.) to
> accomplish this.
>
> You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
> "safety measure" / to permit writing to LBA 0; see GEOM(4) and search
> for the word "foot".
boot from the ZFS root. When booting from a cd, the basic:
gpart bootcode -p ${bootdir}/zfsboot ${disk}
dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024 conv=notrunc,sync
works. But, if I boot from ZFS, then I can't dd anything into the front of the
drives. Right now, the problem after booting from the CD, is trying to mount
a read/write filesystem (mfs, or the like) so that I can scp the bootblocks onto the
system and install them. BUt, I eventually found the command I'd lost. so I
think I'm alright. Thanks...
- Chris
Garrett Wollman
May 12, 2013, 11:14:20 PM5/12/13
to
In article <20130512205...@icarus.home.lan>, j...@koitsu.org writes:
>You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
>"safety measure" / to permit writing to LBA 0; see GEOM(4) and search
>for the word "foot".
If you have set up your partitioning properly (read: following the
>You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
>"safety measure" / to permit writing to LBA 0; see GEOM(4) and search
>for the word "foot".
clearly recommended best practice on the wiki), there should never,
ever be any reason to do this. (That is why it's called a DEBUG
flag.) The necessary and sufficient invocation is:
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsloader -i 1 [a]daX
I have no idea how this works with MBR partitioning, but I would make
one suggestion in that regard: DON'T. Whatever makes you think you
want to do that, think harder and find another way.
-GAWollman
Jeremy Chadwick
May 12, 2013, 11:17:42 PM5/12/13
to
On Sun, May 12, 2013 at 10:20:26PM -0400, Chris Ross wrote:
>
> On May 12, 2013, at 16:58 , Jeremy Chadwick <j...@koitsu.org> wrote:
> > The command is "gpart bootcode", however I cannot be bothered to
> > remember the syntax; I imagine it greatly depends on if you're using GPT
> > vs. MBR, in addition to what your partition layout look like. Meaning:
> > there is no "universal standard", it depends entirely on how you set
> > your stuff up. But the command is definitely "gpart bootcode".
> >
> > Next, AFAIK there is no need to boot alternate media (CD etc.) to
> > accomplish this.
> >
> > You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
> > "safety measure" / to permit writing to LBA 0; see GEOM(4) and search
> > for the word "foot".
>
> In the past, I've found I've been unable to install all of the bootblocks if I
> boot from the ZFS root. When booting from a cd, the basic:
>
> gpart bootcode -p ${bootdir}/zfsboot ${disk}
> dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024 conv=notrunc,sync
>
> works. But, if I boot from ZFS, then I can't dd anything into the front of the
> drives. Right now, the problem after booting from the CD, is trying to mount
> a read/write filesystem (mfs, or the like) so that I can scp the bootblocks onto the
> system and install them. BUt, I eventually found the command I'd lost. so I
> think I'm alright. Thanks...
What does "unable to install" mean? What output/error do you get? I am
>
> On May 12, 2013, at 16:58 , Jeremy Chadwick <j...@koitsu.org> wrote:
> > The command is "gpart bootcode", however I cannot be bothered to
> > remember the syntax; I imagine it greatly depends on if you're using GPT
> > vs. MBR, in addition to what your partition layout look like. Meaning:
> > there is no "universal standard", it depends entirely on how you set
> > your stuff up. But the command is definitely "gpart bootcode".
> >
> > Next, AFAIK there is no need to boot alternate media (CD etc.) to
> > accomplish this.
> >
> > You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
> > "safety measure" / to permit writing to LBA 0; see GEOM(4) and search
> > for the word "foot".
>
> In the past, I've found I've been unable to install all of the bootblocks if I
> boot from the ZFS root. When booting from a cd, the basic:
>
> gpart bootcode -p ${bootdir}/zfsboot ${disk}
> dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024 conv=notrunc,sync
>
> works. But, if I boot from ZFS, then I can't dd anything into the front of the
> drives. Right now, the problem after booting from the CD, is trying to mount
> a read/write filesystem (mfs, or the like) so that I can scp the bootblocks onto the
> system and install them. BUt, I eventually found the command I'd lost. so I
> think I'm alright. Thanks...
going to assume you get EPERM (Operation not permitted), which would be
caused by GEOM's "preventive foot-shooting" (keep reading).
Is there some reason you're sticking with the MBR scheme instead of GPT?
Taken from GEOM(4):
Both types of bootstrap code are used to boot from the GUID Partition Ta-
ble. First, a protective MBR is embedded into the first disk sector from
the /boot/pmbr image. It searches the GPT freebsd-boot partition (see
the PARTITION TYPES section) in the GPT and runs the next bootstrap stage
from it. The freebsd-boot partition should be smaller than 545 KB.
There are two variants of bootstrap code to write to this partition:
/boot/gptboot and /boot/gptzfsboot. /boot/gptboot is used to boot from
UFS. It searches freebsd-ufs GPT partitions and starts /boot/loader (the
third bootstrap stage) if found. The /boot/gptzfsboot is used to boot
from ZFS. It searches freebsd-zfs GPT partitions and starts
/boot/zfsloader if found.
So by moving to GPT you would relieve yourself of a lot of pain,
particularly that dd nonsense (which looks like it could seriously hurt
you, especially if you're doing it by hand by booting some CD). An
added bonus to using the GPT scheme is that you can align your
partitions easier for 4096-byte sector drives.
With GPT, I believe you'd use this, and only this:
sysctl kern.geom.debugflags=16
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ${disk}
sysctl kern.geom.debugflags=0
(That also assumes the GPT freebsd-boot partition is what's comes first
on $disk (i.e. index 1), as it should be)
If you're using mirrors, you would need to do the gpart command for each
disk that is part of your mirror vdev; i.e. if ada0 and ada1 are a
mirror, issue the gpart command against ada0 and ada1, otherwise you may
find that if one of your disks dies you might not be able to boot from
the system.
All this comes from:
https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror
(You'll find the EPERM situation mentioned there too)
I should also note that if you do go with GPT, please use a larger
freebsd-boot partition size (512KBytes is ideal, not 64KBytes), because
the bootstraps are often >64KBytes these days.
http://www.wonkity.com/~wblock/docs/html/ssd.html
Good luck.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Jeremy Chadwick
May 12, 2013, 11:28:38 PM5/12/13
to
On Sun, May 12, 2013 at 11:14:20PM -0400, Garrett Wollman wrote:
> In article <20130512205...@icarus.home.lan>, j...@koitsu.org writes:
>
> >You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
> >"safety measure" / to permit writing to LBA 0; see GEOM(4) and search
> >for the word "foot".
>
> If you have set up your partitioning properly (read: following the
> clearly recommended best practice on the wiki), there should never,
> ever be any reason to do this. (That is why it's called a DEBUG
> flag.) ...
> In article <20130512205...@icarus.home.lan>, j...@koitsu.org writes:
>
> >You may also need to set kern.geom.debugflags=0x10 to inhibit GEOM's
> >"safety measure" / to permit writing to LBA 0; see GEOM(4) and search
> >for the word "foot".
>
> If you have set up your partitioning properly (read: following the
> clearly recommended best practice on the wiki), there should never,
> ever be any reason to do this. (That is why it's called a DEBUG
I'm in full agreement with you, but the irony is that you refer to "the
wiki", which I have intentionally ignored for years now because it's
always wrong/always out of date/under scrutiny/do-not-care-to-debate.
Case in point:
https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
5. Install the Protected MBR (pmbr) and gptzfsboot loader
Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0
This may fail with an "operation not permitted" error message, since the
kernel likes to protect critical parts of the disk. If this happens for
you, run:
Fixit# sysctl kern.geom.debugflags=0x10
https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror
5. Install the Protected MBR (pmbr) and gptzfsboot loader to both drives
Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0
Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad1
This may fail with an "operation not permitted" error message, since the
kernel likes to protect critical parts of the disk. If this happens for
you, run:
Fixit# sysctl kern.geom.debugflags=0x10
https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition
10. Install ZFS boot
...
Install the boot1 stage:
Fixit# dd if=/mnt2/boot/zfsboot of=/dev/ad0s3 count=1
This may fail with an "operation not permitted" error message, since the
kernel likes to protect critical parts of the disk. If this happens for
you, run:
Fixit# sysctl kern.geom.debugflags=0x10
> The necessary and sufficient invocation is:
>
> # gpart bootcode -b /boot/pmbr -p /boot/gptzfsloader -i 1 [a]daX
>
> I have no idea how this works with MBR partitioning, but I would make
> one suggestion in that regard: DON'T. Whatever makes you think you
> want to do that, think harder and find another way.
ada0s1 (NOT THE PARTITION ada0s1a). I found this out long ago when
doing the classic "bsdlabel -B ada0" method of updating boot blocks only
to find it bitch/complain and insist I use the slice.
I haven't dared touch gpart for bootblock updates on any FreeBSD system
I have access to, simply because the gpart syntax is long and could
really screw you over if you make a typo. Plus, remembering which files
to refer to in /boot is always spotty. "Uh, do I use -b here or -p...
Uh, do I use /boot/mbr or /boot/pmbr... err...". /boot is such a mess
these days.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Garrett Wollman
May 12, 2013, 11:54:45 PM5/12/13
to
In article <20130513032...@icarus.home.lan>, j...@koitsu.org write:
>https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
>
>5. Install the Protected MBR (pmbr) and gptzfsboot loader
Bug #1: "Protective", not "Protected".
>https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
>
>5. Install the Protected MBR (pmbr) and gptzfsboot loader
> Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0
>
> This may fail with an "operation not permitted" error message, since the
> kernel likes to protect critical parts of the disk. If this happens for
> you, run:
>
> Fixit# sysctl kern.geom.debugflags=0x10
...and then file a bug report, with severity "serious" and
priority "high", because this indicates that something is
seriously broken in the kernel's implementation of GPT
partitioning.
The only way this step can fail (absent bugs) is if something (other
than gpart) has either the whole-disk device or the partition 1 device
open in exclusive mode, which is a "can't happen" condition at this
stage in an installation. (Well, it can happen if the disk you are in
the process of destroying has a still-mounted filesystem on it, which
is what the code is supposed to prevent!)
This little bit of cargo-culting used to be necessary for *MBR* and
*bsdlabel* partitioning, before the days of "gpart bootcode", to
update the boot0 and embedded partition-boot (boot1) blocks while the
filesystem was mounted, because the bsdlabel boot blocks are stored in
the first 64k of the root filesystem. When using GPT, the boot blocks
are stored in the boot partition, which doesn't have a mountable
filesystem on it, so should never be open for write except when gpart
bootcode is doing the deed.
-GAWollman
Chris Ross
May 13, 2013, 11:47:24 AM5/13/13
to
On May 12, 2013, at 23:17 , Jeremy Chadwick wrote:
> On Sun, May 12, 2013 at 10:20:26PM -0400, Chris Ross wrote:
>> In the past, I've found I've been unable to install all of the bootblocks if I
>> boot from the ZFS root. When booting from a cd, the basic:
>>
>> gpart bootcode -p ${bootdir}/zfsboot ${disk}
>> dd if=${bootdir}zfsloader of=/dev/${disk}a bs=512 oseek=1024 conv=notrunc,sync
>>
>> works. But, if I boot from ZFS, then I can't dd anything into the front of the
>> drives. Right now, the problem after booting from the CD, is trying to mount
>> a read/write filesystem (mfs, or the like) so that I can scp the bootblocks onto the
>> think I'm alright. Thanks...
>
> What does "unable to install" mean? What output/error do you get? I am
> going to assume you get EPERM (Operation not permitted), which would be
> caused by GEOM's "preventive foot-shooting" (keep reading).
>
> Is there some reason you're sticking with the MBR scheme instead of GPT?
I apologize for all of the noise on the list. I failed to mention the important detail,
>
> What does "unable to install" mean? What output/error do you get? I am
> going to assume you get EPERM (Operation not permitted), which would be
> caused by GEOM's "preventive foot-shooting" (keep reading).
>
> Is there some reason you're sticking with the MBR scheme instead of GPT?
which is that I'm working on a sparc64 system, so it's all VTOC8, not MBR nor
GPT.
But as noted, I was able to mount an MBR an accomplish what I'd intended
when booting from a CD-R. Thanks.
- Chris
0 new messages