Preparing OpenSuse to run from a read-only rootfs

English Forums Feedback
1

How to run OpenSuse from a read-only rootfs (e.g. on a USB stick with the write-protection switch enabled)
This guide will also apply to other distributions, possibly with small modifications.
With thanks to my friend who developed this procedure. Can be freely copied.

Benefit:

  • during normal use the USB stick is write protected (e.g. while surfing on the internet) and the system cannot be changed (intrusion protection)
  • the Linux distribution can be setup as desired and additional packages can be added
  • compared to a typical Live distribution which runs its entire rootfs from a ramdisk, this solution uses less memory
  • compared to a typical Live distribution which runs its entire rootfs from a ramdisk, this solution makes it easy to install new and updated packages, and change program settings

Procedure:
[ul]
[li]insert your USB stick with the write protection functionality disabled (for now, so we can install) [/li][li]start a regular distribution install but instead of installing on a harddrive install to the USB stick [/li][li]at the partitioning section change the regular procedure:[/li][LIST]
[li]select a file system (fs) without journaling to reduce the wear of the USB stick, use e.g. ext2[/li]or ext4 and change options (e.g. in SuSe: no Journal, noatime)
or remove the journal later with: tunefs -O ^has_journal /dev/sdxX
[li]if your entire disk device will be read-only (e.g. USB stick with write switch): allow no swap partition [/li][li]mount no other partition (e.g. /home) [/li][/ul]

[li]at the GRUB setup ensure that the boot manager needs to be in the MBR of the USB stick (select → install boot code in MBR) [/li][li]finish installation and set your preferences in the programs you intend to use (to store them on the USB stick for later use) [/li][li]you can now boot from the USB stick installation but it will still be in write-enabled mode, so you can make the changes you want. [/li][/LIST]
After installation further measures to prepare working in readonly mode and reducing the wear of the USB stick should be made. You can also do this by mounting the USB stick (still in write-mode) on another Linux device.

[ul]
[li]in /etc/fstab[/li][LIST]
[li]change: UUID=… / ext2 acl, user_xattr 1 1 [/li]to UUID=… / ext2 acl, user_xattr,noatime,nodiratime 1 1
[li]add:[/li]tmpfs /tmp tmpfs nodev,nosuid 0 0
tmpfs /var/log tmpfs nodev,nosuid 0 0
tmpfs /var/tmp tmpfs nodev,nosuid 0 0
tmpfs /home tmpfs nodev,nosuid 0 0
[li]If your system needs any other directories to be writable, add similar tmpfs lines for those locations as well. [/li][/ul]

[/LIST]

[ul]
[li] in /etc/rc.d/boot.local (or /etc/init.d/boot.local)[/li][LIST]
[li]add:[/li]if [ -z “$(ls /home)” ]; then
cp -a /var/user /home
fi
[i]# the home-folder used, now depends on fstab and whether the tmpfs is used or not (tmpfs is allways fresh and therefore empty)

this means you need to copy your real /home/user-folder to /var to make it available for this command. This should be done after you adjusted all your settings (e.g. in web browsers or e-mail programs) and before you reboot with the USB write protection switch set to read only

the copying is done by 1) cd /home 2) cp -a user /var

replace “user” by your user account name

[/i]
[/ul]

[li] Copy the contents of /home/user to /var/user as per the instructions above, replacing “user” with your actual username. [/li][/LIST]

Now you can enable the write-protection switch on your USB stick and boot from it in read-only mode.
NOTE: all changes to tmpfs directories are lost at shutdown! To save any files mount a w/r medium (e.g. another USB stick) and store data there.

If you want to update your system, change settings or add programs, you need to first switch the write-protection off again, and then mount the USB stick in another Linux system to edit fstab. Comment out all the lines starting with tmpfs. Then boot from the USB stick, you will have your system in r/w mode again. Remember to synchronize any changes you make in /home/user with the copy of your home directory in /var/user.

Note: if you try to boot from the USB stick with the write-protection turned on, but the tmpfs lines are missing or commented out from /etc/fstab, then your system will not boot because it needs to be able to write to /tmp, /var/log, /var/tmp and /home.

Possible issues:
My system had access to the local network and could reach the router but not the internet. Fixed it with:
root# ip route add default via 192.168.x.y
where 192.168.x.y is the gateway / router address; check with “ip route” whether the command was successful

Optional change:
To speed up booting (reduce wait time for the Grub2 boot menue and allow only the system on the USB stick)
change in /etc/default/grub the following three lines as root:
[i]GRUB_DEFAULT=0
…
GRUB_TIMEOUT=1
…
GRUB_DISABLE_OS_PROBER=true

[/i]Save the file and to update grub.cfg by running the appropriate command for your system:
grub2-mkconfig -o /boot/grub2/grub.cfg (openSUSE w/ Bios)
grub2-mkconfig -o /boot/grub2-efi/grub.cfg (openSUSE w/ EFI)
update-grub (Debian and Ubuntu)
grub2-mkconfig -o /etc/grub2.cfg (Fedora w/ Bios)
grub2-mkconfig -o /etc/grub2-efi.cfg (Fedora w/ EFI)

2

Interesting. Thanks for posting.

Do you have any idea about he minimum amount of memory needed. After all there is no swap available and several parts of the direcctory tree are in memory as tmpfs. I understand that it depends much on the intended usage, but it could be that you have some experiences already.

3

Have you considered using “overlayfs”?

I mention that, because it is what recent live media seem to do. The “initrd” mounts the read-only file system somewhere. Then it creates and mounts a second read-write file system (could be “tmpfs”). Then it make “/” an overlay, with the read-only file system and the read-write file system overlaid on top. Anything written goes to the read/write version. And the read-write part of the overlay is “tmpfs”, then it is lost on reboot.

4

That is a good suggestion. We have indeed discussed overlayfs and unionfs, but since the procedure in the guide worked for our purposes, we did not explore it further.

A possible downside of the procedure in this guide, is that you need to manually edit /etc/fstab each time you want to boot the system in r/w mode. I’m sure it would be possible to write a script (in the initrd?) that checks whether or not the stick is writable, and if yes, substitutes the proper fstab for that situation. If anyone has the time to make and test such an addition, I’d be happy if you shared it here.

Sorry, we don’t have any exact data on the extra memory usage this generates. All I can say is that it will be less than the memory usage of a typical Live system with everything in tmpfs. So if you can run such a live stick, then you can run this - and with more free RAM.

The empty tmpfs structures themselves don’t cost too much, so this should work on a computer meeting the minimum requirement for openSuse 13.2 (1 GB RAM). When using something leaner like Debian without too many frills, I reckon it should work on less as well. As soon as you start getting files in /tmp this will use more memory - but that is true for any live system.

In principle there is nothing stopping you from adding a swap partition on a second device, but many people will use a system like this for privacy/security reasons, in which case swap space is not wanted.

5

Thanks for the answer. I have openSUSE 13.1 (with KDE) running here on 2GB and that is OK. Due to a hardware problem I run on 1GB for a week. Even that is quite possible, but now and then bit of swapping (and thus waiting a few seconds) is introduced. Thus my advice would be from about 2GB upwards would be fine.

Very true.

6

Skimming the OP’s post…

  • Doesn’t mounting the home directory as a subdirectory of /var/ simply mount the directory into RAM? That’d be OK to get around the “read only” disk fs but if the content is to be preserved beyond a shutdown, you’d still need to mount it somewhere that is rw.
  • IMO an important method for building and installing openSUSE on a flash dongle is to consider using Kiwi to build yourself a custom JeOS image (unless you really do want a full default install). Today, a default JeOS image is about 650mb (investigating why this isn’t closer to 212MB like most distros. Understand YAST and Ruby is a partial reason but doesn’t nearly account for the diff)
  • AFAIK ext2 doesn’t implement journaling, so the “noatime” flag is unnecessary (in the fstab).
  • Same as above for “nodiratime”
  • Although ext2 and ext4 ordinarily should be the main choices, if the entire fs is “read only” I’m not sure whether there is any purpose for any of these flags, for example how would journaling be written if the disk is read only?
  • Particular for non-SSD drives, if installing on a dongle alternative fs designed specifically for flash memory might be considered, a pretty good list exists on Arch Linux Wiki
    https://en.wikipedia.org/wiki/List_of_file_systems#File_systems_optimized_for_flash_memory.2C_solid_state_media
  • In fact, there is so much new good and critically important stuff like required and optional firmware updates IMO the Arch Linux Wiki should be skimmed <every time> before a new install
    https://wiki.archlinux.org/index.php/Solid_State_Drives

The “Possible Issue” re network configuration.
Likely a DHCP issue.

The “Optional Change”
User preference, certainly not a problem.

My current evaluation is that the steps described here are good for consideration, but individual steps I described should be looked at more closely.

IMO,
TSU