Discussion:
Pre-LVM & encryption setup
(too old to reply)
Tuxedo
2018-09-04 20:40:28 UTC
Permalink
Hello,

Having been convinced that LVM is best used for full Linux encryption, I've
now configured three partitions for dual boot on an SSD.

I placed ntfs first, as I've seen others doing that. I will never need to
make changes to the Windows partitions as I will rarely use it, so maybe
it's best placed first.

Using GParted, I then did the following:

Createed primary ntfs partition: 93.13 GiB.

Created primary ext4 boot partition: 190.00 MiB.
It should be large enough for possible use of multiple kernels and GRUB,
although Lilo will probably always be used.

Created primary ext4 Linux partition for LVM to include encrypted Slackware,
/home/ and swap: 1.73 TiB (the remaining disk space).

GParted's detailed output is included further below.

A 'parted' align-check on each partition returned:

GNU Parted 3.2.94-7188
Using /dev/nvme0n1

(parted) align-check opt 1
1 aligned

(parted) align-check opt 2
2 aligned

(parted) align-check opt 3
3 aligned

Having done the same tests on a previous setup which only passed as
"minimal", this time it's "optimal" on all partitions. Perhaps because this
time I downloaded and used the latest version of GParted.

Excluding the /dev/ram.. and /dev/loop.. output, 'fdisk -l' returns:

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 (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x03e7d03a

Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 195313663 195311616 93.1G 7 HPFS/NTFS/exFAT
/dev/nvme0n1p2 195313664 195702783 389120 190M 83 Linux
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 83 Linux

Before doing the LVM setup, encryption and Slackware installation, can
anyone confirm if the above is Ok?

Or would the partitions be better placed in a different order?

Many thanks,
Tuxedo


Full output of GParted:

GParted 0.31.0 --enable-libparted-dmraid --enable-online-resize

Libparted 3.2.94-7188
Create Primary Partition #1 (ntfs, 93.13 GiB) on /dev/nvme0n1 00:00:01 (
SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p1 (partition)
start: 2048
end: 195313663
size: 195311616 (93.13 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 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/nvme0n1p1 00:00:01 ( SUCCESS )

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

mkntfs -Q -v -F -L 'Windows' '/dev/nvme0n1p1' 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 #2 (ext4, 190.00 MiB) on /dev/nvme0n1 00:00:00
( SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p2 (partition)
start: 195313664
end: 195702783
size: 389120 (190.00 MiB)
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 198705152 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 199163904 00:00:00 ( SUCCESS )
write 8.00 KiB of zeros at byte offset 199221248 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: ext4
create new ext4 file system 00:00:00 ( SUCCESS )

mkfs.ext4 -F -O ^64bit -L 'boot' '/dev/nvme0n1p2' 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 194560 1k blocks and 48768 inodes
Filesystem UUID: 956e89d8-5c18-4484-be8b-10c4d637a0cb
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.44.0 (7-Mar-2018)

========================================
Create Primary Partition #3 (ext4, 1.73 TiB) on /dev/nvme0n1 00:00:03 (
SUCCESS )

create empty partition 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p3 (partition)
start: 195702784
end: 3907028991
size: 3711326208 (1.73 TiB)
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 4.00 KiB of zeros at byte offset 274877906944 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 1900198494208 00:00:00 (
SUCCESS )
write 4.00 KiB of zeros at byte offset 1900198952960 00:00:00 ( SUCCESS
)
write 8.00 KiB of zeros at byte offset 1900199010304 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: ext4
create new ext4 file system 00:00:03 ( SUCCESS )

mkfs.ext4 -F -O ^64bit -L 'Linux' '/dev/nvme0n1p3' 00:00:03 ( 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 463915776 4k blocks and 115982336 inodes
Filesystem UUID: 918333f5-6d8e-45dc-8ec2-561ab988a41a
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.44.0 (7-Mar-2018)
Pascal Hambourg
2018-09-04 21:34:00 UTC
Permalink
Post by Tuxedo
Created primary ext4 Linux partition for LVM
This does not make any sense : a partition cannot be both ext4 and LVM.
Actually this partition is supposed to be neither of these but a LUKS
container. The encrypted device based on it will be an LVM PV. Some LVs
will be ext4.
Tuxedo
2018-09-04 22:11:46 UTC
Permalink
[...]
Post by Pascal Hambourg
This does not make any sense : a partition cannot be both ext4 and LVM.
Actually this partition is supposed to be neither of these but a LUKS
container. The encrypted device based on it will be an LVM PV. Some LVs
will be ext4.
Many thanks for pointing out my misunderstanding :-)

Within GParted, I now have the option to format /dev/nvme0n1p3 to 'lvm2 pv',
which I just did. The output of 'fdisk -l' is now:

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 (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x03e7d03a

Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 195313663 195311616 93.1G 7 HPFS/NTFS/exFAT
/dev/nvme0n1p2 195313664 195702783 389120 190M 8e Linux LVM
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 83 Linux

Is this correct?

If so, is it good to proceed with the cryptsetup/luksFormat and thereafter
pvcreate, vgcreate, lvcreate for root, home and swap?

I'm slowly getting there....

Tuxedo


The detailed output of GParte's reformat action:

GParted 0.31.0 --enable-libparted-dmraid --enable-online-resize

Libparted 3.2.94-7188
Format /dev/nvme0n1p2 as lvm2 pv 00:00:00 ( SUCCESS )

calibrate /dev/nvme0n1p2 00:00:00 ( SUCCESS )

path: /dev/nvme0n1p2 (partition)
start: 195313664
end: 195702783
size: 389120 (190.00 MiB)
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 198705152 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 199163904 00:00:00 ( SUCCESS )
write 8.00 KiB of zeros at byte offset 199221248 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 flag: lvm
create new lvm2 pv file system 00:00:00 ( SUCCESS )

lvm pvcreate -M 2 '/dev/nvme0n1p2' 00:00:00 ( SUCCESS )

Physical volume "/dev/nvme0n1p2" successfully created.
Tuxedo
2018-09-04 22:16:49 UTC
Permalink
Post by Tuxedo
Is this correct?
Oops! I did that on the wrong partition (boot). I meant to reformat
/dev/nvme0n1p3 to 'lvm2 pv'.

Tuxedo
Tuxedo
2018-09-04 22:24:40 UTC
Permalink
Post by Tuxedo
Oops! I did that on the wrong partition (boot). I meant to reformat
/dev/nvme0n1p3 to 'lvm2 pv'.
I reformatted again and 'fdisk -l' now appears as follows:

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 (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x03e7d03a

Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 195313663 195311616 93.1G 7 HPFS/NTFS/exFAT
/dev/nvme0n1p2 195313664 195702783 389120 190M 83 Linux
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 8e Linux LVM

Is this the good way?

Tuxedo
Pascal Hambourg
2018-09-05 18:14:19 UTC
Permalink
Post by Tuxedo
[...]
Post by Pascal Hambourg
This does not make any sense : a partition cannot be both ext4 and LVM.
Actually this partition is supposed to be neither of these but a LUKS
container. The encrypted device based on it will be an LVM PV. Some LVs
will be ext4.
Many thanks for pointing out my misunderstanding :-)
Within GParted, I now have the option to format /dev/nvme0n1p3 to 'lvm2 pv',
Not good yet. The partition is to be used as a LUKS container, not a PV.
Any format you apply with Gparted or whatever will be destroyed by
cryptsetup luksCreate.
Tuxedo
2018-09-05 18:59:31 UTC
Permalink
Pascal Hambourg wrote:

[...]
Post by Pascal Hambourg
Not good yet. The partition is to be used as a LUKS container, not a PV.
Any format you apply with Gparted or whatever will be destroyed by
cryptsetup luksCreate.
Ok. GParted does not offer a LUKS container option. In other words, it makes
no difference what the original partition format is initially set to?

Tuxedo
Pascal Hambourg
2018-09-05 19:16:47 UTC
Permalink
Post by Tuxedo
[...]
Post by Pascal Hambourg
Not good yet. The partition is to be used as a LUKS container, not a PV.
Any format you apply with Gparted or whatever will be destroyed by
cryptsetup luksCreate.
Ok. GParted does not offer a LUKS container option. In other words, it makes
no difference what the original partition format is initially set to?
No difference, except that it will set the partition type identifier
("Linux filesystem" for ext4, "LVM" for LVM PV...), which is mostly
informational only.
Doesn't Gparted allow to create a partition without formating it ?
Tuxedo
2018-09-05 19:27:38 UTC
Permalink
Pascal Hambourg wrote:

[...]
Post by Pascal Hambourg
No difference, except that it will set the partition type identifier
("Linux filesystem" for ext4, "LVM" for LVM PV...), which is mostly
informational only.
Doesn't Gparted allow to create a partition without formating it ?
Yes indeed! The last two options in GParted's Create New Partition GUI are
'cleared' and 'unformatted'. I'll set it to unformatted and let the
partition take up the remaining disk space but utilise less in the lvcreate
stage. I'll set the space as a Primary Partition, adding 'Linux' as its
'Label' in case it makes any difference.

Thanks,
Tuxedo
Eef Hartman
2018-09-04 23:23:12 UTC
Permalink
Post by Tuxedo
Or would the partitions be better placed in a different order?
For an SSD, that doesn't have any physical cilinders, it doesn't
matter: all parts of the disk are accessed at equal speed.
Tuxedo
2018-09-05 07:05:28 UTC
Permalink
Post by Eef Hartman
Post by Tuxedo
Or would the partitions be better placed in a different order?
For an SSD, that doesn't have any physical cilinders, it doesn't
matter: all parts of the disk are accessed at equal speed.
Ok. Thanks. I will leave the partitions in the same order.

Having formatted the last partition in gparted as 'lvm2 pv' I now have the
following table:

Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 195313663 195311616 93.1G 7 HPFS/NTFS/exFAT
/dev/nvme0n1p2 195313664 195702783 389120 190M 83 Linux
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 8e Linux LVM

Each partition validated in parted's align-check opt test.

I will skip the random data writing part:
dd if=/dev/urandum of /dev/dev/nvme0n1p3
... because of the problems with SSDs using TRIM and the requirement to
configure --allow-discards when later opening the volume (as would normally
be done by 'cryptsetup --allow-discards luksOpen /dev/nvme0n1p3 slackluks').

Apart from this security drawback, is the setup good to proceed with the
folowing steps?

cryptsetup -s 256 -y luksFormat /dev/nvme0n1p3

pvcreate /dev/mapper/slackluks

lvcreate -L 1690G -n root cryptvg

lvcreate -L 9G -n swap cryptvg

As an only user of the system, I guess there's no useful reason to make a
separate 'home' lv.

Instead, my single user directory can simply exist in the same logical
volume. It would remove the need of possibly having to adjust the volumes
sizes later in case too little or too much is allocated to a root vs. home.

Thanks for any advise.

Tuxedo
Eef Hartman
2018-09-05 07:25:47 UTC
Permalink
Post by Tuxedo
/dev/nvme0n1p2 195313664 195702783 389120 190M 83 Linux
Thta is a bit overkill for a /boot partition (as the most recent 4.14
kernel is only about 8 M). 50 would have been more then sufficient but
what does it matter, you got more then enough diskspace anyway.
Post by Tuxedo
As an only user of the system, I guess there's no useful reason to
make a separate 'home' lv.
If you later want to upgrade cq. install a second distribution a
separate home could be useful, but I admit, I don't do it either, my
home is just for the config (etc) files, "mail" being the major part
of it (130M), less then 400M in total. All really large dirs/files
are on "their own" partitions cq disks (my root disk is only 250 M,
the 2nd one is 2 T and I got 8 external disks, both e-sata as well
as usb, varying from 250 M - the oldest ones - to 2 T).

By the way, my whole "root" is contained in a 10 G (/) partition,
with -current you will probably need more, but essentially your user
files will take up the bulk of storage needed (i.e. my music files
are about 800 G).
Tuxedo
2018-09-05 17:44:13 UTC
Permalink
Post by Eef Hartman
Post by Tuxedo
/dev/nvme0n1p2 195313664 195702783 389120 190M 83 Linux
Thta is a bit overkill for a /boot partition (as the most recent 4.14
kernel is only about 8 M). 50 would have been more then sufficient but
what does it matter, you got more then enough diskspace anyway.
A 100MB boot partition (/dev/sdx1) was mentioned in
http://ftp.slackware.com/pub/slackware/slackware64-14.2/README_CRYPT.TXT

In case this document is outdated and since it was recommended to double
that size in an earlier alt.os.linux.slackware thread "Pre LUKS and LVM
setup" in case multiple kernels and GRUB are used, I allocated 190 MiB.

However, I don't see myself using GRUB unless I must for some reason and I
probably won't be using multiple kernels either, so I'll shrink the boot
section to about 150MB to let no space go to waste! The SSD didn't come
cheap.

[...]
Post by Eef Hartman
If you later want to upgrade cq.
What is cq?
Post by Eef Hartman
install a second distribution a
separate home could be useful, but I admit, I don't do it either, my
home is just for the config (etc) files, "mail" being the major part
of it (130M), less then 400M in total. All really large dirs/files
are on "their own" partitions cq disks (my root disk is only 250 M,
the 2nd one is 2 T and I got 8 external disks, both e-sata as well
as usb, varying from 250 M - the oldest ones - to 2 T).
By the way, my whole "root" is contained in a 10 G (/) partition,
with -current you will probably need more, but essentially your user
files will take up the bulk of storage needed (i.e. my music files
are about 800 G).
Indeed. Thanks for posting your storage info. I don't plan to install a
second distribution. A well-installed Slackware should be enough :-)

In this case, I'll put home and root in a same LV as I don't see why the OS
and user files need to be divided across LVs, or between partitions on a
traditional setup, at least not in a single user and system laptop
environment.

Tuxedo
root
2018-09-05 14:02:21 UTC
Permalink
Post by Tuxedo
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 8e Linux LVM
^^^^

Wow. What ssd is that?
Tuxedo
2018-09-05 16:03:22 UTC
Permalink
Post by root
Post by Tuxedo
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 8e Linux LVM
^^^^
Wow. What ssd is that?
The dealer fitted it in exchange of one of Lenovo's standard disks:
https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m2-2tb-mz-v7e2t0bw/#specs

However, it could be a slightly different model number that's in my system.
Samsung has at least two different varieties of more or less the same SSD
and I don't want to open the laptop to read the model number. I haven't
installed Slackware or any OS on it yet and I'm not sure what tool to use to
find out more exact details.

Tuxedo
root
2018-09-05 16:53:24 UTC
Permalink
Post by Tuxedo
Post by root
Post by Tuxedo
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 8e Linux LVM
^^^^
Wow. What ssd is that?
https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m2-2tb-mz-v7e2t0bw/#specs
However, it could be a slightly different model number that's in my system.
Samsung has at least two different varieties of more or less the same SSD
and I don't want to open the laptop to read the model number. I haven't
installed Slackware or any OS on it yet and I'm not sure what tool to use to
find out more exact details.
Tuxedo
Thanks for the info.

I am running a smaller version of that ssd. I had no trouble installing
Slack 14.2 but lilo can't access that partition. I used grub.
Tuxedo
2018-09-05 18:00:45 UTC
Permalink
root wrote:

[...]
Post by root
I am running a smaller version of that ssd. I had no trouble installing
Slack 14.2 but lilo can't access that partition. I used grub.
I'll try with LILO and if it fails I'll use GRUB instead. I've used GRUB
before and remember the additional configuration baggage only to boot a
system while having the possibility of displaying a pointless startup image.

Tuxedo
Bit Twister
2018-09-05 17:30:04 UTC
Permalink
Post by Tuxedo
However, it could be a slightly different model number that's in my system.
Samsung has at least two different varieties of more or less the same SSD
and I don't want to open the laptop to read the model number. I haven't
installed Slackware or any OS on it yet and I'm not sure what tool to use to
find out more exact details.
I find hwinfo pretty handy for looking around for hardware information.
You need to be root to get a full report.
Eef Hartman
2018-09-05 19:37:41 UTC
Permalink
I'm not sure what tool to use to find out more exact details.
I assume lspci -v (run as root, although running it (/sbin/lspci) as
non-root should return some info too).
Pascal Hambourg
2018-09-05 18:23:39 UTC
Permalink
Post by Tuxedo
Having formatted the last partition in gparted as 'lvm2 pv' I now have the
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 195313663 195311616 93.1G 7 HPFS/NTFS/exFAT
/dev/nvme0n1p2 195313664 195702783 389120 190M 83 Linux
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 8e Linux LVM
Each partition validated in parted's align-check opt test.
dd if=/dev/urandum of /dev/dev/nvme0n1p3
... because of the problems with SSDs using TRIM and the requirement to
configure --allow-discards when later opening the volume (as would normally
be done by 'cryptsetup --allow-discards luksOpen /dev/nvme0n1p3 slackluks').
Apart from this security drawback, is the setup good to proceed with the
folowing steps?
cryptsetup -s 256 -y luksFormat /dev/nvme0n1p3
The above cryptsetup luksOpen command should go here.
Post by Tuxedo
pvcreate /dev/mapper/slackluks
lvcreate -L 1690G -n root cryptvg
My usual advice : do not allocate all the space in the VG. Leave plenty
of available space for future allocations. Extending an LV is easy
(lvextend + resize2fs) and can usually be done online. Reducing an LV
and its contents to free some space is more difficult and error-prone
and must often be done offline.
Post by Tuxedo
lvcreate -L 9G -n swap cryptvg
As an only user of the system, I guess there's no useful reason to make a
separate 'home' lv.
Instead, my single user directory can simply exist in the same logical
volume. It would remove the need of possibly having to adjust the volumes
sizes later in case too little or too much is allocated to a root vs. home.
My above advice addresses this concern.
Pascal Hambourg
2018-09-05 18:26:45 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
Having formatted the last partition in gparted as 'lvm2 pv' I now have the
Device         Boot     Start        End    Sectors  Size Id Type
/dev/nvme0n1p1           2048  195313663  195311616 93.1G  7
HPFS/NTFS/exFAT
/dev/nvme0n1p2      195313664  195702783     389120  190M 83 Linux
/dev/nvme0n1p3      195702784 3907028991 3711326208  1.7T 8e Linux LVM
Each partition validated in parted's align-check opt test.
dd if=/dev/urandum of /dev/dev/nvme0n1p3
... because of the problems with SSDs using TRIM and the requirement to
configure --allow-discards when later opening the volume (as would normally
be done by 'cryptsetup --allow-discards luksOpen /dev/nvme0n1p3 slackluks').
Apart from this security drawback, is the setup good to proceed with the
folowing steps?
cryptsetup -s 256 -y luksFormat /dev/nvme0n1p3
The above cryptsetup luksOpen command should go here.
Post by Tuxedo
pvcreate /dev/mapper/slackluks
Oops ! Forgot to mention the VG creation is missing :

vgcreate cryptvg /dev/mapper/slackluks
Post by Pascal Hambourg
Post by Tuxedo
lvcreate -L 1690G -n root cryptvg
My usual advice : do not allocate all the space in the VG. Leave plenty
of available space for future allocations. Extending an LV is easy
(lvextend + resize2fs) and can usually be done online. Reducing an LV
and its contents to free some space is more difficult and error-prone
and must often be done offline.
Post by Tuxedo
lvcreate -L 9G -n swap cryptvg
As an only user of the system, I guess there's no useful reason to make a
separate 'home' lv.
Instead, my single user directory can simply exist in the same logical
volume. It would remove the need of possibly having to adjust the volumes
sizes later in case too little or too much is allocated to a root vs. home.
My above advice addresses this concern.
Tuxedo
2018-09-05 18:52:43 UTC
Permalink
Post by Pascal Hambourg
Post by Tuxedo
Having formatted the last partition in gparted as 'lvm2 pv' I now have
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 195313663 195311616 93.1G 7
HPFS/NTFS/exFAT
/dev/nvme0n1p2 195313664 195702783 389120 190M 83 Linux
/dev/nvme0n1p3 195702784 3907028991 3711326208 1.7T 8e Linux LVM
Each partition validated in parted's align-check opt test.
dd if=/dev/urandum of /dev/dev/nvme0n1p3
... because of the problems with SSDs using TRIM and the requirement to
configure --allow-discards when later opening the volume (as would
normally be done by 'cryptsetup --allow-discards luksOpen /dev/nvme0n1p3
slackluks').
Apart from this security drawback, is the setup good to proceed with the
following steps?
cryptsetup -s 256 -y luksFormat /dev/nvme0n1p3
Post by Pascal Hambourg
The above cryptsetup luksOpen command should go here.
Ok. Thanks, so here I should run:

cryptsetup luksOpen --allow-discards /dev/nvme0n1p3 slackluks

pvcreate /dev/mapper/slackluks

Thereafter:

vgcreate cryptvg /dev/mapper/slackluks

lvcreate -L 1690G -n root cryptvg
Post by Pascal Hambourg
My usual advice : do not allocate all the space in the VG. Leave plenty
of available space for future allocations. Extending an LV is easy
(lvextend + resize2fs) and can usually be done online. Reducing an LV
and its contents to free some space is more difficult and error-prone
and must often be done offline.
lvcreate -L 9G -n swap cryptvg

Then:

mkswap /dev/crypt/swap

Thereafter continue with 'chroot /mnt' and use the
mkinitrd_command_generator.sh script procedure and finally update lilo.
Post by Pascal Hambourg
Post by Tuxedo
As an only user of the system, I guess there's no useful reason to make a
separate 'home' lv.
Instead, my single user directory can simply exist in the same logical
volume. It would remove the need of possibly having to adjust the volumes
sizes later in case too little or too much is allocated to a root vs. home.
My above advice addresses this concern.
Thanks - I will adjust the partitioning and give it a test-run!

Tuxedo
Pascal Hambourg
2018-09-05 19:24:50 UTC
Permalink
Post by Tuxedo
cryptsetup -s 256 -y luksFormat /dev/nvme0n1p3
cryptsetup luksOpen --allow-discards /dev/nvme0n1p3 slackluks
pvcreate /dev/mapper/slackluks
vgcreate cryptvg /dev/mapper/slackluks
lvcreate -L 1690G -n root cryptvg
lvcreate -L 9G -n swap cryptvg
mkswap /dev/crypt/swap
The root LV should be formatted with the desired filesystem type.
Post by Tuxedo
Thereafter continue with 'chroot /mnt' and use the
mkinitrd_command_generator.sh script procedure and finally update lilo.
This is becoming Slackware specific. I cannot help you on this.
Tuxedo
2018-09-05 19:51:00 UTC
Permalink
Pascal Hambourg wrote:

[...]
Post by Pascal Hambourg
The root LV should be formatted with the desired filesystem type.
Ok. I think the Slackware menu installer will take me through that step,
offering quick or slow formatting options.

So far fdisk -l returns:

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 (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdb1741a4

Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 195313663 195311616 93.1G 7 HPFS/NTFS/exFAT
/dev/nvme0n1p2 195313664 195606527 292864 143M 83 Linux
/dev/nvme0n1p3 195606528 3907028991 3711422464 1.7T 83 Linux
Post by Pascal Hambourg
Post by Tuxedo
Thereafter continue with 'chroot /mnt' and use the
mkinitrd_command_generator.sh script procedure and finally update lilo.
This is becoming Slackware specific. I cannot help you on this.
I'll follow the Slackware installation instructions :-)

Tuxedo

Loading...