On Tue, 5 Aug 2014, Raimo Niskanen wrote:
> On Thu, Jul 31, 2014 at 06:12:49PM +0200, Raimo Niskanen wrote:
> > Hello misc@
> >
> > I once created an USB stick (uSDHC card with reader, actually) using
> > OpenBSD 5.4 (might have been an earlier that I later binary upgraded)
> > that contains a softraid encrypted and bootable OpenBSD installation.
> > It has worked just fine.
> >
> > Just now I created a new stick with OpenBSD 5.5 in the same way,
> > since binary upgrading seemed awkward due to the time_t change,
> > and while doing so I attached the old stick to copy configuration
> > files. When attaching it softraid0 said something about roaming disk
> > that was sdX but now sdY - updating metadata, which is not unusual.
> >
> > At least I think that is what triggered the problem...
> >
> > After this the old USB stick does not boot. The list of disks
> > that show up in the boot prompt are: hd0, hd1, and sr0, but
> > sr0 is no longer marked with a '*' which I beleive indicates
> > bootability, so boot(8) tries to boot hd1 and fails.
> > If I tell boot(8) via "set device sd0a" to boot from sd0
> > it does so and that works fine.
> >
> > So autmatic booting now does not work on the old stick?
> > Is this a bug or expected? Can I fix the old stick?
> > (just curious, it is not that important)
> >
> > Some more details: both sticks have an MBR with just the last
> > slot type A6 (dedicated for OpenBSD), and their disklabels
> > have a partition 'a' of type RAID and a swap partition 'b'.
> > The whole installation is then within the softraid disk.
> > The old stick was created on i386 and the new on amd64.
> >
> > I hope that was enough information for someone to get an idea.
> >
> > I myself suspect there is some kind of metadata change that
> > got written when roaming to OpenBSD 5.5 that the old boot(8)
> > loader gets confused by. Nevertheless it is surprising that
> > roaming a softraid disk can change it to the worse...
>
> For the record.
>
> I have been informed that it is very likely that some kind of metadata
> change was written to the disk which confuses the old boot loader.
I highly doubt this, especially given that there have been no real metadata
related changes for multiple releases.
The fact that sr0 still shows up means that the metadata is correctly
identified. The lack of the '*' after sr0 means that the BIOC_SCBOOTABLE flag
has been cleared - rerunning installboot on the softraid device will
re-enable the flag (and update the boot loader).
> Furthermore this is an odd not prioritized use case. What is supposed to
> work is to move a softraid disk to a new release and run it there.
My guess is that you ran 'bioctl -d' to "delete" the volume - this will have
cleared the BIOC_SCBOOTABLE flag and set the flags to BIOC_SCNOAUTOASSEMBLE.
One can argue that this is a bug, however one of the long standing gripes
with softraid is that there is no distinction between create vs attach and
delete vs detach. Fixing this is somewhere on my TODO list...
> My guess is that if there has been a metadata format change in softraid it
> is a good strategy to rewrite that metadata when the disk gets "imported"
> so the new softraid code then will not have to account for multible
> metadata formats during normal operation.
Migrations between versions are handled - if necessary, the metadata will get
updated when you attach the softraid volume.
--
"Action without study is fatal. Study without action is futile."
-- Mary Ritter Beard
