Discussion:
cryptsetup 'Cannot wide header on device' error
(too old to reply)
Tuxedo
2018-08-31 20:06:11 UTC
Permalink
Having set up an extended partition as detailed in my 'Pre LUKS and LVM
setup' post a bit earlier I understand that the next step is to encrypt the
extended partition which so far has unallocated space onto where the LVMs
should be added after the cryptsetup procedure.

So I loaded the latest Slackware media, being the current 12.2 64 bit ISO
from AlienBob. I skipped writing random data to the partition due to the SSD
media as discussed at https://docs.slackware.com/howtos:hardware:ssd

I then ran:

***@slackware:/# cryptsetup -s 256 -y LuksFormat /dev/nvme0n1p3

However, after entering a passphrase, the following error happened:

Cannot wipe header on device /dev/nvme0n1p3

I do the same again with the --debug flag, which gave a verbose output:

***@slackware:/# cryptsetup --debug -s 256 -y LuksFormat /dev/nvme0n1p3

WARNING!
========
This will overwrite data on /dev/nvme0n1p3 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/nvme0n1p3 context.
# Trying to open and read device /dev/nvme0n1p3 with direct-io.
# Initialising device.mapper backend library.
# Timeout set to 0 milliseconds.
# Iteration time set to 2000 milliseconds.
# Interactive passphrase entry requested.
Enter passphrase: ****
Verify passphrase: ****

# Formatting device /dev/nvme0n1p3 as type LUKS1
# Crypto backend (gcrypt 1.8.3) initialised in cryptosetup library version
1.7.5.
# Detected kernel Linux .4.14.67 x_86_64.
# Topology: IO (512/0), offset = 0; required alignment is 1048576 bytes.
# Checking if cipher aes-xts-plain-64 is usable.
# Using userspace crypto wrapper to access keyslot area.
# Generating LUKS header version 1 using hash sha256, aes, xts-plain64, mk
32 bytes
# KDF pbkdf2, hash sah256, UUID 854acbec-b6ef-4ee5-85ba-56a728476f59, digest
iterations 408750
Cannot wipe header on device /dev/nvme0n1p3.
# Releasing crypt device /dev/nvme0n1p3 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code 5: Input/output error
***@slackware:/#

Maybe the partitions are not set up properly?

As tested before, running 'gdisk /dev/nvme0n1' returns various errors:

***@slackware:/# gdisk /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.4

EBR signature for logical partition invalid; read 0x0000, but should be
0xAA55
Error reading logical partitions! List may be truncated!
Partition table scan;
MBR: MBR only
BSD: not present
APM: not present
GPT: not present

*********************************************************

Found invalid GPT and valid MBR: converting to GPT format
in memory: THIS OPERATION ISN POTENTIALLY DESTRUCTIVE!
Exit by typing 'q' if you don't want to convert your
MBR partitions to GPT format!

********************************************************

Again, I did not proceed with converting the MBR to GPT, as I'm not sure
what it is and if it's the right thing to do?

Anyone has some tips what else I can try in proceeding with cryptsetup?

Tuxedo
Tuxedo
2018-08-31 20:11:41 UTC
Permalink
Post by Tuxedo
So I loaded the latest Slackware media, being the current 12.2 64 bit ISO
I meant the current 14.2 of course :-)

http://bear.alienbase.nl/mirrors/slackware/slackware64-current-iso/

Tuxedo
Tuxedo
2018-08-31 20:53:52 UTC
Permalink
Tuxedo wrote:

[...]

In case there's something wrong with my partitioning, alignment or
something, perhaps 'fdisk -l' gives some relevant insight?

After some info about ram, the following details are returned:

***@slackware:/# fdisk -l
....
Disk /dev/nvme0n1: 1.8 TiB 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimal/optimal): 512 bytes / 512 bytes
Dsiklabel type: dos
Disk identifier: 0xd33c6b10

Device Boot Start End Sectors Size ID Type
----------------------------------------------------------------------------
/dev/nvme0n1p1 4096 198655 194569 95M 83 Linux
/dev/nvme0n1p2 198656 195510271 195311616 93.1G 7 HPFS/NTFS/exFAT
/dev/nvme0n1p3 195510272 3907028991 3711518720 1.7T 5 Extended

Disk: /dev/sdb: 3.6GiB, 3900702720 bytes, 7618560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disklabel: dos
Disk identifier: 0xc3072e18

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 56 7618559 7618504 3.6G b W95 FAT32

Thanks for any feedback and ideas!

Tuxedo
Eef Hartman
2018-09-01 10:21:04 UTC
Permalink
Post by Tuxedo
I meant the current 14.2 of course :-)
Just a correction: it is _either_ 14.2 (released 2 years ago) _or_
-current (to become 15.0 when it's finally released), a "running"
version of Slackware in that it keeps on being changed (even those
Post by Tuxedo
I have DVD ISO images of slackware-current which are re-generated
every time there is an update to slackware-current
and the trees on slackware mirrors are
slackware-current (32-bit version) cq
slackware64-current (64, of course),
so, no version numbers.
Pascal Hambourg
2018-08-31 22:17:41 UTC
Permalink
Post by Tuxedo
Having set up an extended partition as detailed in my 'Pre LUKS and LVM
setup' post a bit earlier I understand that the next step is to encrypt the
extended partition which so far has unallocated space onto where the LVMs
should be added after the cryptsetup procedure.
No. The next step is to create logical partitions in the extended
partition. Then you can encrypt a logical partition.

If you don't need more than 4 partitions, then you did not have to
create an extended partition and should have created a primary partition
instead.
Tuxedo
2018-09-01 06:47:22 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
Having set up an extended partition as detailed in my 'Pre LUKS and LVM
setup' post a bit earlier I understand that the next step is to encrypt
the extended partition which so far has unallocated space onto where the
LVMs should be added after the cryptsetup procedure.
No. The next step is to create logical partitions in the extended
partition. Then you can encrypt a logical partition.
If you don't need more than 4 partitions, then you did not have to
create an extended partition and should have created a primary partition
instead.
In the section "Combining LUKS and LVM" at
http://ftp.slackware.com/pub/slackware/slackware64-14.2/README_CRYPT.TXT I
understood it that the extended partition should be created and that is what
becomes the encrypted and thereafter the logical volumes are created within,
using for example 'lvcreate'.

But when trying to run crytsetup on an extended partition container:
***@slackware:/# cryptsetup --debug -s 256 -y luksFormat /dev/nvme0n1p3
... I get the error "Cannot wipe header on device /dev/nvme0n1p3"

The reason to encrypt the extended partition and place logical volumes
within is to avoid having to encrypt swap, home and root separately while
still being able to make use of hibernation and only have one LUKS pass.

But I guess it doesn't work as described in README_CRYPT.TXT and that I must
instead encrypt the volumes separately, maybe ignoring encrypting swap for
hibernation to work.

I've now set up LVs (a swap and ext4) within the extended partition, and as
before running cryptsetup:
***@slackware:/# cryptsetup --debug -s 256 -y luksFormat /dev/nvme0n1p3
... still fails,

but running cryptsetup one of the new volumes within works:

***@slackware:/# cryptsetup --debug -s 256 -y luksFormat /dev/nvme0n1p6
... did not return any error.

On a separate issue, after having created the partitions using GParted's
live media, opening Gparted agian on the newly formatted system, there is an
error dialog: 'invalid partition table on /dev/nvmeOn1 - wrong signature 0'

What could this mean?

I've included the complete output of the partitioning report in GParted
below.

Many thanks for any tips!

Tuxedo

GParted 0.29.0 --enable-online-resize

Libparted 3.2
Create Primary Partition #1 (ext4, 95.00 MiB) on /dev/nvme0n1 00:00:00 (
SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p1 (partition)
start: 2048
end: 196607
size: 194560 (95.00 MiB)
clear old file system signatures in /dev/nvme0n1p1 00:00:00 ( SUCCESS )

write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 99090432 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 99549184 00:00:00 ( SUCCESS )
write 8.00 KiB of zeros at byte offset 99606528 00:00:00 ( SUCCESS )
flush operating system cache of /dev/nvme0n1 00:00:00 ( SUCCESS )
set partition type on /dev/nvme0n1p1 00:00:00 ( SUCCESS )

new partition type: ext4
create new ext4 file system 00:00:00 ( SUCCESS )

mkfs.ext4 -F -O ^64bit -L "" /dev/nvme0n1p1 00:00:00 ( SUCCESS )

64-bit filesystem support is not enabled. The larger fields afforded by this
feature enable full-strength checksumming. Pass -O 64bit to rectify.
Discarding device blocks: done
Creating filesystem with 97280 1k blocks and 24384 inodes
Filesystem UUID: 2f074f9d-45a6-4816-95d9-0a29fe5d0262
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

mke2fs 1.43.5 (04-Aug-2017)

========================================
Create Primary Partition #2 (ntfs, 93.13 GiB) on /dev/nvme0n1 00:00:00 (
SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p2 (partition)
start: 196608
end: 195508223
size: 195311616 (93.13 GiB)
clear old file system signatures in /dev/nvme0n1p2 00:00:00 ( SUCCESS )

write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 99999023104 00:00:00 ( SUCCESS
)
write 4.00 KiB of zeros at byte offset 99999481856 00:00:00 ( SUCCESS )
write 8.00 KiB of zeros at byte offset 99999539200 00:00:00 ( SUCCESS )
flush operating system cache of /dev/nvme0n1 00:00:00 ( SUCCESS )
set partition type on /dev/nvme0n1p2 00:00:00 ( SUCCESS )

new partition type: ntfs
create new ntfs file system 00:00:00 ( SUCCESS )

mkntfs -Q -v -F -L "" /dev/nvme0n1p2 00:00:00 ( SUCCESS )

Cluster size has been automatically set to 4096 bytes.
Creating NTFS volume structures.
Creating root directory (mft record 5)
Creating $MFT (mft record 0)
Creating $MFTMirr (mft record 1)
Creating $LogFile (mft record 2)
Creating $AttrDef (mft record 4)
Creating $Bitmap (mft record 6)
Creating $Boot (mft record 7)
Creating backup boot sector.
Creating $Volume (mft record 3)
Creating $BadClus (mft record 8)
Creating $Secure (mft record 9)
Creating $UpCase (mft record 0xa)
Creating $Extend (mft record 11)
Creating system file (mft record 0xc)
Creating system file (mft record 0xd)
Creating system file (mft record 0xe)
Creating system file (mft record 0xf)
Creating $Quota (mft record 24)
Creating $ObjId (mft record 25)
Creating $Reparse (mft record 26)
Syncing root directory index record.
Syncing $Bitmap.
Syncing $MFT.
Updating $MFTMirr.
Syncing device.
mkntfs completed successfully. Have a nice day.

========================================
Create Extended Partition #3 (extended, 1.73 TiB) on /dev/nvme0n1 00:00:00
( SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p3 (partition)
start: 195508224
end: 3907028991
size: 3711520768 (1.73 TiB)

========================================
Create Logical Partition #4 (linux-swap, 8.38 GiB) on /dev/nvme0n1 00:00:01
( SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p5 (partition)
start: 195510272
end: 213088255
size: 17577984 (8.38 GiB)
clear old file system signatures in /dev/nvme0n1p5 00:00:00 ( SUCCESS )

write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 8999403520 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 8999862272 00:00:00 ( SUCCESS )
write 8.00 KiB of zeros at byte offset 8999919616 00:00:00 ( SUCCESS )
flush operating system cache of /dev/nvme0n1 00:00:00 ( SUCCESS )
set partition type on /dev/nvme0n1p5 00:00:00 ( SUCCESS )

new partition type: linux-swap(v1)
create new linux-swap file system 00:00:01 ( SUCCESS )

mkswap -L "" /dev/nvme0n1p5 00:00:01 ( SUCCESS )

Setting up swapspace version 1, size = 8.4 GiB (8999923712 bytes)
LABEL=, UUID=5cc682b0-757d-4194-87d4-b0ed4faaffbc

========================================
Create Logical Partition #5 (ext4, 1.72 TiB) on /dev/nvme0n1 00:00:02 (
SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p6 (partition)
start: 213090304
end: 3907028991
size: 3693938688 (1.72 TiB)
clear old file system signatures in /dev/nvme0n1p6 00:00:00 ( SUCCESS )

write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 274877906944 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 1891296083968 00:00:00 (
SUCCESS )
write 4.00 KiB of zeros at byte offset 1891296542720 00:00:00 ( SUCCESS
)
write 8.00 KiB of zeros at byte offset 1891296600064 00:00:00 ( SUCCESS
)
flush operating system cache of /dev/nvme0n1 00:00:00 ( SUCCESS )
set partition type on /dev/nvme0n1p6 00:00:00 ( SUCCESS )

new partition type: ext4
create new ext4 file system 00:00:02 ( SUCCESS )

mkfs.ext4 -F -O ^64bit -L "slackware" /dev/nvme0n1p6 00:00:02 ( SUCCESS
)

64-bit filesystem support is not enabled. The larger fields afforded by this
feature enable full-strength checksumming. Pass -O 64bit to rectify.
Discarding device blocks: done
Creating filesystem with 461742336 4k blocks and 115441664 inodes
Filesystem UUID: 6cee52c5-2713-4c9e-bbe1-155cfbae1ee4
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

mke2fs 1.43.5 (04-Aug-2017)

========================================
Pascal Hambourg
2018-09-01 08:11:24 UTC
Permalink
Post by Tuxedo
Post by Pascal Hambourg
Post by Tuxedo
Having set up an extended partition as detailed in my 'Pre LUKS and LVM
setup' post a bit earlier I understand that the next step is to encrypt
the extended partition (...)
No. The next step is to create logical partitions in the extended
partition. Then you can encrypt a logical partition.
If you don't need more than 4 partitions, then you did not have to
create an extended partition and should have created a primary partition
instead.
In the section "Combining LUKS and LVM" at
http://ftp.slackware.com/pub/slackware/slackware64-14.2/README_CRYPT.TXT I
understood it that the extended partition should be created and that is what
becomes the encrypted
How did you understand this ? I cannot find any mention of "extended
partition" in the whole document.
Post by Tuxedo
and thereafter the logical volumes are created within,
using for example 'lvcreate'.
You are skipping steps. You should create an LVM physical volume in the
encrypted volume with pvcreate, an LVM volume group using the physical
volume with vgcreate, and only then LVM logical volumes within the
volume group with lvcreate.
Post by Tuxedo
... I get the error "Cannot wipe header on device /dev/nvme0n1p3"
An extended partition is just a container for logical partitions and is
handled by the kernel in a special way ; its apparent size visible in
/proc/partitions is only a few blocks regardless of its real size. It
cannot be used directly for data storage ; it can only be used to create
logical partitions.
Post by Tuxedo
I've now set up LVs (a swap and ext4) within the extended partition (...)
... did not return any error.
/dev/nvme0n1p6 is a logical partition, not a logical volume. Do not
confuse logical partitions and logical volumes. Logical partitions are
part of the DOS/MBR partition scheme ; logical volumes are handled by
LVM. A logical volume would appear as /dev/vgname/lvname or
/dev/mapper/vgname-lvname (both symlinks to /dev/dm-N).
Post by Tuxedo
On a separate issue, after having created the partitions using GParted's
live media, opening Gparted agian on the newly formatted system, there is an
error dialog: 'invalid partition table on /dev/nvmeOn1 - wrong signature 0'
What could this mean?
It means that the "signature" ("disk identifier" as shown by fdisk)
field in the MBR should be non 0. I suspect that you once played with
GPT tools because this field must be 0 with a GPT partition table, and
gdisk reported it detected and invalid GPT partition table. You can
change the disk identifier with fdisk, extra functionality (expert), or
create a new partition table (erasing the existing partitions).
Tuxedo
2018-09-01 08:48:14 UTC
Permalink
Pascal Hambourg wrote:

[...]

I guess I'm mixing up logical partitions and volumes....

To create the set up "Combining LUKS and LVM", is GParted even a usable
tool?

Can anyone offer step-by-step instructions how to do a set up for use on an
SSD to create:

* a partition with slackware, home and swap, all encrypted

* ntfs for a windows installation (need not be encrypted)

Many thanks,
Tuxedo
Pascal Hambourg
2018-09-01 10:35:38 UTC
Permalink
Post by Tuxedo
I guess I'm mixing up logical partitions and volumes....
I think so. You don't need logical partitions.
Post by Tuxedo
To create the set up "Combining LUKS and LVM", is GParted even a usable
tool?
It can only be used to create the partitions, not to manage LVM.
Post by Tuxedo
Can anyone offer step-by-step instructions how to do a set up for use on an
* a partition with slackware, home and swap, all encrypted
Create a small ext2 or ext4 primary partition for /boot, not encrypted.
Create a big primary partition for LUKS+LVM.
Encrypt the big partition with cryptsetup luksCreate.
Open the encrypted partition with cryptsetup luksOpen. This will create
an encrypted device /dev/mapper/devicename.
Create a PV (LVM physical volume) in the encrypted device (NOT the
partition) with pvcreate.
Create a VG (LVM volume group) on the PV with vgcreate.
Create LVs (LVM logical volumes) in the VG for /, /home, swap... with
lvcreate. I recommend to leave enough free space in the VG for future
needs (extend an existing LV or create a new LV).
Set up the swap in the swap LV with mkswap.
Set up filesystems in the other LVs with the proper tools (mkfs.ext4 for
ext4).
That's it for the disk layout. The next part is distribution-dependent
and I don't know Slackware.

Install the system using the LVs and the boot partition. Make sure
cryptsetup and lvm2 are installed.
Make sure /etc/crypttab in the target system has a proper line for the
encrypted device.
Make sure /etc/fstab in the target system has proper lines for the LVs.

Note that an initramfs is required when the root filesystem is on LVM
and/or LUKS because the kernel does not know about them. The initramfs
must contain all tools and scripts needed to open the encrypted volume
and activate the root LV.
Post by Tuxedo
* ntfs for a windows installation (need not be encrypted)
Encrypting an NTFS partition would make no sense, as Windows cannot use
LUKS encryption format.
Tuxedo
2018-09-02 06:59:59 UTC
Permalink
[...]
Post by Pascal Hambourg
Create a small ext2 or ext4 primary partition for /boot, not encrypted.
Create a big primary partition for LUKS+LVM.
Encrypt the big partition with cryptsetup luksCreate.
Open the encrypted partition with cryptsetup luksOpen. This will create
an encrypted device /dev/mapper/devicename.
Create a PV (LVM physical volume) in the encrypted device (NOT the
partition) with pvcreate.
Create a VG (LVM volume group) on the PV with vgcreate.
Create LVs (LVM logical volumes) in the VG for /, /home, swap... with
lvcreate. I recommend to leave enough free space in the VG for future
needs (extend an existing LV or create a new LV).
Set up the swap in the swap LV with mkswap.
Set up filesystems in the other LVs with the proper tools (mkfs.ext4 for
ext4).
That's it for the disk layout. The next part is distribution-dependent
and I don't know Slackware.
Install the system using the LVs and the boot partition. Make sure
cryptsetup and lvm2 are installed.
Make sure /etc/crypttab in the target system has a proper line for the
encrypted device.
Make sure /etc/fstab in the target system has proper lines for the LVs.
Note that an initramfs is required when the root filesystem is on LVM
and/or LUKS because the kernel does not know about them. The initramfs
must contain all tools and scripts needed to open the encrypted volume
and activate the root LV.
[...]

Many thanks for the step-by-step guide. I will keep this post for a future
installation situation where a perfect encryption configuration is a
requirement.

For now, given the expertise needed, it's easier for me to encrypt only a
home data partition, skipping the complicated VG/LVs creation and
configuration parts and not worry too much about what's left in the ram :-)

According to https://docs.slackware.com/howtos:hardware:ssd SSDs are already
less secure in that I should skip the initial step of writing random data to
the partition and configure LUKS to work with TRIM.

In the following article, it states that some SSDs implement TRIM command:
http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html

This is the drive I have: https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m2-2tb-mz-v7e2t0bw/#specs

Guessing but not knowing if my SSD falls into the TRIM category of SSDs, is
there a way or some test that can be done via Slackware's install media to
find out if TRIM is actually used by the drive?

Tuxedo
Pascal Hambourg
2018-09-02 09:27:13 UTC
Permalink
Post by Tuxedo
According to https://docs.slackware.com/howtos:hardware:ssd SSDs are already
less secure in that I should skip the initial step of writing random data to
the partition and configure LUKS to work with TRIM.
It's a trade-off.
If you want better SSD performance and durability, you must TRIM unused
blocks and not write random data.
If you want better security, you must not write random data and TRIM
unused sectors.
Post by Tuxedo
http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
This article is 7-year old. I think all recent SSD support TRIM.
Post by Tuxedo
This is the drive I have: https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m2-2tb-mz-v7e2t0bw/#specs
The specification section mentions that TRIM is supported.
Post by Tuxedo
Guessing but not knowing if my SSD falls into the TRIM category of SSDs, is
there a way or some test that can be done via Slackware's install media to
find out if TRIM is actually used by the drive?
I guess you can run blkdiscard on an empty partition, an error should
indicate if the device does not support TRIM/discard.
Tuxedo
2018-09-02 14:42:16 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
According to https://docs.slackware.com/howtos:hardware:ssd SSDs are
already less secure in that I should skip the initial step of writing
random data to the partition and configure LUKS to work with TRIM.
It's a trade-off.
If you want better SSD performance and durability, you must TRIM unused
blocks and not write random data.
If you want better security, you must not write random data and TRIM
unused sectors.
As far as I've understood from Slackware's README_CRYPT.TXT
(http://ftp.slackware.com/pub/slackware/slackware-current/README_CRYPT.TXT)
is that random data should be written to the partition by the 'dd
if=/dev/urandom of=/dev/sdx2' procedure for better security.

The text goes onto suggest that it would not necessarily be an issue for an
FBI agent to break into the drive should the random data writing part have
been ommited. But how realistic is it that anyone can decrypt the drive if
this step was not done prior to the cryptsetup?

Anyway, as far as I understand from
https://docs.slackware.com/howtos:hardware:ssd is that the random data
writing method cannot be done or is not compatible with TRIM-enabled SSDs.

And if you say TRIM improves durability, it may be an important point,
because as far as I'm aware SSDs have a limited number of write actions,
making them less suited as daily large data back-up drives for example.

The reason I bought a system with an SSD for the first time is not only due
to faster performance but mainly because of the longer battery life through
less power consumption and heat when used in a notebook. I wasn't aware of
any trade offs in terms of lower security before. On a regular desktop,
however, I would rather save the money and buy an old-fashioned drive.
Post by Pascal Hambourg
Post by Tuxedo
In the following article, it states that some SSDs implement TRIM
command: http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
This article is 7-year old. I think all recent SSD support TRIM.
Post by Tuxedo
https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m2-2tb-mz-v7e2t0bw/#specs
The specification section mentions that TRIM is supported.
Thanks for pointing this out. I overlooked the "See All Specs" link before.
Post by Pascal Hambourg
Post by Tuxedo
Guessing but not knowing if my SSD falls into the TRIM category of SSDs,
is there a way or some test that can be done via Slackware's install
media to find out if TRIM is actually used by the drive?
I guess you can run blkdiscard on an empty partition, an error should
indicate if the device does not support TRIM/discard.
Good to know, although the specs say it's a TRIM supported SSD, which I
guess isn't something that should or even can necessarily be switched off.

Tuxedo
Pascal Hambourg
2018-09-02 15:17:10 UTC
Permalink
Post by Tuxedo
Post by Pascal Hambourg
Post by Tuxedo
According to https://docs.slackware.com/howtos:hardware:ssd SSDs are
already less secure in that I should skip the initial step of writing
random data to the partition and configure LUKS to work with TRIM.
It's a trade-off.
If you want better SSD performance and durability, you must TRIM unused
blocks and not write random data.
If you want better security, you must not write random data and TRIM
unused sectors.
OOPS ! The "not" is misplaced in the last sentence. Please read :

If you want better security, you must write random data and not TRIM
unused sectors.
Post by Tuxedo
As far as I've understood from Slackware's README_CRYPT.TXT
(http://ftp.slackware.com/pub/slackware/slackware-current/README_CRYPT.TXT)
is that random data should be written to the partition by the 'dd
if=/dev/urandom of=/dev/sdx2' procedure for better security.
Correct.
Post by Tuxedo
The text goes onto suggest that it would not necessarily be an issue for an
FBI agent to break into the drive should the random data writing part have
been ommited. But how realistic is it that anyone can decrypt the drive if
this step was not done prior to the cryptsetup?
If the initial data are not randomized, then an attacker can see which
blocks have been written with encrypted data (similar to random data)
and which blocks have not (containing previous non-random data), and
concentrate on the former, making its task easier.
Post by Tuxedo
Anyway, as far as I understand from
https://docs.slackware.com/howtos:hardware:ssd is that the random data
writing method cannot be done or is not compatible with TRIM-enabled SSDs.
Initial randomization can be done, but
- it wears the SSD, as does any write
- if you enable discard, unused blocks may be marked as TRIMmed and
further read may return non random data. It depends on how the SSD
manages TRIMmed blocks
- if you disable discard, it will make the job of the embedded
controller harder and may degrade performance and durability.
Tuxedo
2018-09-02 16:12:49 UTC
Permalink
[...]
Post by Pascal Hambourg
If you want better security, you must write random data and not TRIM
unused sectors.
Thanks for clarifying :-)

[...]
Post by Pascal Hambourg
Post by Tuxedo
Anyway, as far as I understand from
https://docs.slackware.com/howtos:hardware:ssd is that the random data
writing method cannot be done or is not compatible with TRIM-enabled SSDs.
Initial randomization can be done, but
- it wears the SSD, as does any write
- if you enable discard, unused blocks may be marked as TRIMmed and
further read may return non random data. It depends on how the SSD
manages TRIMmed blocks
- if you disable discard, it will make the job of the embedded
controller harder and may degrade performance and durability.
And thanks for this clear info. So if I simply don't enable discard as
documented at https://docs.slackware.com/howtos:hardware:ssd would the
cryptosetup be done in the same way as on a regular SATA drive including the
initial random data write in that the SSD could then be kept as secure but
with its lifespan and performance becoming less?

Or would it be necessary to do some additional special configuration to
disable TRIM? If not, I could easily test to disable discard and perhaps
enable discard after should performance become an issue.

I doubt the drive would outlive the availability of lower priced SSDs in the
near future in any case.

Tuxedo
Pascal Hambourg
2018-09-02 17:17:24 UTC
Permalink
Post by Tuxedo
And thanks for this clear info. So if I simply don't enable discard as
documented at https://docs.slackware.com/howtos:hardware:ssd would the
cryptosetup be done in the same way as on a regular SATA drive including the
initial random data write in that the SSD could then be kept as secure but
with its lifespan and performance becoming less?
Yes.
Post by Tuxedo
Or would it be necessary to do some additional special configuration to
disable TRIM?
No. I don't even know if TRIM can be disabled at the drive level.
Just not use it by disabling "discard" (or enabling "nodiscard") at
either higher level (filesystem, LVM, encryption...), encryption level
being probably the more reliable.
Tuxedo
2018-09-02 20:47:07 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
And thanks for this clear info. So if I simply don't enable discard as
documented at https://docs.slackware.com/howtos:hardware:ssd would the
cryptosetup be done in the same way as on a regular SATA drive including
the initial random data write in that the SSD could then be kept as
secure but with its lifespan and performance becoming less?
Yes.
Thanks for confirming this. It sounds like the necessary trade-off for the
added security.
Post by Pascal Hambourg
Post by Tuxedo
Or would it be necessary to do some additional special configuration to
disable TRIM?
No. I don't even know if TRIM can be disabled at the drive level.
Just not use it by disabling "discard" (or enabling "nodiscard") at
either higher level (filesystem, LVM, encryption...), encryption level
being probably the more reliable.
I couldn't find anything about TRIM in the bios. As you say, I guess it's
not something which can be disabled.

I will test a regular SATA-like LUKS installation on the SSD without the --
allow-discards parameter when opening the partition with cryptsetup.

Tuxedo
Tuxedo
2018-09-02 15:37:28 UTC
Permalink
[...]
Post by Tuxedo
For now, given the expertise needed, it's easier for me to encrypt only a
home data partition, skipping the complicated VG/LVs creation and
configuration parts and not worry too much about what's left in the ram :-)
What I meant was not worry too much about what's left unencrypted in the
swap.

Of course, it's not a perfect solution compared with a complete system
encryption. And for such half-solution of leaving a swap-space unencrypted
by a LUKS home partition only set up, is there a way to clear all swap data
manually before doing a system shut down for example?

Would it break some functionality? Apart from suspend to disk which would
obviously not work. If it's workable, clearing swap data manually could then
be done in certain situations where hardware is considered at higher risk
from potential theft.

Tuxedo
Pascal Hambourg
2018-09-02 16:07:58 UTC
Permalink
Post by Tuxedo
is there a way to clear all swap data
manually before doing a system shut down for example?
Not reliably. Of course a command or script could be run during shutdown
after swapoff to overwrite the swap, but
- all the swap space must be overwritten
- this increases SSD wear and takes time
- the swap must be initialized again with mkswap afterwards
- the command may not run or complete on an unclean shutdown

IMO it would be much less reliable and convenient that encrypted swap.
Encrypted swap does not require to encrypt all the system. You can just
encrypt the swap partition. There are two ways of doing so :
- use LUKS with a fixed passphrase
- use plain dm-crypt (no LUKS header) with a random key generated at
each boot. /etc/crypttab has options to handle this case.
Pascal Hambourg
2018-09-02 16:08:53 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
is there a way to clear all swap data
manually before doing a system shut down for example?
Not reliably. Of course a command or script could be run during shutdown
after swapoff to overwrite the swap, but
- all the swap space must be overwritten
- this increases SSD wear and takes time
- the swap must be initialized again with mkswap afterwards
- the command may not run or complete on an unclean shutdown
IMO it would be much less reliable and convenient that encrypted swap.
^^^^
s/that/than/
Post by Pascal Hambourg
Encrypted swap does not require to encrypt all the system. You can just
- use LUKS with a fixed passphrase
- use plain dm-crypt (no LUKS header) with a random key generated at
each boot. /etc/crypttab has options to handle this case.
Tuxedo
2018-09-02 16:23:00 UTC
Permalink
Post by Pascal Hambourg
Post by Pascal Hambourg
Post by Tuxedo
is there a way to clear all swap data
manually before doing a system shut down for example?
Not reliably. Of course a command or script could be run during shutdown
after swapoff to overwrite the swap, but
- all the swap space must be overwritten
- this increases SSD wear and takes time
- the swap must be initialized again with mkswap afterwards
- the command may not run or complete on an unclean shutdown
IMO it would be much less reliable and convenient that encrypted swap.
^^^^
s/that/than/
Post by Pascal Hambourg
Encrypted swap does not require to encrypt all the system. You can just
- use LUKS with a fixed passphrase
- use plain dm-crypt (no LUKS header) with a random key generated at
each boot. /etc/crypttab has options to handle this case.
Thanks for clarifying this too. My manual swap-cleaning idea was clearly not
a sensible one :-)

README_CRYPT.TXT addresses LUKS on the swap, which can be done after the
more important home directory encryption has been set up and as you say
without encrypting the whole system.

I will also look into the plain dm-crypt method.

Tuxedo
Ars Ivci
2018-09-02 16:50:36 UTC
Permalink
[...]
Post by Tuxedo
README_CRYPT.TXT addresses LUKS on the swap, which can be done after the
more important home directory encryption has been set up and as you say
without encrypting the whole system.
I will also look into the plain dm-crypt method.
Tuxedo
May I humbly suggest something? I'm not a Linux expert but I know a
thing or two about security. If you think laptop will carry sensitive
data, your priority is securing the data; security comes first.

If you will use a swap partition, you have to encrypt it; period.
Security comes first.

If suspend does not work with an encrypted swap, no biggie. Don't
suspend, security comes first.

If a swap file does the trick, use it; security comes first.

If btrfs or some file system does not work it a swap file, use the one
that works with it. Security comes first.

If this is just a mental exercise and the data is not sensitive, use the
simplest way.

Personally, I do not have an encrypted partition. I have my horse stats,
triple backed up (very important), comics collection (losing it will
hurt but I can recover some of them), and finally my pr0n collection
(losing it will be an excuse to start a brand new one).

Let me say again, if security is a concern, don't cut corners.

t.
Tuxedo
2018-09-02 20:56:49 UTC
Permalink
Ars Ivci wrote:

[...]
Post by Ars Ivci
May I humbly suggest something? I'm not a Linux expert but I know a
thing or two about security. If you think laptop will carry sensitive
data, your priority is securing the data; security comes first.
No need to be humble :-)
Post by Ars Ivci
If you will use a swap partition, you have to encrypt it; period.
Security comes first.
If suspend does not work with an encrypted swap, no biggie. Don't
suspend, security comes first.
If a swap file does the trick, use it; security comes first.
A swap file doesn't work for suspend I think, and this is the only reason
for me to use swap partition on a laptop. Otherwise a swap file is no longer
needed on Slackware or a Linux system with 8GB ram.

So I must find a good way to encrypt the swap partition.
Post by Ars Ivci
If btrfs or some file system does not work it a swap file, use the one
that works with it. Security comes first.
If this is just a mental exercise and the data is not sensitive, use the
simplest way.
Personally, I do not have an encrypted partition. I have my horse stats,
triple backed up (very important), comics collection (losing it will
hurt but I can recover some of them), and finally my pr0n collection
(losing it will be an excuse to start a brand new one).
Let me say again, if security is a concern, don't cut corners.
t.
Thanks for the above comments. You're right!

Tuxedo
Pascal Hambourg
2018-09-03 17:40:39 UTC
Permalink
Post by Tuxedo
A swap file doesn't work for suspend I think, and this is the only reason
for me to use swap partition on a laptop.
Actually suspend-to-disk can work with a swap file, but resume requires
to pass the physical offset of the swap file in the filesystem to the
kernel command line.

I have read that uswsusp can use any arbitrary file for suspend/resume,
but never used it.
Ars Ivci
2018-09-02 16:27:16 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
is there a way to clear all swap data
[...]
Post by Pascal Hambourg
IMO it would be much less reliable and convenient that encrypted swap.
Encrypted swap does not require to encrypt all the system. You can just
- use LUKS with a fixed passphrase
- use plain dm-crypt (no LUKS header) with a random key generated at
each boot. /etc/crypttab has options to handle this case.
Third is using a swap file instead of a partition.
t.
Pascal Hambourg
2018-09-02 17:31:10 UTC
Permalink
Post by Ars Ivci
Post by Pascal Hambourg
Encrypted swap does not require to encrypt all the system. You can
- use LUKS with a fixed passphrase
- use plain dm-crypt (no LUKS header) with a random key generated at
each boot. /etc/crypttab has options to handle this case.
Third is using a swap file instead of a partition.
Provided that the underlying filesystem is encrypted. If the OP decided
that only /home is encrypted, the swap file would have to be be in
/home, which is not the most natural location.
Tuxedo
2018-09-02 20:32:04 UTC
Permalink
Post by Pascal Hambourg
Post by Ars Ivci
Post by Pascal Hambourg
Encrypted swap does not require to encrypt all the system. You can
- use LUKS with a fixed passphrase
- use plain dm-crypt (no LUKS header) with a random key generated at
each boot. /etc/crypttab has options to handle this case.
Third is using a swap file instead of a partition.
Provided that the underlying filesystem is encrypted. If the OP decided
that only /home is encrypted, the swap file would have to be in
/home, which is not the most natural location.
I meant I would encrypt the swap partition separately, which may mean having
to type a password twice on start up, once for the home and once for swap,
which wouldn't be an issue. So the only unencrypted part would be the slack
operating system partition including necessary parts needed for booting it,
also including whatever semi-secure files end up in program settings and
/tmp/ etc. But first step is to get the home part well encrypted on the SSD.

For now it's the simplest and most secure overall solution for me, while
avoiding combining LUKS and LVM, which I reserve for a future installation
project following your step-by-step guide, also when I have more time.

Tuxedo
Eef Hartman
2018-09-02 20:50:44 UTC
Permalink
Post by Tuxedo
I meant I would encrypt the swap partition separately, which may
mean having to type a password twice on start up, once for the home
and once for swap, which wouldn't be an issue.
If you would create a separate /boot for the kernel and (optional)
ramdisk, you could make ALL of the rest a big, LUKS encrypted,
partition in which /, /home and swap are separate lv's.
You could even consider creating other lv's as needed inside this
LVM VolumeGroup.

Having an lv for swap avoids the "having to decide a definite size"
for it, as it can always be shrunk or extended (and, of course, as it
then is within the encrypted partition you won't need a separate
password for it as ALL of the LVM lv's will be encrypted.
Tuxedo
2018-09-03 08:28:32 UTC
Permalink
[...]
Post by Eef Hartman
If you would create a separate /boot for the kernel and (optional)
ramdisk, you could make ALL of the rest a big, LUKS encrypted,
partition in which /, /home and swap are separate lv's.
You could even consider creating other lv's as needed inside this
LVM VolumeGroup.
Having an lv for swap avoids the "having to decide a definite size"
for it, as it can always be shrunk or extended (and, of course, as it
then is within the encrypted partition you won't need a separate
password for it as ALL of the LVM lv's will be encrypted.
You are right. It's the best solution and I think I must give it a try!

Tuxedo
Pascal Hambourg
2018-09-03 17:56:11 UTC
Permalink
Post by Eef Hartman
If you would create a separate /boot for the kernel and (optional)
ramdisk, you could make ALL of the rest a big, LUKS encrypted,
partition in which /, /home and swap are separate lv's.
AFAIK, an initramfs is not optional when / is encrypted because
accessing it requires userland action. Same when / is on LVM, on
software RAID with 1.x superblock, or identified by a filesystem LABEL
or UUID.
Post by Eef Hartman
You could even consider creating other lv's as needed inside this
LVM VolumeGroup.
Having an lv for swap avoids the "having to decide a definite size"
for it, as it can always be shrunk or extended (and, of course, as it
then is within the encrypted partition you won't need a separate
password for it as ALL of the LVM lv's will be encrypted.
A trade-off could be to leave / on an unencrypted plain partition in
order to make boot easier, and use LVM logical volumes in a single
encrypted PV (one single passphrase) for anything that may contain
sensitive date : /home, /tmp (or use tmpfs), /var, swap...
Eef Hartman
2018-09-03 19:07:24 UTC
Permalink
Post by Pascal Hambourg
A trade-off could be to leave / on an unencrypted plain partition in
order to make boot easier,
Yes, that's an alternative,then you w ouldn't need a separate /boot.
Post by Pascal Hambourg
encrypted PV (one single passphrase) for anything that may contain
sensitive date : /home, /tmp (or use tmpfs), /var, swap...
But indeed /var then must NOT be in the root partition but split-off
into its own lv. There's too much sensitive data e.g. in logfiles.
Pascal Hambourg
2018-09-03 17:45:30 UTC
Permalink
Post by Tuxedo
Post by Pascal Hambourg
Encrypted swap does not require to encrypt all the system. You can
- use LUKS with a fixed passphrase
- use plain dm-crypt (no LUKS header) with a random key generated at
each boot. /etc/crypttab has options to handle this case.
(...)
Post by Tuxedo
I meant I would encrypt the swap partition separately, which may mean having
to type a password twice on start up, once for the home and once for swap,
If you use plain dm-crypt encryption with a random temporary key for
swap, you won't have to type a second passphrase. But of course this
does not support hibernation since the encryption key is lost at shutdown.
Tuxedo
2018-09-03 18:52:08 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
Post by Pascal Hambourg
Encrypted swap does not require to encrypt all the system. You can
- use LUKS with a fixed passphrase
- use plain dm-crypt (no LUKS header) with a random key generated at
each boot. /etc/crypttab has options to handle this case.
(...)
Post by Tuxedo
I meant I would encrypt the swap partition separately, which may mean
having to type a password twice on start up, once for the home and once
for swap,
If you use plain dm-crypt encryption with a random temporary key for
swap, you won't have to type a second passphrase. But of course this
does not support hibernation since the encryption key is lost at shutdown.
I will try the Luks with LVM solution. It makes most sense after all!

Meanwhile, thanks for your answers to my many questions.

Tuxedo
Rich
2018-09-01 14:39:46 UTC
Permalink
Post by Tuxedo
[...]
I guess I'm mixing up logical partitions and volumes....
Partition: A subset of the space on a single device (typically a single
spinning disk unit, but as far as Linux is concerned it is a "disk
device" (i.e., /dev/sda /dev/sdb /dev/sdc are "disk devices", /dev/sda1
is partition 1 on disk "a").

LVM2: A system for taking a single real disk device (i.e., /dev/sda)
and creating from it one or more other, virtual, disk devices (i.e.,
/dev/sde and /dev/sdf could both actually be residing inside real disk
device /dev/sda by using LVM2)

Volumne (LVM2 term): A unit of storage in LVM2. Without a modifier
(physical/logical) it is just a "unit of storage".

With LVM2 you tell it what "physical volumes" it may use (physical in
this context meaning "disk devices" (i.e., /dev/sda, dev/sdb, etc.) and
additional details of 'how' it is to use them (mirror, jbod, etc.).

That provides LVM2 a "pool" of storage space.

From out of that "pool" you create "logical volumes" of your desired
sizes. Each "logical volume" is a "disk device" (i.e., /dev/sde
/dev/sdf, although the actual names will be different).

You then 'partition' each disk device (if you want, although you 'can'
create a filesystem on the full disk device if you like). In each
partition you then create a filesystem.


In the normal senario of several physical disks and several partitions
per physical disk, once you set things up the sizes are fixed unless
you want to start backing data up and redoing things.

With LVM you can separate the physical relationship of a disk device
(/dev/sda) to an actual physical disk drive on a SATA port so that you
can change the size of the disk (/dev/sda) (or delete the disk
entirely) without ever changing the physical layout of the physical
disks inside the LVM2 set.
Tuxedo
2018-09-01 08:27:43 UTC
Permalink
Post by Tuxedo
On a separate issue, after having created the partitions using GParted's
live media, opening Gparted agian on the newly formatted system, there is
an error dialog: 'invalid partition table on /dev/nvmeOn1 - wrong
signature 0'
What could this mean?
As setting up encryption with LVMs appears overly complicated, I will return
to the idea of using primary partitions only.

I've now recreated a table with four primaries, and this time after
restarting GParted's live GUI returned no error such as the above.

In the detailed GParted report, there's a bit of info relating to the new
/dev/nvme0n1p1 (slackware partition) and /dev/nvme0n1p4 (data partition):
"64-bit filesystem support is not enabled."

Considering I'm installing the 14.2 64 bit Slackware, can this be ignored?

Normally I reformat the partitions in Slackware's setup tool anyway, so I
guess they will be 64-bit filesystem supported thereafter.

I now have the following setup:

/dev/nvme0n1p1 ext4 slackware 186.26 GiB
/dev/nvme0n1p2 ntfs windows 93.13 GiB
/dev/nvme0n1p3 linux-swap 8.38 GiB
/dev/nvme0n1p4 ext4 data 1.54 TiB

How to encrypt swap and make hibernation work I'm not entirely sure but
maybe either encryption or hibernation will be available.

I've included GParted's full output below.

With some luck encryption will be a builtin feature in future Slackwares :-)

Tuxedo


GParted 0.29.0 --enable-online-resize

Libparted 3.2
Create Primary Partition #1 (ext4, 186.26 GiB) on /dev/nvme0n1 00:00:01
( SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p1 (partition)
start: 2048
end: 390627327
size: 390625280 (186.26 GiB)
clear old file system signatures in /dev/nvme0n1p1 00:00:00 ( SUCCESS )

write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 199999619072 00:00:00 ( SUCCESS
)
write 4.00 KiB of zeros at byte offset 200000077824 00:00:00 ( SUCCESS )
write 8.00 KiB of zeros at byte offset 200000135168 00:00:00 ( SUCCESS )
flush operating system cache of /dev/nvme0n1 00:00:00 ( SUCCESS )
set partition type on /dev/nvme0n1p1 00:00:00 ( SUCCESS )

new partition type: ext4
create new ext4 file system 00:00:01 ( SUCCESS )

mkfs.ext4 -F -O ^64bit -L "slackware" /dev/nvme0n1p1 00:00:01 ( SUCCESS
)

64-bit filesystem support is not enabled. The larger fields afforded by this
feature enable full-strength checksumming. Pass -O 64bit to rectify.
Discarding device blocks: done
Creating filesystem with 48828160 4k blocks and 12214272 inodes
Filesystem UUID: c73ec117-bee1-4a65-ae11-1ae8164cb895
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

mke2fs 1.43.5 (04-Aug-2017)

========================================
Create Primary Partition #2 (ntfs, 93.13 GiB) on /dev/nvme0n1 00:00:00 (
SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p2 (partition)
start: 390627328
end: 585938943
size: 195311616 (93.13 GiB)
clear old file system signatures in /dev/nvme0n1p2 00:00:00 ( SUCCESS )

write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 99999023104 00:00:00 ( SUCCESS
)
write 4.00 KiB of zeros at byte offset 99999481856 00:00:00 ( SUCCESS )
write 8.00 KiB of zeros at byte offset 99999539200 00:00:00 ( SUCCESS )
flush operating system cache of /dev/nvme0n1 00:00:00 ( SUCCESS )
set partition type on /dev/nvme0n1p2 00:00:00 ( SUCCESS )

new partition type: ntfs
create new ntfs file system 00:00:00 ( SUCCESS )

mkntfs -Q -v -F -L "windows" /dev/nvme0n1p2 00:00:00 ( SUCCESS )

Cluster size has been automatically set to 4096 bytes.
Creating NTFS volume structures.
Creating root directory (mft record 5)
Creating $MFT (mft record 0)
Creating $MFTMirr (mft record 1)
Creating $LogFile (mft record 2)
Creating $AttrDef (mft record 4)
Creating $Bitmap (mft record 6)
Creating $Boot (mft record 7)
Creating backup boot sector.
Creating $Volume (mft record 3)
Creating $BadClus (mft record 8)
Creating $Secure (mft record 9)
Creating $UpCase (mft record 0xa)
Creating $Extend (mft record 11)
Creating system file (mft record 0xc)
Creating system file (mft record 0xd)
Creating system file (mft record 0xe)
Creating system file (mft record 0xf)
Creating $Quota (mft record 24)
Creating $ObjId (mft record 25)
Creating $Reparse (mft record 26)
Syncing root directory index record.
Syncing $Bitmap.
Syncing $MFT.
Updating $MFTMirr.
Syncing device.
mkntfs completed successfully. Have a nice day.

========================================
Create Primary Partition #3 (linux-swap, 8.38 GiB) on /dev/nvme0n1 00:00:00
( SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p3 (partition)
start: 585938944
end: 603516927
size: 17577984 (8.38 GiB)
clear old file system signatures in /dev/nvme0n1p3 00:00:00 ( SUCCESS )

write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 8999403520 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 8999862272 00:00:00 ( SUCCESS )
write 8.00 KiB of zeros at byte offset 8999919616 00:00:00 ( SUCCESS )
flush operating system cache of /dev/nvme0n1 00:00:00 ( SUCCESS )
set partition type on /dev/nvme0n1p3 00:00:00 ( SUCCESS )

new partition type: linux-swap(v1)
create new linux-swap file system 00:00:00 ( SUCCESS )

mkswap -L "swap" /dev/nvme0n1p3 00:00:00 ( SUCCESS )

Setting up swapspace version 1, size = 8.4 GiB (8999923712 bytes)
LABEL=swap, UUID=35bbd19b-d75d-4836-a02f-ba83c1d28da1

========================================
Create Primary Partition #4 (ext4, 1.54 TiB) on /dev/nvme0n1 00:00:02 (
SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p4 (partition)
start: 603516928
end: 3907028991
size: 3303512064 (1.54 TiB)
clear old file system signatures in /dev/nvme0n1p4 00:00:00 ( SUCCESS )

write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 274877906944 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 1691397652480 00:00:00 (
SUCCESS )
write 4.00 KiB of zeros at byte offset 1691398111232 00:00:00 ( SUCCESS
)
write 8.00 KiB of zeros at byte offset 1691398168576 00:00:00 ( SUCCESS
)
flush operating system cache of /dev/nvme0n1 00:00:00 ( SUCCESS )
set partition type on /dev/nvme0n1p4 00:00:00 ( SUCCESS )

new partition type: ext4
create new ext4 file system 00:00:02 ( SUCCESS )

mkfs.ext4 -F -O ^64bit -L "data" /dev/nvme0n1p4 00:00:02 ( SUCCESS )

64-bit filesystem support is not enabled. The larger fields afforded by this
feature enable full-strength checksumming. Pass -O 64bit to rectify.
Discarding device blocks: done
Creating filesystem with 412939008 4k blocks and 103235584 inodes
Filesystem UUID: 65884ae1-566b-4f9e-8655-a2dfc22b4776
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

mke2fs 1.43.5 (04-Aug-2017)

========================================
Pascal Hambourg
2018-09-01 10:02:28 UTC
Permalink
Post by Tuxedo
As setting up encryption with LVMs appears overly complicated,
It is not complicated at all. But you must learn how to use LVM first.
Post by Tuxedo
In the detailed GParted report, there's a bit of info relating to the new
"64-bit filesystem support is not enabled."
Considering I'm installing the 14.2 64 bit Slackware, can this be ignored?
It can be ignored. The 64bit ext4 feature has nothing to do with 64-bit
system architecture.
Eef Hartman
2018-09-01 08:32:22 UTC
Permalink
Post by Pascal Hambourg
No. The next step is to create logical partitions in the extended
partition. Then you can encrypt a logical partition.
If you don't need more than 4 partitions, then you did not have to
create an extended partition and should have created a primary partition
instead.
With a gpt partition table you do not need extended partitions at all!
GPT can have (at least) 128 partitions without the old need for
extended partitions for them. So make everything you want to put into
lvm in a single partition, the document in 14.2 is for old-type bios
MBR type of partitions.
Tuxedo
2018-09-01 08:51:30 UTC
Permalink
Eef Hartman wrote:

[...]
Post by Eef Hartman
With a gpt partition table you do not need extended partitions at all!
GPT can have (at least) 128 partitions without the old need for
extended partitions for them. So make everything you want to put into
lvm in a single partition, the document in 14.2 is for old-type bios
MBR type of partitions.
Will this work with the old LILO Linux-Windows MBR dual boot?

Tuxedo
Eef Hartman
2018-09-01 09:53:36 UTC
Permalink
Post by Tuxedo
Will this work with the old LILO Linux-Windows MBR dual boot?
It depends on _which_ version of Windows. 10, I believe, can only
boot with UEFI/gpt while 7 or 8 can still use the older MBR one.
But, I admit, I don't have experience with either, (almost) all of my
systems are Linux-only (the exception is an old Pentium-III that
originally came with Windows-ME, to which I added Linux when I bought
it. But the W-ME is still there, although restricted to a 4 GB
partition and _is_ bootable from lilo).

My newest computer (and the one I'm writing this on) came without O/S
at all, so I installed Linux (originally Slackware 13.1, now updated
to 14.x) on it and later added a 2 TB disk as a 2nd one.

That one (and its external backup) is the only one with a gpt
partition table (and as they do not need to be bootable at all,
I just created a single partition on both of them).

BTW: I got about 8 external disks, varying from 250 GB to that 2 TB
one and, as I said, only the largest (Toshiba 2 TB) disk uses gpt.
Richard Kettlewell
2018-09-01 10:29:59 UTC
Permalink
Post by Eef Hartman
Post by Tuxedo
Will this work with the old LILO Linux-Windows MBR dual boot?
It depends on _which_ version of Windows. 10, I believe, can only
boot with UEFI/gpt
Windows 10 can boot from MBR.
--
https://www.greenend.org.uk/rjk/
Pascal Hambourg
2018-09-01 10:06:58 UTC
Permalink
Post by Tuxedo
Post by Eef Hartman
With a gpt partition table you do not need extended partitions at all!
GPT can have (at least) 128 partitions without the old need for
extended partitions for them. (...)
AFAICS the OP does not need more than 4 partitions, so he needs neither
an extended partition nor GPT.
Post by Tuxedo
Will this work with the old LILO Linux-Windows MBR dual boot?
No. Windows cannot boot in BIOS/legacy mode from a GPT disk. Not sure
about LILO, I only use GRUB 2 with GPT.
Eef Hartman
2018-09-01 10:37:02 UTC
Permalink
Post by Pascal Hambourg
AFAICS the OP does not need more than 4 partitions, so he needs neither
an extended partition nor GPT.
That is true, with "only" 4 partitions the difference is academic.
To the OP: extended partitions are needed when with an old-time MBR
partition table you need MORE then 4 partitions. With LVM you will
only need a single partition which then can be split-up into lv's,
giving you dynamically resizable "partitions" (actually those lv's).
Pascal Hambourg
2018-09-01 11:18:45 UTC
Permalink
Post by Eef Hartman
Post by Pascal Hambourg
AFAICS the OP does not need more than 4 partitions, so he needs neither
an extended partition nor GPT.
That is true, with "only" 4 partitions the difference is academic.
To be honest, GPT provides a few other enhancements :
- support for more than 4-G sectors (i.e. 2 TiB with 512-byte sectors)
- support for partition labels and true partition UUIDs
Post by Eef Hartman
To the OP: extended partitions are needed when with an old-time MBR
partition table you need MORE then 4 partitions. With LVM you will
only need a single partition which then can be split-up into lv's,
giving you dynamically resizable "partitions" (actually those lv's).
I am not sure that including /boot in LVM is a good idea, even if the
bootloader supports it. GRUB 2 does, what about LILO ?
Same with encryption. GRUB 2 can work with an encrypted /boot, but I
doubt LILO can.
IMO it is wiser to have a separate /boot partition.
Eef Hartman
2018-09-01 15:05:00 UTC
Permalink
Post by Pascal Hambourg
- support for more than 4-G sectors (i.e. 2 TiB with 512-byte sectors)
Mostly not important as those large disks will have a 4 K _physical_
sector size anyway, so using a smaller _logical_ sector will just slow
down I/O to that disk (it has to read the whole sector, overwrite the
512 bytes in the buffer en REwrite the whole physical sector again.

OK, if you have lots and lots of small (< 1 K) files, you may want
this option as to be able to store more of them
Post by Pascal Hambourg
I am not sure that including /boot in LVM is a good idea, even if the
bootloader supports it. GRUB 2 does, what about LILO ?
I don't hink so, but you _can_ include swap in the LVM partition
(create it with the --contiguous option) so you wouldn't need a
separate physical partition for it, just a lv.
Post by Pascal Hambourg
IMO it is wiser to have a separate /boot partition.
But /boot, Windows and Linux (LUKS + LVM) only would need 3 partitions.
Pascal Hambourg
2018-09-01 18:53:51 UTC
Permalink
Post by Eef Hartman
Post by Pascal Hambourg
- support for more than 4-G sectors (i.e. 2 TiB with 512-byte sectors)
Mostly not important as those large disks will have a 4 K _physical_
sector size anyway, so using a smaller _logical_ sector will just slow
down I/O to that disk
Partition tables deal with logical sectors, so physical sector size does
not matter for addressing capability. If you want to partition a disk
with more than 4-Gi (2^32) logical sectors, such as a disk bigger than
2TB with 512-byte logical sectors, you must use GPT - regardless of the
physical sector size. AFAICS, most large disks still have 512-byte
logical sectors.

Physical sector size matters only for data alignment : filesystem blocks
should be aligned with physical sectors for optimal performance.
Post by Eef Hartman
Post by Pascal Hambourg
I am not sure that including /boot in LVM is a good idea, even if the
bootloader supports it. GRUB 2 does, what about LILO ?
I don't hink so, but you _can_ include swap in the LVM partition
The swap is not involved in the boot process. Only the contents of /boot
(boot loader, kernel image, initramfs) is.
Post by Eef Hartman
(create it with the --contiguous option)
Why bother with contiguous extent allocation ?
Post by Eef Hartman
so you wouldn't need a separate physical partition for it
Why would swap need a separate partition when using LVM ?
Loading...