Re: mount not working as expected? and what are my default bioctl rounds?
beecdadd...@danwin1210.de wrote: > But manual says this > "If it is a DUID, it will be automatically mapped to the appropriate entry > in /dev" > I assumed the opposite would be true, if I did mount sd3i, and that mount > would check it's DUID and check in fstab for it it does not do that? No way, of course it doesn't do that.
Re: mount not working as expected? and what are my default bioctl rounds?
On Sun, March 3, 2024 11:50 am, Otto Moerbeek wrote: > On Sun, Mar 03, 2024 at 10:47:31AM -, beecdadd...@danwin1210.de > wrote: > > >> hi list I want to know how many rounds my computer defaults to for >> bioctl -r, so I can change it and know how stronger it is can you help >> me? >> >> after reading mount manual about DUID I realized that it is not working >> for me as expected in /etc/fstab I have the same DUID I got from >> disklabel of that same crypto volume (sd3), and when I do mount sd3i, it >> goes to look at fstab and should find that same DUID.i entry, but it >> gives me this mount: can't find fstab entry for sd3i. >> >> >> the fstab line is this DUID-of-sd3.i /mnt/extssd ffs >> rw,noatime,noexec,nodev,nosuid 0 0 > > When you have a duid entry in fstab, you should refer to is by duid. But manual says this "If it is a DUID, it will be automatically mapped to the appropriate entry in /dev" I assumed the opposite would be true, if I did mount sd3i, and that mount would check it's DUID and check in fstab for it it does not do that? > >> >> the real RAID non-crypto volume of external ssd is sd2, as said crypto >> volume gets attached as sd3 >> >> and on topic of fstab, I couldn't find what the last two '0 0' are >> called, I remember linux has had it in manual in past so I know they say >> if system can boot without those drives or something like that > > You did not look very hard: true.. I was looking for numbers, but numbers were written in words instead of 0 1 2... my bad, I hope it was readable so I could find it quickly > > > man fstab: ... > A line has the following format: > > > fs_spec fs_file fs_vfstype fs_mntops fs_freq fs_passno ... >
Re: mount not working as expected? and what are my default bioctl rounds?
On Sun, Mar 03, 2024 at 10:47:31AM -, beecdadd...@danwin1210.de wrote: > hi list > I want to know how many rounds my computer defaults to for bioctl -r, so I > can change it and know how stronger it is can you help me? > > after reading mount manual about DUID I realized that it is not working > for me as expected > in /etc/fstab I have the same DUID I got from disklabel of that same > crypto volume (sd3), and when I do mount sd3i, it goes to look at fstab > and should find that same DUID.i entry, but it gives me this > mount: can't find fstab entry for sd3i. > > the fstab line is this > DUID-of-sd3.i /mnt/extssd ffs rw,noatime,noexec,nodev,nosuid 0 0 When you have a duid entry in fstab, you should refer to is by duid. > > the real RAID non-crypto volume of external ssd is sd2, as said crypto > volume gets attached as sd3 > > and on topic of fstab, I couldn't find what the last two '0 0' are called, > I remember linux has had it in manual in past so I know they say if system > can boot without those drives or something like that You did not look very hard: man fstab: ... A line has the following format: fs_spec fs_file fs_vfstype fs_mntops fs_freq fs_passno ...
mount not working as expected? and what are my default bioctl rounds?
hi list I want to know how many rounds my computer defaults to for bioctl -r, so I can change it and know how stronger it is can you help me? after reading mount manual about DUID I realized that it is not working for me as expected in /etc/fstab I have the same DUID I got from disklabel of that same crypto volume (sd3), and when I do mount sd3i, it goes to look at fstab and should find that same DUID.i entry, but it gives me this mount: can't find fstab entry for sd3i. the fstab line is this DUID-of-sd3.i /mnt/extssd ffs rw,noatime,noexec,nodev,nosuid 0 0 the real RAID non-crypto volume of external ssd is sd2, as said crypto volume gets attached as sd3 and on topic of fstab, I couldn't find what the last two '0 0' are called, I remember linux has had it in manual in past so I know they say if system can boot without those drives or something like that
Re: bioctl: Can't locate device
> On Jan 22, 2024, at 15:55, Jan Stary wrote:
>
> On Jan 22 13:53:17, open...@mlst.nl wrote:
>> Hi Jan,
>>
>> I followed the Disk FAQ, foe UEFI.
>> https://www.openbsd.org/faq/faq14.html#softraid
>>
>> # fdisk -gy -b 532480 sd1
>> # fdisk -gy -b 532480 sd2
>> # fdisk -gy -b 532480 sd3
>> # fdisk -gy -b 532480 sd4
>>
>> For all of them I did:
>> # disklabel -E sd1
>> sd1> a a
>> offset: [64]
>> size: [39825135] *
>> FS type: [4.2BSD] RAID
>> sd1*> w
>> sd1> q
>>
>> # bioctl -c 1 -l sd1a,sd2a softraid0
>
> To be clear: this creates sd5 ...
>
>> # bioctl -c 1 -l sd3a,sd4a softraid0
>
> ... and this creates sd6, right?
Yes… someone did make me see my mistake. I never created the device with
MAKEDEV. After that the devices are seen!
Thanx for helping me out as well.
Mischa
>
>> # dd if=/dev/zero of=/dev/rsd5c bs=1m count=1
>> # dd if=/dev/zero of=/dev/rsd6c bs=1m count=1
>>
>> After that newfs.
>
> How exactly? newfs sd5a?
> Without any fdisk or disklabel on the newly created sd5?
> What does disklabel sd5 say?
>
>> One thing I forgot:
>> root@epyc1:~ # sysctl hw | grep drive
>> hw.sensors.softraid0.drive0=online (sd5), OK
>> hw.sensors.softraid0.drive1=online (sd6), OK
>>
>> Mischa
>>
>>> On 2024-01-22 12:56, Jan Stary wrote:
>>> How exactly did you create the sd5 SR RAID 1 and the sd6 SR RAID 1?
>>>
>>> On Jan 22 12:23:36, open...@mlst.nl wrote:
>>>> Hi All,
>>>>
>>>> I created to softraid0 drives, following the FAQ.
>>>> ALl seems to be working without problems, however bioctl isn’t able
>>>> to “see”
>>>> the softraid0 drives, sd5 and sd6.
>>>>
>>>> root@epyc1:~ # dmesg | egrep 'sd([0-6])'
>>>> sd0 at scsibus1 targ 0 lun 0:
>>>> t10.ATA_DELLBOSS_VD_37b61d1b1f560010_
>>>> sd0: 457798MB, 512 bytes/sector, 937571968 sectors, thin
>>>> sd1 at scsibus2 targ 1 lun 0:
>>>> sd1: 7630885MB, 512 bytes/sector, 15628053168 sectors
>>>> sd2 at scsibus3 targ 1 lun 0:
>>>> sd2: 7630885MB, 512 bytes/sector, 15628053168 sectors
>>>> sd3 at scsibus6 targ 1 lun 0:
>>>> sd3: 7630885MB, 512 bytes/sector, 15628053168 sectors
>>>> sd4 at scsibus7 targ 1 lun 0:
>>>> sd4: 7630885MB, 512 bytes/sector, 15628053168 sectors
>>>> sd5 at scsibus9 targ 1 lun 0:
>>>> sd5: 7630625MB, 512 bytes/sector, 15627520063 sectors
>>>> sd6 at scsibus9 targ 2 lun 0:
>>>> sd6: 7630625MB, 512 bytes/sector, 15627520063 sectors
>>>> root on sd0a (964c4608967fd9ca.a) swap on sd0b dump on sd0b
>>>>
>>>> root@epyc1:~ # for i in $(jot 7 0); do bioctl sd${i}; done
>>>> sd0: , serial 37b61d1b1f560010
>>>> sd1: , serial (unknown)
>>>> sd2: , serial (unknown)
>>>> sd3: , serial (unknown)
>>>> sd4: , serial (unknown)
>>>> bioctl: Can't locate sd5 device via /dev/bio
>>>> bioctl: Can't locate sd6 device via /dev/bio
>>>>
>>>> root@epyc1:~ # df -h
>>>> Filesystem SizeUsed Avail Capacity Mounted on
>>>> /dev/sd0a 986M107M830M12%/
>>>> /dev/sd0l 277G192K263G 1%/home
>>>> /dev/sd0d 3.9G 10.0K3.7G 1%/tmp
>>>> /dev/sd0f 29.1G1.3G 26.3G 5%/usr
>>>> /dev/sd0g 986M288M648M31%/usr/X11R6
>>>> /dev/sd0h 19.4G 23.8M 18.4G 1%/usr/local
>>>> /dev/sd0k 5.8G2.0K5.5G 1%/usr/obj
>>>> /dev/sd0j 2.9G2.0K2.8G 1%/usr/src
>>>> /dev/sd5c 7.0T367G6.3T 6%/var
>>>> /dev/sd6c 7.0T670G6.0T10%/var/data
>>>>
>>>> Any idea?
>>>>
>>>> Mischa
>>>>
>>>>
>>
>>
Re: bioctl: Can't locate device
On Jan 22 13:53:17, open...@mlst.nl wrote:
> Hi Jan,
>
> I followed the Disk FAQ, foe UEFI.
> https://www.openbsd.org/faq/faq14.html#softraid
>
> # fdisk -gy -b 532480 sd1
> # fdisk -gy -b 532480 sd2
> # fdisk -gy -b 532480 sd3
> # fdisk -gy -b 532480 sd4
>
> For all of them I did:
> # disklabel -E sd1
> sd1> a a
> offset: [64]
> size: [39825135] *
> FS type: [4.2BSD] RAID
> sd1*> w
> sd1> q
>
> # bioctl -c 1 -l sd1a,sd2a softraid0
To be clear: this creates sd5 ...
> # bioctl -c 1 -l sd3a,sd4a softraid0
... and this creates sd6, right?
> # dd if=/dev/zero of=/dev/rsd5c bs=1m count=1
> # dd if=/dev/zero of=/dev/rsd6c bs=1m count=1
>
> After that newfs.
How exactly? newfs sd5a?
Without any fdisk or disklabel on the newly created sd5?
What does disklabel sd5 say?
> One thing I forgot:
> root@epyc1:~ # sysctl hw | grep drive
> hw.sensors.softraid0.drive0=online (sd5), OK
> hw.sensors.softraid0.drive1=online (sd6), OK
>
> Mischa
>
> On 2024-01-22 12:56, Jan Stary wrote:
> > How exactly did you create the sd5 SR RAID 1 and the sd6 SR RAID 1?
> >
> > On Jan 22 12:23:36, open...@mlst.nl wrote:
> > > Hi All,
> > >
> > > I created to softraid0 drives, following the FAQ.
> > > ALl seems to be working without problems, however bioctl isn’t able
> > > to “see”
> > > the softraid0 drives, sd5 and sd6.
> > >
> > > root@epyc1:~ # dmesg | egrep 'sd([0-6])'
> > > sd0 at scsibus1 targ 0 lun 0:
> > > t10.ATA_DELLBOSS_VD_37b61d1b1f560010_
> > > sd0: 457798MB, 512 bytes/sector, 937571968 sectors, thin
> > > sd1 at scsibus2 targ 1 lun 0:
> > > sd1: 7630885MB, 512 bytes/sector, 15628053168 sectors
> > > sd2 at scsibus3 targ 1 lun 0:
> > > sd2: 7630885MB, 512 bytes/sector, 15628053168 sectors
> > > sd3 at scsibus6 targ 1 lun 0:
> > > sd3: 7630885MB, 512 bytes/sector, 15628053168 sectors
> > > sd4 at scsibus7 targ 1 lun 0:
> > > sd4: 7630885MB, 512 bytes/sector, 15628053168 sectors
> > > sd5 at scsibus9 targ 1 lun 0:
> > > sd5: 7630625MB, 512 bytes/sector, 15627520063 sectors
> > > sd6 at scsibus9 targ 2 lun 0:
> > > sd6: 7630625MB, 512 bytes/sector, 15627520063 sectors
> > > root on sd0a (964c4608967fd9ca.a) swap on sd0b dump on sd0b
> > >
> > > root@epyc1:~ # for i in $(jot 7 0); do bioctl sd${i}; done
> > > sd0: , serial 37b61d1b1f560010
> > > sd1: , serial (unknown)
> > > sd2: , serial (unknown)
> > > sd3: , serial (unknown)
> > > sd4: , serial (unknown)
> > > bioctl: Can't locate sd5 device via /dev/bio
> > > bioctl: Can't locate sd6 device via /dev/bio
> > >
> > > root@epyc1:~ # df -h
> > > Filesystem SizeUsed Avail Capacity Mounted on
> > > /dev/sd0a 986M107M830M12%/
> > > /dev/sd0l 277G192K263G 1%/home
> > > /dev/sd0d 3.9G 10.0K3.7G 1%/tmp
> > > /dev/sd0f 29.1G1.3G 26.3G 5%/usr
> > > /dev/sd0g 986M288M648M31%/usr/X11R6
> > > /dev/sd0h 19.4G 23.8M 18.4G 1%/usr/local
> > > /dev/sd0k 5.8G2.0K5.5G 1%/usr/obj
> > > /dev/sd0j 2.9G2.0K2.8G 1%/usr/src
> > > /dev/sd5c 7.0T367G6.3T 6%/var
> > > /dev/sd6c 7.0T670G6.0T10%/var/data
> > >
> > > Any idea?
> > >
> > > Mischa
> > >
> > >
>
>
Re: bioctl: Can't locate device
Hi Jan,
I followed the Disk FAQ, foe UEFI.
https://www.openbsd.org/faq/faq14.html#softraid
# fdisk -gy -b 532480 sd1
# fdisk -gy -b 532480 sd2
# fdisk -gy -b 532480 sd3
# fdisk -gy -b 532480 sd4
For all of them I did:
# disklabel -E sd1
sd1> a a
offset: [64]
size: [39825135] *
FS type: [4.2BSD] RAID
sd1*> w
sd1> q
# bioctl -c 1 -l sd1a,sd2a softraid0
# bioctl -c 1 -l sd3a,sd4a softraid0
# dd if=/dev/zero of=/dev/rsd5c bs=1m count=1
# dd if=/dev/zero of=/dev/rsd6c bs=1m count=1
After that newfs.
One thing I forgot:
root@epyc1:~ # sysctl hw | grep drive
hw.sensors.softraid0.drive0=online (sd5), OK
hw.sensors.softraid0.drive1=online (sd6), OK
Mischa
On 2024-01-22 12:56, Jan Stary wrote:
How exactly did you create the sd5 SR RAID 1 and the sd6 SR RAID 1?
On Jan 22 12:23:36, open...@mlst.nl wrote:
Hi All,
I created to softraid0 drives, following the FAQ.
ALl seems to be working without problems, however bioctl isn’t able to
“see”
the softraid0 drives, sd5 and sd6.
root@epyc1:~ # dmesg | egrep 'sd([0-6])'
sd0 at scsibus1 targ 0 lun 0:
t10.ATA_DELLBOSS_VD_37b61d1b1f560010_
sd0: 457798MB, 512 bytes/sector, 937571968 sectors, thin
sd1 at scsibus2 targ 1 lun 0:
sd1: 7630885MB, 512 bytes/sector, 15628053168 sectors
sd2 at scsibus3 targ 1 lun 0:
sd2: 7630885MB, 512 bytes/sector, 15628053168 sectors
sd3 at scsibus6 targ 1 lun 0:
sd3: 7630885MB, 512 bytes/sector, 15628053168 sectors
sd4 at scsibus7 targ 1 lun 0:
sd4: 7630885MB, 512 bytes/sector, 15628053168 sectors
sd5 at scsibus9 targ 1 lun 0:
sd5: 7630625MB, 512 bytes/sector, 15627520063 sectors
sd6 at scsibus9 targ 2 lun 0:
sd6: 7630625MB, 512 bytes/sector, 15627520063 sectors
root on sd0a (964c4608967fd9ca.a) swap on sd0b dump on sd0b
root@epyc1:~ # for i in $(jot 7 0); do bioctl sd${i}; done
sd0: , serial 37b61d1b1f560010
sd1: , serial (unknown)
sd2: , serial (unknown)
sd3: , serial (unknown)
sd4: , serial (unknown)
bioctl: Can't locate sd5 device via /dev/bio
bioctl: Can't locate sd6 device via /dev/bio
root@epyc1:~ # df -h
Filesystem SizeUsed Avail Capacity Mounted on
/dev/sd0a 986M107M830M12%/
/dev/sd0l 277G192K263G 1%/home
/dev/sd0d 3.9G 10.0K3.7G 1%/tmp
/dev/sd0f 29.1G1.3G 26.3G 5%/usr
/dev/sd0g 986M288M648M31%/usr/X11R6
/dev/sd0h 19.4G 23.8M 18.4G 1%/usr/local
/dev/sd0k 5.8G2.0K5.5G 1%/usr/obj
/dev/sd0j 2.9G2.0K2.8G 1%/usr/src
/dev/sd5c 7.0T367G6.3T 6%/var
/dev/sd6c 7.0T670G6.0T10%/var/data
Any idea?
Mischa
bioctl: Can't locate device
Hi All,
I created to softraid0 drives, following the FAQ.
ALl seems to be working without problems, however bioctl isn’t able to
“see” the softraid0 drives, sd5 and sd6.
root@epyc1:~ # dmesg | egrep 'sd([0-6])'
sd0 at scsibus1 targ 0 lun 0:
t10.ATA_DELLBOSS_VD_37b61d1b1f560010_
sd0: 457798MB, 512 bytes/sector, 937571968 sectors, thin
sd1 at scsibus2 targ 1 lun 0:
sd1: 7630885MB, 512 bytes/sector, 15628053168 sectors
sd2 at scsibus3 targ 1 lun 0:
sd2: 7630885MB, 512 bytes/sector, 15628053168 sectors
sd3 at scsibus6 targ 1 lun 0:
sd3: 7630885MB, 512 bytes/sector, 15628053168 sectors
sd4 at scsibus7 targ 1 lun 0:
sd4: 7630885MB, 512 bytes/sector, 15628053168 sectors
sd5 at scsibus9 targ 1 lun 0:
sd5: 7630625MB, 512 bytes/sector, 15627520063 sectors
sd6 at scsibus9 targ 2 lun 0:
sd6: 7630625MB, 512 bytes/sector, 15627520063 sectors
root on sd0a (964c4608967fd9ca.a) swap on sd0b dump on sd0b
root@epyc1:~ # for i in $(jot 7 0); do bioctl sd${i}; done
sd0: , serial 37b61d1b1f560010
sd1: , serial (unknown)
sd2: , serial (unknown)
sd3: , serial (unknown)
sd4: , serial (unknown)
bioctl: Can't locate sd5 device via /dev/bio
bioctl: Can't locate sd6 device via /dev/bio
root@epyc1:~ # df -h
Filesystem SizeUsed Avail Capacity Mounted on
/dev/sd0a 986M107M830M12%/
/dev/sd0l 277G192K263G 1%/home
/dev/sd0d 3.9G 10.0K3.7G 1%/tmp
/dev/sd0f 29.1G1.3G 26.3G 5%/usr
/dev/sd0g 986M288M648M31%/usr/X11R6
/dev/sd0h 19.4G 23.8M 18.4G 1%/usr/local
/dev/sd0k 5.8G2.0K5.5G 1%/usr/obj
/dev/sd0j 2.9G2.0K2.8G 1%/usr/src
/dev/sd5c 7.0T367G6.3T 6%/var
/dev/sd6c 7.0T670G6.0T10%/var/data
Any idea?
Mischa
Re: bioctl: one key for multiple disks
On Sun, Jan 07, 2024 at 12:40:18PM +0100, Stefan Kreutz wrote: > You can indeed create multiple 1M RAID disklabel partitions per device Yes, you can. And that may be the most appropriate solution in this case, and in cases where you have several machines each with one softraid crypto partition and want to store the key for each machine on one physical device. But my understanding is that the OP wants to use the same encryption key for multiple softraid crypto partitions, not just the same physical device to hold multiple keys, which is what you are describing. All of this, (and more), is _possible_ iff you understand in detail how the softraid crypto system works at a low level, and are comfortable manually hacking things to make it work. There are no tools, (in base), to do such manipulations of softraid volumes automatically. Another solution, if you have a lot of softraid crypto volumes on the same machine, (E.G. many physical disks each with one such partition), is to use a key for the main one, (possibly the boot volume), and _passphrases_ for the rest of them. Those passphrases can then be stored in files on the encrypted volume that uses the key, and automatically attached as necessary one the first volume has been attached using the key.
Re: bioctl: one key for multiple disks
You can indeed create multiple 1M RAID disklabel partitions per device (typically a USB stick), one partition per key. I've been using this setup for years. To save yourself some frustration, I suggest you backup the keydisks as described in the FAQ: https://www.openbsd.org/faq/faq14.html#softraidFDE On Sun, Jan 07, 2024 at 11:15:25AM +0300, 4 wrote: > how to use one key for multiple disks? i naively believed that since bioctl > does not have any keys for this, then a key on the specified key's partition > will be used, and if it is not there, a new one will be created, and deleting > the key it is the responsibility of the user, but in practice there is > nothing like this, the key is simply overwritten with a new one. i understand > that logic and reason are not about obsd, but maybe there is some kind of > hack to solve this problem? > "- just create a new key's partition for each disk" > "- oh, yeah! a brilliant solution. and very scalable!" > but i'm not sure that even this can be done. i'm tired of restoring the > router's state after unsuccessful experiments, i would like to use someone > else's experience. > i don’t know how the crypto partition works, i don’t know how to see what’s > on it, but maybe it’s possible to place several keys on one partition if i > can’t use one key for several disks? i don’t know.. there are dozens of > theoretical ways for how to solve the problem of storing keys >
bioctl: one key for multiple disks
how to use one key for multiple disks? i naively believed that since bioctl does not have any keys for this, then a key on the specified key's partition will be used, and if it is not there, a new one will be created, and deleting the key it is the responsibility of the user, but in practice there is nothing like this, the key is simply overwritten with a new one. i understand that logic and reason are not about obsd, but maybe there is some kind of hack to solve this problem? "- just create a new key's partition for each disk" "- oh, yeah! a brilliant solution. and very scalable!" but i'm not sure that even this can be done. i'm tired of restoring the router's state after unsuccessful experiments, i would like to use someone else's experience. i don’t know how the crypto partition works, i don’t know how to see what’s on it, but maybe it’s possible to place several keys on one partition if i can’t use one key for several disks? i don’t know.. there are dozens of theoretical ways for how to solve the problem of storing keys
Re: bioctl -v -P
Am Fr., 5. Jan. 2024 um 12:50 Uhr schrieb Stuart Henderson : > > # bioctl -v -P wd0e > > bioctl: BIOCDISCIPLINE: inapeopriate ioctl for device > wd0e is not a softraid volume. Use the softraid volume, > e.g. sd1 or sd0 or similar. Thanks a lot. After doing bioctl -c C -l /dev/wd0e softraid0 and using the softraid volume given there after typing the pass it worked as expected. I just did not use these commands since a lot of years ago. Rod.
Re: bioctl -v -P
On Fri, Jan 05, 2024 at 12:36:41PM +, Roderick wrote: > # bioctl -v -P wd0e > bioctl: BIOCDISCIPLINE: inapeopriate ioctl for device Because wd0e is not a softraid volume. You have not provided enough information in your message to know for certain what the correct device is on your system, so you need to work it out yourself, or provide that information.
Re: bioctl -v -P
On 2024-01-05, Roderick wrote: > I get > > # bioctl -v -P wd0e > bioctl: BIOCDISCIPLINE: inapeopriate ioctl for device > > Is it not possible to change the pass? > > What was supposed that I do under > > https://www.openbsd.org/faq/upgrade74.html#ConfigChanges > > ??? wd0e is not a softraid volume. Use the softraid volume, e.g. sd1 or sd0 or similar. -- Please keep replies on the mailing list.
bioctl -v -P
I get # bioctl -v -P wd0e bioctl: BIOCDISCIPLINE: inapeopriate ioctl for device Is it not possible to change the pass? What was supposed that I do under https://www.openbsd.org/faq/upgrade74.html#ConfigChanges ??? Thanks for any hint! Rod
Re: Bioctl password file
On Thu, Jan 06, 2022 at 12:23:43PM -0500, fo...@dnmx.org wrote: > So, instead of using a password or a keyfile, I'd like to use a passfile. > How do I create one? I tried searching on the internet but couldn't find > an guide. > > Do I just put the password itself in the file and chmod it to the > specified permissions? Yes.
bioctl -cC -l /dev/sd1a softraid0 for encryption two disks RAID1 mirrored
Hi misc, I'd like to have two encrypted 1TB disks in RAID 1 mirror mode (no hardware RAID installed). Is it possible to use bioctl for that purpose or do I need to use HW RAID and encrypt mirrored disks with bioctl -cC -l /dev/sd1a softraid0 ? Please advice. Martin
Re: bioctl -cC -l /dev/sd1a softraid0 for encryption two disks RAID1 mirrored
On Mon, Oct 19, 2020 at 06:28:50PM +, Martin wrote: > I'd like to have two encrypted 1TB disks in RAID 1 mirror mode (no hardware > RAID installed). Is it possible to use bioctl for that purpose or do I need > to use HW RAID and encrypt mirrored disks with bioctl -cC -l /dev/sd1a > softraid0 ? > Please advice. Yes, it's possible, and quite common I guess. OpenBSD cannot boot from an encrypted softraid(4) RAID 1+CRYPTO though, so true RAID 1+CRYPTO FDE is not achieveable. (You'll have to leave an unencrypted partition for root so that the system can boot into singleuser. When not finding the remaining of fstab(5) mounts, rc(8) will complain and stop and give you the option to drop to a prompt where you can manually bioctl(8) the CRYPTO partition before continue booting. Kinda cumbersome since every (re)boot will have to be performed attended, so you should carefully consider whether your data is truly so important as to justify the added troubles.) Cheers, Erling
Re: softraid/bioctl cant find device /dev/bio
On Mon, Aug 3, 2020 at 2:09 PM Brian Brombacher wrote: > > > > On Aug 3, 2020, at 12:22 PM, sven falempin > wrote: > > > > On Mon, Aug 3, 2020 at 12:00 PM Brian Brombacher > > wrote: > > > >> > >> > >> On Aug 3, 2020, at 11:51 AM, sven falempin > >> wrote: > >> > >> > >> > >> > >>> On Mon, Aug 3, 2020 at 11:38 AM Brian Brombacher > > >>> wrote: > >>> > >>> > >>> > >>>> On Aug 3, 2020, at 9:54 AM, sven falempin > >>> wrote: > >>>> > >>>> Hello > >>>> > >>>> I saw a similar issue in the mailing list around decembre 2019, > >>>> following an electrical problem softraid doesn't bring devices ups > >>>> > >>>> > >>>> # ls /dev/sd?? > >>>> /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e > >>>> /dev/sd2k > >>>> /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f > >>>> /dev/sd2l > >>>> /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g > >>>> /dev/sd2m > >>>> /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h > >>>> /dev/sd2n > >>>> /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i > >>>> /dev/sd2o > >>>> /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j > >>>> /dev/sd2p > >>>> # dmesg | grep 6.7 > >>>> OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 > >>>> # dmesg | grep sd > >>>> dera...@amd64.openbsd.org: > /usr/src/sys/arch/amd64/compile/RAMDISK_CD > >>>> wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) > >>>> sd0 at scsibus1 targ 0 lun 0: > >>>> t10.ATA_QEMU_HARDDISK_Q > >>>> M5_ > >>>> sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin > >>>> sd1 at scsibus1 targ 1 lun 0: > >>>> t10.ATA_QEMU_HARDDISK_Q > >>>> M7_ > >>>> sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin > >>>> wskbd0 at pckbd0: console keyboard, using wsdisplay1 > >>>> softraid0: trying to bring up sd2 degraded > >>>> softraid0: sd2 was not shutdown properly > >>>> softraid0: sd2 is offline, will not be brought online > >>>> # bioctl -d sd2 > >>>> bioctl: Can't locate sd2 device via /dev/bio > >>>> # > >>>> > >>>> I suspect a missing devices in /dev ( but it seems i have the required > >>> one ) > >>>> and MAKEDEV all of course did a `uid 0 on /: out of inodes` > >>>> > >>>> I have backups but i ' d like to fix the issue ! > >>> > >>> Hi Sven, > >>> > >>> The device sd2 wasn’t attached by softraid, your /dev/bio is fine. > This > >>> can happen if softraid fails to find all component disks or the > metadata on > >>> one or more components does not match expectations (newer metadata > seen on > >>> other disks). Make sure all of the component disks are working. If > that > >>> is not the issue, you may need to re-run the command that you used to > >>> create the array and include -C force. Be very careful doing this, I > >>> suggest running the command once without -C force to ensure it found > all > >>> the components and fails to bring the array up due to the same error > >>> message you got (attempt to bring up degraded). > >>> > >>> If you’re not careful, you can blow out the whole array. > >>> > >>> -Brian > >>> > >>> > >>> The disk looks fine, the disklabel is ok, the array is just sd0 and > sda1 > >> both got the disklabel RAID part, > >> shall i do further checks ? > >> > >> # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0 > >> softraid0: trying to bring up sd2 degraded > >> softraid0: sd2 was not shutdown properly > >> softraid0: sd2 is offline, will not be brought online > >> softraid0: trying to bring up sd2 degraded > >> softraid0: sd2 was not shutdown properly > >> softraid0: sd2 is offline, will not be brought online > >> > >> I wouldnt like to blow the whole array ! sd0a should be in perfect > >> condition but unsure about sd1a, i probably need to bioctl -R sd1 > >> > >> > >> Traditionally at this point, I would run the command again with -C force > >> and my RAID 1 array is fine. I might be doing dangerous things and not > >> know, so other voices please chime in. > >> > >> [Moved to misc@] > >> > >> > >> > >> > > # bioctl -C force -c 1 -l /dev/sd0a,/dev/sd1a softraid0 > > sd2 at scsibus2 targ 1 lun 0: > > sd2: 1907726MB, 512 bytes/sector, 3907023473 sectors > > softraid0: RAID 1 volume attached as sd2 > > > > both volumes are online , partitions are visible > > but fsck is not happy at all :-( > > > > Can i do something before fsck -y ( i have backups ) > > Make sure your backups are good. > > Run fsck -n and see how wicked the issues are. It may just be cleaning > itself up after the electrical outage. > > I’m glad I have multiple partition and serious backup, waiting for disk change number two is dead 💀 Thanks for the help! > -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: softraid/bioctl cant find device /dev/bio
> On Aug 3, 2020, at 12:22 PM, sven falempin wrote: > > On Mon, Aug 3, 2020 at 12:00 PM Brian Brombacher > wrote: > >> >> >> On Aug 3, 2020, at 11:51 AM, sven falempin >> wrote: >> >> >> >> >>> On Mon, Aug 3, 2020 at 11:38 AM Brian Brombacher >>> wrote: >>> >>> >>> >>>> On Aug 3, 2020, at 9:54 AM, sven falempin >>> wrote: >>>> >>>> Hello >>>> >>>> I saw a similar issue in the mailing list around decembre 2019, >>>> following an electrical problem softraid doesn't bring devices ups >>>> >>>> >>>> # ls /dev/sd?? >>>> /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e >>>> /dev/sd2k >>>> /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f >>>> /dev/sd2l >>>> /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g >>>> /dev/sd2m >>>> /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h >>>> /dev/sd2n >>>> /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i >>>> /dev/sd2o >>>> /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j >>>> /dev/sd2p >>>> # dmesg | grep 6.7 >>>> OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 >>>> # dmesg | grep sd >>>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD >>>> wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) >>>> sd0 at scsibus1 targ 0 lun 0: >>>> t10.ATA_QEMU_HARDDISK_Q >>>> M5_ >>>> sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin >>>> sd1 at scsibus1 targ 1 lun 0: >>>> t10.ATA_QEMU_HARDDISK_Q >>>> M7_ >>>> sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin >>>> wskbd0 at pckbd0: console keyboard, using wsdisplay1 >>>> softraid0: trying to bring up sd2 degraded >>>> softraid0: sd2 was not shutdown properly >>>> softraid0: sd2 is offline, will not be brought online >>>> # bioctl -d sd2 >>>> bioctl: Can't locate sd2 device via /dev/bio >>>> # >>>> >>>> I suspect a missing devices in /dev ( but it seems i have the required >>> one ) >>>> and MAKEDEV all of course did a `uid 0 on /: out of inodes` >>>> >>>> I have backups but i ' d like to fix the issue ! >>> >>> Hi Sven, >>> >>> The device sd2 wasn’t attached by softraid, your /dev/bio is fine. This >>> can happen if softraid fails to find all component disks or the metadata on >>> one or more components does not match expectations (newer metadata seen on >>> other disks). Make sure all of the component disks are working. If that >>> is not the issue, you may need to re-run the command that you used to >>> create the array and include -C force. Be very careful doing this, I >>> suggest running the command once without -C force to ensure it found all >>> the components and fails to bring the array up due to the same error >>> message you got (attempt to bring up degraded). >>> >>> If you’re not careful, you can blow out the whole array. >>> >>> -Brian >>> >>> >>> The disk looks fine, the disklabel is ok, the array is just sd0 and sda1 >> both got the disklabel RAID part, >> shall i do further checks ? >> >> # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0 >> softraid0: trying to bring up sd2 degraded >> softraid0: sd2 was not shutdown properly >> softraid0: sd2 is offline, will not be brought online >> softraid0: trying to bring up sd2 degraded >> softraid0: sd2 was not shutdown properly >> softraid0: sd2 is offline, will not be brought online >> >> I wouldnt like to blow the whole array ! sd0a should be in perfect >> condition but unsure about sd1a, i probably need to bioctl -R sd1 >> >> >> Traditionally at this point, I would run the command again with -C force >> and my RAID 1 array is fine. I might be doing dangerous things and not >> know, so other voices please chime in. >> >> [Moved to misc@] >> >> >> >> > # bioctl -C force -c 1 -l /dev/sd0a,/dev/sd1a softraid0 > sd2 at scsibus2 targ 1 lun 0: > sd2: 1907726MB, 512 bytes/sector, 3907023473 sectors > softraid0: RAID 1 volume attached as sd2 > > both volumes are online , partitions are visible > but fsck is not happy at all :-( > > Can i do something before fsck -y ( i have backups ) Make sure your backups are good. Run fsck -n and see how wicked the issues are. It may just be cleaning itself up after the electrical outage.
Re: softraid/bioctl cant find device /dev/bio
On Mon, Aug 3, 2020 at 12:00 PM Brian Brombacher wrote: > > > On Aug 3, 2020, at 11:51 AM, sven falempin > wrote: > > > > > On Mon, Aug 3, 2020 at 11:38 AM Brian Brombacher > wrote: > >> >> >> > On Aug 3, 2020, at 9:54 AM, sven falempin >> wrote: >> > >> > Hello >> > >> > I saw a similar issue in the mailing list around decembre 2019, >> > following an electrical problem softraid doesn't bring devices ups >> > >> > >> > # ls /dev/sd?? >> > /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e >> > /dev/sd2k >> > /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f >> > /dev/sd2l >> > /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g >> > /dev/sd2m >> > /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h >> > /dev/sd2n >> > /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i >> > /dev/sd2o >> > /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j >> > /dev/sd2p >> > # dmesg | grep 6.7 >> > OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 >> > # dmesg | grep sd >> >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD >> > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) >> > sd0 at scsibus1 targ 0 lun 0: >> > t10.ATA_QEMU_HARDDISK_Q >> > M5_ >> > sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin >> > sd1 at scsibus1 targ 1 lun 0: >> > t10.ATA_QEMU_HARDDISK_Q >> > M7_ >> > sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin >> > wskbd0 at pckbd0: console keyboard, using wsdisplay1 >> > softraid0: trying to bring up sd2 degraded >> > softraid0: sd2 was not shutdown properly >> > softraid0: sd2 is offline, will not be brought online >> > # bioctl -d sd2 >> > bioctl: Can't locate sd2 device via /dev/bio >> > # >> > >> > I suspect a missing devices in /dev ( but it seems i have the required >> one ) >> > and MAKEDEV all of course did a `uid 0 on /: out of inodes` >> > >> > I have backups but i ' d like to fix the issue ! >> >> Hi Sven, >> >> The device sd2 wasn’t attached by softraid, your /dev/bio is fine. This >> can happen if softraid fails to find all component disks or the metadata on >> one or more components does not match expectations (newer metadata seen on >> other disks). Make sure all of the component disks are working. If that >> is not the issue, you may need to re-run the command that you used to >> create the array and include -C force. Be very careful doing this, I >> suggest running the command once without -C force to ensure it found all >> the components and fails to bring the array up due to the same error >> message you got (attempt to bring up degraded). >> >> If you’re not careful, you can blow out the whole array. >> >> -Brian >> >> >> The disk looks fine, the disklabel is ok, the array is just sd0 and sda1 > both got the disklabel RAID part, > shall i do further checks ? > > # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0 > softraid0: trying to bring up sd2 degraded > softraid0: sd2 was not shutdown properly > softraid0: sd2 is offline, will not be brought online > softraid0: trying to bring up sd2 degraded > softraid0: sd2 was not shutdown properly > softraid0: sd2 is offline, will not be brought online > > I wouldnt like to blow the whole array ! sd0a should be in perfect > condition but unsure about sd1a, i probably need to bioctl -R sd1 > > > Traditionally at this point, I would run the command again with -C force > and my RAID 1 array is fine. I might be doing dangerous things and not > know, so other voices please chime in. > > [Moved to misc@] > > > > # bioctl -C force -c 1 -l /dev/sd0a,/dev/sd1a softraid0 sd2 at scsibus2 targ 1 lun 0: sd2: 1907726MB, 512 bytes/sector, 3907023473 sectors softraid0: RAID 1 volume attached as sd2 both volumes are online , partitions are visible but fsck is not happy at all :-( Can i do something before fsck -y ( i have backups ) -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: softraid/bioctl cant find device /dev/bio
> On Aug 3, 2020, at 11:51 AM, sven falempin wrote: > > > > >> On Mon, Aug 3, 2020 at 11:38 AM Brian Brombacher >> wrote: >> >> >> > On Aug 3, 2020, at 9:54 AM, sven falempin wrote: >> > >> > Hello >> > >> > I saw a similar issue in the mailing list around decembre 2019, >> > following an electrical problem softraid doesn't bring devices ups >> > >> > >> > # ls /dev/sd?? >> > /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e >> > /dev/sd2k >> > /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f >> > /dev/sd2l >> > /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g >> > /dev/sd2m >> > /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h >> > /dev/sd2n >> > /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i >> > /dev/sd2o >> > /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j >> > /dev/sd2p >> > # dmesg | grep 6.7 >> > OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 >> > # dmesg | grep sd >> >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD >> > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) >> > sd0 at scsibus1 targ 0 lun 0: >> > t10.ATA_QEMU_HARDDISK_Q >> > M5_ >> > sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin >> > sd1 at scsibus1 targ 1 lun 0: >> > t10.ATA_QEMU_HARDDISK_Q >> > M7_ >> > sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin >> > wskbd0 at pckbd0: console keyboard, using wsdisplay1 >> > softraid0: trying to bring up sd2 degraded >> > softraid0: sd2 was not shutdown properly >> > softraid0: sd2 is offline, will not be brought online >> > # bioctl -d sd2 >> > bioctl: Can't locate sd2 device via /dev/bio >> > # >> > >> > I suspect a missing devices in /dev ( but it seems i have the required one >> > ) >> > and MAKEDEV all of course did a `uid 0 on /: out of inodes` >> > >> > I have backups but i ' d like to fix the issue ! >> >> Hi Sven, >> >> The device sd2 wasn’t attached by softraid, your /dev/bio is fine. This can >> happen if softraid fails to find all component disks or the metadata on one >> or more components does not match expectations (newer metadata seen on other >> disks). Make sure all of the component disks are working. If that is not >> the issue, you may need to re-run the command that you used to create the >> array and include -C force. Be very careful doing this, I suggest running >> the command once without -C force to ensure it found all the components and >> fails to bring the array up due to the same error message you got (attempt >> to bring up degraded). >> >> If you’re not careful, you can blow out the whole array. >> >> -Brian >> >> > The disk looks fine, the disklabel is ok, the array is just sd0 and sda1 both > got the disklabel RAID part, > shall i do further checks ? > > # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0 > softraid0: trying to bring up sd2 degraded > softraid0: sd2 was not shutdown properly > softraid0: sd2 is offline, will not be brought online > softraid0: trying to bring up sd2 degraded > softraid0: sd2 was not shutdown properly > softraid0: sd2 is offline, will not be brought online > > I wouldnt like to blow the whole array ! sd0a should be in perfect condition > but unsure about sd1a, i probably need to bioctl -R sd1 Traditionally at this point, I would run the command again with -C force and my RAID 1 array is fine. I might be doing dangerous things and not know, so other voices please chime in. [Moved to misc@]
Re: Is it possible to build bioctl -c C -l ... on a bioctl -c 1 -l ... ?
Hello, wo...@intermezzo.net (Wolly), 2019.06.18 (Tue) 13:58 (CEST): > 3 years ago I tried to build a "bioctl -c C -l ... " over a "bioctl -c 1 > -l ..." on a hetzner server and I failed. > Is it possible to do so, and when, what are the requirements? it is possible but it will not automagically assemble when booting (and is therefore not endorsed). Marcus
Is it possible to build bioctl -c C -l ... on a bioctl -c 1 -l ... ?
Hello misc, 3 years ago I tried to build a "bioctl -c C -l ... " over a "bioctl -c 1 -l ..." on a hetzner server and I failed. Is it possible to do so, and when, what are the requirements? Thank you in advance. -Heiko
Re: How to overrule bioctl "chunk already in use"
29 Mar 2019, 02:42 by n...@holland-consulting.net: > On 3/28/19 10:29 AM, Rachel Roch wrote: > >> Hi, >> >> I've been following the instructions here >> https://www.openbsd.org/faq/faq14.html >> <https://www.openbsd.org/faq/faq14.html> >> <>> https://www.openbsd.org/faq/faq14.html >> <https://www.openbsd.org/faq/faq14.html>>> > to setup softraid. >> >> Unfortunately I somehow messed up the original attempt through my own >> stupidity. >> > > it happens. > And best that it happen before production than after. > >> So I've been trying to go through the steps again. However nothing >> I do can elminate the "softraid0 sd0a chunk already in use" message >> at the "bioctl -c 1 -l sd0a,sd1a softraid0" step. >> >> I've tried everything ! Rebooting the server, /dev/zero to the >> first 500MB of sd0 and sd1, changing uuid in disklabel, erasing and >> re-writing disk label. >> >> I looked at the man page and thought "ah ha !" ... maybe "-C force", >> but nope ! >> > > you were close with the zeroing the head of the components. In fact, > I'm not sure what you did wrong, but that's the solution. > > I'd suggest starting by zeroing the beginning of each physical disk -- > using the r device and the c partition -- i.e., > > # dd if=/dev/zero of=/dev/rsd0c > # dd if=/dev/zero of=/dev/rsd1c > > I've had enough problems, I really suggest this unless you are > absolutely sure your disk has never even heard of OpenBSD before you > install it. :) (I think I had figured out at one point that zeroing the > RAID partitions was sufficient, but when it comes to zeroing, a little > more is never too much. :) > > Now, if you were going to script this, you would put a block size and a > count in there...but since you are just typing this at the command line, > count to three and hit CTRL-C then do the next. You really only have to > clear a megabyte or so, and probably a LOT less...you can't hit CTRL-C > fast enough, I suspect. :) > > By using the 'r' device and the 'c' partion, you have wiped the very > very start of the disk -- sector zero onward. > > I'd reboot after that. I don't think it's needed, but either the > disklabel or MBR partition can be held in memory and written back out to > disk under some circumstance, I don't recall exactly what (probably > having to do with mounted partitions), so a reboot, and then verifying > that fdisk sd0 shows lots of zeros everywhere including the Signature. > NOW fdisk, create your OpenBSD partition, then your RAID disklabel > partitions, and you should be in business. > > If that doesn't do it, show us your exact commands and exact output you > are seeing. > > Nick. > Thanks Nick ! Your suggestion did the trick.
Re: How to overrule bioctl "chunk already in use"
On 3/28/19 10:29 AM, Rachel Roch wrote: > Hi, > > I've been following the instructions here > https://www.openbsd.org/faq/faq14.html > <https://www.openbsd.org/faq/faq14.html> to setup softraid. > > Unfortunately I somehow messed up the original attempt through my own > stupidity. it happens. And best that it happen before production than after. > So I've been trying to go through the steps again. However nothing > I do can elminate the "softraid0 sd0a chunk already in use" message > at the "bioctl -c 1 -l sd0a,sd1a softraid0" step. > > I've tried everything ! Rebooting the server, /dev/zero to the > first 500MB of sd0 and sd1, changing uuid in disklabel, erasing and > re-writing disk label. > > I looked at the man page and thought "ah ha !" ... maybe "-C force", > but nope ! you were close with the zeroing the head of the components. In fact, I'm not sure what you did wrong, but that's the solution. I'd suggest starting by zeroing the beginning of each physical disk -- using the r device and the c partition -- i.e., # dd if=/dev/zero of=/dev/rsd0c # dd if=/dev/zero of=/dev/rsd1c I've had enough problems, I really suggest this unless you are absolutely sure your disk has never even heard of OpenBSD before you install it. :) (I think I had figured out at one point that zeroing the RAID partitions was sufficient, but when it comes to zeroing, a little more is never too much. :) Now, if you were going to script this, you would put a block size and a count in there...but since you are just typing this at the command line, count to three and hit CTRL-C then do the next. You really only have to clear a megabyte or so, and probably a LOT less...you can't hit CTRL-C fast enough, I suspect. :) By using the 'r' device and the 'c' partion, you have wiped the very very start of the disk -- sector zero onward. I'd reboot after that. I don't think it's needed, but either the disklabel or MBR partition can be held in memory and written back out to disk under some circumstance, I don't recall exactly what (probably having to do with mounted partitions), so a reboot, and then verifying that fdisk sd0 shows lots of zeros everywhere including the Signature. NOW fdisk, create your OpenBSD partition, then your RAID disklabel partitions, and you should be in business. If that doesn't do it, show us your exact commands and exact output you are seeing. Nick.
How to overrule bioctl "chunk already in use"
Hi, I've been following the instructions here https://www.openbsd.org/faq/faq14.html <https://www.openbsd.org/faq/faq14.html> to setup softraid. Unfortunately I somehow messed up the original attempt through my own stupidity. So I've been trying to go through the steps again. However nothing I do can elminate the "softraid0 sd0a chunk already in use" message at the "bioctl -c 1 -l sd0a,sd1a softraid0" step. I've tried everything ! Rebooting the server, /dev/zero to the first 500MB of sd0 and sd1, changing uuid in disklabel, erasing and re-writing disk label. I looked at the man page and thought "ah ha !" ... maybe "-C force", but nope ! Any ideas Rachel
Re: "bioctl -d" before shutdown
On Tue, 26 Feb 2019, cho...@jtan.com wrote: [...] What is anyone afraid might happen after that(*)? You are right, there should be nothing to fear, that is why answered Stefan. I though, as obvoiusly also Stefan, it should be good to do "bioctl -d". [*] RAID and other hardware magic notwithstanding but if you're using that then you know what you're doing and if you don't then you have my ridicule. You got it. The "magic" and my imperfect knowledge plays a role. Life would be realy hard if I were so wise like you. Give your soon-to-be-ex employer my contact details. You have a good employer that likes wise people like you. Rodrigo
Re: "bioctl -d" before shutdown
Roderick writes: > > I suspect, umount (that always syncs) is enough and umount > happens always at shutdown. How do people cope with "I suspect"? "I suspect" would scare the crap out of me. Did it never occur that it's possible to _know_? Not unmounting is dangerous because there are in-memory buffers. Unmounting a filesystem syncs those buffers _to the physical medium_. What is anyone afraid might happen after that(*)? I'm a million miles from a kernel hacker but sheesh! It's not bloody rocket science! Understand your tools before you use them. Matthew [*] RAID and other hardware magic notwithstanding but if you're using that then you know what you're doing and if you don't then you have my ridicule. Give your soon-to-be-ex employer my contact details.
Re: "bioctl -d" before shutdown
I suspect, umount (that always syncs) is enough and umount happens always at shutdown. Rodrigo On Mon, 25 Feb 2019, Kapfhammer, Stefan wrote: I have the umount and bioctl -d commands in /etc/rc.shutdown, in case I forget to do it manually. If you don't do that proberly, you will need to fsck the device, next time you attach it. -Stefan Origineel bericht Van: Roderick Verzonden: zondag 24 februari 2019 21:53 Aan: misc@openbsd.org Onderwerp: "bioctl -d" before shutdown Excuseme that I ask instead of inspecting rc files. :) I do manually bioctl -c C -l /dev/XXX softraid0 and mount the resulting device. Should I manually unmount and do "bioctl -d " before shutdown? Or just shutdown? The umount will sure be done, but also the bioctl -d? Thanks Rodrigo
Re: "bioctl -d" before shutdown
Hi, I have the umount and bioctl -d commands in /etc/rc.shutdown, in case I forget to do it manually. If you don't do that proberly, you will need to fsck the device, next time you attach it. -Stefan Origineel bericht Van: Roderick Verzonden: zondag 24 februari 2019 21:53 Aan: misc@openbsd.org Onderwerp: "bioctl -d" before shutdown Excuseme that I ask instead of inspecting rc files. :) I do manually bioctl -c C -l /dev/XXX softraid0 and mount the resulting device. Should I manually unmount and do "bioctl -d " before shutdown? Or just shutdown? The umount will sure be done, but also the bioctl -d? Thanks Rodrigo
"bioctl -d" before shutdown
Excuseme that I ask instead of inspecting rc files. :) I do manually bioctl -c C -l /dev/XXX softraid0 and mount the resulting device. Should I manually unmount and do "bioctl -d " before shutdown? Or just shutdown? The umount will sure be done, but also the bioctl -d? Thanks Rodrigo
Re: bioctl, encryption, and keydisk
etienne.m...@magickarpet.org (Etienne), 2018.05.04 (Fri) 19:06 (CEST):
> On 04/05/18 17:40, Marcus MERIGHI wrote:
>
> > I'm currently reading https://marc.info/?l=openbsd-misc&m=141435482820277
> > "crypto softraid and keydisk on same harddrive", 2014-10-26.
> >
> > jsing@ had this patch, which was tested and worked for the OP - but was
> > not commited: https://marc.info/?l=openbsd-misc&m=141450636905550
> >
>
> Nice! Thanks for that, I'll try.
here's jsing@ patch regenerated with -current so that it applies
cleanly.
In case it stil works (please report back) we could forward it to tech@
in the hope of someone taking care of it...
Marcus
Index: i386_softraid.c
===
RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v
retrieving revision 1.10
diff -u -p -u -r1.10 i386_softraid.c
--- i386_softraid.c 28 Apr 2016 16:48:18 - 1.10
+++ i386_softraid.c 5 May 2018 08:21:52 -
@@ -42,6 +42,7 @@ void sr_install_bootldr(int, char *);
void
sr_install_bootblk(int devfd, int vol, int disk)
{
+ struct bioc_vol bv;
struct bioc_disk bd;
struct disklabel dl;
struct partition *pp;
@@ -56,6 +57,15 @@ sr_install_bootblk(int devfd, int vol, i
bd.bd_diskid = disk;
if (ioctl(devfd, BIOCDISK, &bd) == -1)
err(1, "BIOCDISK");
+
+ /* Skip CRYPTO key disks. */
+ /* XXX - pass volume in rather than volume ID. */
+ memset(&bv, 0, sizeof(bv));
+ bv.bv_volid = vol;
+ if (ioctl(devfd, BIOCVOL, &bv) == -1)
+ err(1, "BIOCVOL");
+ if (bv.bv_level == 'C' && bd.bd_size == 0)
+ return;
/* Check disk status. */
if (bd.bd_status != BIOC_SDONLINE && bd.bd_status != BIOC_SDREBUILD) {
Re: bioctl, encryption, and keydisk
On 04/05/18 17:40, Marcus MERIGHI wrote: I'm currently reading https://marc.info/?l=openbsd-misc&m=141435482820277 "crypto softraid and keydisk on same harddrive", 2014-10-26. jsing@ had this patch, which was tested and worked for the OP - but was not commited: https://marc.info/?l=openbsd-misc&m=141450636905550 Nice! Thanks for that, I'll try. -- Étienne
Re: bioctl, encryption, and keydisk
etienne.m...@magickarpet.org (Etienne), 2018.05.04 (Fri) 14:03 (CEST):
> Hello list,
>
> What I'm going to describe will most probably sound very silly, but I
> believe I have a reasonable use case. I'm trying to setup a machine with
> full disk encryption using a partition of the same disk as a keydisk. (take
> all the time you want to laugh, then carry on reading).
>
> So I'm creating two RAID partitions "a" and "p", then run:
>
> bioctl -c C -l sd0a -k sd0p softraid0
>
> and this succeed. I'm then proceeding to a normal installation on sd1, then
> reboot, and I'm greeted with the message `ERR M`.
>
> I have tried this with the p partition at the beginning or at the end of the
> disk, tried to change sizes,... no effect. I'm wondering if what I'm trying
> is actually supported? Any idea?
>
>
> For those who wonder, my use case is installing 100+ virtual machines in the
> cloud with full disk encryption, rebooting them, and using rc.firsttime to
> overwrite the key so if the machine is powered down, it can't be booted
> anymore. I'm also aware that this is still vulnerable to an attack from
> someone who's in control of the host machine.
I'm currently reading https://marc.info/?l=openbsd-misc&m=141435482820277
"crypto softraid and keydisk on same harddrive", 2014-10-26.
jsing@ had this patch, which was tested and worked for the OP - but was
not commited: https://marc.info/?l=openbsd-misc&m=141450636905550
Index: i386_softraid.c
===
RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v
retrieving revision 1.2
diff -u -p -r1.2 i386_softraid.c
--- i386_softraid.c 9 Jun 2014 13:13:48 - 1.2
+++ i386_softraid.c 28 Oct 2014 14:21:27 -
@@ -42,6 +42,7 @@ void sr_install_bootldr(int, char *);
void
sr_install_bootblk(int devfd, int vol, int disk)
{
+ struct bioc_vol bv;
struct bioc_disk bd;
struct disklabel dl;
struct partition *pp;
@@ -56,6 +57,15 @@ sr_install_bootblk(int devfd, int vol, i
bd.bd_diskid = disk;
if (ioctl(devfd, BIOCDISK, &bd) == -1)
err(1, "BIOCDISK");
+
+ /* Skip CRYPTO key disks. */
+ /* XXX - pass volume in rather than volume ID. */
+ memset(&bv, 0, sizeof(bv));
+ bv.bv_volid = vol;
+ if (ioctl(devfd, BIOCVOL, &bv) == -1)
+ err(1, "BIOCVOL");
+ if (bv.bv_level == 'C' && bd.bd_size == 0)
+ return;
/* Check disk status. */
if (bd.bd_status != BIOC_SDONLINE && bd.bd_status != BIOC_SDREBUILD) {
Marcus
bioctl, encryption, and keydisk
Hello list, What I'm going to describe will most probably sound very silly, but I believe I have a reasonable use case. I'm trying to setup a machine with full disk encryption using a partition of the same disk as a keydisk. (take all the time you want to laugh, then carry on reading). So I'm creating two RAID partitions "a" and "p", then run: bioctl -c C -l sd0a -k sd0p softraid0 and this succeed. I'm then proceeding to a normal installation on sd1, then reboot, and I'm greeted with the message `ERR M`. I have tried this with the p partition at the beginning or at the end of the disk, tried to change sizes,... no effect. I'm wondering if what I'm trying is actually supported? Any idea? For those who wonder, my use case is installing 100+ virtual machines in the cloud with full disk encryption, rebooting them, and using rc.firsttime to overwrite the key so if the machine is powered down, it can't be booted anymore. I'm also aware that this is still vulnerable to an attack from someone who's in control of the host machine. -- Étienne
bioctl "intermitently" reports RAID 1 array as degraded
Hello I am trying to understand what I may be missing (I have been noticing this issue for a year or so). I have a machine running -current that is setup with 2 SSD hard drives. The SSD's are fdisk'ed with 1 openbsd partition: # fdisk sd0 Disk: sd0 geometry: 19457/255/63 [312581808 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 19456 254 63 [ 64: 312576641 ] OpenBSD The disklabels on each disk have an "a" 4.2BSD partition, a "b" swap partition, and then a "m" RAID partition: # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: INTEL SSDSA2BW16 duid: 43d094716532e926 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 19457 total sectors: 312581808 boundstart: 64 boundend: 312576705 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 2104448 64 4.2BSD 2048 16384 1 # / b: 18860313 2104512swap# none c:3125818080 unused m:291611880 20964825RAID Most of the time, everything is fine: # bioctl -i sd2 Volume Status Size Device softraid0 0 Online 149305012224 sd2 RAID1 0 Online 149305012224 0:0.0 noencl 1 Online 149305012224 0:1.0 noencl BUT, every once in a while (let's say, a couple of weeks, then a couple of months), all of sudden the array will report as being degraded. However, other than the notice that the array is degraded and that a mirror is offline, I can find nothing in any log, or any changes in the dmesg to suggest what may have happened. I have changed the hard drive cables. I have changed out the SSD drives. But, it still happens every so often. When the array is degraded, I can still fdisk/disklabel the "offline" disk without a problem. I can rebuild the degraded array with the "offline" disk (# bioctl -R /dev/sd1m sd2), and the rebuild completes without a problem, and the array is stable for weeks/months until, randomly, it happens again. I am wondering if there is anything I should be looking at/for to help figure out what the issue is? As I said, I have already swapped out hardware (at least) once. If it is a hardware issue, I can keep swapping out hardware, but (at this point) it seems that the probability is really low that I would have multiple drives that have the same intermittent problem (but, obviously, not zero). I would appreciate any advice on how to track down what the problem may be the next time it happens. Thanks Ted
Re: bioctl and S.M.A.R.T support for physical disks
smartctl -i /dev/sd0c works for me as well. I would like to thank all of you who helped on and off the list. Predrag
Re: bioctl and S.M.A.R.T support for physical disks
On Tue, Oct 17, 2017 at 11:30:16PM -0400, Predrag Punosevac wrote: > Hi Misc, > > I am using > > # bioctl sd4 > Volume Status Size Device > softraid0 0 Online 2000396018176 sd4 RAID1 > 0 Online 2000396018176 0:0.0 noencl > 1 Online 2000396018176 0:1.0 noencl > > for my desktop > > # uname -a > OpenBSD oko.bagdala2.net 6.2 GENERIC.MP#0 amd64 > > Physical drives used to create mirror on this machine are > /dev/sd0 and /dev/sd1 > > When I try to probe the drives with S.M.A.R.T utility I get > > # smartctl -i -d sat /dev/sd0 Try "smartctl -i -d sat /dev/rsd0c". > smartctl 6.5 2016-05-07 r4318 [x86_64-unknown-openbsd6.2] (local build) > Copyright (C) 2002-16, Bruce Allen, Christian Franke, > www.smartmontools.org > > Smartctl open device: /dev/sd0 [SAT] failed: Operation not supported by > device > > > and this is without device option > > # smartctl -i /dev/sd0 > smartctl 6.5 2016-05-07 r4318 [x86_64-unknown-openbsd6.2] (local build) > Copyright (C) 2002-16, Bruce Allen, Christian Franke, > www.smartmontools.org > > Smartctl open device: /dev/sd0 failed: Operation not supported by device > > It makes me wonder if S.M.A.R.T. support for physical disks is added to > bioctl since 2006/7 when Marco Peereboom was talking about that on > NYC*BUG. I am using high end enterprise drives on this machine which do > support S.M.A.R.T. and I did enable S.M.A.R.T. in bios. > > Cheers, > Predrag > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: bioctl and S.M.A.R.T support for physical disks
Quoting Predrag Punosevac : Hi Misc, I am using # bioctl sd4 Volume Status Size Device softraid0 0 Online 2000396018176 sd4 RAID1 0 Online 2000396018176 0:0.0 noencl 1 Online 2000396018176 0:1.0 noencl for my desktop # uname -a OpenBSD oko.bagdala2.net 6.2 GENERIC.MP#0 amd64 Physical drives used to create mirror on this machine are /dev/sd0 and /dev/sd1 When I try to probe the drives with S.M.A.R.T utility I get # smartctl -i -d sat /dev/sd0 smartctl 6.5 2016-05-07 r4318 [x86_64-unknown-openbsd6.2] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org Smartctl open device: /dev/sd0 [SAT] failed: Operation not supported by device and this is without device option # smartctl -i /dev/sd0 smartctl 6.5 2016-05-07 r4318 [x86_64-unknown-openbsd6.2] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org Smartctl open device: /dev/sd0 failed: Operation not supported by device It makes me wonder if S.M.A.R.T. support for physical disks is added to bioctl since 2006/7 when Marco Peereboom was talking about that on NYC*BUG. I am using high end enterprise drives on this machine which do support S.M.A.R.T. and I did enable S.M.A.R.T. in bios. Cheers, Predrag Hi, smartctl -i /dev/sd0c works Vijay -- Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca
bioctl and S.M.A.R.T support for physical disks
Hi Misc, I am using # bioctl sd4 Volume Status Size Device softraid0 0 Online 2000396018176 sd4 RAID1 0 Online 2000396018176 0:0.0 noencl 1 Online 2000396018176 0:1.0 noencl for my desktop # uname -a OpenBSD oko.bagdala2.net 6.2 GENERIC.MP#0 amd64 Physical drives used to create mirror on this machine are /dev/sd0 and /dev/sd1 When I try to probe the drives with S.M.A.R.T utility I get # smartctl -i -d sat /dev/sd0 smartctl 6.5 2016-05-07 r4318 [x86_64-unknown-openbsd6.2] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org Smartctl open device: /dev/sd0 [SAT] failed: Operation not supported by device and this is without device option # smartctl -i /dev/sd0 smartctl 6.5 2016-05-07 r4318 [x86_64-unknown-openbsd6.2] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org Smartctl open device: /dev/sd0 failed: Operation not supported by device It makes me wonder if S.M.A.R.T. support for physical disks is added to bioctl since 2006/7 when Marco Peereboom was talking about that on NYC*BUG. I am using high end enterprise drives on this machine which do support S.M.A.R.T. and I did enable S.M.A.R.T. in bios. Cheers, Predrag
Re: Bioctl rounds doesn't appear to affect the passphrase time?
On Sunday 25 June 2017 22:28:17 Kevin Chadwick wrote: > Doh... Yeah, starting from scratch with -r works. I guess quickly finding > how long rounds take is not quite as easy as bioctl -d and try again. The number of rounds can also be changed when you change the passphrase on an existing volume.
Re: Bioctl rounds doesn't appear to affect the passphrase time?
Doh... Yeah, starting from scratch with -r works. I guess quickly finding how long rounds take is not quite as easy as bioctl -d and try again. I guess the rounds it chooses is equal to a seconds worth, but surprised that it would be exactly 256. Struck me as a maxed byte or something. Sorry for the noise. On 25 Jun 2017 6:17 pm, "Ted Unangst" wrote: > Kevin Chadwick wrote: > > On Fri, 23 Jun 2017 20:24:24 +0200 > > > > > > > > > > I started by trying very high values with a simple password and > > > > > > expected to have to wait a long time but it was always around 7 > > > > > > seconds? > > > > > very high as in -r 2000 ? > > > > > > > > Yeah, 2048? Is there a MAX? > > > Not really. > > > > > > Oh it's been only 9 month since bioctl(8) switched over to bcrypt > > > PBKDF. You might run a older version (dmesg would help) in which case > > > you want to go much higher... 16000? > > > > > > # bioctl -v -c C -l /dev/vnd0a softraid0 > > > > > > shows you what KDF you are using. > > > > Thanks > > > > -r 1 shows "bioctl: number of KDF rounds is too small: 1" > > > > -r 4 shows "Deriving key using bcrypt PBKDF with 256 rounds..." > > > > whatever I set -r to, seems to say 256 rounds and returns in a similar > > timeframe. > > > > e.g. bioctl -v -c C -r 32000 -l /dev/vnd0a softraid0 > > well, of course. if it used a different number of rounds, the key wouldn't > match the one generated when the volume was created. if you're trying to > create a new volume, start with blank metadata. > >
Re: Bioctl rounds doesn't appear to affect the passphrase time?
Kevin Chadwick wrote: > On Fri, 23 Jun 2017 20:24:24 +0200 > > > > > > > I started by trying very high values with a simple password and > > > > > expected to have to wait a long time but it was always around 7 > > > > > seconds? > > > > very high as in -r 2000 ? > > > > > > Yeah, 2048? Is there a MAX? > > Not really. > > > > Oh it's been only 9 month since bioctl(8) switched over to bcrypt > > PBKDF. You might run a older version (dmesg would help) in which case > > you want to go much higher... 16000? > > > > # bioctl -v -c C -l /dev/vnd0a softraid0 > > > > shows you what KDF you are using. > > Thanks > > -r 1 shows "bioctl: number of KDF rounds is too small: 1" > > -r 4 shows "Deriving key using bcrypt PBKDF with 256 rounds..." > > whatever I set -r to, seems to say 256 rounds and returns in a similar > timeframe. > > e.g. bioctl -v -c C -r 32000 -l /dev/vnd0a softraid0 well, of course. if it used a different number of rounds, the key wouldn't match the one generated when the volume was created. if you're trying to create a new volume, start with blank metadata.
Re: Bioctl rounds doesn't appear to affect the passphrase time?
On Fri, 23 Jun 2017 20:24:24 +0200 > > > > I started by trying very high values with a simple password and > > > > expected to have to wait a long time but it was always around 7 > > > > seconds? > > > very high as in -r 2000 ? > > > > Yeah, 2048? Is there a MAX? > Not really. > > Oh it's been only 9 month since bioctl(8) switched over to bcrypt > PBKDF. You might run a older version (dmesg would help) in which case > you want to go much higher... 16000? > > # bioctl -v -c C -l /dev/vnd0a softraid0 > > shows you what KDF you are using. Thanks -r 1 shows "bioctl: number of KDF rounds is too small: 1" -r 4 shows "Deriving key using bcrypt PBKDF with 256 rounds..." whatever I set -r to, seems to say 256 rounds and returns in a similar timeframe. e.g. bioctl -v -c C -r 32000 -l /dev/vnd0a softraid0 kernel is 6.1 Jun 12 2017 bioctl sha256 starts with 1404c5e13f5f (i386 6.1) This is adding the vnd as sd1 as softraid0 already has an enc sd0 the vnd0 is attached to a 256MB file I would use the blowfish crypto of vnconfig instead but would rather use the bcrypt password hashing if possible. I assume vnconfig still uses PKCS #5, as the man page says? p.s. sorry for the delay, somehow I managed to hose my boot code, perhaps with bioctl -d sd0 whilst running from sd0 rather than bioctl -d sd1. installboot saved the day anyway. Teaches me to mess around with disks as root after a beer!
Re: Bioctl rounds doesn't appear to affect the passphrase time?
Kevin Chadwick wrote: > On Fri, 23 Jun 2017 18:13:20 +0200 > > > > > I started by trying very high values with a simple password and > > > expected to have to wait a long time but it was always around 7 > > > seconds? > > very high as in -r 2000 ? > > Yeah, 2048? Is there a MAX? i do not recommend using the maximum.
Re: Bioctl rounds doesn't appear to affect the passphrase time?
On Fri, 23 Jun 2017 18:34:54 +0100 Kevin Chadwick wrote: > On Fri, 23 Jun 2017 18:13:20 +0200 > > > > > I started by trying very high values with a simple password and > > > expected to have to wait a long time but it was always around 7 > > > seconds? > > very high as in -r 2000 ? > > Yeah, 2048? Is there a MAX? Not really. Oh it's been only 9 month since bioctl(8) switched over to bcrypt PBKDF. You might run a older version (dmesg would help) in which case you want to go much higher... 16000? # bioctl -v -c C -l /dev/vnd0a softraid0 shows you what KDF you are using.
Re: Bioctl rounds doesn't appear to affect the passphrase time?
On Fri, 23 Jun 2017 18:13:20 +0200 > > I started by trying very high values with a simple password and > > expected to have to wait a long time but it was always around 7 > > seconds? > very high as in -r 2000 ? Yeah, 2048? Is there a MAX?
Re: Bioctl rounds doesn't appear to affect the passphrase time?
On Fri, 23 Jun 2017 17:02:18 +0100 Kevin Chadwick wrote: > On 6.1 i386 with syspatch 004 I am running: > > time /sbin/bioctl -c C -l /dev/vnd0a -r31 softraid0 > > I guess I am simply seeing my passphrase input time and the round has > a marginal affect? Perhaps more on memory usage? Yes you are measuring your typing speed. > Is 31 the highest number of rounds? -r auto gives me 129 rounds (~1sec to compute key) > I started by trying very high values with a simple password and expected > to have to wait a long time but it was always around 7 seconds? very high as in -r 2000 ? > tx np
Bioctl rounds doesn't appear to affect the passphrase time?
On 6.1 i386 with syspatch 004 I am running: time /sbin/bioctl -c C -l /dev/vnd0a -r31 softraid0 I guess I am simply seeing my passphrase input time and the round has a marginal affect? Perhaps more on memory usage? Is 31 the highest number of rounds? I started by trying very high values with a simple password and expected to have to wait a long time but it was always around 7 seconds? tx
Re: bioctl crypto size limitation ?
On Friday 26 May 2017 15:59:18 sharon s. wrote: > On 05/26/17 15:49, sharon s. wrote: > > disklabel: ioctl DIOCWDINFO: Open partition would move or shrink > > disklabel: unable to write label > > Stupid me, I forgot that the softraid device was still attached. > > 12Tb, 14Tb and 15Tb works as well, 16 seems to be where it breaks. Okay, this makes more sense: #define SR_CRYPTO_MAXKEYS 32 /* max keys per volume */ #define SR_CRYPTO_KEY_BLKSHIFT 30 /* 0.5TB per key */ 32 * 0.5TB == 16TB That said, the original design of softraid crypto was to use 0.5TB per volume key, however there has been a very long standing bug where it only uses the first key for the entire disk. Unfortunately, when the bug was found it was impossible to change this since it would break anyone who had a volume larger than 0.5TB. The plan was to address this when the crypto metadata was redesigned, which is still yet to happen (and fixing it also means there is another bug that has to be addressed first...) Something is obviously still checking/hitting this limit though and is triggering the failure. There are probably a couple of things to fix here - the error message from bioctl should at least tell you what the issue is instead of "unknown error". It is also possible to remove the 16TB restriction (which I thought was ineffective) since there is really no technical limit - it does however potentially make key guessing attacks easier (which is why the intention was to use multiple keys per volume)... And overall, I guess we need to look at bumping the limit since people are now hitting it (unfortunately, I don't have access to appropriate hardware for testing though :)
Re: bioctl crypto size limitation ?
On 05/25/17 22:59, Florian Ermisch wrote: Just make slice sd0a smaller than 100% of the RAID array. Regards, Florian Am 25. Mai 2017 19:03:59 MESZ schrieb myml...@gmx.com: I'm wondering if there is a limit to the size of a disk for full disk encryption. I'm trying to encrypt a 32Tb raid 6 drive on a lsi 9265-8i with 8 x 6Tb drives and it's failing with the error "unknown error". (very descriptive!) I was able to encrypt the 256Gb system disk without error during installation. Without encrypting the 32Tb drive, I had no problem creating the FS and mounting it. I know people will say this is a bad idea because of fsck (and maybe other reasons), but this drive will be mounted ro 99% of the time. Steps to recreate: dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) fdisk -iy -g sd0 (I left off the "-b 960" because this is not a bootable partiton) disklabel -E sd0 Label editor (enter '?' for help at any prompt) a a offset: [64] size: [70319603585] FS type: [4.2BSD] RAID w q # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... bioctl: unknown error dmesg: OpenBSD 6.1-current (GENERIC.MP) #54: Thu May 11 19:20:09 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34333851648 (32743MB) avail mem = 33287512064 (31745MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9d000 (51 entries) bios0: vendor American Megatrends Inc. version "2.1" date 03/17/2012 bios0: Supermicro X8DT3 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG SLIT SLIC OEMB SRAT HPET SSDT acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) PS2K(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.32 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2400324600 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 9, package 0 cpu3 at mainbus0: apid 20 (application processor) cpu3: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 10, package 0 cpu4 at mainbus0: apid 32 (application processor) cpu4: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 0, package 1 cpu5 at mainbus0: apid 48 (application processor) cpu5: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 0, core 8, package 1 cpu6 at mainbus0: apid 50 (application processor) cpu6: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,
Re: bioctl crypto size limitation ?
On 05/26/17 15:49, sharon s. wrote: On 05/26/17 11:43, Ted Unangst wrote: sharon s. wrote: softraid0: invalid metadata format You filled the disk with random data, which is not a valid metadata format... I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto . Sorry, I was hasty. You can also try creating smaller partitions. 16TB, 8TB, etc. to see what works. That would be helpful information to have. 8Tb seems to be fine, 16 not so much. Ran into a weird issue where I couldn't try with 12Tb. # dd if=/dev/random of=/dev/rsd0c bs=1m ^C4310+0 records in 4309+0 records out 4518313984 bytes transferred in 90.924 secs (49692799 bytes/sec) 20170526-1539: tbisch@store:/root:# fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] 16T Rounding size to cylinder (16065 sectors): 34359741611 FS type: [4.2BSD] RAID > w > q No label changes. # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... bioctl: unknown error # dd if=/dev/random of=/dev/rsd0c bs=1m ^C2465+0 records in 2464+0 records out 2583691264 bytes transferred in 51.839 secs (49840098 bytes/sec) # fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] 8T Rounding size to cylinder (16065 sectors): 17179878806 FS type: [4.2BSD] RAID > w > q No label changes. # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... softraid0: CRYPTO volume attached as sd4 # dd if=/dev/random of=/dev/rsd0c bs=1m ^C2914+0 records in 2913+0 records out 3054501888 bytes transferred in 61.213 secs (49899553 bytes/sec) 20170526-1544: tbisch@store:/root:# fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] 12T Rounding size to cylinder (16065 sectors): 25769818241 FS type: [4.2BSD] RAID > w disklabel: ioctl DIOCWDINFO: Open partition would move or shrink disklabel: unable to write label Stupid me, I forgot that the softraid device was still attached. 12Tb, 14Tb and 15Tb works as well, 16 seems to be where it breaks. # dd if=/dev/random of=/dev/rsd0c bs=1m ^C526+0 records in 525+0 records out 550502400 bytes transferred in 11.298 secs (48724516 bytes/sec) 20170526-1551: tbisch@store:/root:# fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] 12T Rounding size to cylinder (16065 sectors): 25769818241 FS type: [4.2BSD] RAID > w > q No label changes. # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... softraid0: CRYPTO volume attached as sd4 # dd if=/dev/random of=/dev/rsd0c bs=1m ^C1526+0 records in 1525+0 records out 1599078400 bytes transferred in 32.276 secs (49543440 bytes/sec) # fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] 15T Rounding size to cylinder (16065 sectors): 32212268801 FS type: [4.2BSD] RAID > w > q No label changes. # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... softraid0: CRYPTO volume attached as sd4
Re: bioctl crypto size limitation ?
On 05/26/17 11:43, Ted Unangst wrote: sharon s. wrote: softraid0: invalid metadata format You filled the disk with random data, which is not a valid metadata format... I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto . Sorry, I was hasty. You can also try creating smaller partitions. 16TB, 8TB, etc. to see what works. That would be helpful information to have. 8Tb seems to be fine, 16 not so much. Ran into a weird issue where I couldn't try with 12Tb. # dd if=/dev/random of=/dev/rsd0c bs=1m ^C4310+0 records in 4309+0 records out 4518313984 bytes transferred in 90.924 secs (49692799 bytes/sec) 20170526-1539: tbisch@store:/root:# fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] 16T Rounding size to cylinder (16065 sectors): 34359741611 FS type: [4.2BSD] RAID > w > q No label changes. # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... bioctl: unknown error # dd if=/dev/random of=/dev/rsd0c bs=1m ^C2465+0 records in 2464+0 records out 2583691264 bytes transferred in 51.839 secs (49840098 bytes/sec) # fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] 8T Rounding size to cylinder (16065 sectors): 17179878806 FS type: [4.2BSD] RAID > w > q No label changes. # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... softraid0: CRYPTO volume attached as sd4 # dd if=/dev/random of=/dev/rsd0c bs=1m ^C2914+0 records in 2913+0 records out 3054501888 bytes transferred in 61.213 secs (49899553 bytes/sec) 20170526-1544: tbisch@store:/root:# fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] 12T Rounding size to cylinder (16065 sectors): 25769818241 FS type: [4.2BSD] RAID > w disklabel: ioctl DIOCWDINFO: Open partition would move or shrink disklabel: unable to write label
Re: bioctl crypto size limitation ?
On 05/26/17 12:00, Christian Weisgerber wrote: On 2017-05-25, myml...@gmx.com wrote: fdisk -iy -g sd0 (I left off the "-b 960" because this is not a bootable partiton) Back in March, Eric Huiban noticed this: | i just performed some remote connection... recreating GPT with an .i EFI | boot partition. The softraid is now 2.7TiB... Grumbl! conclusion : | bioctl needs a mandatory bootable partition to act correctly even on | disks not aimed to be bootable. https://marc.info/?l=openbsd-misc&m=148854591221493&w=2 using the "-b 960" doesn't help: # dd if=/dev/random of=/dev/rsd0c bs=1m ^C18404+0 records in 18403+0 records out 19296944128 bytes transferred in 386.986 secs (49864646 bytes/sec) # fdisk -iy -g -b 960 sd0 Writing MBR at offset 0. Writing GPT. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [1024] size: [70319602625] FS type: [4.2BSD] RAID > w > q No label changes. :# bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... bioctl: unknown error
Re: bioctl crypto size limitation ?
On 05/26/17 09:11, Joel Sing wrote: On Saturday 27 May 2017 01:56:06 Joel Sing wrote: On Friday 26 May 2017 01:05:59 sharon s. wrote: On 05/26/17 00:45, Ted Unangst wrote: myml...@gmx.com wrote: Steps to recreate: dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) fdisk -iy -g sd0 (I left off the "-b 960" because this is not a bootable partiton) disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] FS type: [4.2BSD] RAID > w > q # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... bioctl: unknown error softraid0: invalid metadata format You filled the disk with random data, which is not a valid metadata format... I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto . Hrmmm, it looks like that part of the FAQ is incorrect or missing a step. You should be able to work around it by either zeroing the first ~1MB of disk (per the FAQ), or by using 'bioctl -C force' (carefully). Actually, re-reading this it should be correct - the "invalid metadata format" error is more likely indicating an issue identifying the partition type/size (as unhelpful as that is). Could you provide the output from `disklabel sd0'? Currently have have created a standard filesystem and have it mounted, disklable looks like so: 20170526-1519: tbisch@store:/root:# disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: MR9265-8i duid: 194997bb8410087b flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 4377192 total sectors: 70319603712 boundstart: 1024 boundend: 70319603649 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 70319602560 1024 4.2BSD 8192 65536 52270 # /data c: 703196037120 unused i: 960 64 MSDOS I was a little surprised that the offset was 1024, haven't seen that before. If i unmount, send some random data to the drive, re-init the drive and then run run disklabel it looks like so: # umount /backup # dd if=/dev/random of=/dev/rsd0c bs=1m ^C7342+0 records in 7341+0 records out 7697596416 bytes transferred in 153.355 secs (50194418 bytes/sec) # fdisk -iy -g sd0 Writing MBR at offset 0. Writing GPT. # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: MR9265-8i duid: 8100dcb121ad1107 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 4377192 total sectors: 70319603712 boundstart: 64 boundend: 70319603649 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 70319603585 64RAID c: 703196037120 unused Additionally, the system kernel paniced when I was moving data to it the other day, the automatic fsck took 8 minutes for the 32Tb drive.
Re: bioctl crypto size limitation ?
On Thu, May 25, 2017 at 10:03:59AM -0700, myml...@gmx.com wrote: | I'm wondering if there is a limit to the size of a disk for full disk | encryption. My biggest crypto disk is: [weerd@pom] $ df -h /store Filesystem SizeUsed Avail Capacity Mounted on /dev/sd16a 5.4T841G4.3T16%/store [weerd@pom] $ dmesg | grep sd16 sd16 at scsibus12 targ 2 lun 0: SCSI2 0/direct fixed sd16: 5723166MB, 512 bytes/sector, 11721044513 sectors It is backed by this physical disk: [weerd@pom] $ doas bioctl -vhi softraid0 Volume Status Size Device softraid0 1 Online 5.5T sd16CRYPTO 0 Online 5.5T 1:0.0 noencl 'unknown serial' [weerd@pom] $ dmesg | grep -e '^sd1[ :]' sd1 at scsibus1 targ 2 lun 0: SCSI3 0/direct fixed naa.50014ee2b81f4111 sd1: 5723166MB, 512 bytes/sector, 11721045168 sectors disklabels are as follows: sd1: 16 partitions: #size offset fstype [fsize bsize cpg] a: 11721045041 64RAID c: 117210451680 unused sd16: #size offset fstype [fsize bsize cpg] a: 11721044288 64 4.2BSD 8192 65536 52270 # /store c: 117210445130 unused I did not create the -b special boot partition on either of these volumes. Everything worked just fine without. The reduction in sector count is due to rounding. Cheers, Paul 'WEiRD' de Weerd | I'm trying to encrypt a 32Tb raid 6 drive on a lsi 9265-8i with 8 x 6Tb | drives and it's failing with the error "unknown error". (very descriptive!) | | I was able to encrypt the 256Gb system disk without error during | installation. | | Without encrypting the 32Tb drive, I had no problem creating the FS and | mounting it. | | I know people will say this is a bad idea because of fsck (and maybe other | reasons), but this drive will be mounted ro 99% of the time. | | Steps to recreate: | | dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) | | fdisk -iy -g sd0 (I left off the "-b 960" because this is not a bootable | partiton) | | disklabel -E sd0 | | Label editor (enter '?' for help at any prompt) | > a a | offset: [64] | size: [70319603585] | FS type: [4.2BSD] RAID | > w | > q | | # bioctl -v -c C -l sd0a softraid0 | New passphrase: | Re-type passphrase: | Deriving key using bcrypt PBKDF with 16 rounds... | bioctl: unknown error | | | dmesg: | | OpenBSD 6.1-current (GENERIC.MP) #54: Thu May 11 19:20:09 MDT 2017 | dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP | real mem = 34333851648 (32743MB) | avail mem = 33287512064 (31745MB) | mpath0 at root | scsibus0 at mpath0: 256 targets | mainbus0 at root | bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9d000 (51 entries) | bios0: vendor American Megatrends Inc. version "2.1" date 03/17/2012 | bios0: Supermicro X8DT3 | acpi0 at bios0: rev 2 | acpi0: sleep states S0 S1 S4 S5 | acpi0: tables DSDT FACP APIC MCFG SLIT SLIC OEMB SRAT HPET SSDT | acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) NPE6(S4) | NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) PS2K(S4) USB0(S4) USB1(S4) | USB2(S4) USB5(S4) [...] | acpitimer0 at acpi0: 3579545 Hz, 24 bits | acpimadt0 at acpi0 addr 0xfee0: PC-AT compat | cpu0 at mainbus0: apid 0 (boot processor) | cpu0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.32 MHz | cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT | cpu0: 256KB 64b/line 8-way L2 cache | cpu0: TSC frequency 2400324600 Hz | cpu0: smt 0, core 0, package 0 | mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges | cpu0: apic clock running at 133MHz | cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE | cpu1 at mainbus0: apid 2 (application processor) | cpu1: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz | cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT | cpu1: 256KB 64b/line 8-way L2 cache | cpu1: smt 0, core 1, package 0 | cpu2 at mainbus0: apid 18 (application processor) | cpu2: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz | cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT | cpu2: 256KB 64b
Re: bioctl crypto size limitation ?
On 2017-05-25, myml...@gmx.com wrote: > fdisk -iy -g sd0 (I left off the "-b 960" because this is not a > bootable partiton) Back in March, Eric Huiban noticed this: | i just performed some remote connection... recreating GPT with an .i EFI | boot partition. The softraid is now 2.7TiB... Grumbl! conclusion : | bioctl needs a mandatory bootable partition to act correctly even on | disks not aimed to be bootable. https://marc.info/?l=openbsd-misc&m=148854591221493&w=2 -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: bioctl crypto size limitation ?
sharon s. wrote: > > > >> softraid0: invalid metadata format > > You filled the disk with random data, which is not a valid metadata > > format... > I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto . Sorry, I was hasty. You can also try creating smaller partitions. 16TB, 8TB, etc. to see what works. That would be helpful information to have.
Re: bioctl crypto size limitation ?
On Saturday 27 May 2017 01:56:06 Joel Sing wrote: > On Friday 26 May 2017 01:05:59 sharon s. wrote: > > On 05/26/17 00:45, Ted Unangst wrote: > > > myml...@gmx.com wrote: > > >> Steps to recreate: > > >> > > >> dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) > > >> > > >> fdisk -iy -g sd0 (I left off the "-b 960" because this is not a > > >> bootable partiton) > > >> > > >> disklabel -E sd0 > > >> > > >> Label editor (enter '?' for help at any prompt) > > >> > > >> > a a > > >> > > >> offset: [64] > > >> size: [70319603585] > > >> FS type: [4.2BSD] RAID > > >> > > >> > w > > >> > q > > >> > > >> # bioctl -v -c C -l sd0a softraid0 > > >> New passphrase: > > >> Re-type passphrase: > > >> Deriving key using bcrypt PBKDF with 16 rounds... > > >> bioctl: unknown error > > >> > > >> softraid0: invalid metadata format > > > > > > You filled the disk with random data, which is not a valid metadata > > > format... > > > > I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto . > > Hrmmm, it looks like that part of the FAQ is incorrect or missing a step. > You should be able to work around it by either zeroing the first ~1MB of > disk (per the FAQ), or by using 'bioctl -C force' (carefully). Actually, re-reading this it should be correct - the "invalid metadata format" error is more likely indicating an issue identifying the partition type/size (as unhelpful as that is). Could you provide the output from `disklabel sd0'?
Re: bioctl crypto size limitation ?
On Friday 26 May 2017 01:05:59 sharon s. wrote: > On 05/26/17 00:45, Ted Unangst wrote: > > myml...@gmx.com wrote: > >> Steps to recreate: > >> > >> dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) > >> > >> fdisk -iy -g sd0 (I left off the "-b 960" because this is not a > >> bootable partiton) > >> > >> disklabel -E sd0 > >> > >> Label editor (enter '?' for help at any prompt) > >> > >> > a a > >> > >> offset: [64] > >> size: [70319603585] > >> FS type: [4.2BSD] RAID > >> > >> > w > >> > q > >> > >> # bioctl -v -c C -l sd0a softraid0 > >> New passphrase: > >> Re-type passphrase: > >> Deriving key using bcrypt PBKDF with 16 rounds... > >> bioctl: unknown error > >> > >> softraid0: invalid metadata format > > > > You filled the disk with random data, which is not a valid metadata > > format... > > I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto . Hrmmm, it looks like that part of the FAQ is incorrect or missing a step. You should be able to work around it by either zeroing the first ~1MB of disk (per the FAQ), or by using 'bioctl -C force' (carefully).
Re: bioctl crypto size limitation ?
On 05/26/17 00:45, Ted Unangst wrote: myml...@gmx.com wrote: Steps to recreate: dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) fdisk -iy -g sd0 (I left off the "-b 960" because this is not a bootable partiton) disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] FS type: [4.2BSD] RAID > w > q # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... bioctl: unknown error softraid0: invalid metadata format You filled the disk with random data, which is not a valid metadata format... I followed the FAQ, http://www.openbsd.org/faq/faq14.html#softraidCrypto .
Re: bioctl crypto size limitation ?
myml...@gmx.com wrote: > Steps to recreate: > > dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) > > fdisk -iy -g sd0 (I left off the "-b 960" because this is not a > bootable partiton) > > disklabel -E sd0 > > Label editor (enter '?' for help at any prompt) > > a a > offset: [64] > size: [70319603585] > FS type: [4.2BSD] RAID > > w > > q > > # bioctl -v -c C -l sd0a softraid0 > New passphrase: > Re-type passphrase: > Deriving key using bcrypt PBKDF with 16 rounds... > bioctl: unknown error > softraid0: invalid metadata format You filled the disk with random data, which is not a valid metadata format...
Re: bioctl crypto size limitation ?
Just make slice sd0a smaller than 100% of the RAID array. Regards, Florian Am 25. Mai 2017 19:03:59 MESZ schrieb myml...@gmx.com: >I'm wondering if there is a limit to the size of a disk for full disk >encryption. > >I'm trying to encrypt a 32Tb raid 6 drive on a lsi 9265-8i with 8 x 6Tb > >drives and it's failing with the error "unknown error". (very >descriptive!) > >I was able to encrypt the 256Gb system disk without error during >installation. > >Without encrypting the 32Tb drive, I had no problem creating the FS and > >mounting it. > >I know people will say this is a bad idea because of fsck (and maybe >other reasons), but this drive will be mounted ro 99% of the time. > >Steps to recreate: > >dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) > >fdisk -iy -g sd0 (I left off the "-b 960" because this is not a >bootable partiton) > >disklabel -E sd0 > >Label editor (enter '?' for help at any prompt) > > a a >offset: [64] >size: [70319603585] >FS type: [4.2BSD] RAID > > w > > q > ># bioctl -v -c C -l sd0a softraid0 >New passphrase: >Re-type passphrase: >Deriving key using bcrypt PBKDF with 16 rounds... >bioctl: unknown error > > >dmesg: > >OpenBSD 6.1-current (GENERIC.MP) #54: Thu May 11 19:20:09 MDT 2017 >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >real mem = 34333851648 (32743MB) >avail mem = 33287512064 (31745MB) >mpath0 at root >scsibus0 at mpath0: 256 targets >mainbus0 at root >bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9d000 (51 entries) >bios0: vendor American Megatrends Inc. version "2.1" date 03/17/2012 >bios0: Supermicro X8DT3 >acpi0 at bios0: rev 2 >acpi0: sleep states S0 S1 S4 S5 >acpi0: tables DSDT FACP APIC MCFG SLIT SLIC OEMB SRAT HPET SSDT >acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) >NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) PS2K(S4) USB0(S4) > >USB1(S4) USB2(S4) USB5(S4) [...] >acpitimer0 at acpi0: 3579545 Hz, 24 bits >acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >cpu0 at mainbus0: apid 0 (boot processor) >cpu0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.32 MHz >cpu0: >FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT >cpu0: 256KB 64b/line 8-way L2 cache >cpu0: TSC frequency 2400324600 Hz >cpu0: smt 0, core 0, package 0 >mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges >cpu0: apic clock running at 133MHz >cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE >cpu1 at mainbus0: apid 2 (application processor) >cpu1: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz >cpu1: >FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT >cpu1: 256KB 64b/line 8-way L2 cache >cpu1: smt 0, core 1, package 0 >cpu2 at mainbus0: apid 18 (application processor) >cpu2: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz >cpu2: >FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT >cpu2: 256KB 64b/line 8-way L2 cache >cpu2: smt 0, core 9, package 0 >cpu3 at mainbus0: apid 20 (application processor) >cpu3: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz >cpu3: >FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT >cpu3: 256KB 64b/line 8-way L2 cache >cpu3: smt 0, core 10, package 0 >cpu4 at mainbus0: apid 32 (application processor) >cpu4: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz >cpu4: >FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT >cpu4: 256KB 64b/line 8-way L2 cache >cpu4: smt 0, core 0, package 1 >cpu5 at mainbus0: apid 48 (application processor) >cpu5: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz >cpu5: >FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR
bioctl crypto size limitation ?
I'm wondering if there is a limit to the size of a disk for full disk encryption. I'm trying to encrypt a 32Tb raid 6 drive on a lsi 9265-8i with 8 x 6Tb drives and it's failing with the error "unknown error". (very descriptive!) I was able to encrypt the 256Gb system disk without error during installation. Without encrypting the 32Tb drive, I had no problem creating the FS and mounting it. I know people will say this is a bad idea because of fsck (and maybe other reasons), but this drive will be mounted ro 99% of the time. Steps to recreate: dd if=/dev/random of=/dev/rsd0c bs=1m (took over a week) fdisk -iy -g sd0 (I left off the "-b 960" because this is not a bootable partiton) disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [70319603585] FS type: [4.2BSD] RAID > w > q # bioctl -v -c C -l sd0a softraid0 New passphrase: Re-type passphrase: Deriving key using bcrypt PBKDF with 16 rounds... bioctl: unknown error dmesg: OpenBSD 6.1-current (GENERIC.MP) #54: Thu May 11 19:20:09 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34333851648 (32743MB) avail mem = 33287512064 (31745MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9d000 (51 entries) bios0: vendor American Megatrends Inc. version "2.1" date 03/17/2012 bios0: Supermicro X8DT3 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG SLIT SLIC OEMB SRAT HPET SSDT acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) PS2K(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.32 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2400324600 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 9, package 0 cpu3 at mainbus0: apid 20 (application processor) cpu3: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 10, package 0 cpu4 at mainbus0: apid 32 (application processor) cpu4: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 0, package 1 cpu5 at mainbus0: apid 48 (application processor) cpu5: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 0, core 8, package 1 cpu6 at mainbus0: apid 50 (application processor) cpu6: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2400.01 MHz cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
Re: bioctl showing "0% done" on apparently healthy softraid
On 03/19/17 12:03, Theo Buehler wrote: > On Sat, Mar 18, 2017 at 11:36:15AM -0400, Joe Gidi wrote: >> Apologies for the horribly mangled formatting on the first attempt. >> Resending, hopefully much more legibly... >> >> I have a file server running -current on amd64. It has a three-drive RAID1 >> softraid array. Up until yesterday, I'd been running a snap from February >> 18 and everything was behaving as expected. >> >> After updating to a fresh snapshot yesterday, I noticed that the output of >> bioctl is different and a bit odd. It now shows "0% done", but the array >> and all three member drives are showing as online: >> >> $ sudo bioctl sd4 >> Volume Status Size Device >> softraid0 0 Online 4000786726912 sd4 RAID1 0% done >> 0 Online 4000786726912 0:0.0 noencl >> 1 Online 4000786726912 0:1.0 noencl >> 2 Online 4000786726912 0:2.0 noencl >> >> SMART status on all member drives is healthy, and I can see no sign of >> an actual drive failure, so I don't understand why bioctl appears to >> be showing a rebuild in progress. >> >> Can anyone clue me in on why I'm seeing this? > > This is printed due to an unintended side effect of a code cleanup that > happened end of last May. It is harmless and I just committed a diff > that restores the previous behavior. Sorry for the inconvenience. Confirmed -- this snap fixes mine: OpenBSD 6.1-beta (GENERIC.MP) #42: Mon Mar 20 07:22:05 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # bioctl softraid0 Volume Status Size Device softraid0 0 Online 985661513728 sd2 RAID1 0 Online 985661513728 0:0.0 noencl 1 Online 985661513728 0:1.0 noencl
Re: bioctl showing "0% done" on apparently healthy softraid
On Sat, Mar 18, 2017 at 11:36:15AM -0400, Joe Gidi wrote: > Apologies for the horribly mangled formatting on the first attempt. > Resending, hopefully much more legibly... > > I have a file server running -current on amd64. It has a three-drive RAID1 > softraid array. Up until yesterday, I'd been running a snap from February > 18 and everything was behaving as expected. > > After updating to a fresh snapshot yesterday, I noticed that the output of > bioctl is different and a bit odd. It now shows "0% done", but the array > and all three member drives are showing as online: > > $ sudo bioctl sd4 > Volume Status Size Device > softraid0 0 Online 4000786726912 sd4 RAID1 0% done > 0 Online 4000786726912 0:0.0 noencl > 1 Online 4000786726912 0:1.0 noencl > 2 Online 4000786726912 0:2.0 noencl > > SMART status on all member drives is healthy, and I can see no sign of > an actual drive failure, so I don't understand why bioctl appears to > be showing a rebuild in progress. > > Can anyone clue me in on why I'm seeing this? This is printed due to an unintended side effect of a code cleanup that happened end of last May. It is harmless and I just committed a diff that restores the previous behavior. Sorry for the inconvenience.
Re: bioctl showing "0% done" on apparently healthy softraid
0 inteldrm0: msi inteldrm0: 1024x768 wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x09: msi azalia0: No codecs found xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel I218-V" rev 0x04: msi, address ec:a8:6b:fe:39:2f azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi azalia1: codecs: Realtek/0x0283 audio0 at azalia1 ehci0 at pci0 dev 29 function 0 "Intel 8 Series USB" rev 0x04: apic 8 int 23 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 "Intel 8 Series LPC" rev 0x04 ahci0 at pci0 dev 31 function 2 "Intel 8 Series AHCI" rev 0x04: msi, AHCI 1.3 ahci0: port 3: 6.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 3 lun 0: SCSI3 0/direct fixed naa.500a075109636d9b sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin ichiic0 at pci0 dev 31 function 3 "Intel 8 Series SMBus" rev 0x04: apic 8 int 18 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-10600 SO-DIMM isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x4e/2: NCT6776F rev 0x33 lm1 at wbsio0 port 0xa00/8: NCT6776F umass0 at uhub0 port 13 configuration 1 interface 0 "JMicron USB Mass Storage" rev 3.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets, initiator 0 sd1 at scsibus2 targ 1 lun 0: SCSI2 0/direct fixed sd1: 476940MB, 512 bytes/sector, 976773168 sectors sd2 at scsibus2 targ 1 lun 1: SCSI2 0/direct fixed sd2: 476940MB, 512 bytes/sector, 976773168 sectors uhub2 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.04 addr 2 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets sd3 at scsibus4 targ 1 lun 0: SCSI2 0/direct fixed sd3: 476937MB, 512 bytes/sector, 976767473 sectors root on sd0a (f12e7e1c59ddaa59.a) swap on sd0b dump on sd0b # bioctl softraid0 Volume Status Size Device softraid0 0 Online 500104946176 sd3 RAID1 0% done 0 Online 500104946176 0:0.0 noencl 1 Online 500104946176 0:1.0 noencl -f
Re: bioctl showing "0% done" on apparently healthy softraid
On 03/18/17 11:36, Joe Gidi wrote: > Apologies for the horribly mangled formatting on the first attempt. > Resending, hopefully much more legibly... > > I have a file server running -current on amd64. It has a three-drive RAID1 > softraid array. Up until yesterday, I'd been running a snap from February > 18 and everything was behaving as expected. > > After updating to a fresh snapshot yesterday, I noticed that the output of > bioctl is different and a bit odd. It now shows "0% done", but the array > and all three member drives are showing as online: > > $ sudo bioctl sd4 > Volume Status Size Device > softraid0 0 Online 4000786726912 sd4 RAID1 0% done > 0 Online 4000786726912 0:0.0 noencl > 1 Online 4000786726912 0:1.0 noencl > 2 Online 4000786726912 0:2.0 noencl > > SMART status on all member drives is healthy, and I can see no sign of > an actual drive failure, so I don't understand why bioctl appears to > be showing a rebuild in progress. > > Can anyone clue me in on why I'm seeing this? I'm seeing the same thing on a machine fresh-built on current last week, so looks like a "feature" of -current, rather than an upgrade issue. OpenBSD 6.1-beta (GENERIC.MP) #10: Sun Mar 12 20:24:57 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # bioctl softraid0 Volume Status Size Device softraid0 0 Online 985661513728 sd2 RAID1 0% done 0 Online 985661513728 0:0.0 noencl 1 Online 985661513728 0:1.0 noencl /home/nick $ uptime 11:00PM up 4 days, 15:16, 1 user, load averages: 1.13, 1.12, 1.08 Nick.
bioctl showing "0% done" on apparently healthy softraid
Apologies for the horribly mangled formatting on the first attempt. Resending, hopefully much more legibly... I have a file server running -current on amd64. It has a three-drive RAID1 softraid array. Up until yesterday, I'd been running a snap from February 18 and everything was behaving as expected. After updating to a fresh snapshot yesterday, I noticed that the output of bioctl is different and a bit odd. It now shows "0% done", but the array and all three member drives are showing as online: $ sudo bioctl sd4 Volume Status Size Device softraid0 0 Online 4000786726912 sd4 RAID1 0% done 0 Online 4000786726912 0:0.0 noencl 1 Online 4000786726912 0:1.0 noencl 2 Online 4000786726912 0:2.0 noencl SMART status on all member drives is healthy, and I can see no sign of an actual drive failure, so I don't understand why bioctl appears to be showing a rebuild in progress. Can anyone clue me in on why I'm seeing this? Full dmesg: OpenBSD 6.1-beta (GENERIC.MP) #32: Thu Mar 16 19:22:10 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4162596864 (3969MB) avail mem = 4031762432 (3844MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedc10 (87 entries) bios0: vendor LENOVO version "FBKTB3AUS" date 06/16/2015 bios0: LENOVO ThinkServer TS140 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC FPDT FIDT TCPA DBGP LUFT SSDT SSDT MCFG HPET SSDT SSDT ASF! BGRT EINJ ERST HEST BERT acpi0: wakeup devices UAR1(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) PXSX(S0) RP04(S0) PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) GLAN(S0) EHC1(S0) EHC2(S0) XHC_(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3193.07 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,P OPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC, FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 3193072850 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.61 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,P OPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC, FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.61 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,P OPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC, FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.61 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,P OPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC, FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP04) acpiprt4 at acpi0: bus -1 (PEG0) acpiprt5 at acpi0: bus -1 (PEG1) acpiprt6 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpip
bioctl showing "0% done" on apparently healthy softraid
I have a file server running -current on amd64. It has a three-drive RAID1 softraid array. Up until yesterday, I'd been running a snap from February 18 and everything was behaving as expected. After updating to a fresh snapshot yesterday, I noticed that the output of bioctl is different and a bit odd. It now shows "0% done", but the array and all three member drives are showing as online: $ sudo bioctl sd4       Volume     Status              Size Device softraid0 0 Online     4000786726912 sd4    RAID1 0% done          0 Online     4000786726912 0:0.0  noencl          1 Online     4000786726912 0:1.0  noencl          2 Online     4000786726912 0:2.0  noencl SMART status on all member drives is healthy, and I can see no sign of an actual drive failure, so I don't understand why bioctl appears to be showing a rebuild in progress. Can anyone clue me in on why I'm seeing this? Full dmesg: OpenBSD 6.1-beta (GENERIC.MP) #32: Thu Mar 16 19:22:10 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4162596864 (3969MB) avail mem = 4031762432 (3844MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedc10 (87 entries) bios0: vendor LENOVO version "FBKTB3AUS" date 06/16/2015 bios0: LENOVO ThinkServer TS140 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC FPDT FIDT TCPA DBGP LUFT SSDT SSDT MCFG HPET SSDT SSDT ASF! BGRT EINJ ERST HEST BERT acpi0: wakeup devices UAR1(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) PXSX(S0) RP04(S0) PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) GLAN(S0) EHC1(S0) EHC2(S0) XHC_(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3193.07 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,P OPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC, FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 3193072850 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.61 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,P OPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC, FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.61 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,P OPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC, FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.61 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,P OPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC, FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP04) acpiprt4 at acpi0: bus -1 (PEG0) acpiprt5 at acpi0: bus -1 (PEG1) acpiprt6 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33),
partition alignment and sector sizes [was Re: Started having bioctl encryption problems recently - lost data. Error within FAQ?]
On 2016-06-13, Chris Cappuccio wrote:
> c. You must start the first partition past block 0, block 64
> is standard for various reasons.
I think we should consider changing this.
Most mechanical drives these days have 4KB sectors (though many hide
it with synthetic 512 byte sectors) which work OK with fdisk and
disklabel's defaults, but other storage devices have larger natural
boundaries. RAID stripe sizes are often a power-of-two >=64KB and
256KB/512KB is not uncommon for a flash erase block. Straddling
two of these boundaries is suboptimal for performance and, in
the case of flash, longevity.
These days I usually manually align to multiples of 2048 sectors
(1MB), which keeps the maths simple and matches what Microsoft have been
doing for drives of over 4GB since Vista/2008, VMware VMFS-5 (since ESXi
5), and various Linux utilities if DOS compatibility mode is not used.
(https://www.thomas-krenn.com/en/wiki/Partition_Alignment has a pretty
good write-up).
Diffs only meant as a starting point for discussion or for people
experimenting, but as a minimal change automating this in disklabel
could be done as something like this,
Index: disklabel/editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.300
diff -u -p -r1.300 editor.c
--- disklabel/editor.c 10 Dec 2015 17:26:59 - 1.300
+++ disklabel/editor.c 14 Jun 2016 10:32:34 -
@@ -2070,8 +2070,7 @@ align:
orig_size = DL_GETPSIZE(pp);
orig_offset = DL_GETPOFFSET(pp);
- bsize = (DISKLABELV1_FFS_FRAG(pp->p_fragblock) *
- DISKLABELV1_FFS_FSIZE(pp->p_fragblock)) / lp->d_secsize;
+ bsize = 2048;
if (DL_GETPOFFSET(pp) != starting_sector) {
/* Can't change offset of first partition. */
adj = bsize - (DL_GETPOFFSET(pp) % bsize);
(disklabel normally also rounds size down to a multiple of the cylinder
size if you enter values in anything other than sectors. The reported
C/H/S geometry hasn't borne any relation to real geometry in most cases
for years so it might be worth looking at removing that too, but that's
done before bsize-rounding so it's just making partitions smaller than
requested in some cases, rather than causing alignment problems.)
One possible fdisk diff below, though I'm not sure the power-of-2 makes
sense if aligning to 1MB boundaries.
Index: fdisk/mbr.c
===
RCS file: /cvs/src/sbin/fdisk/mbr.c,v
retrieving revision 1.65
diff -u -p -r1.65 mbr.c
--- fdisk/mbr.c 30 Dec 2015 17:21:39 - 1.65
+++ fdisk/mbr.c 14 Jun 2016 10:43:03 -
@@ -145,8 +145,11 @@ MBR_init(struct mbr *mbr)
}
#endif
- /* Start OpenBSD MBR partition on a power of 2 block number. */
- i = 1;
+ /*
+* Start OpenBSD MBR partition on a power of 2 block number
+* with a minimum 2048-block alignment.
+*/
+ i = 2048;
while (i < DL_SECTOBLK(&dl, mbr->part[3].bs))
i *= 2;
adj = DL_BLKTOSEC(&dl, i) - mbr->part[3].bs;
Re: Started having bioctl encryption problems recently - lost data. Error within FAQ?
Hello misc@, Phones suck. # dd if=/dev/random of=/dev/rsd0c bs=1m #__Zero out random garbage._### # dd if=/dev/zero of=/dev/rsd0c bs=1m count=1 # fdisk -iy sd0 # disklabel -E sd0 (create an "a" partition, see above for more info) # bioctl -c C -l sd0a softraid0 New passphrase: Re-type passphrase: softraid0: CRYPTO volume attached as sd1 # dd if=/dev/zero of=/dev/rsd1c bs=1m count=1 __Add a MBR__# # fdisk -iy sd1 # disklabel -E sd1 (create an "i" partition, see above for more info) # newfs sd1i # mkdir -p /mnt/secretstuff # mount /dev/sd1i /mnt/secretstuff # mv planstotakeovertheworld.txt /mnt/secretstuff/ # umount /mnt/secretstuff # bioctl -d sd1 Regards, Gerald Hanuer
Re: Started having bioctl encryption problems recently - lost data. Error within FAQ?
Hello misc@, On Tue, Jun 14, 2016 at 12:30 AM Theo Buehler However, I don't quite understand your double zeroing of the disk. > #__Zero out random garbage._### > # dd if=/dev/zero of=/dev/rsd0c bs=1m count=1 [...] > #__Zero out random garbage ( not the raw disk ).__# > # dd if=/dev/zero of=/dev/sd1c bs=1m count=1 The first one is an ok alternative to what's done in the FAQ, but I don't understand your comment on not using the raw disk for the second command. Using the raw device as it is written *is* correct, see also the example section in the bioctl(4) manual. You are correct, this is not needed, ( Over zealous "pasto" ) This reads better. # dd if=/dev/random of=/dev/rsd0c bs=1m #__Zero out random garbage._### # dd if=/dev/zero of=/dev/rsd0c bs=1m count=1 # fdisk -iy sd0 # disklabel -E sd0 (create an "a" partition, see above for more info) # bioctl -c C -l sd0a softraid0 New passphrase: Re-type passphrase: softraid0: CRYPTO volume attached as sd1 __Add a MBR__# # fdisk -iy sd1 # disklabel -E sd1 (create an "i" partition, see above for more info) # newfs sd1i # mkdir -p /mnt/secretstuff # mount /dev/sd1i /mnt/secretstuff # mv planstotakeovertheworld.txt /mnt/secretstuff/ # umount /mnt/secretstuff # bioctl -d sd1 Regards, Gerald Hanuer
Re: Started having bioctl encryption problems recently - lost data. Error within FAQ?
obsd [d...@protonmail.com] wrote: > 'Encrypting external disks' > http://www.openbsd.org/faq/faq14.html#softraidCrypto > > Followed the FAQ instructions EXACTLY to encrypt an external drive, then > copied data to it and after restarting the computer again.. I cannot access > the drive, infact it doesn't look like anything is even on it. This has > happened whilst following this tutorial on two different systems, using two > different hard disks.. Are the FAQ instructions wrong? Thanks > > $ fdisk wd1 > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > # disklabel wd1 > 16 partitions: > # size offset fstype [fsize bsize cpg] > c: 234441648 0 unused My guess is that you didn't run fdisk, THEN disklabel, THEN bioctl. This stays true for any use of software, not just crypto. If you don't run fdisk prior to disklabel, a. The BIOS may not be able to boot from the device (if necessary) b. Your disklabel will be overwritten by the filesystem itself if it starts at block 0. c. You must start the first partition past block 0, block 64 is standard for various reasons. Chris
Re: Started having bioctl encryption problems recently - lost data. Error within FAQ?
Hello misc@, The added or modified lines have comments. # dd if=/dev/random of=/dev/rsd0c bs=1m #__Zero out random garbage._### # dd if=/dev/zero of=/dev/rsd0c bs=1m count=1 # fdisk -iy sd0 # disklabel -E sd0 (create an "a" partition, see above for more info) # bioctl -c C -l sd0a softraid0 New passphrase: Re-type passphrase: softraid0: CRYPTO volume attached as sd1 #__Zero out random garbage ( not the raw disk ).__# # dd if=/dev/zero of=/dev/sd1c bs=1m count=1 #__Add a MBR__# # fdisk -iy sd1 # disklabel -E sd1 (create an "i" partition, see above for more info) # newfs sd1i # mkdir -p /mnt/secretstuff # mount /dev/sd1i /mnt/secretstuff # mv planstotakeovertheworld.txt /mnt/secretstuff/ # umount /mnt/secretstuff # bioctl -d sd1 This has worked for me. Regards, Gerald Hanuer
Started having bioctl encryption problems recently - lost data. Error within FAQ?
'Encrypting external disks' http://www.openbsd.org/faq/faq14.html#softraidCrypto Followed the FAQ instructions EXACTLY to encrypt an external drive, then copied data to it and after restarting the computer again.. I cannot access the drive, infact it doesn't look like anything is even on it. This has happened whilst following this tutorial on two different systems, using two different hard disks.. Are the FAQ instructions wrong? Thanks # Find the drive out $ dmesg | grep '^[sw]d' # Check the available partition on it $ fdisk wd1 Disk: wd1 geometry: 14593/255/63 [234441648 Sectors] Offset: 0 Signature: 0x0 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused # disklabel wd1 # /dev/rwd1c: type: ESDI disk: ESDI/IDE disk label: KINGSTON SV300S3 duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 14593 total sectors: 234441648 boundstart: 0 boundend: 234441648 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] c: 234441648 0 unused # #
Re: bioctl: unable to read passphrase
Hey, On 05/15/16 09:23, Maurice McCarthy wrote: I believe the installation ramdisk has limited space so you likely used it all up with "MAKEDEV all". It is limited to install on very old systems. thanks for the answer. That actually would explain my problem! Maybe the bioctl error message could be tweaked a little bit to explain the problem a little bit more in detail. Thanks and greetings Leo
Re: bioctl: unable to read passphrase
On Sun, May 15, 2016 at 12:21:48AM +0200 or thereabouts, Leo Unglaub wrote: > > But i think i found out what caused the problem. Every time i did a cd > /dev && sh MAKEDEV all it did not work and bioctl could not read my > passphrase anymore. When i just created the device nodes i needed > manually it seams to work. Maybe this is a bug in the MAKEDEV script or > i just missused it. Sorry about that. > I believe the installation ramdisk has limited space so you likely used it all up with "MAKEDEV all". It is limited to install on very old systems. Regards Moss
Re: bioctl: unable to read passphrase
Hey, On 05/14/16 15:19, Stuart Henderson wrote: Your initial problem report was missing a lot of important information - this is the first mention of it only happening on the install iso, and you didn't mention what it is that you're running (release? snapshot? which date? which arch?) i am deeply sorry about that. The problem happens only on the installer from the 5.9 release. I used the AMD64 image of the release. But i think i found out what caused the problem. Every time i did a cd /dev && sh MAKEDEV all it did not work and bioctl could not read my passphrase anymore. When i just created the device nodes i needed manually it seams to work. Maybe this is a bug in the MAKEDEV script or i just missused it. Sorry about that. Thanks anyway! Greetings Leo
Re: bioctl: unable to read passphrase
On 2016-05-14, Leo Unglaub wrote: > Hey, > > On 05/13/16 21:08, Ted Unangst wrote: >> you might try ktrace, since bioctl is not being very helpful here. > > the problem is that i dont have ktrace available on the install iso. I > tryed to reproduce it on my OpenBSD desktop but there i dont have that > problem. > > I looked up the part in the source where it prints this error message > but i really dont understand why it is triggered. > > Any more ideas on why i could try? > Big thanks and greetings > Leo > > Your initial problem report was missing a lot of important information - this is the first mention of it only happening on the install iso, and you didn't mention what it is that you're running (release? snapshot? which date? which arch?)
Re: bioctl: unable to read passphrase
Hey, On 05/13/16 21:08, Ted Unangst wrote: you might try ktrace, since bioctl is not being very helpful here. the problem is that i dont have ktrace available on the install iso. I tryed to reproduce it on my OpenBSD desktop but there i dont have that problem. I looked up the part in the source where it prints this error message but i really dont understand why it is triggered. Any more ideas on why i could try? Big thanks and greetings Leo
Re: bioctl: unable to read passphrase
> Am 13.05.2016 um 21:56 schrieb Ted Unangst : > > Theo Buehler wrote: >>> On Fri, May 13, 2016 at 07:28:51PM +0200, Leo Unglaub wrote: >>> Hey friends, >>> i have two identical ssd drives in my laptop. sd0 and sd1. I created a Raid >>> 1 (mirroring) on them resulting in sd3. I used the following command: >>> >>>> bioctl -c 1 -l sd0a,sd1a softraid0 >>> >>> >>> On the resulting disk i created sd3b with 2 GB Swap and sd3a with 100GB with >>> a type RAID. >>> >>> Now i want to put a crypto layer (Cryptoraid) on the resulting sd3a. I >>> wanted to use the following command: >>> >>>> bioctl -c C -l sd3a softraid0 >>> >>> But i get the following error message: bioctl: unable to read passphrase. >>> >>> Do you have any ideas why this is happening? >> >> I think this is due to the fact that nested disciplines are not (yet?) >> supported. See stsp@'s notes on softraid: >> https://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf >> page 5 where it says: >> >>Disciplines cannot be nested yet! >>So no CRYPTO on top of RAID 1, for instance > > that will cause problems later Which problems? This should really be mentioned in softraid(4) CAVEATS section then, no? Personally, I'm running CRYPTO on top of a large RAID1 for years without any problems.
Re: bioctl: unable to read passphrase
Theo Buehler wrote: > On Fri, May 13, 2016 at 07:28:51PM +0200, Leo Unglaub wrote: > > Hey friends, > > i have two identical ssd drives in my laptop. sd0 and sd1. I created a Raid > > 1 (mirroring) on them resulting in sd3. I used the following command: > > > > > bioctl -c 1 -l sd0a,sd1a softraid0 > > > > > > On the resulting disk i created sd3b with 2 GB Swap and sd3a with 100GB with > > a type RAID. > > > > Now i want to put a crypto layer (Cryptoraid) on the resulting sd3a. I > > wanted to use the following command: > > > > > bioctl -c C -l sd3a softraid0 > > > > But i get the following error message: bioctl: unable to read passphrase. > > > > Do you have any ideas why this is happening? > > I think this is due to the fact that nested disciplines are not (yet?) > supported. See stsp@'s notes on softraid: > https://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf > page 5 where it says: > > Disciplines cannot be nested yet! > So no CRYPTO on top of RAID 1, for instance that will cause problems later, but should not prevent bioctl from reading a passphrase.
Re: bioctl: unable to read passphrase
On Fri, May 13, 2016 at 07:28:51PM +0200, Leo Unglaub wrote: > Hey friends, > i have two identical ssd drives in my laptop. sd0 and sd1. I created a Raid > 1 (mirroring) on them resulting in sd3. I used the following command: > > > bioctl -c 1 -l sd0a,sd1a softraid0 > > > On the resulting disk i created sd3b with 2 GB Swap and sd3a with 100GB with > a type RAID. > > Now i want to put a crypto layer (Cryptoraid) on the resulting sd3a. I > wanted to use the following command: > > > bioctl -c C -l sd3a softraid0 > > But i get the following error message: bioctl: unable to read passphrase. > > Do you have any ideas why this is happening? I think this is due to the fact that nested disciplines are not (yet?) supported. See stsp@'s notes on softraid: https://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf page 5 where it says: Disciplines cannot be nested yet! So no CRYPTO on top of RAID 1, for instance
Re: bioctl: unable to read passphrase
Leo Unglaub wrote: > > bioctl -c C -l sd3a softraid0 > > But i get the following error message: bioctl: unable to read passphrase. > > Do you have any ideas why this is happening? you might try ktrace, since bioctl is not being very helpful here.
bioctl: unable to read passphrase
Hey friends, i have two identical ssd drives in my laptop. sd0 and sd1. I created a Raid 1 (mirroring) on them resulting in sd3. I used the following command: bioctl -c 1 -l sd0a,sd1a softraid0 On the resulting disk i created sd3b with 2 GB Swap and sd3a with 100GB with a type RAID. Now i want to put a crypto layer (Cryptoraid) on the resulting sd3a. I wanted to use the following command: bioctl -c C -l sd3a softraid0 But i get the following error message: bioctl: unable to read passphrase. Do you have any ideas why this is happening? Thanks and greetings Leo
Re: bioctl disk encryption
On Sat, 9 Apr 2016 20:18:11 -0400 Matt Schwartz wrote: > I really like the bioctl full disk encryption feature. I would love > to see it extended to support multiple users/passkeys. I once worked > with a commercial full disk encryption product that allowed this ... You could store keying material on those iStorage datAshur sticks; they support a user and admin key. Just have one for each user. Alternatively, you could just store the keying material on the same disk, but on encrypted softraid partitions, each encrypted with its own key. Assuming there is already one softraid partition 'a' on the disk, you have support for 14 different users: an admin with the primary key material stored on his own USB drive, and 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', and 'p' to encrypt with softraid, storing another RAID chunk which stores the key material. And you may even be able to use 'b' but as I understand, this is reserved for swap space. Not ideal, but "extended to support multiple users/passkeys" seems incredibly complex. Perhaps an example scenario for such usage would help. As someone else pointed out, access to the encrypted partition basically requires root access to the system anyway. > and could even be managed over a network. So basically, an exploit waiting to happen. > Coming up with a solution to manage encryption keys over a network is > trivial ... Well go on then. Where's the code? > but I'd love to see the full disk encryption extended to support > multiple users with individual passkeys. Right. Any ideas on how to implement this?
Re: bioctl disk encryption
On Sun, 10 Apr 2016, Matt Schwartz wrote: > I really like the bioctl full disk encryption feature. I would love to see > it extended to support multiple users/passkeys. I once worked with a > commercial full disk encryption product that allowed this and could even be > managed over a network. Coming up with a solution to manage encryption keys > over a network is trivial but I'd love to see the full disk encryption > extended to support multiple users with individual passkeys. > > Thanks for listening! This is pretty much completely pointless. FDE is supposed to protect your data when an adversary gains physical access to the disks. Physical access to the machine = root access to the OS. If you suspect someone could've tampered with the OS/bootloader (e.g. log the passphrase in cleartext), you better carry the bootloader on a USB stick and keep it under your pillow. If you trust your local users not to screw with the machine, just give them the damn passphrase. How many users share physical access to that box? 2? 5? 150? Perhaps too many? How often does a member of the staff leave the company? Is changing the passphrase every 6-12 months such a bother? For any networked access, the traditional unix permission model does the job, and having or not having FDE wouldn't make a slightest difference. One user can't see or modify the files of another. K.
Re: bioctl disk encryption
Okay, I wasn't screaming - cheering on a great operating system, most definitely. I'll dig into the source code a bit to see what I can learn. On Apr 9, 2016 9:12 PM, "Jiri B" wrote: > > On Sat, Apr 09, 2016 at 08:18:11PM -0400, Matt Schwartz wrote: > > I really like the bioctl full disk encryption feature. I would love to see > > it extended to support multiple users/passkeys. I once worked with a > > commercial full disk encryption product that allowed this and could even be > > managed over a network. Coming up with a solution to manage encryption keys > > over a network is trivial but I'd love to see the full disk encryption > > extended to support multiple users with individual passkeys. > > > > Thanks for listening! > > This is not how things work in OpenBSD. So you are screaming 'do that work > for me!!!'. Understand the reality, it's hobbist project mostly, there are > not paid by you or any big corporation (yes, there's some funding). > > So send your own diffs or do not expect your wish to become reality. There > are more important things to work on (if you at least follow recent OpenBSD > development - SMP, threads/performance,...). > > j.
bioctl disk encryption
I really like the bioctl full disk encryption feature. I would love to see it extended to support multiple users/passkeys. I once worked with a commercial full disk encryption product that allowed this and could even be managed over a network. Coming up with a solution to manage encryption keys over a network is trivial but I'd love to see the full disk encryption extended to support multiple users with individual passkeys. Thanks for listening!
Adding chunk to softraid volume with bioctl - required chunk size
Hello I have a question about RAID 1 volumes set up with bioctl. When I originally set up the softraid, I created a RAID partition that (essentially) took up the entire drive. However, the disklabel INSIDE the softraid does NOT use the all the space available (e.g. The chunks making up the RAID partition are 120GB, but the disklabel within the RAID only currently uses 60GB of space; so, 60 GB of space have not/will not have any data on them). My question is, if I want to add a new chunk to this array, does it have to be 120GB; or, since I am only using 60GB within the RAID, can I add a new chunk that is only 60GB? And, if so, is there anything special I need to do when adding the smaller chunk? With the falling price of SSD's, I am thinking of replacing the spinning disks with SSD's. It seems I will never need the additional space in the RAID, and it would be cheaper to buy smaller SSD's. Thanks Ted [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wipingthesame?
Aha. *Is* the keydisk the master key, and hence can't be changed? Very low priority topic: What about implementing some routine for regenerating the master key, even if that would imply reprocessing *all* of the disk's contents? That could be beneficial in a place where you don't have the space to backup 100% of the disk as to start over. On 2015-11-21 03:03, Ted Unangst wrote: Tinker wrote: Aha. *Is* the keydisk the master key, and hence can't be changed? The keydisk is the mask for the master key. It can (in theory) be changed like changing a password. Really, the key disk is just a prehashed password. Very low priority topic: What about implementing some routine for regenerating the master key, even if that would imply reprocessing *all* of the disk's contents? That could be beneficial in a place where you don't have the space to backup 100% of the disk as to start over. You could, but you'd be really screwed if you crashed halfway. I don't think the kernel can/should do this, but it is not impossible for a userland utility to manipulate softraid partitions.
Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wipingthesame?
I think it would make sense to be able to do this. I have a scenario where I would like to install OpenBSD on a remote machine with a customized bsd.rd in order to automatically set it all up, feeding a password into the stdin of bioctl.. Now, bioctl doesn't allow hashed password to be fed into it (as opposed to the encrypt command which does for user logins and auto_install) This leaves me with only one choice, to feed a password into bioctl in order to set up the fully encrypted drive, and then change the password with bioctl -P afterwards.. Only problem with that is just what was said.. the original password could still be used to decrypt the partitions as the keydisk hasn't changed. Original Message Subject: Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wipingthesame? Local Time: November 20 2015 7:03 pm UTC Time: November 20 2015 7:03 pm From: t...@tedunangst.com To: ti...@openmailbox.org CC: misc@openbsd.org,owner-m...@openbsd.org Tinker wrote: > Aha. > > *Is* the keydisk the master key, and hence can't be changed? The keydisk is the mask for the master key. It can (in theory) be changed like changing a password. Really, the key disk is just a prehashed password. > > > Very low priority topic: > > What about implementing some routine for regenerating the master key, > even if that would imply reprocessing *all* of the disk's contents? > > That could be beneficial in a place where you don't have the space to > backup 100% of the disk as to start over. You could, but you'd be really screwed if you crashed halfway. I don't think the kernel can/should do this, but it is not impossible for a userland utility to manipulate softraid partitions.
Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wipingthesame?
Tinker wrote: > Aha. > > *Is* the keydisk the master key, and hence can't be changed? The keydisk is the mask for the master key. It can (in theory) be changed like changing a password. Really, the key disk is just a prehashed password. > > > Very low priority topic: > > What about implementing some routine for regenerating the master key, > even if that would imply reprocessing *all* of the disk's contents? > > That could be beneficial in a place where you don't have the space to > backup 100% of the disk as to start over. You could, but you'd be really screwed if you crashed halfway. I don't think the kernel can/should do this, but it is not impossible for a userland utility to manipulate softraid partitions.
Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping thesame?
Aha. *Is* the keydisk the master key, and hence can't be changed? Very low priority topic: What about implementing some routine for regenerating the master key, even if that would imply reprocessing *all* of the disk's contents? That could be beneficial in a place where you don't have the space to backup 100% of the disk as to start over. On 2015-11-21 02:45, Ted Unangst wrote: Tinker wrote: Ah, and maybe equally importantly, what are the security ramifications of changing password/keydisk vs. wiping and installing from scratch with a new password/keydisk? The master key, which the data on disk is encrypted with, is masked with your password. The master key never changes. But if you change your password, the mask changes. The master key is not recoverable with the old password. Say that you would change password/keydisk today, and then next week someone gets a copy of your encrypted disk, and of your previous password/keydisk. Would they be able to extract any part of the disk information then, if not why? However, if somebody has a copy of your disk today (with old password) and they later, next month, learn your old password, they can decrypt that disk. That should be obvious. But they also now have a copy of the master key. So if they get your new disk, they can also decrypt that. Changing passwords is convenient, but if you have somehow lost control of either the password or the disk, it would be safer to start over.
Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping thesame?
Tinker wrote: > Ah, and maybe equally importantly, what are the security ramifications > of changing password/keydisk vs. wiping and installing from scratch with > a new password/keydisk? The master key, which the data on disk is encrypted with, is masked with your password. The master key never changes. But if you change your password, the mask changes. The master key is not recoverable with the old password. > Say that you would change password/keydisk today, and then next week > someone gets a copy of your encrypted disk, and of your previous > password/keydisk. > > Would they be able to extract any part of the disk information then, if > not why? However, if somebody has a copy of your disk today (with old password) and they later, next month, learn your old password, they can decrypt that disk. That should be obvious. But they also now have a copy of the master key. So if they get your new disk, they can also decrypt that. Changing passwords is convenient, but if you have somehow lost control of either the password or the disk, it would be safer to start over.
Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same?
I was wondering the exact same thing. Looking forward to finding out. Original Message Subject: Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same? Local Time: November 20 2015 2:13 pm UTC Time: November 20 2015 2:13 pm From: ti...@openmailbox.org To: misc@openbsd.org CC: owner-m...@openbsd.org Ah, and maybe equally importantly, what are the security ramifications of changing password/keydisk vs. wiping and installing from scratch with a new password/keydisk? Say that you would change password/keydisk today, and then next week someone gets a copy of your encrypted disk, and of your previous password/keydisk. Would they be able to extract any part of the disk information then, if not why? On 2015-11-20 21:58, Tinker wrote: > "bioctl -P" is to change passphrase without wiping the encrypted > partition's contents. How do you generate a new keydisk without wiping > the same? > > I.e. I have an encrypted partition /dev/sd0a which is encrypted using > the keydisk /dev/sd1a . Say /dev/sd1a's contents were compromised. How > do you generate a new one without needing to wipe /dev/sd0a . > > I.e. exactly the same as "-P" but for the keydisk usecase. > > (Of course the old keydisk/password is needed at replacement time.) > > Thanks, > Tinker
Re: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same?
Ah, and maybe equally importantly, what are the security ramifications of changing password/keydisk vs. wiping and installing from scratch with a new password/keydisk? Say that you would change password/keydisk today, and then next week someone gets a copy of your encrypted disk, and of your previous password/keydisk. Would they be able to extract any part of the disk information then, if not why? On 2015-11-20 21:58, Tinker wrote: "bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same? I.e. I have an encrypted partition /dev/sd0a which is encrypted using the keydisk /dev/sd1a . Say /dev/sd1a's contents were compromised. How do you generate a new one without needing to wipe /dev/sd0a . I.e. exactly the same as "-P" but for the keydisk usecase. (Of course the old keydisk/password is needed at replacement time.) Thanks, Tinker
"bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same?
"bioctl -P" is to change passphrase without wiping the encrypted partition's contents. How do you generate a new keydisk without wiping the same? I.e. I have an encrypted partition /dev/sd0a which is encrypted using the keydisk /dev/sd1a . Say /dev/sd1a's contents were compromised. How do you generate a new one without needing to wipe /dev/sd0a . I.e. exactly the same as "-P" but for the keydisk usecase. (Of course the old keydisk/password is needed at replacement time.) Thanks, Tinker
