On Wed, 6 Aug 2014, Raimo Niskanen wrote:
> On Wed, Aug 06, 2014 at 01:04:23AM +1000, Joel Sing wrote:
> > 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).
>
> I booted the old system and used it's installboot.
>
> It worked like a charm - thanks!
Excellent. Good to hear.
> > > 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...
>
> Good catch! That I did since I wanted to detach the volume.
>
> Would not deleting the volume and just leaving it online until reboot have
> worked better in this case?
Yes, that would have left the flags intact.
> I wish you luck with fixing this problem. That would be superb!
Thanks. It is not technically difficult, I just have to find the time :)
> > > 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.
>
> And that might mean that the volume becomes unusable in an older release...
> Correct?
Correct. Once the metadata has been upgraded to the new version, the old
kernel will not be able to assemble it... but that's the price of progress.
--
"Action without study is fatal. Study without action is futile."
-- Mary Ritter Beard
