Nonpersistant image of a working hdd (or other solution)

allright, i have been banging my head against a wall for this problem (or wish) i have and i think it is time to get help.

here is what i am trying to do,
i want a nonpersistant picture of a harddrive that works and boots but resets it self at shutdown.
i would like to use manjaro as it is the distro that i am most familjar with, (except raspian)

i started out with installing manjaro on a harddrive, after a while i started to realise how much it saves, so i tried to tmpfs mount places of intrest. but i started to realise that it is like trying to patch a gaping hole with a bandaid,

so i stated to look to make an iso out of my harddrive and run it in ventoy. i tried to use dd and clonezilla, i tried to take a picture of the whole disk or just the partitions but it never seemd to work, i think if i understand right dd does not make a iso per se, and i still need the uefi boot partition. and i belive that the os still need to write stuff. managed to get clonezilla to make a picture (not iso) but i gave up here due to the need of not beeing writeprotective

next idea, overlayfs,
this seems like the best idea, freeze root and use tmpfs as a write to storage.
but i have a very hard time to get this to work
i have been using iask.ai to find me solutions of linux problems and it throws this at me

sudo pacman -S overlayroot
sudo systemctl enable overlayroot

this would have been the easiest i think, however it seems overlayroot is not there, and what i can find from the appstore (?) is a fuse something overlayfs

iask.ai gives me this command to use overlayfs
mount -t overlay overlay -o lowerdir=/lower,upperdir=/upper,workdir=/work/merged
and i should add this to fstab
overlay /merged overlay noauto,x-systemd.automount,lowerdir=/lower,upperdir=/upper,workdir=/work 0 0

but i cant seem to make the lowerdir the whole root, or rather i dont know how. nor do i know how to make the working dir a tmpfs.

so could anyone help me with this?

i cant use live usb due to there is a program that i want added and i dont want to install it every single time, i cant use archiso due to…stuff? the program is non arch standard and i dont know it how does it things that it do. i cant also not load everything into tmpfs even if that was possible in manjaro. the program in question is around 60gig in total. i just dont have that much ram.

in short, read os and program from hdd, all changes that are made goes to tmpfs (or other solution)

Thankyou in advance for help

ovelay filesystem - see Overlay filesystem - ArchWiki

roll your own ISO - Building a custom ISO image for X86 - as you can modify the result exactly to your liking - results can be stored on external device such as USB - reboot and any changes are gone.

That is something … and very unusual

Can it be done?

An ISO of +60G that could be possible - I don’t know if the ISO9660 supports that size but your assumptions that overlay would be better is … better.

I have no experience with overlay filesystem so this is thoughts based on the link above.

Assuming you have a standard user account and what ever you do is written to that users home.

I suggest testing in small scale before commiting to the actual implementation.

Create a an overlay folder

sudo mkdir /useroverlay

Test it - by doing

mount -t overlay overlay -o lowerdir=/home,upperdir=/useroverlay,work=/tmp

I am not entirely sure - as stated no experience - just able to read.

Perhaps GitHub - containers/fuse-overlayfs: FUSE implementation for overlayfs - in the repo

You would likely be able to use GitHub - hilderingt/archlinux-overlayroot: Overlay your read-only root filesystem with a volatile tmpfs filesystem with OverlayFS.

Have you considered imaging (cloning) the HDD as a virtual disk, and using a VM application to access it? VirtualBox, VMware (and others) usually have snapshot features which you may be able to leverage to return to a previous state when needed.

Perhaps this might be a manageable solution.

Cheers.

Maybe BTRFS or another file system with snapshots can help you.

  1. Create a system according to your wishes
  2. Create a snapshot of it (read-only).
  3. Do whatever you want every day
  4. At shutdown, create a writable (!) snapshot from (2) and replace the boot-default with this one.

:footprints:

it is not that can i cant read, it is just that i know the words but they are put together into meaning that i dont understand >< english is not my main language. it is a burden for me for sure and i do apologize,

anyway,

mount -t overlay overlay -o lowerdir=/home,upperdir=/useroverlay,work=/tmp`

gives me

mount: overlay: can't find in /etc/fstab.

i started to try out the last link you gave me and it gives me a bit of confusion,
maybe you could help me here,
it states
add overlayroot to your kernel command line
ai help here gave me that i should add it to

GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash udev.log_priority=3 overlayroot”

then archlinux-overlayroot stats that i could add more to
optional:

  • add opts=<option>,... to overlayroot=...
    does that mean that i should add it to the end of overlayroot in the grub files?
    as in

GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash udev.log_priority=3 overlayroot=tmpfs=all:opts=noswap overlayroot=ro=all”

then comes the changes to the config file and i have blasted clue what i should add here, (or what i am doing)
added

OVLROOT_FS_RAMONLY=“tmpfs”

as it seems that makes it not count tmpfs mounted things (or so i belive anyway)
then i added

OVLROOT_FSTAB=“/tmp/overlayroot.fstab”

but this maybe was unessesary?
anyway restarted and it gave me the funniest error message i have yet seen
ERROR: failed to mount the real root device, bailing out, you are own your own, good luck.

used a fallback on startup and here is were i am right now

something i did noticed is that root is
/.overlay/ro/
and

sudo mount

gives me


proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=32458732k,nr_inodes=8114683,mode=755,inode64)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
/dev/sda2 on /.overlay/ro type ext4 (ro,noatime)
overlayroot-tmpfs on /.overlay type tmpfs (rw,relatime,inode64)
overlayroot on / type overlay (rw,relatime,lowerdir=/.overlay/ro,upperdir=/.overlay/rw/root,workdir=/.overlay/work/root,uuid=on)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=6838)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=32504780k,nr_inodes=1048576,inode64)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=6500952k,nr_inodes=1625238,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

so it has done SOMETING but i am just to inexperienced (allright stuiped) to know if this is what i wanted or if there is more i need to do.

To the rest that have awnserd me
Thankyou!
i have tought about a VR machine but i havent fiddled around with that in linux and i have a enougf headache trying to do this with out otherstuff that can breakdown.

i dont know anything about BTRFS and i think i will try out overlayroot as far as i can before trying to learn more.

I apologize too - I didnt’t think it could be offensive - I have never touched on overlays - I have wanted to but not had the time - so I just read and tried to translate it to something meaningful for myself and hopefully for you.

Sorry, i came out a bit more defencive then i tought. in my defence if you do read some other linux forums they tend to (not all) really chew you up if you dont have compiled it, write the program your self, found the error, and then why bother posting here at all. i was ready for someting like that and overreacted.

im going to take a look again at the link you posted. i really should not try and do these stuff while i am tired.
but i can be wrong, (i blame the ask ai) but what i have posted would work, would it not?

Overlayroot Configuration: The lines you provided describe the overlayroot configuration on a Linux system. This setup is commonly used in systems where you want to have a read-only root filesystem with changes written to a separate writable overlay. Let’s break down the two lines you provided:

    overlayroot-tmpfs on /.overlay type tmpfs (rw,relatime,inode64): This line indicates that a tmpfs filesystem is mounted on / with the overlayroot configuration. Tmpfs is a temporary filesystem that resides in memory and is used for storing temporary files.

    overlayroot on / type overlay (rw,relatime,lowerdir=/.overlay/ro,upperdir=/.overlay/rw/root,workdir=/.overlay/work/root,uuid=on): This line shows that an overlay filesystem is mounted on /. The overlay filesystem combines two directories - a read-only lower directory (lowerdir) and a writable upper directory (upperdir). Any changes made to the system are stored in the upper directory while the lower directory remains unchanged.

In summary, this configuration allows for a read-only root filesystem with any modifications being written to a separate writable overlay, ensuring that the base system remains intact and can be easily reverted to its original state.
``.

i have been running this till and from for a couple of days and while i still get a annoying error it does seem to be working as intended.
thanks all for the help

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.