OpenSUSE 13 fstab appears to have changed its format.
How do I install a tmpfs in version 13.2?
The format of fstab has not changed.
Why do you think so?
How do I install a tmpfs in version 13.2?
Similar to earlier versions.
You basically have two options:
- create an entry in the fstab, something like:
tmpfs /tmp tmpfs nodev,nosuid,size=2G 0 0
- create a systemd unit
Actually one is already included: /usr/lib/systemd/system/tmp.mount
You’d just have to enable this somehow…
“sudo systemctl start tmp.mount” will remount /tmp on a tmpfs, but “sudo systemctl enable tmp.mount” does not work. Maybe creating a symlink in “default.target.wants” will work?
sudo ln -s /usr/lib/systemd/system/tmp.mount /etc/systemd/system/default.target.wants/
On 2014-12-29 13:06, wolfi323 wrote:
>
> johngwalker;2685731 Wrote:
>> OpenSUSE 13 fstab appears to have changed its format.
> The format of fstab has not changed.
> Why do you think so?
It has changed the contents 
That’s what he probably means.
But I don’t see it has entries for tmpfs in my test system. The output
of “mount” does show them, so they are not done via fstab. Perhaps
systemd units.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes, the existing tmpfs’s are mounted by systemd.
But those are irrelevant to “install a tmpfs in version 13.2” I’d say… 
As I understand it he wants to mount /tmp as a tmpfs. A /tmp entry never has been in the fstab by default (on openSUSE at least).
Yes, I’d like to load /tmp as a tmpfs, which I have done before. If all I do is add the line that I have previously added, you suggest, then there will be no problem. So thank you for that.
However, my initial attempt to change things was a bit of a ****-up, and now KDE won’t load. I have the original fstab saved in /etc under the name fstab.original (I’m risk-averse like that) but I can’t rename it back to fstab, nor can I get ris of my amended fstab, because, whatever, I do, the partition is loaded as read-only. I’ve tried loading a rescue cd without success.
So how do I load the partition as read-write in order to change the name of the file?
Sorry to dump a subsequent question on you.
Well, I’m not 100% sure that the line will work as it is (in particular regarding the mount options), I have it from the Arch Wiki.
It was merely meant as an example for the syntax, and I haven’t tried it myself either.
However, my initial attempt to change things was a bit of a ****-up, and now KDE won’t load. I have the original fstab saved in /etc under the name fstab.original (I’m risk-averse like that) but I can’t rename it back to fstab, nor can I get ris of my amended fstab, because, whatever, I do, the partition is loaded as read-only. I’ve tried loading a rescue cd without success.
KDE will fail to start if it cannot write to /tmp.
But creating a wrong /tmp entry in the fstab should not cause your whole / partition become read-only.
Normally this only happens if there’s some error in the filesystem. Would be a strange coincidence though, so maybe you made some mistake when editing the fstab.
Can you post the file?
So how do I load the partition as read-write in order to change the name of the file?
Depending on why the partition is mounted read-only, you might be able to remount it read-write with:
sudo mount / -o rw,remount
If that doesn’t work, boot from a LiveCD, or try one of the following:
- add “init=/bin/sh” to the boot options, this should get you in a minimal text mode system, with / mounted read-write (hopefully)
- add “rd.break” to the boot options, this will stop the boot process just before / is mounted read-write and the system is switched to the real /. At this point / is mounted read-only to /sysroot, you should be able to mount it read-write via “mount /sysroot -o rw,remount”, or you can also unmount it and run fsck e.g.
Restore fstab with “cp /sysroot/etc/fstab.original /sysroot/etc/fstab”
You can modify the boot options by pressing ‘e’ at the boot menu screen, then search for the line starting with “linux” and append the wanted option at the end. Then press ‘F10’ to boot.
You no longer have to do the fstab line to use /tmp as tmpfs it is done in initrd
To be certain once you get it running do a mount command and see how /tmp is mounted
Thanks, that was very helpful. Even after following the instructions it needed liberal use of sudo, but I have managed to log on via KDE, which all I was asking to be able to do. So thank you for your prompt replies, both of you.
And yes, I’d done more than changed the /tmp line. I’d made a complete pig’s ear of the file. But, fortunately, I have a habit of renaming essential files before playing with them. So now I know how to get it back I’m a happy bunny 
gogalthorp,
I didn’t see your post until after I’d made what I thought was my last one. I ran mount once I’d logged in and /tmp doesn’t appear to be in a tmpfs.
Mount gives me
/dev/sda3 on /tmp type btrfs (rw,relatime,space_cache)
I’m afriad I’m not used to reading these things, but it seems to say that /tmp is on my hard drive.
I’ll add a line to my ftstab and see what mount says after I reboot.
There is a line in the original fastab allocating /tmp to the hard drive. I added a line allocating it to tmpfs and had to remove the original line. Mount now gives me
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
Success, I think.
So thanks to all of you. Hopefully my experiments have helped your knowledge in some small way as well.
There is not normally.
But, if you use btrfs, starting with 13.2 entries in the fstab are created for all subvolumes, and one of them is indeed /tmp (this is not done to mount it though, but to make it easier to specify options for the separate subvolumes I think).
In this case, you have to remove that one first (or modify it accordingly), yes.
Sorry, I forgot about this.
On 2014-12-29 19:26, wolfi323 wrote:
> Sorry, I forgot about this.
Me too. As my 13.2 test system doesn’t have btrfs on root, I did not
notice the change when I looked.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-12-29 19:16, johngwalker wrote:
>
> There is a line in the original fastab allocating /tmp to the hard
> drive. I added a line allocating it to tmpfs and had to remove the
> original line. Mount now gives me
>
>> tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
As there is already a tmpfs, one thing to check is whether your tmpfs is
using a separate space or the same one. A separate one uses more ram,
obviously. I’m unsure how to verify this.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I do have one 13.2 system with root on btrfs. But that was freshly installed with 13.1 (choosing btrfs as root) over a year ago, and upgraded to 13.2 via “zypper dup”.
The 13.1 installer did not add the subvolumes to the fstab yet (this is new with 13.2), and the upgrade didn’t either.
AFAIK, each tmpfs will only use as much RAM as it needs. The size that can be specified is only the maximum size.
I don’t think that multiple tmpfs’s can use the same space therefore.
On 2014-12-29 21:36, wolfi323 wrote:
> I do have one 13.2 system with root on btrfs. But that was freshly
> installed with 13.1 (choosing btrfs as root) over a year ago, and
> upgraded to 13.2 via “zypper dup”.
> The 13.1 installer did not add the subvolumes to the fstab yet (this is
> new with 13.2), and the upgrade didn’t either.
Possibly the update via DVD might have done the change. They have done other changes…
>> As there is already a tmpfs, one thing to check is whether your tmpfs is
>> using a separate space or the same one. A separate one uses more ram,
>> obviously. I’m unsure how to verify this.
>>
>
> AFAIK, each tmpfs will only use as much RAM as it needs. The size that
> can be specified is only the maximum size.
> I don’t think that multiple tmpfs’s can use the same space therefore.
Well, they do, actually. Or some do.
Telcontar:~ # df -h | grep tmpfs
devtmpfs 3.9G 64K 3.9G 1% /dev
tmpfs 4.0G 1.5M 4.0G 1% /dev/shm
tmpfs 4.0G 355M 3.6G 9% /run
tmpfs 4.0G 0 4.0G 0% /sys/fs/cgroup
tmpfs 4.0G 355M 3.6G 9% /var/lock
tmpfs 4.0G 355M 3.6G 9% /var/run
Telcontar:~ #
Now I write a file to one of them:
elcontar:~ # dd if=/dev/zero of=/var/run/deleteme bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.06298 s, 1.7 GB/s
Telcontar:~ # df -h | grep tmpfs
devtmpfs 3.9G 64K 3.9G 1% /dev
tmpfs 4.0G 1.5M 4.0G 1% /dev/shm
tmpfs 4.0G 455M 3.5G 12% /run
tmpfs 4.0G 0 4.0G 0% /sys/fs/cgroup
tmpfs 4.0G 455M 3.5G 12% /var/lock
tmpfs 4.0G 455M 3.5G 12% /var/run
Telcontar:~ #
See the equal increase in /var/lock and /var/run and /run mounts? They are the same space.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Well, at least /run and /var/run are actually the same filesystem, the latter is a bind mount of the former. So of course they take “the same space”.
And /var/lock is probably a bind mount of /run/lock, which is also on the same filesystem.
Btw, on my 13.2 system here I don’t have all those tmpfses any more:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 75G 75G 357M 100% /
devtmpfs 996M 0 996M 0% /dev
tmpfs 1003M 0 1003M 0% /dev/shm
tmpfs 1003M 1.3M 1002M 1% /run
tmpfs 1003M 0 1003M 0% /sys/fs/cgroup
/dev/sdb1 110G 109G 1.3G 99% /windows/C
# mount | grep tmpfs
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1019860k,nr_inodes=254965,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
/var/lock is a symlink to /run/lock, and /var/run a symlink to /run:
# ls -l /var/total 21
drwxr-xr-x 2 root root 72 8. Okt 16:30 account
drwxr-xr-x 11 root root 440 1. Dez 19:52 adm
lrwxrwxrwx 1 root root 11 4. Nov 20:43 agentx -> /run/agentx
drwxr-xr-x 21 root root 536 29. Dez 10:58 cache
drwxr-xr-x 2 root root 48 25. Sep 10:12 crash
drwxr-xr-x 2 root root 72 31. Mai 2012 db
drwxr-xr-x 9 root root 488 20. Dez 08:07 games
drwxr-xr-x 76 root root 2000 30. Dez 00:00 lib
lrwxrwxrwx 1 root root 11 3. Nov 18:35 lock -> ../run/lock
drwxr-xr-x 24 root root 9128 30. Dez 00:00 log
lrwxrwxrwx 1 root root 10 4. Nov 17:23 mail -> spool/mail
drwxr-xr-x 3 root root 72 9. Mär 2012 mpi-selector
drwxr-xr-x 2 root root 48 25. Sep 10:12 opt
lrwxrwxrwx 1 root root 6 3. Nov 18:35 run -> ../run
drwxr-xr-x 14 root root 368 4. Nov 17:23 spool
drwxrwxrwt 303 root root 9960 30. Dez 00:06 tmp
drwxr-xr-x 3 root root 104 25. Sep 14:49 yp
And no, I did not change anything myself regarding this.
On 2014-12-30 00:26, wolfi323 wrote:
>
> robin_listas;2685898 Wrote:
>> See the equal increase in /var/lock and /var/run and /run mounts? They
>> are the same space.
> Well, at least /run and /var/run are actually the same filesystem, the
> latter is a bind mount of the former. So of course they take “the same
> space”.
Ow. Bind. Of course!
> Btw, on my 13.2 system here I don’t have all those tmpfses any more:
Ah, that paragraph was from my 13.1 system. on 13.2 I have:
oS-13-2:~ # df -h | grep tmpfs
devtmpfs 363M 0 363M 0% /dev
tmpfs 368M 0 368M 0% /dev/shm
tmpfs 368M 5,9M 362M 2% /run
tmpfs 368M 0 368M 0% /sys/fs/cgroup
oS-13-2:~ #
which is the same as you have.
> /var/lock is a symlink to /run/lock, and /var/run a symlink to /run:
Yep. But not in 13.1.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
What do you recommend putting into a tmpfs? I’ve only ever had /tmp recommended to me, but I can see the point of having everything that can be thrown away held in memnory.
On 2014-12-30 02:26, johngwalker wrote:
>
> What do you recommend putting into a tmpfs? I’ve only ever had /tmp
> recommended to me, but I can see the point of having everything that can
> be thrown away held in memnory.
You get advantage with files that are accessed a lot. And files that are
known to be temporary are already stored on those directories.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Thanks, but I’m looking for directory names. Nothing in the default fstab is assigned to a tmpfs. but I’ve assigned /tmp. Are there any others I should add?