On 2022-04-30, Nick Holland <nick@holland-consulting.net> wrote:
> On 4/30/22 5:16 AM, Sylvain Saboua wrote:
>> Hello
>>
>> I have recently got an upgrade for my laptop with a 1TB SSD drive.
>> I successfully managed to install a dual boot between archlinux and
>> openbsd, both on encrypted partitions.
>>
>> Everything was fine with both systems, until the final act of the
>> dual boot which consists in setting a partition for file sharing> between the two operating systems, using encfs on ext2.
>
> So...you want to share an encrypted partition between two unrelated
> operating systems.
>
> Pretty sure that's not going to work. And since you haven't provided
> any details of what you did, I'm guessing you don't have a plan to
> get around the problems. Linux and OpenBSD use very different
> encryption mechanisms.
encfs runs on top of other filesystems and works on various OS.
it is in packages. As far as the problems experienced here are
concerned I think it can be ignored what exactly is stored on the
ext2fs partition, the same probably would probably occur with
plain stored files.
(btw if I wanted to share between OpenBSD and another OS I would
go with FAT32, it's more likely that others will have already found the
worst bugs with FAT32 than with the less-used ext2fs support).
>> Creating this partition in archlinux works fine, but has seemingly
>> corrupted the disklabel for openbsd : openbsd boots fine until the
>> disk-checking step comes, whereupon I am informed that the j and k
>> partitions on the sd1 disklabel are somewhat corrupted:>
>> /dev/sd1k (/home): BAD SUPER BLOCK: MAGIC NUMBER WRONG
>> /dev/sd1j (/usr/obj): BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE
>> WITH THOSE IN LAST ALTERNATE
>>
>> UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY
>>
>> Automatic file system check failed: help!
>> Enter pathname of shell or RETURN for sh:
>
> This absolutely does not imply a corrupted disklabel. This is a
> corrupted partition. Or an encrypted partition that OpenBSD doesn't
> know how to decrypt.
If the partition table now points to the wrong place then it seems
likely that could result in a "magic number wrong" too. I did wonder if
adding it in Arch would cause OpenBSD to update the "constructed"
disklabel entries for non-OpenBSD filesystems, which start from 'i',
but disklabel(8) says that these are "not dynamic, they are fixed
at the time disklabel is run. That means that subsequent changes
that affect non-OpenBSD partitions will not be present in the
default label" - which suggests it's something else.
So corrupted partition due to creating another filtesystem on top of
an OpenBSD one does seem more likely here.
>> I don't know how I can upgrade an encrypted install using the usb
>> medium, but perhaps if I would this would be a way to solve my problem?
simplest way is to boot an upgrade kernel (bsd.rd) on a softraid-crypted
filesystem from the OpenBSD boot loader. You should be able to do it
from USB storage too but probably need to run bioctl by hand to "create"
the softraid device in that case.
> But as I and others have said in the past, multiboot systems are
> complicated.
Yes multiboot is the fiddly bit here.
I would suggest maybe creating the "fdisk style" (MBR) paritition table
first, with a chunk for OpenBSD, a chunk for $other_OS, and the shared
space, then install OpenBSD so that those "disklabel style" partition
entries are automatically constructed for those, and install onto the
other partitions, avoiding those two.
My preference for dualbooting would be, if possible, to use an entirely
separate disk (in the same machine). There's far less risk of error
that way.
No comments:
Post a Comment