installboot fails - (un)safe to reboot?

[Jan Danielsson]

Hello,

I'm trying to remotely upgrade a NetBSD system, and I've encountered
a problem.

I've built userland and kernel, and I've copied the new kernel in
place, I copied the new usr/mdec/boot to /boot, and I was going to
update the updated bootstrap code using:

# installboot /dev/rsd0a /..buildpath../usr/mdec/bootxx_ffsv1

But this fails with:
installboot: Opening file system `/dev/rsd0a' read-write: Operation
not permitted

Obviously I'd like to know why installboot fails, but more
importantly I'd like to know if it's safe to reboot in this state (/boot
updated, but installboot hasn't run)?

[Jan Danielsson]

On 07/05/14 15:38, Jan Danielsson wrote:
[---]

Post by Jan Danielsson
installboot: Opening file system `/dev/rsd0a' read-write: Operation
not permitted
Obviously I'd like to know why installboot fails, but more
importantly I'd like to know if it's safe to reboot in this state (/boot
updated, but installboot hasn't run)?

installboot(8) says:

[---]
2. Use installboot to install the primary bootstrap
program (usually /usr/mdec/bootxx_FSTYPE) into
filesystem.

The following platforms do not require this step
if the primary bootstrap already exists and the
secondary bootstrap file is just being updated:
alpha, amd64, amiga, i386, pmax, sparc64, and vax.
[---]

So, I guess I'm alright then. And next time I'll read the top part
of the manpage as well.

[Andy Ruhl]

On Wed, May 7, 2014 at 6:45 AM, Jan Danielsson

Post by Jan Danielsson
So, I guess I'm alright then. And next time I'll read the top part
of the manpage as well.

Beware of this information, I'm not an expert on primary and secondary
bootstrap...

I've been upgrading an i386 machine for a long time and I'm pretty
sure the primary bootstrap hasn't been touched in a very long time. I
think it's not a big deal as long as it can find the secondary.

Andy

[Martin Husemann]

Post by Jan Danielsson
installboot: Opening file system `/dev/rsd0a' read-write: Operation
not permitted

disklabel -w ?

Martin

[Greg Troxel]

Post by Jan Danielsson
I'm trying to remotely upgrade a NetBSD system, and I've encountered
a problem.
I've built userland and kernel, and I've copied the new kernel in
place, I copied the new usr/mdec/boot to /boot, and I was going to
# installboot /dev/rsd0a /..buildpath../usr/mdec/bootxx_ffsv1
installboot: Opening file system `/dev/rsd0a' read-write: Operation
not permitted
Obviously I'd like to know why installboot fails, but more
importantly I'd like to know if it's safe to reboot in this state (/boot
updated, but installboot hasn't run)?

Presumably you are talking i386 or amd64. Booting is quite platform
specific. I will assume i386/amd64, MBR (not GPT) for the rest of this
message.

You also need to be careful about whether your root is UFS1 vs UFS2.

Two things:

The old primary bootblocks are probably ok. <fuzzy>A long time ago,
(between NetBSD 3 and 4??) there was a change, at least on sparc,
where the old primary bootblocks couldn't boot he new secondary.</>
But if your primary bootblocks are from NetBSD 4 or newer, they are
almost certainly ok.

You are running afoul of the check that you can't write to a raw
partition on which there is a mounted filesystem. However, you can
write to the d partition which overlays the a partition, or you can
create an extra matching partition and then write that one.

The tricky part about this, where I keep forgetting and have to figure
it out, is how the beginning of disk relates to the partition.
Specifically, does the primary bootstrap go at the beginning of the disk
vs the beginning of the NetBSD fdisk partition. So take the following
with a grain of salt.

Block 0 of the disk has the MBR boot code and the MBR table. It's job
is to select a partition and read the primary boot code from that
partition. The primary boot code lives in sectors 2-15 of the fdisk
partition (because 0 is for the MBR, and there was some reason not to
use sector 1).

On a system without securelevel being set, one can run the installboot
command like you did.