#gentoolinux — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #gentoolinux, aggregated by home.social.
-
Not a #TIL (Today I Learned) about Linux, but a common misunderstanding I see in every Arch installation guide that isn't the ArchWiki:
People want to enable TRIM to conserve their SSD's lifespan, and thus they execute the following command:
```
systemctl enable --now fstrim.timer
```That command by itself does absolutely nothing. All it does is create a scheduled job to trim (that is, discard unused blocks) the SSD (by default once a week), but it will (silently) fail every single week because the SSD's support for TRIM was never activated.
You can verify for yourself that this is true by executing the following command. It will tell you (for all mounted filesystems) that TRIM isn't supported by this device.
```
fstrim --all --verbose
```Alternatively, execute this:
```
lsblk --discard
```What you need to also do is enable TRIM support when you decrypted your encrypted partition, by passing the two flags `--allow-discards --persistent`.
```
partition='sda2'
device_mapper_file_name='root'cryptsetup --allow-discards --persistent open \
/dev/${partition} \
${device_mapper_file_name}
```The `cryptsetup` command with the `--persistent` flag and `--allow-discards` flag will activate the TRIM flag in the LUKS metadata. You need to set this flag only once.
Use the command `cryptsetup refresh` rather than `cryptsetup open` for already existing installations.
Now the command `fstrim --all --verbose` should execute successfully, showing you that TRIM is correctly set up.
-
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
🧵⬆️ For example: The Arch wiki says¹ that when I give my home partition the very specific name `/dev/mapper/home` chosen by Poettering and not something arbitrary like `/dev/mapper/home_partition`, then systemd will create a symlink in `/dev/disk/by-designator/` and I can henceforth use the following names
- `/dev/disk/by-designator/home` to refer to the unlocked volume
- `/dev/disk/by-designator/home-luks` to refer to the encrypted partitionto make use of persistent naming methods and to become able to avoid having to hard-code UUIDs into `/etc/fstab`.
But this works only if I use the particular names that Poettering has in mind, like `home` (rather than something arbitrary that I come up with, like `davids_home` or `home_partition`). This is a constructed example to illustrate the point.
So far I can follow Poettering's thinking. But all of this falls apart as soon as LVM (Logical Volume Manager) comes into play.
I don't see the benefits of following Poettering's Discoverable Partitions Specification and thus don't see why I should follow it if I want to use LVM (Logical Volume Manager).
¹ https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Using_systemd-cryptsetup-generator
-
#Linux Does someone understand how Lennart Poettering's Discoverable Partitions Specification¹ integrates with Logical Volume Manager (LVM)?
Poettering insists that I give my partitions very specific names so that systemd can auto-mount the partitions for me and `/etc/fstab` becomes obsolete, to name just one of the motivations/benefits. If I LUKS-encrypt my partitions, Poettering wants that I name my partitions either of these pre-defined names:²
- /dev/mapper/root
- /dev/mapper/usr
- /dev/mapper/home
- /dev/mapper/srv
- /dev/mapper/esp
- /dev/mapper/xbootldr
- /dev/mapper/swap
- /dev/mapper/root-verity
- /dev/mapper/root-verity-sig
- /dev/mapper/usr-verity
- /dev/mapper/usr-verity-sig
- /dev/mapper/tmp
- /dev/mapper/varI can follow Poettering's thinking (even if you or I don't need to agree with it) … so long as nobody ever uses LVM.
If I add a second SSD to my computer, create just a single partition on it, LUKS-encrypt it and add a volume group on top of LUKS, which I then split into, say, three logical volumes: `/home`, `/var`, and `/var/log` to construct just a random example.
- Why should I name the underlying device mapper file `/dev/mapper/home` when there's more than `/home` on that volume group?
- If I named the device mapper file something arbitrary like `/dev/mapper/davids-lvm-container`, then LVM also wouldn't work with Poettering's Discoverable Partitions Specification. If I use LVM for everything, then none of the benefits motivated by Poettering work, even if I do as Poettering suggests. And if none of the benefits works anyway, then why should I bother using the names that Poettering suggests rather than the names I find intuitive, even if that means I have to keep `/etc/fstab` around and keep doing the things manually that everyone's always been doing manually anway?My ability to follow Poettering's thinking falls apart when I pull LVM into the equation.
Does Poettering not use LVM (Logical Volume Manager)? Am I missing something?
If I could see any benefit in doing things the way Poettering suggests, I would do it. I just don't see the benefits (when using LVM at least).
¹ https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
² https://man.archlinux.org/man/systemd.image-filter.7 -
#TIL (Today I Learned) that when you use LVM (Logical Volume Manager) on Linux (to abstract your storage), you should prefer the volume path
/dev/my_volume_group/my_logical_volume
provided by LVM over the more low-level volume path
/dev/mapper/my_volume_group-my_logical_volume
that is provided by the underlying device mapper framework.
You should never interact with the underlying device mapper framework directly, and rather interact indirectly with it through the LVM and/or cryptsetup abstractions because the filepaths provided by the device mapper framework are 'intended for "internal use" and subject to possible "change between releases and distributions",' as the Arch Wiki puts it.
Sources:
- https://man.archlinux.org/man/lvm.8#VALID_NAMES
- https://wiki.archlinux.org/title/LVM#LVM_building_blocks -
Gentoo was trying to download rust-bin 1.74.1 to compile rust 1.74.1 to compile rust 1.75.0 to compile rust 1.76.0 to compile rust 1.77.1 to compile rust 1.78.0 to compile rust 1.79.0 to compile rust 1.80.1 to compile rust 1.81.0 to compile rust 1.82.0 to compile rust 1.83.0 to compile rust 1.84.1 to compile rust 1.85.1 to compile rust 1.86.0 to compile rust 1.87.0 to compile rust 1.88.0 to compile rust 1.89.0 🫠
-
#Kuroko and #Bim both on my #GentooLinux system
Am I just switching to #ToaruOS tools entirely now?
What next? #Yutani on Linux??? (Actually, that's not a bad idea...)
-