Re: ZFS crash with -CURRENT from Aug 23rd
On 8/27/21 11:35 AM, Ryan Moeller wrote: zfs_deleteextattr_sa() at zfs_deleteextattr_sa+0x1e/frame 0xfe0147380360 zfs_setextattr() at zfs_setextattr+0x1e3/frame 0xfe01473804e0 Panic String: VERIFY(zp->z_is_sa) failed I see the issue, thanks! -Ryan https://github.com/openzfs/zfs/pull/12514
Re: i386 kernel modules unusable due to .plt sections
On Fri, 27 Aug 2021 11:32:43 -0400 Mark Johnston
wrote:
> On Fri, Aug 27, 2021 at 05:29:34PM +0200, Tijl Coosemans wrote:
>> On Fri, 27 Aug 2021 17:24:58 +0300 Konstantin Belousov
>> wrote:
>>> On Fri, Aug 27, 2021 at 03:41:30PM +0200, Tijl Coosemans wrote:
I use devel/llvm* to build base and just switched to llvm12. It seems
that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
These are converted to R_386_JMP_SLOT relocations by the linker which
aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
entries also depend on a base pointer in %ebx but kernel modules aren't
compiled with -fPIC, so this can't work and I suspect this is a
regression in clang12.
The following code shows the difference between clang11 and clang12:
#include
void *
test_memset(void *p, int c, size_t len) {
return (memset(p, c, len));
}
void *
test_memcpy(void *dst, const void *src, size_t len) {
return (memcpy(dst, src, len));
}
void *
test_memmove(void *dst, const void *src, size_t len) {
return (memmove(dst, src, len));
}
Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m32":
r_offset r_info r_type st_value st_name
002c 0504 R_386_PLT32 memset
0067 0304 R_386_PLT32 memcpy
00a7 0402 R_386_PC32 memmove
With clang11:
r_offset r_info r_type st_value st_name
0036 0502 R_386_PC32 memset
0083 0302 R_386_PC32 memcpy
00d2 0402 R_386_PC32 memmove
>>>
>>> Are you asking (for somebody) to add R_386_JMP_SLOT to i386/elf_machdep.c?
>>> Like this, not even built.
>>>
>>> diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c
>>> index 3754b36d9e33..a26a4189e0ee 100644
>>> --- a/sys/i386/i386/elf_machdep.c
>>> +++ b/sys/i386/i386/elf_machdep.c
>>> @@ -245,6 +245,7 @@ elf_reloc_internal(linker_file_t lf, Elf_Addr
>>> relocbase, const void *data,
>>> break;
>>>
>>> case R_386_GLOB_DAT:/* S */
>>> + case R_386_JMP_SLOT:
>>> error = lookup(lf, symidx, 1, );
>>> if (error != 0)
>>> return (-1);
>>
>> No, I've tried that. It handles the relocation but callers still don't
>> setup %ebx as PIC register. I'm looking for someone to confirm it's a
>> compiler bug and not a missing flag or something. I tried -fno-plt and
>> that has no effect.
>
> Does disabling -zifunc-noplt fix the problem? I believe it's set by
> default for i386.
Removing it from sys/conf/kern.pre.mk didn't help.
Re: ZFS crash with -CURRENT from Aug 23rd
zfs_deleteextattr_sa() at zfs_deleteextattr_sa+0x1e/frame 0xfe0147380360 zfs_setextattr() at zfs_setextattr+0x1e3/frame 0xfe01473804e0 Panic String: VERIFY(zp->z_is_sa) failed I see the issue, thanks! -Ryan
Re: i386 kernel modules unusable due to .plt sections
On Fri, Aug 27, 2021 at 05:29:34PM +0200, Tijl Coosemans wrote:
> On Fri, 27 Aug 2021 17:24:58 +0300 Konstantin Belousov
> wrote:
> > On Fri, Aug 27, 2021 at 03:41:30PM +0200, Tijl Coosemans wrote:
> >> I use devel/llvm* to build base and just switched to llvm12. It seems
> >> that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
> >> least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
> >> These are converted to R_386_JMP_SLOT relocations by the linker which
> >> aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
> >> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
> >> entries also depend on a base pointer in %ebx but kernel modules aren't
> >> compiled with -fPIC, so this can't work and I suspect this is a
> >> regression in clang12.
> >>
> >> The following code shows the difference between clang11 and clang12:
> >>
> >>
> >> #include
> >>
> >> void *
> >> test_memset(void *p, int c, size_t len) {
> >> return (memset(p, c, len));
> >> }
> >>
> >> void *
> >> test_memcpy(void *dst, const void *src, size_t len) {
> >> return (memcpy(dst, src, len));
> >> }
> >>
> >> void *
> >> test_memmove(void *dst, const void *src, size_t len) {
> >> return (memmove(dst, src, len));
> >> }
> >>
> >>
> >> Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m32":
> >> r_offset r_info r_type st_value st_name
> >> 002c 0504 R_386_PLT32 memset
> >> 0067 0304 R_386_PLT32 memcpy
> >> 00a7 0402 R_386_PC32 memmove
> >>
> >> With clang11:
> >> r_offset r_info r_type st_value st_name
> >> 0036 0502 R_386_PC32 memset
> >> 0083 0302 R_386_PC32 memcpy
> >> 00d2 0402 R_386_PC32 memmove
> >
> > Are you asking (for somebody) to add R_386_JMP_SLOT to i386/elf_machdep.c?
> > Like this, not even built.
> >
> > diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c
> > index 3754b36d9e33..a26a4189e0ee 100644
> > --- a/sys/i386/i386/elf_machdep.c
> > +++ b/sys/i386/i386/elf_machdep.c
> > @@ -245,6 +245,7 @@ elf_reloc_internal(linker_file_t lf, Elf_Addr
> > relocbase, const void *data,
> > break;
> >
> > case R_386_GLOB_DAT:/* S */
> > + case R_386_JMP_SLOT:
> > error = lookup(lf, symidx, 1, );
> > if (error != 0)
> > return (-1);
>
> No, I've tried that. It handles the relocation but callers still don't
> setup %ebx as PIC register. I'm looking for someone to confirm it's a
> compiler bug and not a missing flag or something. I tried -fno-plt and
> that has no effect.
Does disabling -zifunc-noplt fix the problem? I believe it's set by
default for i386.
Re: i386 kernel modules unusable due to .plt sections
On Fri, 27 Aug 2021 17:24:58 +0300 Konstantin Belousov
wrote:
> On Fri, Aug 27, 2021 at 03:41:30PM +0200, Tijl Coosemans wrote:
>> I use devel/llvm* to build base and just switched to llvm12. It seems
>> that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
>> least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
>> These are converted to R_386_JMP_SLOT relocations by the linker which
>> aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
>> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
>> entries also depend on a base pointer in %ebx but kernel modules aren't
>> compiled with -fPIC, so this can't work and I suspect this is a
>> regression in clang12.
>>
>> The following code shows the difference between clang11 and clang12:
>>
>>
>> #include
>>
>> void *
>> test_memset(void *p, int c, size_t len) {
>> return (memset(p, c, len));
>> }
>>
>> void *
>> test_memcpy(void *dst, const void *src, size_t len) {
>> return (memcpy(dst, src, len));
>> }
>>
>> void *
>> test_memmove(void *dst, const void *src, size_t len) {
>> return (memmove(dst, src, len));
>> }
>>
>>
>> Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m32":
>> r_offset r_info r_type st_value st_name
>> 002c 0504 R_386_PLT32 memset
>> 0067 0304 R_386_PLT32 memcpy
>> 00a7 0402 R_386_PC32 memmove
>>
>> With clang11:
>> r_offset r_info r_type st_value st_name
>> 0036 0502 R_386_PC32 memset
>> 0083 0302 R_386_PC32 memcpy
>> 00d2 0402 R_386_PC32 memmove
>
> Are you asking (for somebody) to add R_386_JMP_SLOT to i386/elf_machdep.c?
> Like this, not even built.
>
> diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c
> index 3754b36d9e33..a26a4189e0ee 100644
> --- a/sys/i386/i386/elf_machdep.c
> +++ b/sys/i386/i386/elf_machdep.c
> @@ -245,6 +245,7 @@ elf_reloc_internal(linker_file_t lf, Elf_Addr relocbase,
> const void *data,
> break;
>
> case R_386_GLOB_DAT:/* S */
> + case R_386_JMP_SLOT:
> error = lookup(lf, symidx, 1, );
> if (error != 0)
> return (-1);
No, I've tried that. It handles the relocation but callers still don't
setup %ebx as PIC register. I'm looking for someone to confirm it's a
compiler bug and not a missing flag or something. I tried -fno-plt and
that has no effect.
Re: ZFS crash with -CURRENT from Aug 23rd
On Fri, Aug 27, 2021 at 1:40 PM Jeremie Le Hen wrote: > > Hey, > > I can consistently crash my machine by creating a directory using Samba: > > Tracing pid 57242 tid 270954 td 0xfe01446941e0 > kdb_enter() at kdb_enter+0x37/frame 0xfe0147380210 > vpanic() at vpanic+0x1b2/frame 0xfe0147380260 > spl_panic() at spl_panic+0x3a/frame 0xfe01473802c0 > zfs_sa_get_xattr() at zfs_sa_get_xattr+0x1ac/frame 0xfe0147380300 > zfs_ensure_xattr_cached() at zfs_ensure_xattr_cached+0x6c/frame > 0xfe0147380330 > zfs_deleteextattr_sa() at zfs_deleteextattr_sa+0x1e/frame 0xfe0147380360 > zfs_setextattr() at zfs_setextattr+0x1e3/frame 0xfe01473804e0 > VOP_SETEXTATTR_APV() at VOP_SETEXTATTR_APV+0x40/frame 0xfe0147380500 > null_bypass() at null_bypass+0xf6/frame 0xfe0147380680 > VOP_SETEXTATTR_APV() at VOP_SETEXTATTR_APV+0x40/frame 0xfe01473806a0 > extattr_set_vp() at extattr_set_vp+0x11d/frame 0xfe0147380770 > kern_extattr_set_path() at kern_extattr_set_path+0x181/frame > 0xfe01473809a0 > sys_extattr_set_file() at sys_extattr_set_file+0x29/frame 0xfe01473809c0 > amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0147380af0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0147380af0 > > Let me know if I can provide further information. Actually this may help too Dump header from device: /dev/gptid/25d0ef97-914b-11e4-9b8e-f44d30620eeb Architecture: amd64 Architecture Version: 4 Dump Length: 422400 Blocksize: 512 Compression: none Dumptime: 2021-08-27 11:27:30 +0200 Hostname: obiwan.local Magic: FreeBSD Text Dump Version String: FreeBSD 14.0-CURRENT #7 main-n248866-72a92f91f466: Mon Aug 23 14:24:56 CEST 2021 root@obiwan.local:/usr/obj/usr/src.git/amd64.amd64/sys/OBIWAN Panic String: VERIFY(zp->z_is_sa) failed Dump Parity: 1322125898 Bounds: 3 Dump Status: good -- Jeremie Le Hen j...@freebsd.org
Experiments with sswap(1), srm(1), wipe(1), gdisk(8), lsblk and gpart(8)
On 27/08/2021 12:22, Graham Perrin wrote:
… sswap(1) to securely delete whatever might be there. …
I took an opportunity to experiment with some of the other utilities
that were recently installed by security/secure_delete and
security/wipe. All new to me.
With reference to the attached file, a few points of interest. Some of
it's PEBKAM, I don't mind sharing my mistakes.
I'll report what might be an obscure bug in lsblk.
Line 5, misuse of srm – `srm -lv /dev/da0p3` – was followed by peculiar
output from a run of lsblk. No surprise there.
Lines 131–139, gdisk should have added freebsd-swap at /dev/da0p3, I
ignored the suggestion to remove the hard disk drive ("Warning: The
kernel may continue to use old or deleted partitions."), gpart then
showed nothing (free space) where da0p3 was expected.
Line 152, I used gpart to add freebsd-swap at da0p3.
Lines 288–297, gdisk should have deleted /dev/da0p3, I ignored the
suggestion to remove the drive, lsblk showed da0p3 still present.
Lines 301–359, tail of /var/log/messages whilst I disconnected then
reconnected the multi-purpose dock in which the drive was seated.
Line 375, with nothing in the SD card reader at da0, lsblk showed
freebsd-swap.
Lines 379–383, with the hard disk drive at da4, lsblk showed nothing
(free space) between da4p2 and da4p4 – the preceding deletion by gdisk
was a success.
Lines 418–430, gdisk succesfully added freebsd-swap at /dev/da4p3 – the
partition was detected by lsblk _without_ the need to disconnect then
reconnect the dock.
I disconnected then reconnected the dock, lsblk continues to show what I
might describe as a 'ghost' where truly there's nothing in the SD card
reader at da0.
da0, where previously there was the hard disk drive on the JMicron USB
to ATA/ATAPI bridge.
root@mowa219-gjp4-8570p-freebsd:~ # sswap -lv /dev/da0p3
Error: Target is not a block device - /dev/da0p3
root@mowa219-gjp4-8570p-freebsd:~ # sswap -lv da0p3
Error: Can't open da0p3 for writing.No such file or directory
root@mowa219-gjp4-8570p-freebsd:~ # srm -lv /dev/da0p3
Using /dev/urandom for random input.
Wipe mode is insecure (two passes [0xff/random])
Wiping /dev/da0p3 Warning: /dev/da0p3 is not a regular file, rename/unlink
only!Warning: Couldn't rename /dev/da0p3 - Operation not supported
Removed file /dev/da0p3 ... Done
root@mowa219-gjp4-8570p-freebsd:~ # wipe -nv /dev/da0p3
wipe: cannot stat `/dev/da0p3': No such file or directory
root@mowa219-gjp4-8570p-freebsd:~ # lsblk da0
DEVICE MAJ:MIN SIZE TYPE LABEL
MOUNT
da0 0:181 466G GPT -
-
da0p1 0:184 200M efi msdosfs/EFISYS
-
da0p2 0:188 512K freebsd-boot gpt/gptboot0
-
-:- 492K - -
-
stat: /dev/da0p3: stat: No such file or directory
stat: /dev/da0p3: stat: No such file or directory
da0p316G:freebsd-swap- SWAP
da0p4 0:193 450G freebsd-zfsgpt/zfs0
da0p4.eli 0:196 450G zfs -
-
-:- 4.0K - -
-
root@mowa219-gjp4-8570p-freebsd:~ # gdisk /dev/da0
GPT fdisk (gdisk) version 1.0.8
NOTE: Write test failed with error number 1. It will be impossible to save
changes to this disk's partition table!
You may be able to enable writes by exiting this program, typing
'sysctl kern.geom.debugflags=16' at a shell prompt, and re-running this
program.
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): q
root@mowa219-gjp4-8570p-freebsd:~ # mount | grep da0
root@mowa219-gjp4-8570p-freebsd:~ # gpart show da0
=> 40 976773088 da0 GPT (466G)
40 4096001 efi (200M)
409640 10242 freebsd-boot (512K)
410664984 - free - (492K)
411648 335544323 freebsd-swap (16G)
33966080 9428070404 freebsd-zfs (450G)
976773120 8 - free - (4.0K)
root@mowa219-gjp4-8570p-freebsd:~ # gdisk /dev/da0
GPT fdisk (gdisk) version 1.0.8
NOTE: Write test failed with error number 1. It will be impossible to save
changes to this disk's partition table!
You may be able to enable writes by exiting this program, typing
'sysctl kern.geom.debugflags=16' at a shell prompt, and re-running this
program.
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): q
root@mowa219-gjp4-8570p-freebsd:~ # gpart delete -i 3 da0
da0p3 deleted
root@mowa219-gjp4-8570p-freebsd:~ # gdisk /dev/da0
GPT fdisk (gdisk) version 1.0.8
NOTE: Write
Re: i386 kernel modules unusable due to .plt sections
On Fri, Aug 27, 2021 at 03:41:30PM +0200, Tijl Coosemans wrote:
> Hi,
>
> I use devel/llvm* to build base and just switched to llvm12. It seems
> that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
> least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
> These are converted to R_386_JMP_SLOT relocations by the linker which
> aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
> entries also depend on a base pointer in %ebx but kernel modules aren't
> compiled with -fPIC, so this can't work and I suspect this is a
> regression in clang12.
>
> The following code shows the difference between clang11 and clang12:
>
>
> #include
>
> void *
> test_memset(void *p, int c, size_t len) {
> return (memset(p, c, len));
> }
>
> void *
> test_memcpy(void *dst, const void *src, size_t len) {
> return (memcpy(dst, src, len));
> }
>
> void *
> test_memmove(void *dst, const void *src, size_t len) {
> return (memmove(dst, src, len));
> }
>
>
> Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m32":
> r_offset r_info r_type st_value st_name
> 002c 0504 R_386_PLT32 memset
> 0067 0304 R_386_PLT32 memcpy
> 00a7 0402 R_386_PC32 memmove
>
> With clang11:
> r_offset r_info r_type st_value st_name
> 0036 0502 R_386_PC32 memset
> 0083 0302 R_386_PC32 memcpy
> 00d2 0402 R_386_PC32 memmove
Are you asking (for somebody) to add R_386_JMP_SLOT to i386/elf_machdep.c?
Like this, not even built.
diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c
index 3754b36d9e33..a26a4189e0ee 100644
--- a/sys/i386/i386/elf_machdep.c
+++ b/sys/i386/i386/elf_machdep.c
@@ -245,6 +245,7 @@ elf_reloc_internal(linker_file_t lf, Elf_Addr relocbase,
const void *data,
break;
case R_386_GLOB_DAT:/* S */
+ case R_386_JMP_SLOT:
error = lookup(lf, symidx, 1, );
if (error != 0)
return (-1);
i386 kernel modules unusable due to .plt sections
Hi,
I use devel/llvm* to build base and just switched to llvm12. It seems
that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
These are converted to R_386_JMP_SLOT relocations by the linker which
aren't supported by the kernel, e.g. loading linux.ko gives "kldload:
unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT
entries also depend on a base pointer in %ebx but kernel modules aren't
compiled with -fPIC, so this can't work and I suspect this is a
regression in clang12.
The following code shows the difference between clang11 and clang12:
#include
void *
test_memset(void *p, int c, size_t len) {
return (memset(p, c, len));
}
void *
test_memcpy(void *dst, const void *src, size_t len) {
return (memcpy(dst, src, len));
}
void *
test_memmove(void *dst, const void *src, size_t len) {
return (memmove(dst, src, len));
}
Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m32":
r_offset r_info r_type st_value st_name
002c 0504 R_386_PLT32 memset
0067 0304 R_386_PLT32 memcpy
00a7 0402 R_386_PC32 memmove
With clang11:
r_offset r_info r_type st_value st_name
0036 0502 R_386_PC32 memset
0083 0302 R_386_PC32 memcpy
00d2 0402 R_386_PC32 memmove
ZFS crash with -CURRENT from Aug 23rd
Hey, I can consistently crash my machine by creating a directory using Samba: Tracing pid 57242 tid 270954 td 0xfe01446941e0 kdb_enter() at kdb_enter+0x37/frame 0xfe0147380210 vpanic() at vpanic+0x1b2/frame 0xfe0147380260 spl_panic() at spl_panic+0x3a/frame 0xfe01473802c0 zfs_sa_get_xattr() at zfs_sa_get_xattr+0x1ac/frame 0xfe0147380300 zfs_ensure_xattr_cached() at zfs_ensure_xattr_cached+0x6c/frame 0xfe0147380330 zfs_deleteextattr_sa() at zfs_deleteextattr_sa+0x1e/frame 0xfe0147380360 zfs_setextattr() at zfs_setextattr+0x1e3/frame 0xfe01473804e0 VOP_SETEXTATTR_APV() at VOP_SETEXTATTR_APV+0x40/frame 0xfe0147380500 null_bypass() at null_bypass+0xf6/frame 0xfe0147380680 VOP_SETEXTATTR_APV() at VOP_SETEXTATTR_APV+0x40/frame 0xfe01473806a0 extattr_set_vp() at extattr_set_vp+0x11d/frame 0xfe0147380770 kern_extattr_set_path() at kern_extattr_set_path+0x181/frame 0xfe01473809a0 sys_extattr_set_file() at sys_extattr_set_file+0x29/frame 0xfe01473809c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0147380af0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0147380af0 Let me know if I can provide further information. -- Jeremie Le Hen j...@freebsd.org
dumpdev and encrypted swap
On 27/08/2021 12:22, Graham Perrin wrote: % sysrc dumpdev dumpdev: /dev/ada0p2.eli Correcting myself dumpdev: /dev/ada0p2
Re: Encrypted swap partition no longer encrypted
On 27/08/2021 10:10, Ronald Klop wrote: … change "/dev/ada0p2" to "/dev/ada0p2.eli" in the new fstab and reboot. … Strange, I thought I tried that before writing. One of the first things that I would have tried. Anyhow: now, it has the required effect. An additional mystery. Before replacement of the internal hard disk, I had swap at: /dev/ada0p3.eli With that disk now external, in the dock on USB, metadata can not be read (geli attach fails). I'm happy for this to remain mysterious; assume that non-encrypted data somehow crept in, use sswap(1) to securely delete whatever might be there. % swapinfo Device 1M-blocks Used Avail Capacity /dev/ada0p2.eli 16384 0 16384 0% % sysrc dumpdev dumpdev: /dev/ada0p2.eli % grep swap /etc/fstab | grep -v \# /dev/ada0p2.eli none swap sw,late 0 0 % sudo geli attach /dev/da0p3 grahamperrin's password: geli: Cannot read metadata from /dev/da0p3: Invalid argument. geli: There was an error with at least one provider. % lsblk DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT ada0 0:121 932G GPT - - ada0p1 0:123 260M efi gpt/efiboot0 - -:- 1.0M - - - ada0p2 0:125 16G freebsd-swap gpt/swap0 SWAP ada0p2.eli 2:67 16G freebsd-swap - SWAP ada0p3 0:127 915G freebsd-zfs gpt/zfs0 ada0p3.eli 0:135 915G zfs - - -:- 708K - - - cd0 0:129 0B - - - da0 0:184 466G GPT - - da0p1 0:189 200M efi msdosfs/EFISYS - da0p2 0:192 512K freebsd-boot gpt/gptboot0 - -:- 492K - - - da0p3 0:193 16G freebsd-swap gpt/swap0 SWAP da0p4 0:194 450G freebsd-zfs gpt/zfs0 da0p4.eli 0:198 450G zfs - - -:- 4.0K - - - da1 0:199 0B - - - da2 0:200 0B - - - da3 0:203 0B - - - da4 0:208 0B - - - da5 0:217 466G GPT - - -:- 1.0M - - - da5p1 0:218 466G freebsd-zfs gpt/Transcend da6 0:225 14G GPT - - -:- 1.0M - - - da6p1 0:226 14G freebsd-zfs gpt/cache-transcend da7 0:247 29G GPT - - da7p1 0:248 29G freebsd-zfs gpt/cache-august % sudo geli attach da0p3 geli: Cannot read metadata from da0p3: Invalid argument. geli: There was an error with at least one provider. % fstyp /dev/da0p3 fstyp: /dev/da0p3: filesystem not recognized %
Re: Encrypted swap partition no longer encrypted
On Fri, Aug 27, 2021 at 11:10:26AM +0200, Ronald Klop wrote: > Hi, > > For encrypted swap you can put ".eli" behind the device name in fstab. > > So change "/dev/ada0p2" to "/dev/ada0p2.eli" in the new fstab and reboot. > NB: after encryption is enabled the device is not available as dumpdev > anymore. If one uses "sw,late" in the "Options" field of the swap fstab entry, thus: # DeviceMountpoint FStype Options DumpPass# /dev/ada0s4b.elinoneswapsw,late 0 0 I find that it permits (in this case) /dev/ada0s4b to be used for the dumpdev, whlie using /dev/ada0s4b.eli for swap. (This is for stable/12, stable/13, and head -- though I haven't updated since 10 August.) > ... Peace, david -- David H. Wolfskill da...@catwhisker.org Life is not intended to be a zero-sum game. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Encrypted swap partition no longer encrypted
Hi, For encrypted swap you can put ".eli" behind the device name in fstab. So change "/dev/ada0p2" to "/dev/ada0p2.eli" in the new fstab and reboot. NB: after encryption is enabled the device is not available as dumpdev anymore. I don't know what caused the change for you. Regards, Ronald. Van: Graham Perrin Datum: vrijdag, 27 augustus 2021 09:57 Aan: FreeBSD CURRENT Onderwerp: Encrypted swap partition no longer encrypted Yesterday afternoon I installed FreeBSD-CURRENT to a hard disk drive, whilst it was in a dock on USB, and chose encrypted swap. Then, ZFS send and receive to replicate data from a pool that was on the internal drive. Finally, I replaced the internal drive with the one from the dock. Now: swap is not encrypted, this was not my intention. Might the accident have resulted from an inappropriate change to /etc/fstab followed by a swapon command? I did, at one point, activate and boot the wrong boot environment (because `bectl list -c creation` can no longer show the true (original) dates of creation of boot environments that were replicated). root@mowa219-gjp4-8570p-freebsd:~ # bectl mount default /tmp/huh Successfully mounted default at /tmp/huh root@mowa219-gjp4-8570p-freebsd:~ # cat /tmp/huh/etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/da0p1 /boot/efi msdosfs rw 2 2 /dev/da0p2.eli noneswapsw 0 0 root@mowa219-gjp4-8570p-freebsd:~ # bectl umount default root@mowa219-gjp4-8570p-freebsd:~ # grep swap /etc/fstab | grep -v \# /dev/ada0p2 noneswap sw,late0 0 root@mowa219-gjp4-8570p-freebsd:~ # grep ada0 /etc/rc.conf dumpdev="/dev/ada0p2" root@mowa219-gjp4-8570p-freebsd:~ # bectl list -c creation BE Active Mountpoint Space Created default- - 789M 2021-08-26 16:33 n247565-b49ba74deeb-f - - 39.6G 2021-08-26 19:50 n248685-c9f833abf1d-f NR / 49.3G 2021-08-26 21:13 14.0-CURRENT_2021-08-19_045942 - - 1.09G 2021-08-26 22:41 n248269-941650aae97-e - - 40.5M 2021-08-26 22:54 n247798-f39dd6a9784-a - - 22.9M 2021-08-26 22:54 n248139-3a57f08b504-b - - 1.21G 2021-08-26 22:54 n248478-f3a3b061216-a - - 51.0M 2021-08-26 22:54 14.0-CURRENT_2021-08-08_145838 - - 365M 2021-08-26 22:54 n248269-941650aae97-b - - 524M 2021-08-26 22:54 n248269-941650aae97-f - - 29.3M 2021-08-26 22:54 n248478-f3a3b061216-e - - 579M 2021-08-26 22:54 n248478-f3a3b061216-b - - 56.7M 2021-08-26 22:55 n247798-f39dd6a9784-e - - 328M 2021-08-26 22:55 n248269-941650aae97-d - - 260M 2021-08-26 22:55 n248685-c9f833abf1d-e - - 216M 2021-08-26 22:55 n247798-f39dd6a9784-j - - 4.98G 2021-08-26 22:55 n248478-f3a3b061216-d - - 310M 2021-08-26 22:55 n248478-f3a3b061216-c - - 101M 2021-08-26 22:55 root@mowa219-gjp4-8570p-freebsd:~ # bectl list | sort 14.0-CURRENT_2021-08-08_145838 - - 365M 2021-08-26 22:54 14.0-CURRENT_2021-08-19_045942 - - 1.09G 2021-08-26 22:41 BE Active Mountpoint Space Created default- - 789M 2021-08-26 16:33 n247565-b49ba74deeb-f - - 39.6G 2021-08-26 19:50 n247798-f39dd6a9784-a - - 22.9M 2021-08-26 22:54 n247798-f39dd6a9784-e - - 328M 2021-08-26 22:55 n247798-f39dd6a9784-j - - 4.98G 2021-08-26 22:55 n248139-3a57f08b504-b - - 1.21G 2021-08-26 22:54 n248269-941650aae97-b - - 524M 2021-08-26 22:54 n248269-941650aae97-d - - 260M 2021-08-26 22:55 n248269-941650aae97-e - - 40.5M 2021-08-26 22:54 n248269-941650aae97-f - - 29.3M 2021-08-26 22:54 n248478-f3a3b061216-a - - 51.0M 2021-08-26 22:54 n248478-f3a3b061216-b - - 56.7M 2021-08-26 22:55 n248478-f3a3b061216-c - - 101M 2021-08-26 22:55 n248478-f3a3b061216-d - - 310M 2021-08-26 22:55 n248478-f3a3b061216-e - - 579M 2021-08-26 22:54 n248685-c9f833abf1d-e - - 216M 2021-08-26 22:55 n248685-c9f833abf1d-f NR / 49.3G 2021-08-26 21:13 root@mowa219-gjp4-8570p-freebsd:~ # uname -KU 1400030 1400030 root@mowa219-gjp4-8570p-freebsd:~ # uname -a FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #105 main-n248685-c9f833abf1d: Fri Aug 13 20:24:43 BST 2021
Encrypted swap partition no longer encrypted
Yesterday afternoon I installed FreeBSD-CURRENT to a hard disk drive, whilst it was in a dock on USB, and chose encrypted swap. Then, ZFS send and receive to replicate data from a pool that was on the internal drive. Finally, I replaced the internal drive with the one from the dock. Now: swap is not encrypted, this was not my intention. Might the accident have resulted from an inappropriate change to /etc/fstab followed by a swapon command? I did, at one point, activate and boot the wrong boot environment (because `bectl list -c creation` can no longer show the true (original) dates of creation of boot environments that were replicated). root@mowa219-gjp4-8570p-freebsd:~ # bectl mount default /tmp/huh Successfully mounted default at /tmp/huh root@mowa219-gjp4-8570p-freebsd:~ # cat /tmp/huh/etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/da0p1 /boot/efi msdosfs rw 2 2 /dev/da0p2.eli none swap sw 0 0 root@mowa219-gjp4-8570p-freebsd:~ # bectl umount default root@mowa219-gjp4-8570p-freebsd:~ # grep swap /etc/fstab | grep -v \# /dev/ada0p2 none swap sw,late 0 0 root@mowa219-gjp4-8570p-freebsd:~ # grep ada0 /etc/rc.conf dumpdev="/dev/ada0p2" root@mowa219-gjp4-8570p-freebsd:~ # bectl list -c creation BE Active Mountpoint Space Created default - - 789M 2021-08-26 16:33 n247565-b49ba74deeb-f - - 39.6G 2021-08-26 19:50 n248685-c9f833abf1d-f NR / 49.3G 2021-08-26 21:13 14.0-CURRENT_2021-08-19_045942 - - 1.09G 2021-08-26 22:41 n248269-941650aae97-e - - 40.5M 2021-08-26 22:54 n247798-f39dd6a9784-a - - 22.9M 2021-08-26 22:54 n248139-3a57f08b504-b - - 1.21G 2021-08-26 22:54 n248478-f3a3b061216-a - - 51.0M 2021-08-26 22:54 14.0-CURRENT_2021-08-08_145838 - - 365M 2021-08-26 22:54 n248269-941650aae97-b - - 524M 2021-08-26 22:54 n248269-941650aae97-f - - 29.3M 2021-08-26 22:54 n248478-f3a3b061216-e - - 579M 2021-08-26 22:54 n248478-f3a3b061216-b - - 56.7M 2021-08-26 22:55 n247798-f39dd6a9784-e - - 328M 2021-08-26 22:55 n248269-941650aae97-d - - 260M 2021-08-26 22:55 n248685-c9f833abf1d-e - - 216M 2021-08-26 22:55 n247798-f39dd6a9784-j - - 4.98G 2021-08-26 22:55 n248478-f3a3b061216-d - - 310M 2021-08-26 22:55 n248478-f3a3b061216-c - - 101M 2021-08-26 22:55 root@mowa219-gjp4-8570p-freebsd:~ # bectl list | sort 14.0-CURRENT_2021-08-08_145838 - - 365M 2021-08-26 22:54 14.0-CURRENT_2021-08-19_045942 - - 1.09G 2021-08-26 22:41 BE Active Mountpoint Space Created default - - 789M 2021-08-26 16:33 n247565-b49ba74deeb-f - - 39.6G 2021-08-26 19:50 n247798-f39dd6a9784-a - - 22.9M 2021-08-26 22:54 n247798-f39dd6a9784-e - - 328M 2021-08-26 22:55 n247798-f39dd6a9784-j - - 4.98G 2021-08-26 22:55 n248139-3a57f08b504-b - - 1.21G 2021-08-26 22:54 n248269-941650aae97-b - - 524M 2021-08-26 22:54 n248269-941650aae97-d - - 260M 2021-08-26 22:55 n248269-941650aae97-e - - 40.5M 2021-08-26 22:54 n248269-941650aae97-f - - 29.3M 2021-08-26 22:54 n248478-f3a3b061216-a - - 51.0M 2021-08-26 22:54 n248478-f3a3b061216-b - - 56.7M 2021-08-26 22:55 n248478-f3a3b061216-c - - 101M 2021-08-26 22:55 n248478-f3a3b061216-d - - 310M 2021-08-26 22:55 n248478-f3a3b061216-e - - 579M 2021-08-26 22:54 n248685-c9f833abf1d-e - - 216M 2021-08-26 22:55 n248685-c9f833abf1d-f NR / 49.3G 2021-08-26 21:13 root@mowa219-gjp4-8570p-freebsd:~ # uname -KU 1400030 1400030 root@mowa219-gjp4-8570p-freebsd:~ # uname -a FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #105 main-n248685-c9f833abf1d: Fri Aug 13 20:24:43 BST 2021 root@mowa219-gjp4-zbook-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 root@mowa219-gjp4-8570p-freebsd:~ #
