I have a simple script that creates a zram device and formats it to ext4 and finally, it mounts zram on /tmp.


# create zram with size 1.5G
# $zram_dev is created device path (eg. /dev/zram1)
zram_dev=$(/usr/sbin/zramctl -f -s 1536M)

# format it to ext4
yes | /usr/sbin/mkfs.ext4 $zram_dev 

# mount it on /tmp
/usr/bin/mount $zram_dev /tmp

It works when I manually run it. But obviously, I don't want to run it after every login.

I put that script in root crontab and I rebooted the system, and then I couldn't get my graphical interface, I removed it from crontab and everything worked fine.

And at the end of the day, I changed the mount directory to something else like /zram and rebooted the system, surprisingly system comes up. (zram device was created and was mounted on /zram)

I should mention that I tried to do that automation with systemd service and I get the same result I just want to know why I can't mount the zram device on /tmp?

OS: Linux fedora 5.17.5-300.fc36.x86_64 #1 SMP PREEMPT x86_64 x86_64 x86_64 GNU/Linux

1 Answer 1


I am also asking myself how to access/mout/"open" the zram-swap manually (it seems to be by default in /var) - for the same reasons as you, btw., but I have not found any info about it yet.

But what I can say is: afaik, the zramfs-thing is compressed; imagine it's encrypted, anyway undisplayable like an (almost?) whole binary file... So I doubt that you will be able to access it as it were some ordinary ext4 partition. That explains why it works to "format" it while your system doesn't get how to mount "this strange thing" (you even can unmount /boot and shred it or "apt purge" via su(do) packages, without which your system won't boot or do anything at all... anyway, you can nuke everything what root can do ("#rm -r"-ing /etc/, /bin, /sbin, the very essential files. BUT only one (and prob. one only) when logged in yet and/or your system has booted / is running. Afterwards -> "booting problems" , ofc if there won't be any issues before. The more essential, the earlier it's loaded into memory/RAM I assume. You don't guess how often I "played around" with something in this context and messed up everything or almost everything (a little off-topic: DO BACKUPS to another drive and/or some webspace/cloud, the latter for the most important files to you; I even automatized this actually nothing but zip/tar/rar and rsync/cp (versioned names or overwrite/replace without any confirmations), KDE since Debian 11 has in it's systemsettings5 a GUI for scheduled and regular backups, I mean some simple gui, nobody needs fancy backup-tools if # crontab -e and even an one-liner can save your data if booting or else fails badly (always(!!) run crontab -e with "-e" or your cronta will be resetted!) Although it's strange that it is letting you formatting/changing it even as root...

Anyway, I would advise you to post (the relevant line(s) if not all) of /etc/fstab as well as any other scripts you wrote by yourself or modified with the goal to mount (/tmp or sth more) so people who are more experienced than me may help you if it's possible to find a positive answer to your question.

Also take a look into $ man zramctl and run $ df -h and $ mount (outputs of latter two MAY be of use for a solution). I received now the following:

    # sudo swapon --all
    # sudo zramctl
    /dev/zram0 lz4             2G 14.7M  1.7M  2.1M      12 [SWAP]
    # sudo swapon --show
    /dev/dm-2  partition 980M   0B   -2
    /dev/zram0 partition   2G  48M   90

Well, you see, mountpoint "[SWAP]"... can't remember that "conventional" disk-swapping gives you the possibility to access it manually. I guess if some program performs I/O on any (zram-)swap(-partition) the system or even kernel manages what is written and read and where inside any swap-device. Can't find it but I'm pretty sure my zram0 was a file inside /var(subdir...?) at the default size then, back few months ago. dm-2 is the disk-swap which is empty because it's off. Like the manpages tell you, anyway zram#-s are block-devices and disk-swap-devices too, at least I gott that from it's name (dm-2, stands afaik for disk-mapper#2)

Well I rather doubt that we will find a solution we seek for. But if it's possible, I am interested as well. I hope I coulld give you any thoughts, idea or inspiration...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .