You are not logged in.
According to the wiki, https://wiki.archlinux.org/index.php/Dm … stallation
I'm supposed to issue the command
# dd if=/dev/zero of=/file/in/container status=progress I have exactly the setup described in https://wiki.archlinux.org/index.php/Dm … _partition
with no optional partitions, just unencrypted /boot and encrypted /
Can I literally issue the command with '/file/in/container', or should I be careful to replace it with something else?
Of course, I do not want to nuke my stuff, just wipe the free space preserving my installation.
Offline
/file/in/container could also be described as /path/to/mountpoint/somefile
in case of the root filesystem the /path/to/mountpoint is simply /
please note that doing so will (temporarily) cause your system to run out of disk space, which leads to "no space left on device" errors, which leads to real data loss. so consider doing this off some live cd where no other processes are running or attempting to write to that filesystems.
furthermore in case this is lvm on luks and the rootlv is just small part of the container, that does not do the intended wipe at all
also there's only a need to do so if you want to get rid of old unencrypted data like from a previous install. if you installed this on a new drive; or if this is a SSD where free space will be trimmed anyway, there's nothing to do. it's normal for freespace to be visible. data's still encrypted regardless.
Last edited by frostschutz (2019-08-30 12:31:59)
Offline
The idea is that you replace that with the path to a file within the encrypted container. So in your case, since your encrypted container is '/', you could indeed just use that (or any other) arbitrary path (since files created on the '/' mount would be part of the encrypted container, excluding /boot/.... in your case ofc. since that's another mount).
If your encrypted container was '/home' instead of '/', you'd have to adapt to a file in that path instead; e.g. /home/some/file
EDIT: Also, if you're using a filesystem that compresses data, this may not work at all since it is all 0's and thus easily compressed instead of actually written out to disk in full.
Last edited by Omar007 (2019-08-30 12:39:48)
Offline
Thanks.
I understand '/sometestfile' would work for me, with the caveat of 'no space left' errors.
This install is on top of a previous one, my laptop has an SSD, and I use the standard ext4 filesystem.
Should I still do the wipe or perhaps look at trim or else?
Offline
If the SSD is connected using SATA Solid_state_drive/Memory_cell_clearing
If it uses NVME use nvme-cli instead [1]
[1] http://forum.notebookreview.com/threads … ux.827525/
Edit:
Note the above will wipe all the device including reserved cells to 0 rather than filling the cells the device has exposed with a random pattern.
Last edited by loqs (2019-08-30 14:20:39)
Offline
I was looking to preserve my installation, but thanks for the reference, it is very detailed.
My drive is nvme.
Is it still worth to enable periodic trim? after I enabled it and rebooted, I only got
sudo journalctl -u fstrim.timer
systemd[1]: Started Discard unused blocks once a week.but nothing for fstrim.service itself.
Offline
systemctl list-timersOffline
for trim through a luks device you need cryptsetup with allow-discards enabled.
verify with 'dmsetup table | grep crypt', crypt devices of SSD should end with 'allow_discards'
luksSSD1: 0 268608848 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 9:0 4096 1 allow_discardsOffline
NEXT LEFT LAST PASSED UNIT ACTIVATES
Sun 2019-09-01 00:00:00 CEST 13h left Sat 2019-08-31 00:09:58 CEST 10h ago logrotate.timer logrotate.service
Sun 2019-09-01 00:00:00 CEST 13h left Sat 2019-08-31 00:09:58 CEST 10h ago man-db.timer man-db.service
Sun 2019-09-01 00:00:00 CEST 13h left Sat 2019-08-31 00:09:58 CEST 10h ago shadow.timer shadow.service
Sun 2019-09-01 09:42:29 CEST 22h left Sat 2019-08-31 00:18:44 CEST 10h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2019-09-02 00:00:00 CEST 1 day 13h left Fri 2019-08-30 16:19:18 CEST 18h ago fstrim.timer fstrim.service
5 timers listed.
Pass --all to see loaded but inactive timers, too.but
sudo dmsetup table | grep crypt
cryptroot: 0 999131791 crypt aes-xts-plain64 ... ...does not show 'allow_discards'.
Should I edit the mkinitcpio?
Offline
Offline