Malcolm Herbert wrote: >On Tue, Jul 09, 2019 at 08:39:11PM -0400, Greg Troxel wrote: >|I am assuming that this is raidframe and the original system is NetBSD.
Yes. RAID disk from a NetBSD/sandpoint NAS (Synology DS209J) and my analyzation system is a NetBSD/macppc iBook G4. So more or less the same architecture. >|If you have raid autoconfig enabled, I'd expect the raid set to just >|appear, similar to how I would expect the original setup worked. > >a note of caution on this however - I have had experience with >a external device and both my internal drive(s) using raidframe >autoconfigure ... during boot one or other will be remapped to different >raidN ID ... Yes. That's what I remembered too. Letting the RAID disk autonconfigure on a second system might modify it and causes trouble when I try to put it back into its original place. So I really want to avoid any write-operation to it. And I made sure that the kernel on my iBook has no RAID_AUTOCONFIG enabled. >|The raid header is 64 blocks, so a wedge that is like sd0a but starts >|64 sectors later and ends in the same place should function like >|raid0d. Then of course you may have a disklabel or gpt inside the raid. > >this seems the safest way ... Indeed. As Martin already told me in a private mail there is scan_ffs(8) to find the start sector and size of the partition. Then I had to create a wedge for it with dkctl(8). Unfortunately The Sleuth Kit's fls-tool cannot deal with dk(4) devices. It tells me that it cannot access anything in it, because the size it 0. :( Seems I have to write an image of that partition somewhere... -- Frank Wille
